Fix for pump manager returns bogus podSuspended

[marionbarker]

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 #139 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.

[marionbarker]

Initial Testing

Some preliminary testing has been done with the code in this PR using a patch to inject comm errors.

• OmniBLE_test_fakeFailure_for_tryToValidateComms.patch

In order to use this patch, first download it and then in the Trio or LoopWorkspace folder of a Terminal, issue this command:

git apply ~/Downloads/OmniBLE_test_fakeFailure_for_tryToValidateComms.patch --directory=OmniBLE

Configuration

Testing was done with both Trio and Loop.

• test phone running the selected app
• DASH pump using rPi DASH simulator

The issue of getting podSuspended is easy to trigger with Trio, so most testing was done with that.

Method to fake a comms issue

1. Apply the OmniBLE_test_fakeFailure_for_tryToValidateComms patch
2. Build onto the test phone and set a breakpoint at line 346 of OmniBLE/OmniBLE/PumpManager/PodCommsSession.swift but leave breakpoint disabled
3. Start up the app in closed loop and wait for successful loop
4. Observe the timing on the rPi simulator output
5. After the app has exchanged messages with the rPi
   • Enable the breakpoint
   • Go to the Omnipod screen (Xcode will halt at the breakpoint)
   • Enter this expression into Xcode at the lldb line: expr fakeUncertainAfterSendPercent=1.0
   • Disable the breakpoint and continue
   • Enter a manual bolus
   • Expect Bolus with fail because of injected fake comms error

Testing with fake comms issue

When testing Trio 0.2.3, this procedure triggers a podSuspended return from the pump manager that is reflected in the Trio log file.

When testing Trio 0.2.3 with this PR applied, no bogus podSuspended message is seen.

When testing Loop 3.4.4, the behavior with and without this PR appeared to be the same.

The Pump Manager should return the correct podState and not rely on upper level code to protect against bogus errors.

[marionbarker]

Patches used for Testing

I simplified the testing method. The same testing patch is used for Trio and Loop with some versions of OmniBLE. A new testing patch is used when testing Loop 3.4.4 as released.

• OmniBLE_test_fakeFailure_for_3.4.4.patch
• OmniBLE_test_fakeFailure_for_tryToValidateComms.patch

Method to Trigger podSuspended

1. Disable closed loop
2. Set breakpoint
   • tap on pod icon
   • enter at lldb: expr fakeUncertainAfterSendPercent=1.0
     • causes a failure to get a response from the pod followed by a failure to send a command to the pod
   • disable breakpoint and continue
3. Set Manual Temp Basal (MTB)
4. Results depend on the code base.

App	OmniBLE	podSuspended	results
Loop 3.4.4	4ad8117	N	The Loop Uncertain Comms screen is displayed, several getStatus are exchanged and nominal behavior is restored
Loop 3.4.4	1fa2874	Y	MTB refused because of podSuspended, suspend/resume then nominal behavior restored
Loop 3.4.4	7ded2bc this PR	N	MTB refused because of fake comms error, repeat and MTB enacted
Trio 0.2.3	1fa2874	Y	MTB refused because of podSuspended, suspend/resume then nominal behavior restored
Trio 0.2.3	7ded2bc this PR	N	MTB refused because of fake comms error, repeat and MTB enacted
Trio-dev 209f77679	1fa2874	Y	MTB refused because of podSuspended, suspend/resume then nominal behavior restored
Trio-dev 209f77679	7ded2bc this PR	N	MTB refused because of fake comms error, repeat and MTB enacted

[marionbarker]

Status

A new commit updated the type of error returned (.communication instead of .state/.deviceState) in a few places.

Tests

Repeat a small amount of testing

Insert fake communication errors

Using a Trio-dev phone and 10% failure rate for both fakeUncertainBeforeSendPercent and fakeUncertainAfterSendPercent, let the phone run for several hours.

In every case, the correct issue/alert showed on the Trio-dev main screen and in every case, the Trio-dev app recovered on its own.

Insert issues with the rPi and front end

Using a Trio-dev phone without the special patch for inserting fakeUncertain comms errors.
Demonstrate automatic recovery without need for user intervention for

• pod not connected (aka - ^C the rPi, observe various alerts on Trio-dev phone, then resume rPi and observe recovery)
• use front-end to crash after command
  • issue bolus command
  • rPi crashes, Trio-dev shows uncertain delivery alert
  • resume rPi, Trio-dev shows proper bolus in progress view, able to cancel bolus