JohanDegraeve
commented
6 months ago I can confirm that the patch kills updating of BG values running in follower mode from Nightscout with the "Background Keep-alive" mode set to "Disabled". No BG updates happen until set to “Normal”, even with the screen on, while "Normal" mode does work.
the goal is to test in master mode, why did you test in follower mode? In the end this branch will not be merged, because there's another branch with lots of other changes. Goal is that @paulplant copies this minor change here to his branch
bjornoleh
paulplant
LiroyvH
swright87
Logging it on GitHub as well so it's tracked and more people could weigh in if they like: several reports have been submitted, notably from the Anubis community - but also from ONE and G6 users, that their transmitters' batteries are drained way faster than expected when using xDrip4iOS. Official transmitters seem to die in about 45-60 days and Anubii with a larger batteries in 90-110 days or earlier. (Note: Anubis with a proper battery typically easily last double that.)
I've spent quite some time looking in to possible causes (including some time spent with Joshua from the Anubis project, whom I'd like to thank for his insights on the Dexcom firmware), and it keeps coming back to a problem I've mentioned on several occasions over the years where the transmitter goes in to a connection loop with xDrip4iOS. (Eg: you see it connect, disconnect, reconnect, disconnect, reconnect, disconnect and so on and on.)
From what I can see, but do correct me if I'm wrong and/or if the log output is deceiving, the problem lies with xDrip4iOS attempting to reconnect to the transmitter without an apparent reason. When xDrip4iOS initiates a disconnect, it also immediately attempts to reconnect. The Dexcom transmitter will still be awake* and responds to our request to connect. However, as xDrip4iOS then blocks the connection because "last connection was less than x seconds ago": the transmitter doesn't get anything from us. The connection times out after 10 seconds, after which the Dexcom disconnects again. However, as soon as that happens: xDrip4iOS once again tries to connect to the transmitter as indicated in the logs ("Trying to reconnect..."). Once again, the Dexcom transmitter allows this connection but subsequently again xDrip4iOS will not actually send anything to the transmitter because the last connection was less than x ago. After a while of this going on and on, the Dexcom transmitter will give up and phones in again at the original timestamp +5 minutes to send its new readings.
The problem is that this cannot always be reproduced. It's unclear to me why xDrip4iOS sometimes tries to reconnect and sometimes doesn't. It might also be the order of the slots in which it's connecting that might make a difference, but either way: xDrip isn't supposed to try to reconnect, especially not when xDrip itself sent the command to disconnect in the first place. I noticed today that during warm-up a similar issue occurs, but that has different log-output that I haven't analyzed yet. Did also send it to Paul.
I think the underlying issue must still lie within the original FireFly implementation where this behavior was noted, but I think was essentially "dirty patched". (Ignoring the transmitter, which inadvertently keeps it awake for 10 seconds until it times out. And then we ask it to connect again. It's like prank calling someone and every time they pick up you don't say anything.)
Here's an excerpt from the logfiles what that looks like:
And a longer look of such a cycle (including when it phones in again to update the values and then it goes straight back in to a loop):
It looks as if we don't yet expect a disconnect or that we do ask for it to disconnect, but another part of the code thinks its by error and tries to reconnect - but is then frustrated by the 2.1 minute thing. Note: in one of the very first implementations, of which I still have the source code laying around here if anyone's interested :P, this problem is continuous.
Anyway, I don't know IF this is the cause of the reported battery drains. But it seems very likely, as such: logging it as issue here. As an extra note: this seems to occur sooner for me when xDrip4iOS is woken up from slumber. (Eg: it got suspended, but transmitter wakes it up. I'll shamelessly plug my request for full implementation of Background Processing/Activity here which could potentially be good for overall stability (also compared to Loop, iAPS and the official Dexcom-app.))
* = The transmitter is still awake, because the Dexcom keeps listening for a brief moment on all 2 (or 3 in case of Anubis) connection slots to see if the second device (reader/pump) wants a connection as well or not. Instead, xDrip4iOS asks to be connected again - and it honors that request.