Trio reverts to looking for old G7 CGM and misses readings

[aug0211]

Describe the bug

Trio reverts to a prior G7 sensor seemingly at random. The current sensor is not seen and BG readings are dropped. Missed readings, yellow loops and red loops may occur. This normally self heals after a handful of missed readings.

To Reproduce

1. Pair a G7 sensor
2. When the G7's time is up, pair a new G7 sensor as instructed by Dexcom
3. Observe, when you see missed readings, tap into Trio's CGM view and interrogate whether it is using dates and info from your prior G7 sensor

Expected behavior

Trio should pull BG readings from the actively paired sensor.

Screenshots

Setup Information (please complete the following information):

Smartphone:

• Hardware: iphone 13 Mini
• OS Version: iOS 17.5

Pump:

• Manufacturer: Insulet
• Model: Omnipod Dash

CGM:

• Device: Dexcom G7
• Manager app: Dexcom App

Additional context

A number of uses have anecdotally reported more missed readings with Trio than expected. Perhaps this is the cause.

Light discussion on this in Discord chat with 3 people experiencing and discussing this.

[mkellerman-relativity]

This has happened a few times to me as well. This happened 8 days into a new sensor.

[tredair7]

I don’t have any screenshots but we’ve also experienced this issue.

[t1dude]

The root cause seems to be that the CGM Manager does not properly write the new sensor's Bluetooth ID to the CGMManagerState.plist file after it has picked up the new ID from the Dexcom app.

As long as you don't reboot your phone or otherwise kill the Trio app, the CGM Manager seems to be storing the new ID somewhere else (memory?) and does not need to read the ID from the CGMManagerState.plist file.

After a phone reboot, Trio will read from the CGMManagerState.plist file, where it will find the old sensor's Bluetooth ID and start to look for the old sensor.

I suspect this issue might also affect Loop and iAPS.

Documented with 16 numbered screen shots.

1 - Old Sensor in Dexcom App:

2 - Old Sensor in Trio:

3 - Old Sensor in CGMManagerState plist file:

4 - Old Sensor in Bluetooth Settings:

5 - New Sensor added to Dexcom App:

6 - Old and New Sensors in Bluetooth Settings:

7 - Old Sensor removed from Bluetooth Settings:

8 - New Sensor picked up by Trio:

9 - Old Sensor still in CGMManagerState plist file after Trio picked up new sensor:

10 - CGMManagerState plist file was does not have new timestamp:

11 - CGMManagerState plist file has new timestamp after phone reboot:

12 - CGMManagerState plist file still has old sensor ID after reboot and new timestamp:

13 - Trio searching for old sensor after reboot:

14 - Deleted and re-added CGM in Trio - now paired with new sensor:

15 - CGMManagerState plist file has new timestamp after re-adding CGM in Trio:

16 - CGMManagerState plist file has new sensor ID:

[aug0211]

Great finds! It sounds like the plist is correctly updated when adding (or re-adding) the CGM “as new” but not when a new CGM is “auto detected”.

One fix is to of course write to the plist on every connection, but this is IO heavy. We could also read from the plist and if the sensor ID doesn’t match, then update plist (also expensive to read from plist every cycle, assuming we aren’t already doing this (? have not looked).

Do we have any natural hooks to identify that a new sensor is being read, to then trigger the plist update so we can avoid that IO if possible? Of course if it’s already required this is a moot concern :)

[marionbarker]

I think this is Trio only. My Loop phone rebooted yesterday when I updated to iOS 17.6 and had not trouble picking up the G7. My display of the CGMManagerState.plist looks a bit different in that the DXCM## value is not visible.

[aug0211]

That is very good news as it means we're more empowered to fix this directly I think.

[t1dude]

I agree @aug0211 . Dan and I are troubleshooting now and will try to apply a fix. But we have to coordinate testing to avoid wasting sensors :)

[dnzxy]

Fixed via #376 - closing issue.