text:
Discovery fails when both devices are locked

Describe the bug
I've been trying to see how the app works around the issue where an iOS app central cannot discover an iOS app peripheral on another device if they are both in the background (and/or the device is locked).
I did a lot of initial testing of this with an Apple sample project yesterday and could not find a way to make it work and am able to reproduce this problem with the COVID-19 app as well.
A few notes, I've had to make a few small mods to get the app running on my device to the point where it's actively scanning and broadcasting:

Disabled remoteNotificationManager.configure() in the app delegate to bypass Firebase
Faked registration by creating my own Registration, using the device advertising identifier as the UUID and a fake secret/SecKey.
Commented out the peripheral state restoration code in the broadcaster so my two test devices always appear as new devices to each other.

To Reproduce

Install app on two iOS devices. In my test I'm using an iPad and an iPhone.
Install the app on the iPhone, launch the app and make sure its working. Kill the app, turn on Airplane mode.
Install the app on the iPad, launch the app, make sure its working (I'm running this one attached to the debugger so I can watch the log output). Background the app (verify using logs) and lock the device.
Move out of range of the iPad with the iPhone, wake the iPhone up, disable Airplane mode, launch the app, close the app, lock the device.
Move in to range of the iPad and observe no log output - the didDiscover delegate method is not being called on the iPad.
Wake the iPad screen by pressing the home button - the didDiscover delegate is called and it springs to life.

Expected behaviour
This was the behaviour I expected based on my previous testing however I was lead to believe that a way had been found around this limitation.
My understanding of the problem is thus:

iOS apps acting as a peripheral do not broadcast their service UUID in the advertising packet while they are broadcasting in the background. The service UUID is stored in an "overflow area" to quote the Apple docs.
iOS apps acting as a central can only find other iOS peripherals by scanning for a specific service UUID if when they are running in the background - because the other device is not broadcasting it's service UUID, it doesn't find it.
If either app is in the foreground, the connection is made - either the central is in the foreground and is able to find the peripheral without relying on the service UUID being advertised or the peripheral is in the foreground and is broadcasting it's service UUID so the backgrounded central can find it.

Smartphone (please complete the following information):
I'm using an iPhone XS and an iPad mini 4 running the latest version of iOS 13.
EDIT - some further detailed scenarios below.

I appreciate my testing of this is limited at the moment and would be grateful if anyone else is able to reproduce. I've pushed the branch I was running with my small modifications to a fork which might make it easier for people to get up and running:
https://github.com/lukeredpath/COVID-19-app-Documentation-BETA/tree/mods-to-run-on-local-device
You might still need to copy the example GoogleService-Info.plist file to .secret/, update the team ID and configure provisioning.

Hi - not sure how helpful this might be to your particular question, but this article goes into detail about the technical details and workarounds used in the app: https://reincubate.com/blog/staying-alive-covid-19-background-tracing/

Sadly I don't think the above article really addresses the core issue. I've heard some suggestions that it might be relying on the Android app to wake iOS apps up but I'm not convinced that would work - even if an Android app connects to the iOS app (which is running in the background), it won't bring the app to the foreground, iOS will wake the app up in the background briefly (for about 10 seconds) and the device will of course remain locked.
Not ruling it out - I don't have an Android device to test this theory, but if this is the case then it seems like a pretty shonky workaround.

I worked on a similar problem a couple of years ago and saw similar behaviour to what you're describing. Apple are very strict on restricting this kind of stuff so I'd be amazed if a trivial workaround could break this. Having said all that, a practical test beats all else (so kudos to original poster). Someone else needs to repeat this test to add more data points.

I believe they have a workaround which is feasible for use in the wild. We're writing it up now!

Some quite interesting stuff around how they might be getting around the background iOS restrictions can be found in the Android source.
Looking at the Apple documentation on background peripheral bluetooth, they state "All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them"
I wonder if they have managed to reverse engineer this overflow area so it is accessible via Android?
Someone did some looking into this and it seems at least feasible: https://crownstone.rocks/2018/06/27/ios-advertisements-in-the-background
Will be very interesting to see if we can get some more details on how this operates from the developers.

It definitely appears to be the case that they're using Android to bypass this feature, but the key question remains: what happens if two iOS devices, both locked (inactive) encounter each other when there are no android devices in the vicinity

Yes, based on that comment in the Android source and the Crownstone stuff which I was reading yesterday, it does seem like it is possible for Androids to detect the iOS app even if its in the background (although we're all aware of the risks in relying on reverse-engineering a private, undocumented implementation detail like this).
Whether or not an Android device connecting to a background iOS peripheral on a locked device is enough to make that device visible to other locked iOS devices is what I'm not convinced by, until somebody can demonstrate it working and explain how it's doing it.

Just a thought having read a bunch of threads on Twitter about this. Anyone trying to reproduce this must absolutely account for a) new devices finding each other (the OPs point about peripheral state restoration and b) finding each other when both devices are locked before coming into range.
I think it would be very easy to get false positives if you're testing with devices which had already discovered each other (even in a previous test).
The gold standard is: can two locked iOS devices find each other when they come into range for the for first time.

I've continued to do some testing and I'll try and capture this on video tomorrow, but these are the scenarios I've tried. Interestingly it looks like there's more to this than the apps simply being in the background but it could also be related to the power state of the device.
In all scenarios I am starting with the following test conditions:

The iPad app is running with the peripheral state restoration code in ConcreteBTLEListener commented out - the behaviour I'm seeing only seems to occur if two devices have not seen each other. If they have seen each other the central restores them from cache during state restoration (I don't know when this expires). I'm aware that this source code modification potentially invalidates these tests, but I think it's a reasonable assumption that doing this is equivalent to using two devices that have never seen each other before.
The iPad app is connected to Xcode so I can observe the logs.
The app on my iPhone is not connected to Xcode and at the start of each test I ensure that a) the app is running and b) my phone is in Airplane mode.

Scenario 1: App on Device 1 is in foreground, Device 2 app is in background

Launch the app on the iPad from Xcode, observe it is I the foreground.
Unlock my iPhone and turn off Airplane mode.

Result: iPad discovers the iPhone immediately.
### Scenario 2: App on Device 1 is in background (screen on), Device 2 app is in background (screen on)

Launch the app on the iPad from Xcode, press the home button and wait for log output to confirm app is in background mode.
Unlock iPhone and turn off Airplane mode.

Result: iPad discovers the iPhone immediately.
### Scenario 3: App on Device 1 is in background (screen off), Device 2 app is in background (screen on)

Launch the app on the iPad from Xcode, press the home button and wait for log output to confirm app is in background mode.
Lock the iPad.
Unlock iPhone and turn off Airplane mode.

Result: iPad does not discover iPhone (waited for up to 2 minutes keeping iPhone screen on throughout).
After waiting to see that the devices do not discover each other, discovery can be triggered immediately in one of two ways:

Launching the app into the foreground on the iPhone (iPad still locked)
Waking the iPad by pressing the home button to turn the screen on. This works with the iPhone both awake and locked.

In my earlier testing the above scenarios behaved the same if instead of using Airplane mode, I went out of range before launching the app on my iPhone and then came back into range. I'm using Airplane mode for convenience here so I don't have to walk up and down my driveway all night.
So it seems clear to me that the issue isn't solely related to the apps being in the background, but also to do with whether or not the screen is on. Some potential confounding variables that could be throwing off my tests:

I'm using an iPad to test instead of iPhones (an iPad mini 3). Could there be something different about the Bluetooth stack and power management compared to an iPhone?
Could the iPad being tethered in some way affect the behaviour?
Would the results be different if I were to swap the iPad and iPhone in the above scenarios?
Could the removed state restoration code be affecting this test, as noted above?

Would be great if somebody fancies reproducing my tests above with two iPhones.

I have had strange behaviour in the past with background behaviour while using Xcode to read logs.
I did discover that the app has a debug screen that allows you to see logs while not connected to Xcode. If you shake the device you will get a development menu with a number of useful options.

Good spot - just tried scenario 3 untethered from Xcode - I put my iPhone back on Airplane mode again before unlocking the iPad, launching the app and using the debug screen to send the logs to my iMac. Log output confirms the same result.
It also sends over the contact events in plist format so I thought I'd take a look at that with a clean slate.
Deleting the app and re-installing on my iPad was also useful as it seemed to clear the cached state restoration data which means I was able to run the test with the state restoration code intact. I observed the same behaviour as before, here's a snippet of the log from the point I backgrounded the app:
23:40:04 info: Application AppDelegate.swift:183:applicationWillResignActive(_:) – Will Resign Active
23:40:05 info: Application AppDelegate.swift:194:applicationDidEnterBackground(_:) – Did Enter Background
2020-05-07 23:40:05.943201+0100 Sonar[784:192358] Can't end BackgroundTask: no background task exists with identifier 2 (0x2), or it may have already been ended. Break in UIApplicationEndBackgroundTaskError() to debug.

**** TURNED OFF AIRPORT MODE ON MY IPHONE HERE ****

23:40:18 error: Registration RegistratonService.swift:94:register() – Registration did not complete within 20.0 seconds
23:40:18 error: Registration RegistratonService.swift:177:fail(withError:reason:) – Registration failed: Sonar.(unknown context at $100eef8ac).RegistrationTimeoutError
23:40:18 info: BTLE BTLEBroadcaster.swift:217:peripheralManager(_:didReceiveRead:) – responding to read request with empty payload
2020-05-07 23:40:18.836045+0100 Sonar[784:192428] [AppCenter] WARNING: -[MSChannelUnitDefault enqueueItem:flags:]_block_invoke/141 Channel Analytics disabled in log discarding mode, discard this log.
23:40:19 info: BTLE BTLEBroadcaster.swift:217:peripheralManager(_:didReceiveRead:) – responding to read request with empty payload

**** TURNED ON AIRPORT MODE ON MY IPHONE HERE ****

