Bug Report: Eros Pod Fault of 0x31 (-049)

[marionbarker]

Describe the bug
A user reported an 0x31 fault (decimal -049).
This indicates Loop sent a command to the pod when the pod was not in a state to accept it.
In this specific case, Loop issued a Temp Basal command while a temp basal was already running.

Attach an Issue Report
Loop Report 2023-12-30 22_12_13-05_00.md

To Reproduce
Steps to reproduce the behavior:

1. This is a rare occurrence but the code should be evaluated and updated so this can never happen

Expected behavior
There are known states that will cause this fault for pods. Just going to list 2 (not indicating the ones that can happen during pair/prime/insert steps.

1. If the pod is in the middle of a Bolus, it will fault if a new request for Bolus is received
2. If the pod is already running a Temp Basal, it will fault if a new request for Temp Basal is received

No instances of Item 1 have been reported to date.
This instance is a case of item 2.

Screenshots
If applicable, add screenshots to help explain your problem.

Phone

• systemName: iOS
• systemVersion: 16.6
• model: iPhone
• modelIdentifier: iPhone13,1

Loop Version

• appNameAndVersion: Loop v3.2.2 (57)
• profileExpiration: 2024-08-30 23:47:44 +0000
• gitRevision: befcbcb
• gitBranch: N/A
• workspaceGitRevision: ee50fc4
• workspaceGitBranch: main
• sourceRoot: /Users/paulovieira/Downloads/BuildLoop/Loop-230724-1450/LoopWorkspace/Loop
• buildDateString: Thu Aug 31 21:55:51 -03 2023
• xcodeVersion: 14E300c

CGM

• Dexcom G6
• G6CGMManager

Pump

• Eros

Additional context

The commands for the pod that faulted were parsed and are contained in the attached csv file.

podState_Emily_Vieira_20231230_2212_2.csv

[github-actions]

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

[marionbarker]

Bump. This issue is fixed in dev but not yet in main.

[github-actions]

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

[marionbarker]

Bump. Fixed in dev.

[marionbarker]

Status of this bug report:

1. There were 2 PR (OmniBLE PR 110 and OmniKit PR 32) that handled some issues where the stored pod DeliveryStatus did not match the actual DeliveryStatus of the pod
   • These PR are already included in LoopWorkspace dev branch for the Loop app
2. The Trio app is currently in beta testing (Trio is an implementation of the OpenAPS algorithm on an iPhone)
   • Trio uses the LoopKit submodules for OmniBLE and OmniKit (same commit for OmniBLE and OmniKit as Loop)
   • A beta tester for Trio reported an 0x31 error - which indicated another case where the stored pod DeliveryStatus did not match the actual DeliveryStatus of the pod

The full details of this instance are found in this comment for Trio Issue 244

Summary:

• The pod was suspended
• When the pod was resumed, the communication failed to load the basal program into the pod, but the failure was not handled correctly
  • There was no unacknowledgedCommand handling for failed comms during resume. Because of this, the podState was incorrectly left having an uncertain unfinalizedResume dose instead of trying to resolve whether the command was actually received or not. In this failure case, the setBasalSchedule command was not received and this resulted in the podState indicating that the pod was not suspended when it actually still was
  • But this error alone is not sufficient to cause the 0x31 - that required 2 back-to-back boluses, where the second bolus was allowed while the first was still in progress

To Do:

• update the OmniBLE and OmniKit code to be more robust and to handle:
  • comm failures on resume
  • cases where the stored podState does not match the actual DeliveryStatus of the pod
  • all possible returned values of the pod DeliveryStatus
• Both Loop and Trio should use the updated version of the OmniBLE and OmniKit code