UI : Bolus Progress Wheel Persisting After Bolus Completed

kylmcw commented 2 weeks ago

Describe the bug

A clear and concise description of what the bug is. Describe what you see versus what you expect to see.

The Bolus progress wheel seems to persist long after the bolus has completed. I observed it stopping at 75% completion both times, and could only remove it by clicking the "STOP" bolus button, upon which the usual "long beep" from the Omnipod DASH sounded.

Attach a Log

Tap the Trio settings icon at the bottom of the screen, then tap 'Share logs' on the bottom of the list and attach it to this ticket. Trio_logs.zip

To Reproduce

Steps to reproduce the behavior:

Bolus
Leave app (the app is no longer in main focus - I am also not sure if this step is needed)
return to app and observe that the bolus progress wheel is stuck at a certain percentage

Expected behavior

A clear and concise description of what you expected to happen. When the bolus completes, the progress wheel shall complete to 100% and remove itself in all scenarios.

Screenshots

If applicable, add screenshots to help explain your problem.

SMB started and finished at 14:19 with 0.4U. Observe the time on the screen 14:20 with the bolus progress wheel at ~75%.

Setup Information (please complete the following information):

Smartphone:

Hardware: iPhone 15 Pro
OS Version: 17.5.1

Pump:

Manufacturer: Insulet
Model: Omnipod Dash

CGM:

Device: Freestyle Libre 2
Manager app: Trio

Trio Version:

Version Number: 0.1.0
Repo: kylmcw/trio
Git Reference: dev 8de9979

Technical Details

If applicable, provide any technical details that might help in diagnosing the problem. This could include logs, error messages, or relevant configuration details.

I noticed I have a profile running, not sure if this is significant either. 120%, running indefinitely, no other settings changed.

Additional context

Add any other context about the problem here.

kylmcw commented 2 weeks ago

Tagging @kskandis for visibility. @marionbarker tagged on discord in #beta-testing

kskandis commented 2 weeks ago

Looking at your log 2.txt file for the 14:19 SMB, it shows the Bolus is successful and the log sends the completion notification. However, it never calls the updateStatus() after state inProgress completes (which is triggered by DoseProgressObserver - doseProgressReporterDidUpdate() with call to clearBolusReporter()). updateStatus() is necessary here because it calls omnipodBLE.getPodStatus() to store the bolus and retrieve pod's status of noBolus. So the issue is why isn't doseProgressReporterDidUpdate() being triggered.

The only thing that appears different in the log with the successful completion bolus and the failed completion bolus is there are several logs for DEV: APPLICATION PHASE: for the failed completion bolus. These indicate you left the app (your step 2 under Reproduce). We may need to call getPodStatus() upon app appearing (as main focus). This would be consistent with OmniBLEHUDProvider.swift implementation.

kskandis commented 1 week ago

I was able to reproduce this issue "somewhat" using rPi and the alpha branch by doing what @kylmcw described. After enacting a bolus of 1U, I switched to another app on the phone, and when I returned to Trio, I could no longer enter a new bolus. In my case, the following error was written to the log report, so this could be a different issue. Hwr, my log also shows the missing updateStatus(), same as Kyl's log.

In my case, also, after about a minute, a fresh status was received of noBolus, but it appears this was received after rPi pod disconnected and connected. So this may not be a relevant solution to an actual pod.

2024-06-17T21:11:20-0400 [ApsManager] APSManager.swift - processError(_:) - 897 - WARN: error("Error: Invalid Pump State: Pump is bolusing")

2024-06-17T21:11:20-0400 [Default] HomeStateModel.swift - subscribe() - 147 - INFO: Error: Invalid Pump State: Pump is bolusing
...
2024-06-17T21:12:19-0400 [DeviceManager] DeviceDataManager.swift - deviceManager(_:logEventForDeviceIdentifier:type:message:completion:) - 544 - DEV: Device message: Pod disconnected D96B8AC4-4488-3F25-3BC2-5608B20410C8 Optional(Error Domain=CBErrorDomain Code=7 "The specified device has disconnected from us." UserInfo={NSLocalizedDescription=The specified device has disconnected from us.})

2024-06-17T21:12:20-0400 [DeviceManager] DeviceDataManager.swift - deviceManager(_:logEventForDeviceIdentifier:type:message:completion:) - 544 - DEV: Device message: Pod connected D96B8AC4-4488-3F25-3BC2-5608B20410C8
...
2024-06-17T21:12:21-0400 [DeviceManager] DeviceDataManager.swift - pumpManager(_:didUpdate:oldStatus:) - 324 - DEV: New pump status Bolus: noBolus

One solution might be to check pod status immediately upon Trio app appearing by observing UIApplication.didBecomeActiveNotification, much like current LiveActivityBridge.swift does. This is also what OmniBLEHUDProvider.swift does which is used by Loop:

StatusTableViewController.swift

 if let view = pumpManagerHUDProvider.createHUDView() {
         addPumpManagerViewToHUD(view)
 }
pumpManagerHUDProvider.visible = active && onscreen

OmniBLEHUDProvider.swift

    var visible: Bool = false {
        didSet {
            if oldValue != visible && visible {
                hudDidAppear()

    func hudDidAppear() {
        updateReservoirView()
        refresh()

    private func refresh() {
        pumpManager.getPodStatus() { _ in
            DispatchQueue.main.async {
                self.updateReservoirView()

ChartsTableViewController.swift

    open override func viewDidLoad() {
        NotificationCenter.default.publisher(for: UIApplication.didBecomeActiveNotification, object: nil)

                if self?.visible == true {
                    self?.reloadData()

I know this would be additional calls to the pod, which is a concern from a battery usage point of view. We don't necessarily have to write the call to the log file, currently written as APSManager.swift - updateStatus() - 906 - DEV: force update status. OmniBLEHUDProvider.swift does not log it except if there is an error.

@marionbarker attached here is a patch which adds didBecomeActiveNotification code. I tested it with rPi and alpha branch. Pod status is updated to noBolus which will prevent the pod status from being stale (and causing this issue). If this works for you and seems like a reasonable solution, we can create a PR but maybe others have a better solution.

ui-bolus-progress-wheel-persist.patch

log.txt

kylmcw commented 1 week ago

Additional context: This hasn't happened since I started using xDrip4iOS and Omnipod Heartbeat

nightscout / Trio