23:42:16 info: Application AppDelegate.swift:198:applicationWillEnterForeground(_:) – Will Enter Foreground
2020-05-07 23:42:16.524522+0100 Sonar[784:192438] [AppCenter] WARNING: -[MSChannelUnitDefault enqueueItem:flags:]_block_invoke/141 Channel Analytics disabled in log discarding mode, discard this log.
23:42:16 info: Application AppDelegate.swift:187:applicationDidBecomeActive(_:) – Did Become Active

As you can see there's no discovery messages in the logs and on inspection the contactEvents.plist file was empty.

As promised, here is the blog post explaining how the iOS <-> iOS workaround works. https://reincubate.com/blog/nhs-covid-19-background-tracing-details/
Should hopefully explain the behaviour you’ve been seeing.

If I'm reading your blog post right, you're saying that, in order for scenario 3 in my tests above to work effectively it requires either:

Existing proximity to an Android device or,
Existing proximity with an already established connection to another iOS device?

If this is the case, that still means the scenario where any two iOS users with their phones locked in their pockets, who have not seen each other before and who are not in range of any Android devices, will still fail?
Also, if the issue seems related to the screen being off more than the app being in a background/suspended state, then where does that fit in to this?

Providing the device has a managed to establish a connection with any device (whether it be Android or iOS), it appears as though the device is able to effectively poll as though it is in the foreground even when the device is locked.

If this is the case, that still means the scenario where any two iOS users with their phones locked in their pockets, who have not seen each other before and who are not in range of any Android devices, will still fail?

This would depend on the time it last saw an Android or iOS device, because there is a grace period before the app is suspended again (and thus falls back into limited BT-polling mode)

OK, I will re-test scenario three with a third device tomorrow. Is this what you'd expect to see?

iPad app in background, screen locked.
Turn off Airplane mode on iPhone 1, leave app in background - discovery fails as per the above test.
Turn off Airplane mode on iPhone 2 - still no discovery of this one yet.
Bring app on iPhone 2 into foreground - iPad should discover iPhone 2 and iPhone 1?

So what happens with the app if no android devices are around to wakeup?

@lukeredpath I’m not sure what I’d expect to see under those scenarios at the moment if I’m honest as I’m exhausted and got a headache. I’ll get back to you in the morning, but hey there’s no harm in trying.

@Jeff-Stelling and there’s no other iOS devices around for it to talk to? The device would go silent until woken by an Android device

For those interested in how the keep-alive works, it's effectively a ping-pong between the central/peripheral running on each device:

After discovery, the central on each device subscribes to changes in the keep-alive characteristic of the other device's peripheral.

Device 1 central (the listener) gets an RSSI ping from Device 2's peripheral and triggers the didReadRSSI delegate callback.

Device 1 uses the above ping as a trigger to update the value of its the keep alive peripheral characteristic.

Device 2 is notified of the change to Device 1's keep-alive value and triggers the didUpdateValueFor delegate callback where it in turn triggers an update of its keep-alive characteristic.

The above process also happens in reverse, with Device 2 updating the its keep-alive value when when it gets an RSSI ping from Device 1 and Device 1 updating its keep-alive value when it receives the updated value from Device 2.

There's some throttling in place to ensure each device only updates it's keep-alive value no more than every 8 seconds.

OK, so if I understand correctly iOS needs a connection from another device, either an active iOS or Android to keep it alive for a bit. And the theory is that there will be enough foreground iOS/androids to keep things going?
But, if I walk into a shop and there are zero Android devices and zero foreground iOS devices, it won't work?
Also, isn't there some limit to the number of concurrent connections you can make with Bluetooth (https://stackoverflow.com/questions/13469502/maximum-number-of-peripherals-on-corebluetooth)

What happens when Apple fix this bug that allows Android devices to wake background processes on iOS, this is clearly a battery drain and should be fixed?

What happens when Apple fix this bug that allows Android devices to wake background processes on iOS, this is clearly a battery drain and should be fixed?

Yeah, if only Apple and Google had provided a proper solution to this problem ...

What happens when Apple fix this bug that allows Android devices to wake background processes on iOS, this is clearly a battery drain and should be fixed?

Read through this thread, the whole time thinking exactly that. Surely Apple are gonna close the workaround.

If Jamie is right then it’s not just Android devices that are the key to this - the idea is that any other device actively scanning for the service UUID should in theory wake the locked device - so Android devices or other unlocked iPhones. I don’t have any Android to test but will test this with an unlocked iPhone later.

It's not a "workaround" or "bug{, it's using a legitimate Apple Framework that allows your app to function as a peripheral.
This functionality is not limited to use by Android phones, it's also used by other iOS devices (where the app is running in the foreground) to detect the advertising iPhone . Hence why an iOS app that is open can also act as a bridge between two devices where the app is in the background. "Fixing" this could break many other apps that use this for good reasons.
The difference is in how iOS chooses to advertise services (requiring an extra step to discover them) and how it scans for peripherals in foreground (taking the extra step) vs background (just passively listening without taking the extra step).

Of course the Exposure Notification framework from Apple and Google fixes this by advertising the relevant service without requiring any extra steps to discover it. The method is uses to do this is not available for regular apps.
Since the privacy preserving features from that framework or not compatible with the backend architecture of the NHS it will not be useable however for this app.

@thoutbeckers it absolutely is a workaround if you're using an API in the manner that the owners didn't intend. I can't believe Apple intended the peripheral API (something intended for communicating with devices) to be constantly scanning in the background. If they did, they wouldn't have put in the restriction in the first place. Apple absolutely don't care about breaking existing apps if they feel the user experience of their customers (battery life, security) is an issue.

Firstly, a good way to understand the behaviour of the App is to use PacketLogger in Xcode, connect to one device (must have Bluetooth profile installed), and filter on "85bf" (the start of the identifier characteristic, which must be read when one device is discovering another). In this way you can determine if the released App is working in a given scenario.
If there is an Android in range it will wake the iOS App most of the time (unless advertising has been stopped by iOS, although this seems unlikely in the real world). However, it seems there is a bug in this which will prevent the Android App discovering iOS devices that have multiple background advertisements. This is the way backgrounded advertising in iOS works, and preventing it would mean breaking the functionality between iOS devices. But I could see Apple going this far, because they are very careful about this stuff.
My testing showed that the one scenario it won't work is when there are only iOS devices in range and screens are off. Even tapping the screen to wake it is sufficient for the devices to communicate. People use their phones a lot, and there is probably an Android phone around most of the time, but this is one place where it will fail some of the time.
Another scenario is if the screen is on and the App has been in the background for a long time (>1h50m, perhaps overnight) then it will not reconnect to another backgrounded iOS device. There must be no Android phones in range for this to occur. I witnessed this with two iOS devices with the App were in range overnight. Presumably this is because the screens were off and so the Apps were not able to discover and connect to each other, so eventually the iOS background scanning/advertising timeout was triggered. If either device had been woken up before the timeout it may have been sufficient to refresh the App. iOS seems to give it 6540 seconds (1h50m) of background advertising time.
In summary it might work "well enough", but some contacts will definitely be missed. Will they accept that and continue anyway because the data they can obtain is "more useful"? Or will they switch to the Apple-Google model being standardised in several other countries in Europe? It seems like they may be reconsidering their position...

@jdmwood2 That's true, but unintentional usage of an API would lead to an Appstore rejection, not a removal or "fix" of that API.
There are many (especially -but not only- background related) APIs that can be abused. You have to opt-in to them to use them, after which Apple is supposed to review if your usage is justified.
Apple seems to have chosen to allow this usage. Of course they can change their mind at a later point.

@thoutbeckers I've found Apple's approval process to be mercurial and inconsistent so under normal circumstances I wouldn't count on passing being a tacit appribal. Having said that, this a high profile app so we'd hope they'd dig a bit deeper then usual. And yes, they might change their mind either intentionally or as a side effect of unrelated fixes

Apple of course have regularly approved apps only to reject them in a subsequent update.
I think it’s reasonable to say that the background peripheral functionality is being used in a way that is unintended - whether you’d go as far as saying it’s being misused or abused is down to Apple.
The background execution guide clearly states that a background app acting as a peripheral does not broadcast its service UUID in the advertising packet and is therefore only intended to be discovered by other iOS devices actively scanning for that service UUID (in the foreground). The fact that this keep-alive and the reverse engineering of the advertising packet for Android is necessary shows it’s not really intended usage - iOS apps aren’t really intended to spend all day advertising and scanning for others.

It’s also true to say that using the exposure notification API that Apple are working on is t a “fix” for this problem except for in a roundabout way. This could only be used with a complete switch from a centralised to a decentralised model which is a bit more work than simply swapping our the Bluetooth code. The two approaches are fundamentally incompatible with each other.

From Apple's docs:

Apps should be session based and provide an interface that allows the user to decide when to start and stop the delivery of Bluetooth-related events.
Upon being woken up, an app has around 10 seconds to complete a task. Ideally, it should complete the task as fast as possible and allow itself to be suspended again. Apps that spend too much time executing in the background can be throttled back by the system or killed.
Apps should not use being woken up as an opportunity to perform extraneous tasks that are unrelated to why the app was woken up by the system.

This App seems to fall foul of all of these, because of the keep alive mechanism which is an extraneous task that is unrelated to the reason it was woken up. But Apple does use its descretion with some Apps, and turns a blind eye. Particularly in this case you could see them continuing to let it slide unless it is having a significant impact on battery life. I imagine they will be actively testing that now.

Rejecting you or me with a poorly written brief note is not something that will happen to the NHS I imagine. Also, it's pretty much known they are in contact, I can hardly imagine this being unknown to Apple.
I would more worry that the technical solution itself is far from sufficient. It's reliance on connecting devices (rather than just scanning them) will easily work in testing a situation with a few devices, but will likely fail with dozen of devices around you. Android devices will not properly handle dozens of simultaneous connection requests.
The lack of any support/documentation for automating testing such a scenario in the client strongly suggests to me it has not been done.

