Skip to content

indicate when bolus is automatic in pod message#15

Closed
marionbarker wants to merge 3 commits into
LoopKit:devfrom
marionbarker:dev-auto-report
Closed

indicate when bolus is automatic in pod message#15
marionbarker wants to merge 3 commits into
LoopKit:devfrom
marionbarker:dev-auto-report

Conversation

@marionbarker

Copy link
Copy Markdown
Collaborator

This method of incorporating bits to indicate if a particular bolus is automatic (rather than manual) has been used for several years in other forks of Loop and is found Loop-dev for Eros Pods.

The method for interpreting these bits is incorporated in the python parser used to assist people who report Pod concerns with Loop (and other forks). It is extremely helpful to the analysis to know if it was an automatic bolus or manual.


let beep = self.confirmationBeeps
let result = session.bolus(units: enactUnits, acknowledgementBeep: beep, completionBeep: beep)
let result = session.bolus(units: enactUnits, acknowledgementBeep: beep, completionBeep: beep, programReminderInterval: programReminderInterval)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A better way of doing this would be to log extra metadata in the device logs themselves. Shortcuts like this end up making the code harder to read (why are we sending a reminder for a bolus?) and make later changes harder (what about tracking other metadata about the bolus?)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This allows us to determine if the bolus was automatic or manual just from the messages.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is in addition to, not in place of the meta data.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having this information in the message logs has been helpful to people providing Omnipod support across multiple DIY implementations. This has been done like this ever since the OmniKit enactBolus has had a parameter to indicate if a bolus is automatic (in private implementations for over 2 years now as well as in has been Loop dev, FreeAPS and FreeAPSX for quite some time already). Loop's OmniBLE shouldn't be different in this regard than OmniKit on Loop/FreeAPS/FreeAPSX as well as OmniBLE on FreeAPS and eventually FreeAPSX. The only reason why this isn't already here was simply because OmniBLE was forked for Loop dev before the post v2.2.6 OmniKit changes were applied.

Modify the language to make the "trick" obvious
@marionbarker

Copy link
Copy Markdown
Collaborator Author

I modified the language to make it clear what this "trick" is doing.

To belabor the usefulness of this approach - here are some examples:

Use Case #1:

  • User reported "Loop" gave an bolus overnight while the user was sleeping and in Open Loop
  • There were 2 reports of this on Facebook (one triggered the other person to report)
  • Both users were sure they could not have accidentally bolused over night because confirmation is required for manual bolus
  • One user was on FreeAPS (could tell it was an auto-bolus) and one was on Loop Master v2.2.4 (had no way of knowing if the bolus was manually initiated or automatic)
  • I was on Loop-dev at the time, so built Loop master at the next pod change and confirmed that Loop v2.2.4 will suggest an auto-bolus even if it is in Open Loop, and if user taps on the HUD row that suggests the bolus, no confirmation is required - bolus is enacted.
  • Suggested to both users the likely scenario of looking at the phone while half awake and accidentally tapping on the enact auto-bolus row on the HUD.

Use Case #2:

  • User reports unexpected bolus and IOB in their Loop HUD
  • User issues and posts the Loop Report asking for help
  • By analyzing the output (in this case from FreeAPS), the unexpected boluses are determined to be all automatic (4 doses at 5 minute intervals)
  • The carb store in the report has an entry at that time but it is not of sufficient magnitude to explain the dosing
  • Analysis team suggests user should examine Carb permissions in Apple Health to see if they added an item to Apple Health Carbs that was read by Loop or asked if they entered an incorrect number that they later edited

@marionbarker

Copy link
Copy Markdown
Collaborator Author

If we can agree that this language is appropriate, I will close this PR and make new ones after PR 16 and 17 are accepted.

@ps2

ps2 commented Feb 17, 2022

Copy link
Copy Markdown

It's not that I don't think there's not a use case worth supporting here: I definitely think we should have the forensic ability to see if dose was automatic or not. My issue is that I think we should be using actual device logs that can contain other metadata and not just the raw encoded bits.

I'll take this PR for use with the existing infrastructure you have for parsing logs, but I think this kind of thing is bad practice, and would love to see movement towards using actual device logs. There is a lot of other stuff you may want to use in log analysis, like connectivity stats, other BLE layer details, etc, and those would be easy to add to device logs.

I'll merge the other PRs and will wait for another PR from you on this, as you suggested above.

@marionbarker

Copy link
Copy Markdown
Collaborator Author

I will close this now and prepare a new one.

loopkitdev pushed a commit to loopkitdev/OmniBLE that referenced this pull request Mar 12, 2026
…scheduled-presets

LOOP-5235 Enable scheduled presets
loopkitdev pushed a commit to loopkitdev/OmniBLE that referenced this pull request Mar 12, 2026
…scheduled-presets

LOOP-5235 Enable scheduled presets
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants