Have the Loop Insulin Delivered start at 0 U despite variable priming amounts reported from Pod

[itsmojo]

No description provided.

[ps2]

When I was testing this, immediately after pairing I do see that the initial reading on the settings pages is 0.2U, so there does seem to be an issue that needs fixing here. But it's not off by 0.5, which this change implements. When I run this code, I end up with -0.3 U showing on my Pod Settings page, immediately after pairing.

Are we having inconsistent values for the post-pairing StatusResponse.insulin field? I'll attach an Issue Report here, in case it is useful to compare against a pod that is returning a different initial value.

[ps2]

Loop Report 2019-12-06 21:22:59-06:00.md.zip

[itsmojo]

From a detailed examination of this Loop Report and others, the pod status after the 2.6U prime bolus has completed doesn’t report having delivered 2.6U. I’ve seen values ranging from 2.15U to 2.3U looking at about a dozen samples. Then in the cases I examined in detail, there was always was to another 0.5U more delivered as expected for the cannula insert. In the example Loop Report, 2.3U were reported as delivered after the prime bolus and 2.8U after the cannula insert instead of the expected 2.6U+0.5U=3.1U and this difference was the -0.3U reported when the 0.5U cannula insertion bolus amount is subtracted. To have the reported insulin delivered value reported to the user to be 0 right after a new Pod is paired, it seems that we need to have an additional persistent Podstate optional variable for reported insulin delivered after the pod setup process has completed and then subtract this value from the reported insulin delivered value when updateFromStatusResponse() uses PodInsulinMeasurements(). I have already done a prototype of this using a setupInsulinDelivered: Double? PodState variable and it seems to work well, but there were a few corner cases to properly handle a few situations. When this optional variables isn’t set in PodInsulinMeasurements (either when a Pod is first being setup and hasn’t completed its setup it yet or when a new version of Loop is installed with this feature that didn’t get to initialize this optional variable at startup time), then self.delivered would be set to max(0, statusResponse.insulin - Pod.primeUnits - Pod.cannulaInsertionUnits) so that at no time will the delivered insulin value be a negative value. This one line change could be used to close out this PR and then another PR used for the reported prime insulin mismatch OR we could just update this PR for the more general problem and then an additional larger commit for this PR.

[ps2]

Sounds like we should track a primeUnitsDelivered variable in pod state.

[itsmojo]

When we have an actual prime command (as per #566), I would think that counting any manual priming amounts towards a primeUnitsDelivered variable in the pod state might be confusing to the user. If a user would do a manual prime operation, they would expect to to see the reported Insulin Delivered pod status to change accordingly just like on a Medtronic pump they'd expect to see the units left in the reservoir go down on each prime operation. But since the Pod doesn't report a reservoir value when > 50U, there would be no way for a user to see any prime operation affect any pod state in most cases. That is why I was leaning toward calling it a setupInsulinDelivered pod state variable instead which would be set to the pod's reported insulin delivered value on the transition into pod progress 8 (when the pod setup is complete and the pod is available for general use). Another uber simple approach would be to give up on doing any insulin delivered amount adjustments and just report the raw pod insulin delivered value; high end users would just learn that a variable amount of insulin is delivered at pod setup time. Heck, we didn't realize that this was even happening until almost a year of Omnipod Loop use.

[itsmojo]

I decided to implement a new setupUnitsDelivered PodState variable as part of this PR since I never got any feedback on how to proceed on this despite numerous requests. So now using this persistent optional variable, Loop will always start with a reported Insulin Delivered value of 0 U despite a variable amount of insulin delivered being reported as delivered for fixed prime & cannula insertions bolus operations and will now do a reasonable job estimating the actual amounts without ever being negative if this optional variable is not available.

[ps2]

Thanks Joe!