@nrbrook good to hear somebody else has been able to reproduce the third scenario in my testing above - it definitely seems related to a combination of the all being in the background and the device power stage. Were you testing on two iPhones? If so that rules out any possibility of me using an iOS affecting the test.
The issue with the advertising stopping completely after a period of time is concerning - it’s not something I’ve tested for but seems like yet another potential issue that could lead to missed exposure events.
Ultimately none of us can be sure how big of an impact this will have on the reliability of the overall process without real world testing - nobody has done this before. I’m just concerned that by that point it’s too late and any goodwill you might have had with getting the public to use this will be lost.
If they pull the plug on this app later and go with the decentralised approach (which isn’t without its challenges either) will it be too late to make a difference?

@lukeredpath I was testing with iPads and an iPhone, but I don't think the iOS background implementation is any different on iPad vs iPhone.
It is difficult to do "real world testing" with this, even in a small area like the Isle of Wight, even if you can get a good proportion of the population to install it, and even if people are still not too scared to go outside for the test to be useful. @thoutbeckers They could and should be doing automated testing yes, although perhaps have simply not had the time yet.
Ultimately this is a hacky solution and nothing is going to beat using Apple-Google's solution in terms of reliability. They are taking a real risk trying to roll their own, particularly if they are putting any kind of weight on it working successfully. However I would imagine they could just swap out the entire Bluetooth infrastructure in the current App with the Apple framework if (when?) they decide that will be a better route, so users would not need to install a different App.

So to summarize this thread NHSX have spent a month with GCHQ's help building a series workaround/hacks to the iOS <-> iOS backgrounding issue hoping Apple will keep them a pass on background/keep-alive abuse (which they'll probably get) but without actually solving the problem? Anyone who's actually tried to build a cross-platform (iOS + Android) Bluetooth based app (I have) could have told them this right from the start and I'm sure the GCHQ engineers did.
Knowing this they've then assumed they'll get still mass adoption on something storing every UK citizen's data centrally and whilst also reducing battery level on their phones?
At least someone seems to have finally seen sense:
https://www.theguardian.com/technology/2020/may/07/uk-may-ditch-nhs-contact-tracing-app-for-apple-and-google-model
but the mind actually boggles at decision making process on this project.
Please give up on the workaround / hacks and switch to the Apple + Google API's - the app may have half a chance of a) working reliably in the first place and b) being adopted.

So to summarize this thread NHSX have spent a month with GCHQ's help building a series workaround/hacks to the iOS <-> iOS backgrounding issue hoping Apple will keep them a pass on background/keep-alive abuse (which they'll probably get) but without actually solving the problem? Anyone who's actually tried to build a cross-platform (iOS + Android) Bluetooth based app (I have) could have told them this right from the start and I'm sure the GCHQ engineers did.
Knowing this they've then assumed they'll get still mass adoption on something storing every UK citizen's data centrally and whilst also reducing battery level on their phones?
At least someone seems to have finally seen sense:
https://www.theguardian.com/technology/2020/may/07/uk-may-ditch-nhs-contact-tracing-app-for-apple-and-google-model
but the mind actually boggles at the decision making process on this project.
Please give up on the workaround / hacks and switch to the Apple + Google API's - the app may have half a chance of a) working reliably in the first place and b) being adopted.

An admirably succinct summary.

@sanvean yes, it seems that way. I imagine the engineers got excited about the prospect of trying to hack around limitations, and politicians wanted the data, and nobody was pragmatic enough to say "Is this actually going to save lives?"

Too busy asking themselves ‘can we do this’ and never stopped to ask, ‘should we do this ?’

I understand the lust for the data as I imagine it’ll be incredibly useful. In my opinion it’s usefulness doesn’t outweigh the risk of sacrificing users privacy. I don’t believe privacy should be a commodity and the longer we allow it, the worse it’ll become.

@sanvean yes, it seems that way. I imagine the engineers got excited about the prospect of trying to hack around limitations, NCSC just focussed on the security aspect, politicians wanted the data, and nobody was pragmatic enough to say "Is this actually the best way to save lives?"

Yeah I'm sure some hubris mixed in with the classic tech mindset of there's got to be a workaround along with no doubt some key decision maker somewhere objecting to be told what to do by Apple + Google (I wager that was a politician though not the development team).
No doubt that Big Tech currently hold far too much sway and power in the modern world but is right here, right now really the time to tackle that problem?

@sanvean Nobody was looking at the big picture, but focussed instead on their own world of minutiae. Here, the fact there were only two players in the mobile space meant that they could come together and quickly deliver a solution. Thankfully the solution they have developed is privacy preserving. Ideally, this should have had democratic oversight too, because Apple and Google are effectively dictating how one of the main mechanisms out of this crisis will work for the whole world.

I’m a bit concerned the thread is going a bit off-topic - I appreciate the discussion around whether or not the centralised approach and rolling their own was the right approach to take is an important one to have but would be good if we could keep this issue focussed on the technical problem raised.

Hi Luke,
Yes I guess it has but the issue is that there isn't a reliable solution to the problem you've identified (even keep-alive workarounds) which is exactly why other countries have abandoned this approach. It's not actually a debate on the centralised vs. decentralised approach - the discovery method will not work reliably for iOS <-> iOS background discovery.
Apologies if I'm coming across as strongly opinated  on the topic, it's because a) I have actually built an app attempting to solve a similar problem cross platform (think Happn but using Bluetooth) and b) my mother is currently working on the NHS Frontline and directly impacted by the decision making on this project.
Anyways, I very much appreciate the effort here by you on investigating the app in-depth and highlighting this technical issue to the dev team, as I was planning to spend today doing the same now the code was open source as I couldn't believe they'd figured out a way to solve the problem unless Apple had changed something - they haven't based on your analysis.

Thanks - your input has still been very helpful. I’m still hopeful we might get some input from either the devs or decision makers on this issue - if the code is going to be open-sourced this way then it has to be expected that people will raise issues for discussion and I hope that they are able to engage with us.

Thanks - your input has still been very helpful. I’m still hopeful we might get some input from either the devs or decision makers on this issue - if the code is going to be open-sourced this way then it has to be expected that people will raise issues for discussion and I hope that they are able to engage with us.

I couldn't agree more and I applaud your efforts here. However, if there is no real response or solution presented in the coming days I honestly think this thread will need to be published or shared more widely until it does receive the attention it deserves.
This is not a normal Issue you have raised here, the UK's economic recovery and lives are at stake. The app needs to work reliably in all common circumstances and as you have clearly highlighted -it doesn't currently.

Thanks to everyone for their hard work looking into this. It was one of my biggest questions when I heard about the app so it has been great to see everyone dig into the code and piece it together.
I put together a quick matrix showing the possible situations and where it works/doesn't work based on this issue. Does it look correct? I was getting a bit confused with all the possible scenarios, hopefully if it is correct then it will be useful for other folks to understand the limitations.

Nice work all!
I would also just add that beyond the fact that the app definitely seems to not work in the above matrix (nice summary @stephenheron ), it's also worth challenging whether it will work in practice even for the green blocks in that matrix.
I've tried to capture my thoughts in a comment in #7 (not sure if that was the best place). But in brief, will using devices as a peripheral actually work when there are dozens of devices all making concurrent connections with each other (sounds like a exponential problem to me). Will my device stop connecting if > N people are nearby? How will ancient Android devices loaded with manufacturer bloatware cope?

I think Android (Foreground) vs iOS (Background) is Y in first column, also debatable whether Android (Background) vs iOS (Foreground) is a workaround you as just depend on the Android device discovering the iOS Device it should work pretty reliably.
Bottom right is the Workaround/Non-Reliable box. As I understand it if an Android device is near 2 backgrounded iOS devices it can wake them up to discover them.
https://www.theguardian.com/world/2020/may/06/critical-mass-of-android-users-needed-for-success-of-nhs-coronavirus-contact-tracing-app
However say 2 random people with backgrounded iOS devices decide to sit next to each other on a park bench with no-one else around, the devices can't discover each other reliably.

Just a thought - could it be kept alive by doing something, e.g. playing blank music?

Nice work all!
I would also just add that beyond the fact that the app definitely seems to not work in the case shown in the above matrix (nice summary @stephenheron ), it's also worth challenging whether it will work in practice even for the green blocks in that matrix.
I've tried to capture my thoughts in a comment in #7 (not sure if that was the best place). But in brief, will using devices as a peripheral actually work when there are dozens of devices all making concurrent connections with each other (sounds like a exponential problem to me). Will my device stop connecting if > N people are nearby? How will ancient Android devices loaded with manufacturer bloatware cope?
The peripheral API was not presumably designed for this, unlike, say iBeacon (though as others have pointed out, that would still suffer from even worse iOS backround issues).

For iOS there is a concurrent limit not sure on Android:
https://stackoverflow.com/questions/13469502/maximum-number-of-peripherals-on-corebluetooth
If the iOS Bluetooth code is well written you should still be able to cycle through a higher number of devices quickly it's just a concurrent connection limit. Not sure what happens when you put several hundred devices close together (but I'm sure that what's Apple and Google will have been testing and optimising for in the last month, hopefully NHSX too).

@sanvean in my experience having done similar stuff for a startup, reality doesn't often match theory. As you say, let's hope NHSX have done scientific tests to validate precision/recall in realistic situations and not just said "works in the lab so should be fine". Not sure the Devs have released any info on how they have/are/will validate the accuracy.

Thanks to everyone for their hard work looking into this. It was one of my biggest questions when I heard about the app so it has been great to see everyone dig into the code and piece it together.
I put together a quick matrix showing the possible situations and where it works/doesn't work based on this issue. Does it look correct? I was getting a bit confused with all the possible scenarios, hopefully if it is correct then it will be useful for other folks to understand the limitations.

It's not quite as simple as iOS (background). It does work with both devices in the background without workarounds if the advertising timeout has not occurred and the user has not quit the App.

Just a thought - could it be kept alive by doing something, e.g. playing blank music?

