Repository navigation
Ignore the previous pod's reservoir volume after a pod change - #783
Conversation
Loop keeps uploading its last reservoir reading for 15 minutes after a pod change, under the new pod's ID. LoopFollow now ignores volumes for a new Omnipod until it has uploaded a record without one or 15 minutes have passed, and dates readings by the record's pump clock.
TestNot sure the logic on this is correct. ConfigurationUse an rPi for the Loop phone Build the LoopFollow branch from this PR and configure it to follow the Loop URL. Test Details2026-10-29 Build a main v3.14.11 build onto the Loop phone 19:50 NS: 0.00 U (when there was no pod); OmnipodKit shows 50+ 21:00 Deactivate the Pod |
|
Thanks Marion. Agreed on 21:06: with no pod paired LoopFollow now shows "—" instead of 50+. At 21:13 the 0.00 U Nightscout shows is a value uploaded right after the pod change, and LoopFollow showing 50+ there (matching Loop) is the fix working. |
Test❌ When NS says: Finish Setup, LoopFollow should say "-", not "50+" ConfigurationUpdate to the most recent commit for the fix/pod-change-reservoir-carryover branch, 066c3a5 Test Details2026-10-30 Loop phone is connected to an rPi DASH, showing 50+ on reservoir level
|
|
Thanks. LoopFollow now follows the status Loop uploads in place of the reservoir ( |
TestI know that Loop uploads Manual Basal to Nightscout. (Not something the solve with this PR). ConfigurationUpdate to the most recent commit for the fix/pod-change-reservoir-carryover branch, a9a7770 Test Details2026-10-30 Loop phone is connected to an rPi DASH, showing 50+ on reservoir level
|
marionbarker
left a comment
There was a problem hiding this comment.
Approve from test but not merging in case a different indication in LoopFollow is desired.
|
Thanks Marion, LoopFollow now shows the status Loop uploads in place of the reservoir instead of "—" (9890778). I tested the latest commit end to end in the simulator with real pump drivers against simulated pumps: Loop (next-dev) with OmnipodKit and a simulated DASH pod, and Trio (dev) with OmnipodKit, MedtrumKit and DanaKit against simulated DASH, Medtrum Nano and DanaRS v3 pumps. Each uploaded to a local mock Nightscout that LoopFollow on this branch followed. Loop with DASH Case 6 is the carried over volume: Loop uploaded 0 from the No Pod record under the new pod's ID until about 15 minutes after the change, and LoopFollow showed 50+U throughout, as Loop did. Trio with DASH, Medtrum and Dana Trio uploads no pump ID, model or status in place of the reservoir, so this PR can't tell a pump change apart there, and LoopFollow shows what Trio uploads. In cases 1, 6 and 7 that is the previous pump's last volume, which Trio keeps uploading until the new pump reports one. That needs a change in Trio and is outside this PR. |
marionbarker
left a comment
There was a problem hiding this comment.
Approved by test build and spot check.
















Loop uploads its last reservoir reading until it is 15 minutes old, whichever pod it came from, so the first records after a pod change carry the old pod's final volume under the new pod's ID. Since #746 carries a reading for 30 minutes, LoopFollow showed the old pod's volume for around 45 minutes after a change, and the low reservoir alarm could act on it.
For an Omnipod, volumes after a pump ID change are now ignored and the row shows 50+U until the new pod has uploaded a record without a volume or 15 minutes have passed. A new pod reports no volume until it is below 50U, so nothing real is lost. While Loop shows a status in place of the reservoir, such as No Pod, Finish Setup, Manual Basal or Signal Loss, the Pump row shows that status, and the stored pump is kept through those records so the next pod still reads as a change. Medtrum, which Loop always reports as Unknown, still shows its volume. Reading times are the record's pump clock.
Replayed against a month of Nightscout data from one Loop user with DASH, all five pod changes with carried over volumes now show 50+U.