Skip to content

Fix for pump manager returns bogus podSuspended #49

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 12, 2025

Conversation

marionbarker
Copy link
Collaborator

@marionbarker marionbarker commented Feb 10, 2025

Purpose

This PR fixes a problem reported by Trio users Trio Issue 468 in which the pump manager can sometimes report podSuspended following an uncertain comm event.

Background

An earlier PR #47 added one improvement for automatically recovering from uncertain comms but increased the incidence of the podSuspended being returned from the pump manager when the pod was not actually suspended.

Proposed Solution

This PR adds tryToValidateComms which, if successful, enables the pump manager to return the updated response from getStatus.

It also modifies some guard statements so that a podSuspended is only returned when the last message received from the pod indicates the pod is actually suspended.

The goal is to have the PumpManager return the true pod status, if possible.

* add self.tryToValidateComms to handle uncertain comms;
* ensure podSuspended is only returned when actually suspended
@marionbarker marionbarker requested a review from itsmojo February 10, 2025 05:14
@marionbarker
Copy link
Collaborator Author

Status

LGTM

Code inspection

The changes for OmniKit exactly parallel the OmniBLE PR 141 changes.

Testing

Most of the testing was done with the rPi and the DASH version of the PR.

Use a Trio-dev test phone (commit 92294ab8e), SE running iOS 18.3 and connect an Eros pod using an EmaLink.
Use Nightscout as a CGM.

These are the functions that contain a call to tryToValidateComms (the new function):

  • (done) setTime
  • (done) setBasalSchedule
  • (done) setConfirmationBeeps
  • (done) setSilencePod
  • (done) suspendDelivery
  • (done) resumeDelivery
  • (done) enactBolus
  • (done) runTemporaryBasalProgram

Do some kind of test with each function. Put (done) in front of each function when it was exercised at least once.

  • move the EmaLink out of range and then bolus (got no RileyLink available)
  • change time on phone, and update pump time, then restore
  • suspend and then resume delivery - this takes care of setBasalSchedule, suspendDelivery and resumeDelivery
  • change expiration notification time
  • turn on Silence pod
  • turn on a Manual Temp Basal

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.

2 participants