Issue498

[JohanDegraeve]

Libre3 and/or Dexcom G7 and/or OmniPod as heartbeat

• Libre 3 or Dexcom G7 as heartbeat

  • Libre 3 as heartbeat: avoids the need for audioPlayer that keeps the app alive in the background. When Libre 3 sends data, xDrip4iOS will wake up and fetch a reading from LibreView
  • Dexcom G7 as heartbeat: only useful in combination with Loop. Loop must read the Dexcom G7 readings and upload to NightScout. xDrip4iOS will wake up when G7 sends data and will fetch the latest reading from NightScout. This occurs with a delay (Thread.sleep) of 1 second, to give time to loop to upload the reading to NightScout. Sometimes xDrip4iOS is still to early to fetch the reading. In that case, it may help to delete the heartbeat and recreate it.
  • OmniPod as heartbeat: for OmniPod users, this is a useful additional heartbeat. OmniPod has the interesting 'feature' to disconnect and reconnect every few minutes. Which allows to call the heartbeat function.
  • M5Stack as heartbeat: this is implemented as part of the M5Stack transmitter, it does not appear in the list of heartbeat devices. M5Stack will wake up xDrip4iOS if it didn't receive a reading from xDrip4iOS for more than 5 minutes. This allows xDrip4iOS to download the latest reading and send it to the M5Stack. Needs the latest release of M5stack or M5Stick-C software : https://github.com/JohanDegraeve/M5_NightscoutMon or https://github.com/JohanDegraeve/M5_StickC_xdrip_iOS

• the change required also to re-enable alarms, notifications, badge counter, ... when user has chosen followerBackgroundKeepAliveType disabled

• To use Libre 3 has heartbeat:

  • First connect to Libre 3 with official Libre 3 app
  • when connected, go to the iOS settings and read and note the name of the Libre (it's not something with ABBOTT in it, it's more like a random string)
  • force close the Libre 3 app
  • in xDrip4iOS, go to the bluetooth section
  • add a new transmitter of type HeartBeat
  • select Libre 3
  • as transmitter id, fill in the name you read in the iOS settings, just 4 or 5 characters is enough. It's case insensitive.
  • click the scan button. (you will not be asked to do NFC scan)
  • wait till connected
  • now reopen the official Libre 3 app

• To use Dexcom G7 as heartbeat:

  • make sure you connected at least once to the Dexcom G7 with the official Dexcom app and/or Loop.
  • Not necessary to force close other apps (like Official Dexcom G7 app and Loop)
  • go to the iOS settings and read and note the name of the Dexcom G7. It's case insensitive.
  • in xDrip4iOS, go to the bluetooth section
  • add a new transmitter of type HeartBeat
  • select Dexcom G7
  • as transmitter id, fill in the name you read in the iOS settings.
  • click the scan button. (you will not be asked to do NFC scan)
  • wait till connected

• To use OmniPod as heartbeat:

  • Force close any other app that connects to the OmniPod (that should only be Loop)
  • in xDrip4iOS, go to the bluetooth section
  • add a new transmitter of type HeartBeat
  • select OmniPod
  • click the scan button
  • wait till connected
  • you can now reopen Loop

[m-a-v]

Would it theoretically be possible to use an Apple Watch as a heartbeat or do you need an exclusive connection with the Bluetooth device?

[JohanDegraeve]

Would it theoretically be possible to use an Apple Watch as a heartbeat or do you need an exclusive connection with the Bluetooth device?

In case of Dexcom, Libre, M5Stack, etc... the connection is not exclusive to any app on the same device. If the transmitter would be connected to another iphone or android, then it would not work. I would expect that Apple has made the connection to the Apple Watch a bit more secure. If we have the UUID's somewhere then we could try it off course

[paulplant]

@JohanDegraeve - what about adding Libre 2 US/CA and Libre 2 AUS as heartbeat options? This would be useful I think.

[JohanDegraeve]

@JohanDegraeve - what about adding Libre 2 US/CA and Libre 2 AUS as heartbeat options? This would be useful I think.

that can also be done. Do you think the UUID's are different for Libre 2 US/CA/AUS vs Europe?

If we have some logs somwhere then we can compare them with EU versions. Libre 3 is different that's sure

[JohanDegraeve]

cherry-picked into branch develop

[KevinDenys]

I was wondering if this change will help with the battery drain caused by the follower mode?

[JohanDegraeve]

For Dexcom G7 users : A follower can use an expired transmitter and keep this for instance in his/her wallet and use it as heartbeat. That would work. They usually keep transmitting a few weeks, even after the days. That would reduce the battery consumption. Possibly also Libre 3 but I'm not sure if they keep sending data after 14,5 days (which is required to wake up xdrip4ios). That would be required. Dexcom is working a bit different, it disconnects and reconnects every 5 minutes which causes a wake up, even if they don't send any reading.

what type of cgm do you use?

[KevinDenys]

Sorry for the bad explanation.