You could but you'd have to convince Apple why you needed the "play audio" permission. Again, maybe they'll allow this under the circumstances

I have summarised my findings and understanding so far in this blog post https://www.nrbtech.io/blog/2020/5/8/understanding-the-nhs-contact-tracing-app
I will continue to attempt to understand when the advertising timeout is reset.

The matrix is close but in my observations the screen being off is also a key variable - see the scenarios tested above.

Just a thought - could it be kept alive by doing something, e.g. playing blank music?

This would almost certainly fall foul of App Store rules.

I have summarised my findings and understanding so far in this blog post https://www.nrbtech.io/blog/2020/5/8/understanding-the-nhs-contact-tracing-app
I will continue to attempt to understand when the advertising timeout is reset.

Small correction to your post - there is a local notification scheduled to ask the user to relaunch the app. It’s scheduled in the willTerminate app delegate method though and I’m not sure how reliably this will work. It seemed to work consistently for me when I manually killed the app.

Just a thought - could it be kept alive by doing something, e.g. playing blank music?

This would prevent the app from working while using another app to play music?

@lukeredpath @nrbrook Thank you for the feedback on the matrix, I have added a new column for "iOS Worst case scenario" to try and cover things like "Screen off, App Killed, Advertising window expired. Do we think that more accurately describes what we are seeing? Once an iOS device falls into this "Worst case scenario" can any bluetooth iteraction bring it back into life or does a user need to unlock their device for example?

It's not quite as simple as iOS (background). It does work with both iOS devices in the background without workarounds if the advertising timeout has not occurred and the user has not quit the App, as long as the process is running.

This is a bit of a semantic discussion that occurs on this topic. It's true while running in the background it will detect it. But "background" for most people colloquially stands for suspended in the background. Passive scanning will still work while suspended, but not for other iOS devices also suspended in the background, even within the advertising timeout. This is confirmed by the tests people have done.
To complicate things further, there is a narrow case I've not tested (I've not tested this app specifically as others have) where both iOS devices support extended advertising (a Bluetooth 5.0 feature). As far as I know that's only the  iPhone XS, the latest iPad Pro, and I assume the new iPhone SE. Apple kind of promised this would work, but I've not seen that confirmed.

@stephenheron I'd split it into iOS (process running in background), iOS (advertising before timeout) and iOS (not advertising). The first column would be the same as iOS (Background). The second column is "maybe" for all other device cases, because there is no guarantee about advertising or scanning frequency (I can see advertisements go up to 5 minute intervals). The third column is "no" for all.

To complicate things further, there is a narrow case I've not tested (I've also not tested this app specifically as others have) where both iOS devices support extended advertising (a Bluetooth 5.0 feature). As far as I know that's only the iPhone XS, the latest iPad Pro, and I assume the new iPhone SE. Apple kind of promised this would work, but I've not seen that confirmed.

I am testing with the iPhone 11 Pro and an iPad pro which are sending extended advertisements, but I don't think this changes anything.

@stephenheron an unqualified statement that iOS background <-> iOS background works (green) is disproven by the original post in this issue. Regardless of the advertising timeout. But this is also disproven by every other non-Apple/Google tracing app (dp3t, TCN, etc) I know of.
All the tricks in the code are to unsuspend the app using an external source (like an Android device being nearby), but the "natural" state when in the background is that the app is suspended, only passively scanning, and unable to detect other iOS app suspended in the background.

@thoutbeckers IIRC this investigation seemed to suggest that some active scanning still seemed to work during the timeout: https://reincubate.com/blog/nhs-covid-19-background-tracing-details/
(I'm not 100% sure this is in fact what they're saying. Perhaps @jamiebishop can clarify?)

@thoutbeckers The App does work in the background on two iOS devices. I can see this by putting the app in the background and then toggling bluetooth on one device and watching for the data sent between the devices on the other device.

Our observations were that the app worked in the background for iOS <-> iOS devices after ~30 minutes of not seeing each other.

@nrbrook and you're sure you've accounted for the fact that the devices weren't already familiar with each other?
The acid tests is two background iOS devices which have not discovered each other yet, coming into range for the first time while still being in background. That is the realisatic situation of users walking past each other m

There are of course failure cases, but in our experience, it should work fine if enough people use it.

@jdmwood2 Yes – removing and reinstalling the App should simulate this. Doing that while bluetooth is off, and then enabling bluetooth while the App is in the background I can see that the other device with the App in the background does discover it.

@jamiebishop do wake-ups propagate as a network effect? E.g. if my iOS device is "woken" by an Android device, but is still in background, assuming it's alive for the timeout period can it wake up other background iOS devices, and those can keep alive others and so on?

I assume you have the screen on when you toggle Bluetooth @nrbrook
The evidence is either replicating the actual user situation as described by @jdmwood2 , or for a technical proof an HCI packet dump of an iOS device with the screen of, and the app suspended in the background showing it's somehow  advertising the service id or some other information that wakes up the second device, or another iOS device with the screen off and the app suspended requesting doing a scanrequest for a scanrecord with the additional service information.
AFAIK no one disputes there are many tricks are in the codebases to try and take advantage of some deviation of that test scenario, but that's what they are.

@jdmwood2 I haven’t had a chance to test that and I don’t think I will. Unfortunately I’ve got to move onto other work now, but I’m sure someone here probably will try that out.

My concern here is that even if it can be shown that background works under certain circumstances (and I feel like this is still under debate in this thread), I'm far from clear whether it works under realistic situations. And this question is important: the media message in many publications is "background works on iOS". If that is based on some simple lab experiments for which we've only heard second hand reports, it not hugely reassuring (@lukeredpath work is the first which seems to go into detail and with code). I would love to hear from the developers exactly when they think it should work and how they verified that.

There are of course failure cases, but in our experience, it should work fine if enough people use it.

Failure cases that are completely avoidable if NHSX choose to use the new APIs Apple + Google are providing rather than relying on iOS background grey areas and/or hoping an Android device happens to be in vicinity when two backgrounded iOS device meet each other.

@sanvean iOS 13.5 isn’t even available yet, and may not be for another week or two. NHSX are ready to ship now.
Multiple media reports already point to the fact that they’re investigating moving. This is probably a fine solution in the meantime

@sanvean iOS 13.5 isn’t even available yet, and may not be for another week or two. NHSX are ready to ship now.
Multiple media reports already point to the fact that they’re investigating moving. This is probably a fine solution in the meantime

I think we'll have to disagree on the definition of fine here, there's common real world interaction where the app does not function as intended or as people will expect it to based on media reports. For example amongst my family + friends in London I don't actually personally know a single Android device owner. I'm a minority? Yes but a significant one in a major global Coronavirus hotspot.
As mentioned in my original comment above this iOS <-> iOS Background detection issue is well known to any developer who has built a half decent iOS Bluetooth app. The dev team will have known this a month ago and they could have decided to switch over to Apple / Google API's sometime ago after some basic due diligence rather than sticking to testing and rolling out this ultimately flawed approach.
Also while NHSX may technically ready to ship now but I doubt parliament will let them ship this out in its current state given the separate privacy issues.

I agree with @sanvean. There is also a public trust issue: releasing an app which kinda works is not great even if it gets fixed in a few weeks. People may well be adjusting their behaviour assuming the app will give them some measure of protection (or at least clarity) and won't know that it might not be working at all for them. This is a huge deal for a health app.
The government will also get exactly one (1) go at this. If there is negative feedback for a month
due to battery usage or failure to work it's going to be hard to persuade people to try again because "now it works properly, we promise".

@jdmwood2 I agree, although I can see it does work in some specific test cases, it’s much harder to know how well it would work at an event of 50+ people. The theory looks ok but the practical usability of it is unknown and there is no guarantee they will get any good information about how well it has worked based on a limited study on IOW. How will they know if matches failed to be detected?
From what we know they have not started work on an Apple-Google decentralised solution yet (would seem sensible to be doing this in parallel) so we would be behind other countries if we decide to switch.

As mentioned in my original comment above this iOS <-> iOS Background detection issue is well known to any developer who has built a half decent iOS Bluetooth app.

Sure, but they have a workaround and we've observed it working. iOS 13.5 doesn't exist yet, so do you just want them to do nothing in the meantime?

Sure, but they have a workaround and we've observed it working under a lot of scenarios. iOS 13.5 doesn't exist yet, so do you just want them to do nothing in the meantime?

