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
Bug: Need to include limits when OmnipodKit takes over from older pump manager #2451
Describe the bug
This was reported by first by Trio.
Attach an Issue Report
N/A
To Reproduce
Steps to reproduce the behavior:
Start a DASH pod with a version of Loop with OmniBLE pump manager (before 3.14.2) and observe Pump Manager Details for maximumTempBasalRate and note that there is no corresponding maxBolusUnits
Install 3.14.2 so OmnipodKit "takes" over the pod
Observe that the Pump Manager Details do not match the values of the OmniBLE pump manager
In OmnipodKit, the limits are named maxBasalRateUnitsPerHour and maxBolusUnits
I could not replicate the Trio reported problem of maxBasalRateUnitsPerHour being set to 2 U/hr
I could replicate for Trio and Loop, the value for maxBolusUnits being set to 30 U
Expected behavior
The code from #2426 is incomplete and needs to add code to update the therapy limits stored by OmnipodKit to match those in Loop at the time of the transfer
Confirm this issue with Loop
Start Pod with OmniBLE
Begin with a build that has OmniBLE as an available pump manager
We still have not been able to reproduce a max basal rate in the OmnipodKit Pump manager that is at a different value than in the OmniBLE Pump manager using multiple attempts with test phones.
Upon further analysis - the issue reported in Trio must be Trio specific. Only Trio has 2 U/hr as a default max basal rate and it is found in multiple places. We don't know the path where this bug happens for Trio.
And in the long run, we may remove limits from Pump Managers unless they are required by the pump itself
Activity
marionbarker commentedon Jun 18, 2026
Closing this.