I'm not talking about the battery life of the sensor. Im talking about the phones battery life. After switching to Libre 3 and setting up the follower mode using LibreLinkUp I noticed xDrip4Ios eating up more battery life. Also mentioned by Paul on facebook

- Keep-alive “Normal”: as always and has the usual follower battery life impact
- Keep-alive “Aggressive”: much more aggressive than “Normal”. Might be useful for people who have big problems keeping the app running in the background. Noticeable battery impact.

I was wondering if the heartbeat feature would help with the phones battery life cause it would only try to pull data from LibreLinkUp when the sensor send data to the official app

[JohanDegraeve]

Yes I know you were talking about phones battery, but I thought you were talking about real follower mode, ie someone else is following the person who is carrying the Libre/Dexcom. But to answer you question : yes it will solve the battery drain issue. With this change here, you should select the option background keep-alive = disabled. An additional change done here is that it will keep the alarms, notifications, etc. working

[KevinDenys]

But to answer you question : yes it will solve the battery drain issue. Sounds wonderful!

I really hate the Libre 3 alarms and there is no customization with for example between 00-06h do a loud alarm and after that a vibration alarm so that's why I keep using the xdrip4drip (setup as follower mode now)

[dugamarian]

Hi all, I have just a quick question about the timing in which xdrip4ios is reading values from LibreLinkUp. I’m using the Bluetooth connection to keep xdrip4ios alive in the background, but I’m noticing that is every time one reading behind libre app. I’m just curious, why is that happening?

[paulplant]

Hi all, I have just a quick question about the timing in which xdrip4ios is reading values from LibreLinkUp. I’m using the Bluetooth connection to keep xdrip4ios alive in the background, but I’m noticing that is every time one reading behind libre app. I’m just curious, why is that happening?

Please send an issue report. When you say you are using the bluetooth connection, do you mean you have build Johan's heartbeat test branch?

[dugamarian]

Yes indeed. I’m using the heartbeat test branch with libre3

[KevinDenys]

I guess it is a classic race condition

heartbeat happens => libre receives data => uploads it to librelinkup in the meantime heartbeat happens => xdrip4ios receives ping => fetches data => data is not yet uploaded

[paulplant]

Yes, that's what I was thinking so wanted to check the logs to see the time between the heartbeat and the http request for new values.

[dugamarian]

I have send a issue report

[paulplant]

Received. So yes, it looks exactly as @KevinDenys mentioned.

Between the heartbeat being detected and the app forming the required URL and making the http request, there is only 108ms needed.

The server answers with 148 BG values just 180ms later.

So if we can assume that around 400ms (I'm guessing) would be needed for the LibreLink app to receive, decode, process and upload the new value to the server, this would clearly not be available yet but the time xDrip4iOS has already made the http request.

We'll look at putting a delay and ask you to test for us. The idea would be to find the lowest value delay which still operates reliably.

[dugamarian]

Thanks. Of course, no problem

[JohanDegraeve]

I'm using it with DexcomG7 as heartbeat for the moment. Loop is actually the one that uploads to NS, then xdrip downloads from NS. I use a delay of 1 second before downloading the readings. That is working. Although sometimes it's also not working and I can solve it by deleting the heartbeat and readding it. I think it depends also on the sequence in which iOS wakes up the several apps, in my case the offical Dexcom app, Loop and xDrip4iOS.

I made a new commit, could you do a new test? https://github.com/JohanDegraeve/xdripswift/commit/f7148084a921f3947c9579790bce1fc63b53b173

[JohanDegraeve]

I made a new commit, could you do a new test? f714808

this change is now in the develop branch

[dugamarian]

Hello, after testing the change, I've realized that 4 seconds are more suitable. It seems that occasionally a one-second timestamp interferes with the application. Of course, I will test for a longer period of time, but so far, 4 seconds are better. Also, @paulplant, live activity after an hour or two exceeds the payload and is not available until the next day, but you probably already know this.

[paulplant]

Live Activities work fine... I've been testing them for around a month now non-stop and they work well. I think you're just testing a very early version that wasn't finished.

[dugamarian]

Ah ok. Is there a newer version available somewhere?

[paulplant]

Not yet... soon. The next release is going to be a (very) big one so we'll need help testing it. I'll let you know.

[dugamarian]

Ok. Thank you

[JohanDegraeve]

Hello, after testing the change, I've realized that 4 seconds are more suitable.

A sleep of 4 seconds would be too long. The app is blocked during the sleep (it's the UI thread). There's a risk that iOS would kill the app. Also if you would be using the app in the foreground, you would notice the blocking every minute, 4 seconds. Another option is to schedule a Timer of 4 seconds, this would not block the UI. But there's a risk that that the app gets suspended within those 4 seconds, in that case the timer would not get the opportunity to expire and it would only expire when the app is woken up again when the Libre sends the next reading, which is 1 minute later. (note that app suspension is a normal behaviour for apps in the background).

[dugamarian]

Ok. Thank you for the response. Do you think two seconds would work better? One second works for a while but then it reads at two minutes, then it has another period when it reads at one minute, it seems somewhat random to me.