Yes! That it works in some scenarios is no comfort to someone who falls in the cracks of "not working" (I'm still not clear exactly when this would be. If it really is the iOS <-> iOS case - and I appreciate there is disagreement about that - then that is a huge hole).
Sometimes the least harmful act is to do nothing.

Just a couple of extra observations to add:

I know some other people have been testing this working based on observations of the device logs but it seems to me that just because bluetoothd might be doing some stuff on each device, it doesn't mean that its propagating up to the app layer in the form of a didDiscover delegate call - that's why I really wanted to test this with breakpoints/logging with the real source code.

One odd behaviour I noticed is that with the iPad app in the foreground, it would discover the iPhone app even if I manually killed the iPhone app. My understanding that terminating the app in this way would stop all Bluetooth advertising but it didn't seem to.

I know some other people have been testing this working based on observations of the device logs but it seems to me that just because bluetoothd might be doing some stuff on each device, it doesn't mean that its propagating up to the app layer in the form of a didDiscover delegate call - that's why I really wanted to test this with breakpoints/logging with the real source code.

I was watching reads from the characteristic - iOS wouldn’t do that on its own.

One odd behaviour I noticed is that with the iPad app in the foreground, it would discover the iPhone app even if I manually killed the iPhone app. My understanding that terminating the app in this way would stop all Bluetooth advertising but it didn't seem to.

This doesn’t match my observations, killing the app prevented it from working

Call me crazy, but perhaps we could improve the situation greatly by buying a load of cheap Android phones and putting them in key locations. An Android phone at a supermarket entrance that woke up all the iPhones is a lot better than relying on customers to wake each other.

Call me crazy, but perhaps we could improve the situation greatly by buying a load of cheap Android phones and putting them in key locations. An Android phone at a supermarket entrance that woke up all the iPhones is a lot better than relying on customers to wake each other.

Given one of the theoretical risks with a centralised model is re-identification and tracking of location through the use of a network of Bluetooth beacons, this would probably be a bad idea.

True, and I understand that, and I think it's worth it, but in this example your location is already known via your card payment.

Call me crazy, but perhaps we could improve the situation greatly by buying a load of cheap Android phones and putting them in key locations.

Also, then you run the risk of people who have never been in contact getting exposure notifications from each other, simply because there was a non-human Android device that linked them both

Good point, it would need an "I don't count" flag.

True, and I understand that, and I think it's worth it, but in this example your location is already known via your card payment.

That's a common misconception. Stores are banned by MasterCard and visa from using the card number for anything other than card payment. They aren't allowed to hash it and use that to link purchase to a single customer. That's what store loyalty cards are all about.

I didn't say stores did that. Just pointing out that an Android phone performing that specific function wouldn't be the only way for someone to know you were in a supermarket.

What happens when Apple fix this bug that allows Android devices to wake background processes on iOS, this is clearly a battery drain and should be fixed?

I think Apple would suffer a lot of bad publicity if they chose this particular time to make any changes to this area.

Hi all. Just to let you know, we are reading this thread carefully. One of the aims of the Beta is to see how this works in the real world.  We ran several test at RAF Leeming and updated the code based on that.
As we learn more about how this performs - we will get an idea of how likely people are to never see an unlocked iPhone and never see an Android phone. And all the other edge cases.
I want to thank you all for this illuminating, and well-mannered discussion. We're doing our best to get this right, and it's brilliant to see that so many passionate and committed people also care.
Have a great weekend.

@edent thanks for taking time out to keep us updated - it’s good to know that are concerns are being addressed.
This problem isn’t unique to the NHSX app of course. Competing frameworks like DP-3T will have the same Bluetooth issues (until they switch to the Apple exposure framework anyway).
It’s also not the only potential issue - nobody can be sure how effective Bluetooth will be at accurately determining proximity on a reliable enough basis in real world scenarios. Only time will tell with that one.

Thanks @edent. We hugely appreciate your input and from the sounds of things the app is well written considering the challenges you must have faced.
It would amazing to get details about the results of the RAF test and how it was measured. For example, did it simulate carriers of the virus and measure a precision/recall score for how well those carriers were detected by other phones?
Perhaps related to this is #7: a beta test in the wild is great but but how will you know how well it is actually performing? What would the ground truth be in the Beta and how do you plan to measure against it?
This particular issue (whether the iOS reliably detects) is important, but I think equally important is the broader question about how reliably detections are made overall (i.e. false positives vs. false negatives).
If, for example, the app regularly falsely detects someone who walked past me 20m away, then the fact that is reliably running in the background on iOS is a moot point.

The risk of releasing the app to the UK then being impacted by an iOS/Android update is worrying.
We know updates are coming as Apple/Google roll out their contact-tracing API. It's likely that these updates will change the way this issue works, presumably the whole world would have the same problem if they didn't change it somehow.
We know a substantial percentage of phones don't receive updates anymore, so both patched/unpatched devices need to be supported. We should do everything possible to improve the ecosystem for the next time we need it.

@billysielu, you make an important point about the incoming updates to iOS and Android.
This definitely needs to support as many devices as possible. If the contact-tracing APIs roll out and are adopted here and in the Android app, we need to make sure to keep the current tracing systems in here for older phones that do not receive patches anymore.
We also need to make sure that any security/other issues that arise in the current system are dealt with, even if the system changes to the contact-tracing API (to continue the support to older devices).

Really interesting thread, whilst I agree with the thoughts generally suggesting the contact-tracing APIs are the way to do, I have been trying to think outside the box on ways to improve the current app for now.
So, outside the box, Apple Watch. I'm not sure exactly what percentage of iPhone users have one but I believe it could be as high as 20% Source.
How about implementing a basic Apple Watch app with complications showing a green or a red symbol to confirm contact tracing is working to the user.
This could be done with a WatchConnectivity handshake to confirm the app is still ok every time the complication updates (usually every ~15 minutes). This will mean that:

The regular WCSession calls from watch will wake the iPhone app!
The user will be more engaged to keep an eye on the app.
The user will have a visual guide that the app is working correctly.

I appreciate 20% is by no means everyone, but it could be an important number of people to make the difference on the number of devices out and about that are awake. Implementing the app would also be fairly trivial and could be simply added on as an extra for those who want it and have an Apple Watch.
Thoughts?

OK, finally getting around to testing this scenario where a third device can potentially wake up two sleeping iOS devices - using my failing scenario 3 above as the starting point. I don't have any Android device so I'm using a second iPhone as the additional test device.
Initial setup:

A fresh install of the app on both iPhones - each one is built, run, set up (go through the activation screens), confirmed that the Bluetooth is working and scanning before killing the app and turning on Airplane mode. Neither iPhone is connected to Xcode.

A fresh install of the app on the iPad, connected to Xcode. Set up as above, confirmed Bluetooth is scanning and that it has not yet seen either iPhone.

Test process and results:

Close (not kill) the app on the iPad, confirm from logs that the didEnterBackground app delegate method has been called. Lock the device.

Unlock iPhone 1 and turn off Airplane mode. Confirm no discovery or any Bluetooth chatter happening on iPad from log output. Locked iPhone 1 - so far as expected.

Unlock iPhone 2. Turn off Airplane mode. As above, no discovery made or any Bluetooth chatter happening on iPad. The iPad has not seen either iPhone at this point. I cannot at this point confirm if the two iPhones have seen each other.

Bring the app on iPhone 2 to the foreground. Can confirm from iPad log that it has discovered iPhone 2 and is now sending the keep-alive ping-pong.

Crucially, the iPad has still not discovered iPhone 1.

Turn on Airplane mode on iPhone 2 again, I can see from the iPad logs that iPhone 2 has disconnected from the iPad. No further Bluetooth activity is seen.

Re-enable Airplane mode on iPhone 1 - note: waking up the screen to do this does not trigger discovery on the iPad.

With Airplane mode enabled on both iPhones I re-enable Wifi only (no Bluetooth), so I can safely use the debug menu on all three devices to upload the contact event file to my iMac to inspect them without invalidating the test.

I've included the contact events below, output from contactEvents.plist using plutil - each element in the root array represents a contact event with a single device:
iPad (locked):
[
  0 => "05485B5B-A0A2-D028-B39D-74EBFD79A4EF"
  1 => {
    "duration" => 16.20907604694366
    "rssiIntervals" => [
      0 => 0.1024460792541504
      1 => 1.082057952880859
      2 => 15.02457201480865
    ]
    "rssiValues" => [
      0 => -34
      1 => -59
      2 => -40
    ]
    "timestamp" => 2020-05-11 13:13:51 +0000
    "txPower" => 12
  }
]

iPhone 1 (locked):
[
  0 => "6D63FE18-70AF-A52E-A439-1C86173E3993"
  1 => {
    "duration" => 30.2186450958252
    "rssiIntervals" => [
      0 => 0.4501190185546875
      1 => 1.030978083610535
      2 => 7.027959942817688
      3 => 8.256847023963928
      4 => 13.45274102687836
    ]
    "rssiValues" => [
      0 => -46
      1 => -48
      2 => -51
      3 => -50
      4 => -51
    ]
    "timestamp" => 2020-05-11 13:13:50 +0000
    "txPower" => 12
  }
]

iPhone 2 (unlocked, app in foreground):
[
  0 => "C692F3FA-735C-4E5F-F081-20942CE88E99"
  1 => {
    "duration" => 64.41311502456665
    "rssiIntervals" => [
      0 => 1.257708072662354
      1 => 1.007640957832336
      2 => 6.151409029960632
      3 => 16.07540798187256
      4 => 39.92094898223877
    ]
    "rssiValues" => [
      0 => -47
      1 => -58
      2 => -60
      3 => -53
      4 => -41
    ]
    "timestamp" => 2020-05-11 13:13:51 +0000
    "txPower" => 12
  }
  2 => "5DD6B3F9-F01E-880F-E0E4-BA70E7FB77AE"
  3 => {
    "duration" => 24.76079702377319
    "rssiIntervals" => [
      0 => 0.4329550266265869
      1 => 1.080896019935608
      2 => 1.006325960159302
      3 => 6.165926933288574
      4 => 16.07469308376312
    ]
    "rssiValues" => [
      0 => -52
      1 => -47
      2 => -41
      3 => -53
      4 => -51
    ]
    "timestamp" => 2020-05-11 13:13:50 +0000
    "txPower" => 12
  }
]

Summary
What does this show:

iPad has recorded a single contact event for iPhone 2.
iPhone 1 has recorded a single contact event for iPhone 2.
iPhone 2 has recorded two contact events, one for the iPad and one for iPhone 1.
The iPad and iPhone 1 have not recorded a contact event for each other, nor is there any sign in the logs that either discovered the other one.

On the basis above, it seems to me that the theory that another actively scanning device (in this case another iPhone with the screen unlocked and the app in the foreground) will cause two sleeping devices to see each other is false. It may still be the case that an actively scanning Android device will trigger this but I'm unable to test this.

Nice work @lukeredpath. I shared your skepticism that this could ever work. Others have reported that it does work, but they didn't show their workings as you have here (and it's so easy to miss an important step) so I remain skeptical (of the iOS <-> iOS workaround) until they can share more details.
Just a thought, it would be great to rule out iPad and xcode by running this same test with 3 iPhones, none connected to xcode. When I've done this approach in the past, I've dumped debug info to an on-screen text box to allow debugging without an xcode connection. But obviously this is a lot more work. Just a thought.

