Upload SAGE to NS for Dexcom

[MikePlante1]

Address Issue #269 when using Dexcom G5, G6 (ONE), or G7 (ONE+) as a CGM source. Note this does not address using xDrip4iOS as a cgm source.

It expands on (and slightly refactors) the LibreTransmitter fix in #112 . Please reference the comments on that PR about adding the LibreTransmitter library (this PR adds the CGMBLEKit and G7SensorKit libraries).

The only testing I've done for this PR is with my in-vivo phone.

• iPhone 15 ProMax
• iOS 17.5.1
• Dexcom G6 via official G6 app
• Nightscout hosted on GoogleCloud
• Medtronic 722 + OrangeLink

- Testing still needs to be done using G7

Before building this PR, my phone was at the tip of dev: 9672da2

• I checked Files > Trio > Monitor and there was no file cgm-state.json
• On my NS, I generated a 6-month report for Treatments and checked ☑️ Event Type: CGM Sensor Start
• The most recent entries for CGM Sensor Start are 2024-04-01 and 2024-03-22 but those were from when I used xDrip4iOS and directly uploaded glucose to NS from xDrip4iOS instead of Trio/iAPS.
  
• I did have an entry on 2024-03-07 marked as from iAPS, but if I remember correctly, it was from this repo before it was rebranded as Trio and before the change to submodules here 47fa017
  

After receiving my first reading from G6 after building this PR to my phone:

• SAGE on Nightscout was updated correctly.
  
• CGM Sensor Start showed up in Treatment report on the correct day
  
• FIle cgm-state.json now exists in Files > Trio > Monitor
  

[marionbarker]

Status

Everything I could test seemed fine.
I will add an approval knowing that someone else will be checking this.

Code review

Code review looks good - although I wonder if an enum plus case statements is more in keeping with the style of the app.

• Others need to answer that

Test

• started with latest dev (no other patches applied), commit 8303f0a
• applied patch from this PR
• Built to test phone with no issues
• Built to real phone on which I use Trio for LiveActivities triggering off my G7 (I run Loop as my OS-AID)
  • Trio missed the most recent glucose - probably because I was building, so wait a few more cycles
  • Trio captured the next few CGM readings - no more misses, showing up in dynamic island and lock screen widget

[MikePlante1]

Code review looks good - although I wonder if an enum plus case statements is more in keeping with the style of the app.

It looks like the enum for which cgm is being used was just changed to .plugin for all of these, so I just copied the code for Libre. If there's a better way I'm definitely open to hearing it.

Test

• started with latest dev (no other patches applied), commit 8303f0a

• applied patch from this PR

• Built to test phone with no issues

• Built to real phone on which I use Trio for LiveActivities triggering off my G7 (I run Loop as my OS-AID)

  • Trio missed the most recent glucose - probably because I was building, so wait a few more cycles
  • Trio captured the next few CGM readings - no more misses, showing up in dynamic island and lock screen widget

Is your Trio app connected to a Nightscout account to see if it updates SAGE properly for your G7? One whose SAGE was either out of date or non-existent? I can give you credentials for a spare NS if you need.

[aug0211]

Is starting a new CGM required in order to test this, can we test this with an existing/already started CGM?

I suppose we may be able to just forget/remove the existing G7 and re-add in Trio after applying this commit?

[MikePlante1]

Is starting a new CGM required in order to test this, can we test this with an existing/already started CGM?

I suppose we may be able to just forget/remove the existing G7 and re-add in Trio after applying this commit?

(Edit: existing G7 is fine)

Is SAGE currently out-of-date in your NS? If yes, apply this PR and after receiving 1 or 2 readings from G7, check NS to see if SAGE is now updated properly.

[avouspierre]

Even the code introduced specific lib in main code, currently no other simple solution to collect sage information. Probably could be a very good solution to have a generic API / method in loop submodules to retrieve this info and avoid specific code.

[aug0211]

Is starting a new CGM required in order to test this, can we test this with an existing/already started CGM?
I suppose we may be able to just forget/remove the existing G7 and re-add in Trio after applying this commit?

(Edit: existing G7 is fine)

Is SAGE currently out-of-date in your NS? If yes, apply this PR and after receiving 1 or 2 readings from G7, check NS to see if SAGE is now updated properly.

Not currently out of date because I use a shortcut to set it.

It sounds like this can be tested with an exciting sensor though, just by clearing the previous sensor date from the backend in NS.

Thanks, will take a look!

[aug0211]

• Tested with G7 in vivo
• Success
• Deleted previous sensor change date from Nightscout
• Confirmed latest sensor age from Nightscout was gone
• Deployed this code over my live instance of Trio
• After 1 loop, nothing updated
• After 2nd loop, the SAGE updated correctly
• I now also see the sensor insertion date in Nightscout history, noting the sensor bluetooth ID which is nice

Old manual sensor start entry:

Delete the old entry:

Confirm the old entry is gone:

Viola, the new G7 start entry automatically appears:

[dnzxy]

Merging with 3 approvals. Thank you @MikePlante1