You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Problem with insulin delivery accounting in Open Loop and/or Neutral temps #904
Describe the bug
Last night, while running on open loop for many hours, I noticed that IOB and main screen displays for insulin were incorrect periodically.
Additionally, there appear to be other reports surfacing in FB and messages from others that are likely seeing the same that I was able to capture last night (data attached below).
Attach an Issue Report
Two sets of info: 1st while Loop was in error, 2nd next loop corrected first.
Set of First Info: While IOB and main screen were incorrect
Loop Report 1 was captured when the Loop main screen and IOB were errantly showing a high temp basal and much higher IOB (7+ units) than actually present (3+ units). (Screenshots below)
Watch loop display for awhile, seems to reproduce itself within 30 minutes or less I expect. IOB will jump and insulin delivery graph will display a high temp basal for one loop run...then correct itself on next loop run.
Expected behavior
Neutral temps or open loop should produce insulin delivery graph of 0 change and IOB should not increase.
Screenshots
First part (associated with Loop Report 1)
Second part (associated with Loop Report 2)
Phone
Hardware: iphone 7
OS Version: ios 12.1.4
Loop Version
Version Number: 1.9.5-dev-holly
Repo: katie
CGM
Device: G6
Manager app: dexcom app
Pump
Manufacturer: Medtronic
Model: 723
Firmware version: 2.4 1.1 0B 0B
Additional context @ps2 remember that other report I had mentioned in Slack convo previously? What she was seeing is very much the same as what I've captured here. Open loop mode has odd displays and IOB that are transiently (and incorrectly) showing a high temp basal was set. There's also a report of someone seeing same behavior in a FB post right now, but since FB is glitching I'm having trouble getting a link to it in here. I'll grab it when available.
Another example....been open looping for over 12 hours and only added insulin in that time is from the bolus showing on screen (8 units) yet Loop is reporting over 15.5 units on board.
changed the title [-]Problem in Open Loop and/or Neutral temps[/-][+]Problem with insulin delivery accounting in Open Loop and/or Neutral temps[/+]on Mar 13, 2019
For what it's worth, I don't think this is only an open-Loop problem. I see it periodically with closed Loop. For me it's always after a bolus (which seems consistent with above examples), where it temporarily roughly doubles the bolus IOB. It seems like it is double-counting the bolus temporarily - wonder if it could be registering both the reservoir change and the bolus entry in history for a short period of time. I'm running 1.9.4-Anna, but no open loop and no neutral temps (changed Katie's code to take them out, i.e. that bit is back to matching the main branch).
Coincidentally, I saw this happen shortly after posting the comment above. Screenshots below are only seconds apart - Loop completed and erased the problem just as I was finishing the first screenshot so I didn't have time to grab an issue report in the high-IOB state. Note that the difference in IOB (2.83 units) is very close to my most recent bolus, 2.8 units at 9:27 PM. You can see in the first screenshot that it is rendered there as both a high temp basal and a bolus, and then the spurious temp basal spike goes away. I'm attaching an issue report after the second screenshot, but I'll keep watching and see if I can capture both before and after issue reports.
The double bolus counting issue is known and expected behavior, due to the transition time when have read pump history, and don't see a bolus, but are tracking one temporarily, and are also seeing reservoir increases. It's not easily fixable w/o introducing the possibility of undercounting insulin, which is much worse than overcounting for a small period: https://github.com/LoopKit/LoopKit/pull/254/files
I've seen that in the past with recent boluses, and understand what you're saying, but this behavior seems different to me, since it can happen much longer after a bolus than I would expect based on simply not yet seeing the bolus in recent pump history. If you look at Katie's examples above, the first case is a solid two hours after the bolus, and the second is about an hour. In my case it was 20 minutes. I'll keep an eye on it and see if I can catch another case with a full set of issue reports to document this better, but still wondering if there's something going on beyond the expected behavior.
@Kdisimone Are you seeing them for omnipod or medtronic, or both? They are likely separate issues; medtronic is going to be expected to some extent (though there may be improvements we can make if we capture good data about the problem). Omnipod I think we should be able to eliminate the issue, but again, we need to capture good info. Issue reports for both would be good. Maybe it's time to split this up into two tickets, and capture fresh reports. Since this ticket has been opened, there have been a good number of changes to DoseStore.
I'd appreciate any help in triaging this: creating new tickets for the separate issues, and directing people to attach issue reports to the appropriate tickets.
Hi, I've never posted in GitHub before so please lmk if I should be doing anything differently. I've been using Loop for 3.5 years and it's been a life saver. But for about the last year I have had major trust issues. The Loop display is frequently inaccurate, and the issue has occurred despite a new phone and through multiple versions of Loop (I use a Minimed 722). I'm currently using Loop v2.1.0. The display will predict a very negative number showing a lot of IOB. When this first occurred, I ate a ton of carbs and ended up high, and noted a few minutes after eating the display corrected itself (without me entering any of the carb grams). But now I know it does this, so every time I see higher than expected IOB I constantly monitor the screen to see if it's a glitch or real. And intervene accordingly. It usually resolves within about 10 minutes, but it's very time-consuming to closely monitor and my distrust makes me fear one day it will be real IOB, and I won't eat enough in time because I assume the display is wrong. I have some screen shots if that would help?
The other night I caught Loop delivering a 3 unit bolus I really don't recall initiating, which furthers my distrust. I have some screen shots of this and I sent myself an "issue report". Please let me know what you need. I'm unable to read the report to see why it initiated a bolus, which might help me determine if it was a user error vs a very scary glitch. I'm afraid to where Loop right now and have borrowed a Tandem Control IQ but strongly prefer the Loop algorithm and features so would really appreciate being able to help on this issue in any way possible. Thank you all so very much!
@Kdisimone Are you seeing them for omnipod or medtronic, or both? They are likely separate issues; medtronic is going to be expected to some extent (though there may be improvements we can make if we capture good data about the problem). Omnipod I think we should be able to eliminate the issue, but again, we need to capture good info. Issue reports for both would be good. Maybe it's time to split this up into two tickets, and capture fresh reports. Since this ticket has been opened, there have been a good number of changes to DoseStore.
So I opened a new issue for the 3 unit bolus. And all of the issues I'm reporting here have been Minimed 722. I have another screen shot from Aug last year but won't post unless helpful. I'll do an "issue report" next time I get the incorrect IOB display. I only have one for the 3 unit bolus, which I posted in that new thread.
Activity
Kdisimone commentedon Mar 13, 2019
Another example....been open looping for over 12 hours and only added insulin in that time is from the bolus showing on screen (8 units) yet Loop is reporting over 15.5 units on board.
Kdisimone commentedon Mar 13, 2019
and then fixes itself next Loop run.
[-]Problem in Open Loop and/or Neutral temps[/-][+]Problem with insulin delivery accounting in Open Loop and/or Neutral temps[/+]Kdisimone commentedon Mar 13, 2019
Just fixed the original post with correct Loop Issue Reports (sorry, original post had wrong ones...all good now)
elnjensen commentedon Apr 9, 2019
For what it's worth, I don't think this is only an open-Loop problem. I see it periodically with closed Loop. For me it's always after a bolus (which seems consistent with above examples), where it temporarily roughly doubles the bolus IOB. It seems like it is double-counting the bolus temporarily - wonder if it could be registering both the reservoir change and the bolus entry in history for a short period of time. I'm running 1.9.4-Anna, but no open loop and no neutral temps (changed Katie's code to take them out, i.e. that bit is back to matching the main branch).
elnjensen commentedon Apr 9, 2019
Coincidentally, I saw this happen shortly after posting the comment above. Screenshots below are only seconds apart - Loop completed and erased the problem just as I was finishing the first screenshot so I didn't have time to grab an issue report in the high-IOB state. Note that the difference in IOB (2.83 units) is very close to my most recent bolus, 2.8 units at 9:27 PM. You can see in the first screenshot that it is rendered there as both a high temp basal and a bolus, and then the spurious temp basal spike goes away. I'm attaching an issue report after the second screenshot, but I'll keep watching and see if I can capture both before and after issue reports.
Loop Report 2019-04-08 215100-0400.md.txt
ps2 commentedon Apr 9, 2019
The double bolus counting issue is known and expected behavior, due to the transition time when have read pump history, and don't see a bolus, but are tracking one temporarily, and are also seeing reservoir increases. It's not easily fixable w/o introducing the possibility of undercounting insulin, which is much worse than overcounting for a small period: https://github.com/LoopKit/LoopKit/pull/254/files
elnjensen commentedon Apr 9, 2019
I've seen that in the past with recent boluses, and understand what you're saying, but this behavior seems different to me, since it can happen much longer after a bolus than I would expect based on simply not yet seeing the bolus in recent pump history. If you look at Katie's examples above, the first case is a solid two hours after the bolus, and the second is about an hour. In my case it was 20 minutes. I'll keep an eye on it and see if I can catch another case with a full set of issue reports to document this better, but still wondering if there's something going on beyond the expected behavior.
Kdisimone commentedon Apr 3, 2020
@ps2 we still are getting a fair amount of these reports in Looped group. People are quite confused by this display issue.
ps2 commentedon Apr 3, 2020
@Kdisimone Are you seeing them for omnipod or medtronic, or both? They are likely separate issues; medtronic is going to be expected to some extent (though there may be improvements we can make if we capture good data about the problem). Omnipod I think we should be able to eliminate the issue, but again, we need to capture good info. Issue reports for both would be good. Maybe it's time to split this up into two tickets, and capture fresh reports. Since this ticket has been opened, there have been a good number of changes to DoseStore.
ps2 commentedon Apr 3, 2020
I'd appreciate any help in triaging this: creating new tickets for the separate issues, and directing people to attach issue reports to the appropriate tickets.
marydaisy commentedon Apr 21, 2020
Hi, I've never posted in GitHub before so please lmk if I should be doing anything differently. I've been using Loop for 3.5 years and it's been a life saver. But for about the last year I have had major trust issues. The Loop display is frequently inaccurate, and the issue has occurred despite a new phone and through multiple versions of Loop (I use a Minimed 722). I'm currently using Loop v2.1.0. The display will predict a very negative number showing a lot of IOB. When this first occurred, I ate a ton of carbs and ended up high, and noted a few minutes after eating the display corrected itself (without me entering any of the carb grams). But now I know it does this, so every time I see higher than expected IOB I constantly monitor the screen to see if it's a glitch or real. And intervene accordingly. It usually resolves within about 10 minutes, but it's very time-consuming to closely monitor and my distrust makes me fear one day it will be real IOB, and I won't eat enough in time because I assume the display is wrong. I have some screen shots if that would help?
The other night I caught Loop delivering a 3 unit bolus I really don't recall initiating, which furthers my distrust. I have some screen shots of this and I sent myself an "issue report". Please let me know what you need. I'm unable to read the report to see why it initiated a bolus, which might help me determine if it was a user error vs a very scary glitch. I'm afraid to where Loop right now and have borrowed a Tandem Control IQ but strongly prefer the Loop algorithm and features so would really appreciate being able to help on this issue in any way possible. Thank you all so very much!
marydaisy commentedon Apr 21, 2020
These were taken Feb 25th at 3:50 and 3:54pm
marydaisy commentedon Apr 21, 2020
These were taken April 9 at 8:22pm & 8:28pm
loyalchallenger commentedon Apr 21, 2020
This was on my omnipod the other day.

marydaisy commentedon Apr 21, 2020
So I opened a new issue for the 3 unit bolus. And all of the issues I'm reporting here have been Minimed 722. I have another screen shot from Aug last year but won't post unless helpful. I'll do an "issue report" next time I get the incorrect IOB display. I only have one for the 3 unit bolus, which I posted in that new thread.
marydaisy commentedon Apr 21, 2020
I'm updating Loop now and will post again if it occurs, with an "issue report" and screen shots. LMK if anything else would be helpful thank you!
tohvanah commentedon Mar 2, 2021
We are observing similar issues on our new Loop setup.
Setup: iPhone SE, iOS 13.7, Loop 2.2.4 (LoopWorkspace master), OmniPod, Dexcom G6
Loop Report 25 minutes before observing the issue.
Loop Report 2021-03-01 07:09:02-05:00.txt
I don't even remember why I created this report, but it seems useful: it reflects the correct IOB.
Incident 1
Loop Report 2021-03-01 07:44:27-05:00.txt
Incident 2
Loop Report 2021-03-01 17:04:34-05:00.txt
github-actions commentedon Nov 11, 2023
This issue is stale because it has been open for 30 days with no activity.
github-actions commentedon Nov 26, 2023
This issue was closed because it has been inactive for 14 days since being marked as stale.
[LOOP-5737-5778] use last glucose data date when loop is open (LoopKi…