@lukeredpath What iPhone/iPad models were you using? What was the battery level of the phones? Did they have other Apps running? Did they have other Apps advertising in the background? How long was the delay between backgrounding the App and performing a test? How long did you wait before assuming the device could not be discovered? All these are important factors in determining if a device is working in the background, because background scanning and advertising is variable based on some algorithm that Apple doesn't disclose but will take in to account all these factors in deciding intervals and therefore discovery time.
As a 'real world' test, I'd suggest leaving them for at least 5 minutes before assuming that it isn't working. I prefer testing the App store App (I detailed how in previous comments) as there could be code improvements not released on github, or there could be some issue with how you are building and running the app (particularly the ability to test with the real notifications).
Personally I can't test with devices which haven't seen each other before, but if we assume that deleting the App is sufficient to replicate that then it does work in the background for me with two iOS 13 devices almost immediately when the process is still running in the background on both devices.

@nrbrook could you share your experiment details in a similar manner to above so others can replicate?

Unfortunately I don't have a third iPhone device to test. To answer the questions above:

iPad mini 3, iPhone XS and an iPhone 7, all running the latest version of iOS 13.
Battery levels were all above 50%
Probably had some other apps running, I couldn't tell you which.
No other apps advertising in the background that I'm aware of.
Less than 1 minute between backgrounding and launching the foreground app on the second iPhone.
In this particular test I waited a few minutes. I've waited longer on the two device test.

When you are testing with the real app, are you testing both devices locked or unlocked? How are you verifying that they work, have you been able to extract the contact event plist?

iPad Mini with Retina running iOS 12.4.6 with 26% battery ("device A") (I don't believe this is any different to iOS 13, but my other iOS 13 device is linked with my Apple ID so I'm not testing with that) and iPhone 11 Pro running iOS 13.4.1 ("device B").
App deleted from both devices, bluetooth off (in iOS settings)
Install App on both devices, go through setup until you reach "turn on bluetooth"
Device B: Install Bluetooth profile from Apple on iOS 13 device and connect to Mac
Mac: Install PacketLogger and start a new iOS trace
Mac: Filter the trace on '85bf' which is COVID-19 identifier characteristic
Mac: No packets should appear
Device B: Background the App, turn on Bluetooth and Lock screen (still connected to Mac)
Device A: Turn on Bluetooth
Mac: Observe identifier characteristic read and write occurs. This is the indication that the App has read and written the identifier from the other device. I haven't checked that the App does persist successfully at this point, but it has swapped identifiers and that shows it can work.

Because the iPhone may have been advertising/scanning with a smaller interval due to charging from Mac, I swapped the iPhone for an iPad Pro 11" running iOS 13.4.1 with 29% battery life and connected through a USB-A to Mac so it wasn't charging ("Not charging" next to battery) and repeated with the other iPad, and this works too.

I really don't think the observation of Bluetooth behaviour is in itself enough to verify the app is working properly. There may well be Bluetooth activity happening in bluetoothd but if these don't translate into callbacks in the app then it's meaningless. It would be useful if you could extract the app container using Xcode and look in the documents folder - there might not be much useful log output from the Release app but you should be able to verify the contents of the contactEvents.plist file.

Regarding the duration waiting for the devices to discover eachother - if the whole point of the workaround is that the connection from Device 1 (locked/background) to Device 3 (unlocked/foreground) is enough to "activate" (whatever that is suppose to mean) the app on Device 1 so that it can be seen by Device 2 (locked/background) then surely there shouldn't be any delay?

Even if one device has the App in the foreground, if the other device is advertising at a large interval they may not detect each other for a few minutes. Other than waiting until the App is killed by the system but the system is still advertising (which could be hard to reproduce/take some time) I am not sure how this condition can be tested.
Perhaps a useful feature of the App, or at least a useful diagnostic ability, would be an area that displays contacts you are in range of and how long you are in range of them. It could alert you when you are in range of someone for too long. You could perhaps add some configuration to whitelist certain other devices in the same household.

@lukeredpath As I mentioned before, these characteristic reads and writes would definitely not occur without the App doing them, iOS does not read and write proprietary characteristics on its own. It is a better truth test than checking the persisted data because there may be a bug in persisting the data or it may not be persisted immediately by design. Indeed there is a comment in PListPersister.swift:
// TODO: These writing options mean if we reboot and are woken from background by a
// BTLE event before the user unlocks their phone, we won't be able to record any data.
// Can this happen in practice? Does it matter?

You can't download the container from an App store App, but if there is another way to retrieve it I can do that.

Perhaps a useful feature of the App, or at least a useful diagnostic ability, would be an area that displays contacts you are in range of and how long you are in range of them. It could alert you when you are in range of someone for too long. You could perhaps add some configuration to whitelist certain other devices in the same household.

@nrbrook interesting thought, but would this not introduce some form of de-anonymization?
I'm no expert, just a thought.

@TheOtterlord The configuration aspect would link two identifiers together as "in a household" which would perhaps reduce privacy by enabling more data analysis, but it would still ultimately be "anonymous" if there is not enough identifying information to link back to individuals.

@nrbrook Ah, that makes sense. Thanks ;)

I accept there could be a bug with the data persistence but I'm also looking at the output of the logs and not seeing any log entries that would normally be fired in the discovery delegate method either.

I'm probably going to have to take a step back from this now unfortunately - I will keep on monitoring this issue and will be happy to engage in discussion with the developers if they are able to provide some feedback, I just don't have the time to keep testing this myself for now. I continue to hope that what I'm seeing is the result of some weird combination of variables caused by my testing and not what happens in the real world.

@lukeredpath I am not sure what the difference is between our environments if you followed the same steps, but yes, iOS's handling of background Apps and Bluetooth scanning/advertising is a black box and it may depend on factors we aren't aware of. Because it is not officially supported it is a risky approach compared to using Apple's contact tracing framework which was built for this.

