Adapt LoopFollow to Trio 1.0’s Updated Device Status Upload Behavior

[bjorkert]

Trio 1.0 now always uploads both suggested and enacted data, whereas before, only suggested was uploaded if new data was available after an enacted entry.

Adjusted how device status is fetched, ensuring it correctly handles both suggested and enacted data, where data in suggested is prioritized and last loop date is fetched from enacted's timestamp.

[dsnallfot]

Tested this and it works exactly as expected with BT heartbeat (or silent audio) for keeping track of the latest enacted device status and timestamp, and trigger any not looping alerts as intended.

Well done Jonas!

[bjorkert]

Merge conflicts with dev is resolved, it can now be merged using a merge commit

[marionbarker]

Things to Fix

I think the Not Looping alert should show up on the LoopFollow main screen for Trio when the Not Looping alarm goes off.
I think Trio itself may need an update before we test this.

See graphics under Trio URL

Code Review

The code changes seem reasonable. This touches Loop code as well as Trio code. So test both.

Tests

Configure 2 test phones - one feeding a Loop URL and one feeding a Trio URL
Both use their own rPi DASH pump and separate glucose upload patterns (one to each URL)

Build code using this PR
Ensure each LF phone is reading its associated URL and Looping as expected

Loop URL

For the Loop phone, set Not Looping to 15 minutes (don't have PR 366 included yet)
Halt the rPi at 10:42 local

Based on testing for PR 366, expect Not Looping alert at 10:42 + 15 + 15 = around 11:12
Triggered at 11:12 with Not Looping alert - tap snooze
See Not Looping on main screen
resume the rPi

Trio URL

Using Trio private beta, commit 8e87cee75, which includes Ensure latest 'enacted' determination is always uploaded #259 and Merge pull request #264 from nightscout/fix-ns-devicestatus-upload.
Build this version onto the Trio phone.

11:00 NS shows Enacted in the OpenAPS pill
11:01 Interrupt the rPi DASH, last communication: 2025-01-30T11:01:23-08:00

Based on testing for PR 366, expect Not Looping alert at 11:01 + 15 = around 11:15

The Not Looping alarm noise happens at 11:17
But Not Looping warning symbol does not show up on the main screen of LoopFollow
Get another Not Looping sound on LF phone, tap snooze. Still no Not Looping warning on main screen
(Trio phone says : signal loss for pod and 27 min for last loop time.)
At 11:36, the time-ago is no longer shown on Trio phone main screen.
At 11:38 get Not Looping alarm on LF phone, hit snooze

Capture a few OpenAPS pills for completeness.
Pod signal loss happened at 11:01 am.
I'm not sure if Nightscout will ever show a not looping indicator.
Stop testing as 11:45 (still no change on NS OpenAPS pill to indicate there is a problem).

EDITED TO SAY - I must not have built the commit I stated I built. Repeating this test (2 days later with no change to the related modules in Trio) I got different Nightscout display results. I commented out the incorrect comments and removed the graphic about the Nightscout display.

[dsnallfot]

I'm not sure if Nightscout will ever show a not looping indicator.

Just a note on NS behavior:

As long as NS receives device statuses from Trio that is "suggested" NS openaps pill will show the quite counterintuitive "looping" symbol. When Trio enacts a suggestion, the "enacted" device status is uploaded and the NS openaps pill will show "enacted".

Trio will send those "suggested" statuses as long as Trio gets cgm readings even if the pump com is down.

When no device status has been received by NS for X minutes, then it changes the pill to show a ⚠️ warning after "waiting" status for a while.

Ie "looping" status in NS is an indication that close loop isn't happening right now for any reason, but that Trio still receives cgm readings and uploads suggested DS.

[bjorkert]

I have pushed changes to simplify the Not Looping display logic and align its timing with the alarm when enabled; otherwise, it remains 15 minutes as before.

[marionbarker]

Status

Works well with Loop main and Trio private beta.
Does not seem to work with Trio 0.2.3 - but then main did not either.

Code Review

Reviewed both the changes from the most recent 2 commits (since last test) and the changes from all commits. Looks good.

• Include in Trio URL test:
  • Make sure that these items are handled properly when a given cycle has a suggested without a new enacted indication: enactedISF, enactedCR, latestIOB, latestCOB, insulinReq, AutoSens, eventualBG, enactedTarget, TDD and the prediction curves

Tests

Configure 2 test phones - one feeding a Loop URL and one feeding a Trio URL
Both use their own rPi DASH pump and separate glucose upload patterns (one to each URL)

Build LoopFollow code using this PR
Ensure each LF phone is reading its associated URL and looping as expected.
Set Not Looping alarm for each test phone to 15 minutes, with snooze of 10 minutes.

Trio private beta URL

Summary:

• The loss of pod comms is clearly displayed in Nightscout dashboard as well as LoopFollow and alarms sound appropriately

Details:

Build Trio private beta, commit eb1ceacd8 onto the Trio test phone.

Ensure URL is properly connected and LoopFollow displays items correctly (including InfoTable)

• Halt the rPi at 08:05 local.
• Got first Not Looping alarm at 08:20.
• Tap snooze (10 min) and see Not Looping alert on main screen - Success
• Got second Not Looping alarm at 08:30 - Success

Check Info Table:

• Updated shows 08:04:38
• when Not Looping alarm sounded take screenshot of the Info table and OpenAPS pill in NS
• when NS pills turn yellow, take another set of screenshots
• when NS pills turn red, take a final set of screenshots
• Confirm that the Info Table and OpenAPS pills in matched screenshots agree
  • Compared the Info Table and OpenAPS pill (the TDD was not included in the LoopFollow screenshots by accident. other items were present)
  • All items displayed in LoopFollow screenshot matched those in the OpenAPS pill on Nightscout

Restore rPi so Trio begins to loop again at 09:06
Do Loop test then build Trio 0.2.3 on the Trio phone for final test.

Loop URL

Summary:

• The loss of pod comms is clearly displayed in LoopFollow and alarms sound appropriately
• Nightscout dashboard shows Pod comms disconnected in the Loop pill and with pump pill indicating minutes ago
  • Waited for NS pills to turn yellow at 30 minutes and then halted the test

Details:

For the Loop phone, set Not Looping time to 15 minutes

• The total time expected before seeing the Not Looping indication on LoopFollow phone is 15 minutes.
• As soon as pump is disconnected, the prediction lines do not show up on LoopFollow, and the ones seen in Nightscout dashboard are stale (and stop updating)

Halt the rPi at 09:31 local time - right after a successful loop

• Get Not Looping alert at 09:53, tap snooze
• Main LoopFollow screen shows Not Looping at 09:53
• Nightscout Loop Pill turns yellow after 20 minutes of not looping
• After 30 minutes, check NS again: Both the Pump and Loop pills are yellow now (as expected)

Note that IOB is not reported in LoopFollow. But that is not the subject of this PR.

Turn on the rPi again and confirm Not Looping icon goes away on LoopFollow main screen and IOB, COB, Basal, rec. bolus, etc. all begin reporting again.

Trio 0.2.3 URL

Summary:

• This does not alert for Not Looping

Details:

Build Trio 0.2.3 on the phone that was previously running Trio private beta and allow it to begin showing information on Nightscout and LoopFollow.

Halt rPi at 09:57 (about 3 minutes after last successful loop).
The info table Updated parameter updates with every loop
Loop Follow never alarms or shows a Not Looping indication

Build LoopFollow main on this LoopFollow test phone to see if Not Looping was indicated properly before.
This also does not indicate Not Looping. Halt test at 11:00 local.

[marionbarker]

LGTM

@bjorkert confirmed that Trio 0.2.x does not upload the information LoopFollow would need to indicate Not Looping.

I confirmed that the results for LoopFollow have not changed (went back several version through v2.2.4 with the same results) when the URL is fed by Trio 0.2.x.