Manual Prime canula in medtronic pump is counting as IOB

[melenitas]

Sorry my first report, I write all the history, but when I attached the screenshots; I think the explanation was erased.

Describe the bug Once I open my eyes I use to prime with 0.5 to 1u to reduce my hyperglycemia wake up phenomenon. Today I've notice that Loop counted priming as IOB. But the expected is: "Medtronic Only: So long as you have Event History as the Preferred Data Source in Loop settings, primed insulin deliveries (e.g., cannula fills or manual primes) will not be counted towards IOB. "

Attach an Issue Report Attached now on my comment

To Reproduce Steps to reproduce the behavior:

1. Go to medtronic pump
2. Click on 'PRIME
3. Go back to Loop screen
4. See prime is counted as IOB

Expected behavior Medtronic Only: So long as you have Event History as the Preferred Data Source in Loop settings, primed insulin deliveries (e.g., cannula fills or manual primes) will not be counted towards IOB.

Screenshots

Phone

• Hardware: Iphone 6s
• OS Version:IOS 15.8

Loop Version

• Version Number: [3.3.0]
• Repo: Sorry don't understand what info you need here

CGM

• Device: Freestyle Libre 1
• Manager app: with bubble mini direct to LoopDev app

Pump

• Manufacturer: Medtronic
• Model: 522
• Firmware version: 2.4A 1.1 0B 0B

Additional context thank you for your work and patience.

[marionbarker]

Please report your exact version. The easiest way to do this is the issue report. Best to upload the full report. As a minimum, copy and paste the ## Build Details section.

LoopDocs instructions: https://loopkit.github.io/loopdocs/loop-3/settings/#issue-report

[melenitas]

Sorry I can't upload the file from my iphone,this morning, "not a valid file" message appear,

Here the build details:

Build Details

• appNameAndVersion: Loop v3.3.0 (2)
• profileExpiration: 2024-12-09 18:26:50 +0000
• gitRevision: 7c60cac
• gitBranch: N/A
• workspaceGitRevision: 965cc5c
• workspaceGitBranch: dev
• sourceRoot: /Users/runner/work/LoopWorkspace/LoopWorkspac
• buildDateString: Sun Dec 10 18:58:42 UTC 2023
• xcodeVersion: 15A240d

The file from my computer: Loop Report 2023-12-23 08:30:11-06:00.md

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[marionbarker]

Bump. Has this report and log file been reviewed?

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[elnjensen]

I haven't reviewed the log, but suspect that there is not a major issue here. There can indeed be intervals where Loop sees a prime as IOB, but they should resolve quickly.

What happens is that, even when Event History is the primary record, Loop also looks at the reservoir value. Those checks of the two data sources don't happen at exactly the same time (or at least don't show up in Loop's data stores at the same time, perhaps because the history download takes longer). So this sequence can happen:

1. User issues a manual prime.
2. Loop sees that reservoir has decreased, and adds the change to IOB.
3. Loop parses the event history, sees the prime event, and corrects the IOB so that the prime is no longer counted.

In the screenshots shown, we now that Loop eventually saw the prime event in the history, and we can see that it was at 7:38. The screenshots at both 7:41 and 7:51 show it still being counted as IOB. (BUT, looking more closely, the big difference in the battery charge level makes me wonder if all of these shots are from the same day.) By 8:19, the prime is no longer being counted as IOB.

@melenitas if you see this again, I'd encourage you to watch closely and see if it automatically resolves itself within 5 minutes or so. I suspect it will.

[elnjensen]

Here's an example of what I see. In the screenshots below, I did a 0.4U manual prime at 8:16, between screenshots 1 and 2. It is briefly counted as IOB (screenshot 2) but then goes away (screenshot 3).

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.