Apple have killed apps before from big companies with updates that protect privacy, so I don't think killing this app will be much of a problem for them.
They will reject the app and state an existing API does this without the privacy violations attached to using the NHS app.
Do you know the number of people I know with iphones, who don't just exit apps and leave them running, but actually open the app list and swipe them away, killing them? Every iphone user I know does this cause they want their phone to not run out of battery and this app is going to run in the background 24/7 gathering bluetooth signals?
This app is not a contact tracing app. It's a phone tracking app. It's storing a UUID and location information and sending it to a third party. The NHS builds large projects but in the realm of IT they are not exactly the most capable team and considering that teams as large as facebooks can make oopsie's, I'm going to naturally assume the NHS team with their lower skills will make more.
Once detection of this API in an unintended way happens, they'll just modify the API in the future, break this app and tell them to use the new API they built for this reason. At which time the NHS will be sweet out of luck because their entire system is based of slurping private information about my whereabouts and uploading it to a database that I do not have control over via deletion requests or GDPR oversight thanks to Brexit.
Additionally, I have read they plan to allow future use of this data for other analysis in the future, without my consent, because they obtain consent for an unspecified number of reasons, some can be detailed in the future (therefore can't be documented, explained, neither consented to). Going to sell my data to the marketing companies maybe? pharmacy companies? Who knows. Maybe somebody will find an S3 bucket with a public policy attached and slurp up all the data from that.
Please don't tell me it won't happen, because any programmers here will tell you that it happens an uncomfortable amount of times.
But what do I know, I'm just a developer for the last 25 years ¯_(ツ)_/¯ I've seen these things come and go before. You'll fold and go with the Apple/Google api eventually. It's just a matter of how much face you want to lose before you accept defeat.

@christhomas for the record the app doesn’t actually gather any location data (it doesn’t need it), the iOS app doesn’t even request location access. You can see what data is stored in the contact event file in the examples I posted above.

Well that's a partial relief. I'd read in previous versions it was uploading location data as well.
Still, if you had a choice between an app which only works with the NHS in the UK, or an app supported by your operating system globally that doesn't violate your privacy in the above described ways. I can't imagine why you'd want to use this app. The battery drain alone is enough to make me avoid it. My phone lasts a little more than a day as it is.
But I am grateful you've done this analysis. It was very enlightening.

Whoevers idea it was to do a centralised app and not use Apples and Googles model needs to be sacked. This app is a complete waste of money & time and everyone knows it. Using grey area exploits to circumvent the restrictions is totally mind boggling when used in an app as critical as this one. Stop with this nonsense.

Because now it’s an act of hubris which drives them to continue despite clear warnings that they’ll waste more time and effort

I can't help but feel this app is now a waste of the developers hard efforts & the publics money(?). Using grey area exploits to circumvent the restrictions is totally mind boggling when used in an app as critical as this one. I don't agree with it, why not now put the efforts into using what Apple & Google are providing?
Having an app that actually works (that's solely letting people know they've been in contact with a carrier) properly on all devices, in all scenarios is much more important than being able to "analyse" data from a central db.

This is way cheaper than using Apple and Google code because the hidden value is the data, meta or otherwise. Tax payers will end up paying less and get a puppetless solution. No matter what Gopple and and Appgoo say or promise no one can prove, beyond reasonable doubt, that they will scrape up and harvest as much as they can carry, even if they don't need it or know what to do with it.  Having a bespoke suit made takes ages and costs a lot however it is value for money and lasts ages and looks like the wearer means business.  It is a process; a craft not a purchase, which is what you would be doing if you bought a Gobble,  Amasson or  Dapple product.

This is way cheaper than using Apple and Google code because the hidden value is the data, meta or otherwise. Tax payers will end up paying less and get a puppetless solution. No matter what Gopple and and Appgoo say or promise no one can prove, beyond reasonable doubt, that they will scrape up and harvest as much as they can carry, even if they don't need it or know what to do with it. Having a bespoke suit made takes ages and costs a lot however it is value for money and lasts ages and looks like the wearer means business. It is a process; a craft not a purchase, which is what you would be doing if you bought a Gobble, Amasson or Dapple product.

None of what you said is true.

I don't play ping pong.
On Sat, 16 May 2020 at 17:57, Christopher Thomas notifications@github.com
wrote:

This is way cheaper than using Apple and Google code because the hidden
value is the data, meta or otherwise. Tax payers will end up paying less
and get a puppetless solution. No matter what Gopple and and Appgoo say or
promise no one can prove, beyond reasonable doubt, that they will scrape up
and harvest as much as they can carry, even if they don't need it or know
what to do with it. Having a bespoke suit made takes ages and costs a lot
however it is value for money and lasts ages and looks like the wearer
means business. It is a process; a craft not a purchase, which is what you
would be doing if you bought a Gobble, Amasson or Dapple product.
None of what you said is true.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nhsx/COVID-19-app-iOS-BETA/issues/2#issuecomment-629675723,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQDXZZ2WJNXGG2DWP5T2L3RR3AX5ANCNFSM4M3TEQ5A
.

You don’t understand the technical aspects of what you’re talking about either ¯_(ツ)_/¯

Participants are reminded of this repo's Code of Conduct.
Specifically:

be respectful of differing viewpoints and experiences

I have removed a couple of comments. We're very happy to have technical discussions on this thread.

I am increasingly concerned that it seems the government is continuing to push forward with this App, but we have had no comment on the issues raised here other than the mention of the testing at RAF Leeming. This article does not provide any detail on the testing. Useful details would include the hardware used, OS versions, and the time the App had been in the background before the tests were undertaken. A test where the App is installed and then immediately tested is not sufficient to test background functionality.
The Isle of Wight test cannot provide useful feedback on missed contacts because of the nature of the problem, unless the Beta App is verifying tracing via location tracking or other means, but the code on this repository and the permissions it requires suggests it isn’t.
Can anyone from the development team provide additional detail on the testing undertaken and how we could verify the results for ourselves?

This problem isn’t unique to the NHSX app of course. Competing frameworks like DP-3T will have the same Bluetooth issues (until they switch to the Apple exposure framework anyway).

The Apple/Google API is heavily inspired by DP-3T so I doubt they will have the same issues.

The Apple/Google API is heavily inspired by DP-3T so I doubt they will have the same issues.

Architecture has nothing to do with access to APIs. DP-3T has the same problem as this app with background support, just look in their source.

Yes, what @thoutbeckers said. The issue is going to be a problem for any app trying to roll their own Core Bluetooth contact tracing system.
However, DP-3T can be made to work with the Apple/Google APIs as its decentralised whereas this app cannot, as it stands.

DP-3T version 2 can not be made to work Apple/Google, as the Cuckoo filter cannot  be applied on device due to Apple/Google doing all the work matching the exposure keys.
The same more or less applies to version 1. The differences are less big, but you still need to adjust to the differences, and in the end you end up with Google/Apple, not DP-3T. But it will fit reasonably well with the design of an app made for DP-3T.
To keep it on-topic, the rework for NHSX would probably be a lot bigger since the architecture differences are much bigger.

Interesting, I was under the impression that DP-3T was going to use the Apple/Google framework. If they aren’t, then it’s likely to be no more successful than this approach for the same technical reasons.

This in the Telegraph today:

Gus Hosein, a member of the ethics advisory board overseeing the app’s development, described a “frustrating” lack of communication with the government over data resulting from Bluetooth tests.
“I have asked repeatedly for data on how the trials and tests went with Bluetooth data, and they have never shared those results,” he said.

However, signs have emerged that there may be issues with how the app is locating users. A contract released by the Government last week showed the focus of the app’s testing was around “whether the proximity service satisfies the requirements”.

It is not clear that these issues are the issues discussed in this thread, but we have seen no evidence that the issues identified here have been mitigated, or even thoroughly tested. We could have an App released using the Apple Google framework now...

On a side note, it's not clear whether these sorts of apps are going to really catch on / actually work as intended -> https://www.nbcnews.com/tech/tech-news/coronavirus-contact-tracing-apps-were-tech-s-chance-step-they-n1230211

@nrbrook I suspect it could be they are referring to problems getting accurate proximity from the Bluetooth signal strength which is a genuine concern that people ha e raised and it applies to the Apple/Google solution too. Nobody knows how reliably this will work in the long run.

@lukeredpath it does seem to be focussed on proximity issues, but it does say

Experts have claimed that the use of Bluetooth technology to track people involves a number of limitations, including a lack of accuracy that could register phones a distance away.

This article in The Guardian perhaps gives an indication of how well the UK app will perform:

The federal government’s Covidsafe contact tracing app works as few as one in every four times for some devices, documents tabled in the Senate have revealed.

Good to see they have finally realised the Apple/Google model was the best way to go, lets hope this speeds up the public release of this app

Just thought I'd add this article to the discussion: UK virus-tracing app switches to Apple-Google model.

@TheOtterlord

The centralised version trialled on the Isle of Wight worked well at assessing the distance between two users, but was poor at recognising Apple's iPhones.
Specifically, the software registered about 75% of nearby Android handsets but only 4% of iPhones.
By contrast, the Apple-Google model logged 99% of both Android mobiles and iPhones. But its distance calculations were weaker.

So it seems it was this issue that caused the switch.

I can't say I'm really surprised - we all knew from the outset that the only way for this to work reliably (at least in terms of detection) is to use the Apple/Google frameworks as it circumvents all of the limitations of the various background modes.
The question still remains to be answered about the reliability of detecting proximity accurately enough for this to be useful in the real world but I imagine Apple and Google can refine this over time.
With all this said and done, once the switch to the decentralised model is confirmed, I think it's will be time to close this issue as "can't fix, won't fix". ;)

@nrbrook I think it was a number of issues, including this one and others related to security and privacy. I don't think all the data from the trial was published as far as I've seen, but I may be wrong.
@lukeredpath Yeah, this was always going to be the case. The system used in the retired version is unreliable and it makes no sense to continue development with this. The Apple/Google version seems to work really well when you look at other apps already using it around the world. I am not sure why they did not use it sooner.

Well there we have it - Hancock did his best to try and throw Apple under the bus on this one, but I don't think it will work.
If it's true that something about the way this app is calculating proximity is better than what Apple/Google are doing then I would hope that Apple and Google will work with NHSX to try and incorporate those improvements into the Exposure Notification framework.
I think now we can officially put this issue to bed!

Specifically, the software registered about 75% of nearby Android handsets but only 4% of iPhones.
By contrast, the Apple-Google model logged 99% of both Android mobiles and iPhones.

Let that be a lesson to other tracing apps, particularly if anyone involved is reading this thread. Testing sitting behind your desk fiddling with your phone will not give the same results as in the field when people have their phone in their pockets.
As much as I'd like to blame managers or politicians for this one, as this thread demonstrates developers are more than happy to make grand claims based on very little data and poor methodology. A healthy distrust of IT is needed for something as important as fighting a pandemic. While I don't think it ever should have gotten this far (as the abysmal test results indicate this was a waste of time) I've got to commend the NHS for at least doing a large scale test first (looking at you, Singapore/Australia/France).
I hope a similar skepticism  will be leveled against Apple & Google. While the relatively easy problems of discoverability and decent-enough privacy are solved by them, distance measuring is something that can be vastly improved still (but will require protocol level changes most likely). The decisions about tradeoffs on this point should not be left to just software engineers, even if they are some of the best in the world.

authors: Jeff-Stelling TheOtterlord benabrahamson billysielu christhomas chriswunsch00 deathchurch djh42 edent hiddentao hithomasmorelli j-r-t jamiebishop jdmwood2 lukeredpath molorosh mrjcgoodwin nrbrook philipswift r3m0t sanvean simbo64 stephenheron thoutbeckers


text:
Support Select placeholder in Blazor

🧹 Tech Debt
Supporting the placeholder feature in Blazor has implementation challenges related to how we need to not only expose the Selected property for users to set on a ListOption, but we also need to be able to handle changing the Selected state based on the value changing on the Select.
Currently, the NimbleListOption Razor component supplies a Selected property, but it's not even being leveraged in the template, meaning that the Selected property currently on ListOption is basically broken/useless.
The current version of Microsoft's Fluent UI Blazor library seems to have addressed these problems (albeit in a seemingly goofy way). Their FluenOption now binds the selected attribute of the web component to the Selected property on the Razor component as expected, and then also manages toggling that state via a handler that gets called not only when the option is clicked, but also when the keydown handler runs for the owner component.

Removed tech debt label because this has client-facing impact so it's hard to prioritize against the backlog of internal dev-facing work.

source: gharchive/issue

repo: ni/nimble

license: MIT

license_type: permissive

license_source: github-api


text:
How to build a pipeline workflow in the current structure?

Hi, dear author! I'm impressed by the good performance of this repo. However, I get a little confused when I am building my own work. Here is the problem: I want to build a pipeline workflow with disruptor. In the pipeline, a thread will work as both producer and consumer to the job. Is there any good idea how to build this kind of work? Thank you very much!
Yours,
danny

Hi Danny,
Yes, absolutely!
Check out the tests in lib.rs - there's an example of a pipeline where a consumer is also a producer.
Note, that the pipeline has to be constructed in reverse starting with the end consumer.
Kind regards,
Nicholas

authors: lluckydog nicholassm

repo: nicholassm/disruptor-rs


text:
Explore merging with other iTerm2 Night Owl themes

Twitter revealed one other iTerm2 Night Owl theme:

https://github.com/jsit/night-owl-iterm2-theme

@jsit Are you interested in collaborating on a single version? (I wasn't aware of your version when creating mine — sorry!)

There are quite a few differences but we could work to unify them (click to enlarge image).

ANSI bright colours. This version lifts them from the source here: https://github.com/sdras/night-owl-vscode-theme/blob/9d36c7624b85fe02f36c772f572a55225fc54d85/themes/Night Owl-color-theme.json#L182-L189. I think it produces slightly better legibility, visible in the tig screenshot above.
Cursor color. (I chose the same purple as the VS Code cursor.)
Links — open to interpretation; mine are from the link color when alt-clicking a function name to jump to the definition in VS Code.
Bold color. I felt the green better suits this because it stands out and is a dominant colour in the theme, but I'm open to ideas.
Foreground color. I took this from https://github.com/sdras/night-owl-vscode-theme/blob/9d36c7624b85fe02f36c772f572a55225fc54d85/themes/Night Owl-color-theme.json#L8.

Another here: https://github.com/florianeckerstorfer/night-owl-itermcolors


text:
Logger

ImportError: cannot import name 'Logger' from 'logger' (C:\Program Files (x86)\lib\site-packages\logger_init_.py)
How fix it?

Try changing from logger import Logger to from src.logger import Logger in file instabot.py

Closing this issue for now

authors: BreeBreeXD nickpettican

repo: nickpettican/InstaBot

license_source: bigquery


text:
Upgrade to authjs v5

Additional context
https://authjs.dev/guides/upgrade-to-v5

I would advise against upgrading to v5 yet, as it's still experimental.

authors: Byevenes wiredmatt

repo: nicoalbanese/kirimase


text:
The site http://worldtimeapi.org/ is not working

Hello, your site http://worldtimeapi.org has stopped working properly, I can access it 1 time out of 10, and yesterday I saw that the encrypted connection via https was gone. The problems started about a month ago, using a direct connection your site did not open, then I started using a proxy and got access to it without problems, but now I can not access it even using a proxy. Thank you for your attention, I hope you can fix this problem. Thank you for your project.

Hello,
I don't host this site, I can't help you with this issue !
It looks like they do not use my API (or a slightly modified version) : some fields are different.
More, my API uses HTTP, not HTTPS.

repo: nicolasbauw/world-time-api


text:
params with value was overwrite by default

Basic Info

rails_param Version: 0.10.2
Ruby Version: 2.3.8
Rails Version: 4.2.11

Issue description
param! :aa, String, required: true
param! :bb, String, required: false, default: lambda { params[:aa]}

I want to set params[:bb] to params[:aa] when params[:bb] was empty, but when I set :bb in request it was overwrite by lambda { params[:aa]}
Steps to reproduce
see Issue description
code
this code set value to default not check  params[name] is empty.
module RailsParam
  module Param

        # set default
        if options[:default].respond_to?(:call)
          params[name] = options[:default].call
        elsif params[name].nil? && check_param_presence?(options[:default])
          params[name] = options[:default]
        end

  end
end

Hi @archfish and thanks for raising this, I completely agree with you this is not an expected behaviour, and it seems like you've already identified the culprit!
I'll run a deeper investigation and get it fixed

authors: archfish iMacTia


text:
Format digits after decimal for rows and columns

How can I format the columns values from [-1.7, 0, 0.2, 0.5, 0.6] to [-1.70, 0.00, 0.20, 0.50, 0.60] (e.g.: two digits after decimal)?
Thanks

Dimension values are never formatted, they're just displayed as is, so you'd have to convert them to strings and apply the formatting upstream.

authors: diegobill nicolaskruchten

repo: nicolaskruchten/pivottable


text:
docs(phases): Expand documentation of phase.endIf

This adds more detail to the “Moving between phases” section of the documentation to clarify how to return a { next } object from a phase’s endIf.

Semaphore is failing with seemingly no log output, but everything builds/passes locally — I’m guessing there’s a problem on their end.

source: gharchive/pull-request


text:
Возможно ли отключить минификацию js?

Если возможно, то пожалуйста подскажите как это сделать.
Буду очень признателен.

npm start
в build/js/bundle.js неминифицированный файл
в чем вопрос?

Нужно отключить переименовывание функций.
Можно не использовать транспиляцию, если необходимо.

Нужно отключить переименовывание функций.
Можно не использовать транспиляцию, если необходимо.

В целом, изменения, вносимые в JS делаются вебпаком в ходе выполнения задачи обработки JS.
Видимо, нужно выпиливать сборку JS вебпаком и самостоятельно собирать JS простой конкатенацией файлов (то есть, заметно сменить способ обработки с потерей функциональности менеджера зависимостей).
Cмотрите gulpfile.js: список конкатенируемых js-файлов формируется там (и потом список пишется в src/js/entry.js), вы можете перепилить это, к примеру, так:

в самом галпфайле формируем массив js-файлов, которые хотим в сборку
устанавливаем что-то типа https://www.npmjs.com/package/gulp-concat
переписываем задачу сборки JS с использованием пакета для конкатенации (см. доку gulp-concat)

authors: nicothin webdtim

repo: nicothin/NTH-start-project

license: WTFPL


text:
Feature Request: Clear Alarm instead of Disarm

Checklist

[ x] I checked for similar existing requests (both open and closed) before posting.
[x ] My request is generic, other users may benefit from it too.

Proposal
currently it seems you can only disarm an alarm that goes off. Would be nice to clear the alarm, but leave the alarm on, instead of disarming and rearming.
Additional info
[some example of how the new functionality should look like]

missing

[some example of how the new functionality should look like]

HA does not have support for "clear alarm", so it would be an Alarmo-special.
I could add it to the actionable notifications, and to the alarmo-card.
What do you have in mind?

Well basically when an alarm goes off, the button in the panel allows you to disarm it. I would love for there to be a second button on the panel that just says clear the alarm. I guess you could manually set it to turn off any alarms that had already been triggered, but the alarm status would stay armed. An integration into the notifications would be ideal as well with similar functionality.

repo: nielsfaber/alarmo


text:
Manual automation not working

I am trying to make an automation to disarm the alarm when a NFC tag is read.
In automations I have a call to this service:
  - service: alarm_control_panel.alarm_disarm
    data:
      entity_id: alarm_control_panel.alarmo

But the service is not executed.
Also, if I check with the service developer tools, no disarm is made.

May be I am doing something wrong?

This will only work if the alarm does not require a code.
This you check the log?

I have just confirmed.
Thanks for your quick response.
But, what about this service call:
  - service: alarm_control_panel.alarm_disarm
    data:
      entity_id: alarm_control_panel.alarmo
      code: 1234

That is the example exposed for that service call.
That way, both methods (manual automation and integrated user policies at your component) should be valid.
I would like some users to enter a code and me to read my NFC.

That should work. Maybe you should enter the code as a string, so "1234".

That way, both methods (manual automation and integrated user policies at your component) should be valid.

I'm not sure what you mean here.
If you require a code for the disarm action, it should be always provided with the service call.

I would like some users to enter a code and me to read an NFC. I read my NFC card with my phone with HA installed on it.
But I do not want my employees to have my HA instance installed.

I don't know how NFC works on the phone.
If you can create an automation that disarms when valid NFC is provided, it should work.
But still, the automation should contain a code.
Alarmo cannot detect which method was used (Lovelace alarm panel card or automation) for disarming.

Checked, and working.
I can confirm this automation is working:
  trigger:
  - platform: tag
    tag_id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
  action:
  - service: alarm_control_panel.alarm_disarm
    data:
      entity_id: alarm_control_panel.alarmo
      code: "xxxx"

Thanks a lot for your support.

authors: nielsfaber tremebundo


text:
Cannot modify the different modes in the general section of control panel

Alarmo Version
1.8.7
HA Version
2022.3.7
Bug description
This is hard to explain. When I try to modify each mode (Armed away, Armed Home, etc..) it won't display each mode to modify.
On my other instance of home assistant (at a summer home) it works fine. The instance for my house it doesn't. When I go to the general section of the alarm panel and click on the arrows next to the modes, it should drop down with the different options. It doesn't do that. The down arrow just turns to an up arrow. If I click again, it goes back to a down arrow but no drop down shows up.
I tried removing Alarmo from home assistant and re-install it and still no joy.
Steps to reproduce
Clicking different modes.
Relevant log output
No response

Please check if the Alarmo version v1.8.7 is actually shown correctly in the top right corner.
If not, you need to clear the browser cache to solve the problem.

ok so when I first had the problem I was remoting into home assistant via NabuCasa. When I got home from vacation, I opened it locally and everything worked. I did not have to clear the browser cache to fix it. It also did display v1.8.7 in the corner.


text:
Is "*.ext matches .ext" related to 8.3 names?

In Provider specific filters, it is stated that "*.ext where ext is three characters matches *.ext*".
This reminds me of a legacy Windows feature: on some systems, files with long names or extensions get a 8.3 name for DOS compatibility. For example, a file "application.docx" may get a short name "applic~1.doc" and matches *.doc. This feature can be controlled by the fsutil command.
Do you think this is the reason?

Yes, I think this might be the reason, directly or related. Some obsolete and probably related API is still in use. Maybe for some compatibility, maybe it's actually good. Thank you for the info about fsutil, it's new to me. Of course it cannot fix the issue as such for us, PS scripts/tools writers. Scripts cannot count on the issue "fixed".

repo: nightroman/PowerShellTraps


text:
Add lite token counter

Add a new self-contained src/liteTokenCounter.js file with a simplified BytePairEncodingCore class for token counting.

Class Definition

Create a BytePairEncodingCore class with encodeNative and encodeNativeGenerator methods.
Initialize byte pair ranks, special tokens, and token split regex in the constructor.
Precompute and cache regular expression patterns for special tokens.

Encoding Methods

Implement encodeNativeGenerator method to yield tokens for text segments and special tokens.
Implement encodeNative method to return an array of tokens for text segments and special tokens.

Helper Methods

Add findNextSpecialStartIndex method to find the start index of the next special token.
Add getBpeRankFromString method to get the BPE rank from a string.
Add bytePairEncode method to encode input text using byte pair encoding.
Add bytePairMerge method to merge byte pairs and return encoded tokens.
Add getBpeRankFromBytes and getBpeRankFromBytesOrThrow methods to get BPE rank from bytes.
Add binarySearch method to perform binary search on byte pairs.

Utility Functions

Inline compareUint8Arrays, isAscii, tryConvertToString, isValidUTF8, and escapeRegExp helper functions.

For more details, open the Copilot Workspace session.

Can you explain the motivation or usefulness of this file?

You can ignore this. This was for a personal project I was working on.

repo: niieani/gpt-tokenizer