Use Two Decimals for Insulin Remaining

[databoy2k]

This allows the Overview ("Home") screen to show two decimal points if the insulin remaining is <50U. This is useful for issuing boluses that use up all of the remaining reservoir without having to check the reservoir amount in the pump's settings.

Use Case for Explanation:

1. I use Omnipod Dash with AAPS. Often, towards the end of the pump, I will want to issue a bolus that empties the reservoir (at least as empty as the Dash will allow it, since it doesn't actually report 100% of the insulin in it) before changing to a new pump.
2. The current overview/"Home" tab rounds the reservoir value to the nearest whole number. The Dash reports to two decimals (hudredths of a unit). If you go by the overview screen, you can issue a bolus that results in an error (Not enough insulin in reservoir) or that doesn't empty the pump (up to 0.45U remaining). You don't know which without checking the unrounded number.
3. Current workflow to do this is to go to the "Dash" menu and check the "Reservoir" value, then return to the "Home" menu to tap "Insulin" and deliver that value. This is time consuming, especially if you're about to switch out the pump and go through that process anyway.

This PR thus changes the home screen to show, e.g. "1.95U" remaining at the end of a pump, so that without changing tabs one can issue a bolus of 1.95U. Note that the current home screen would show "2U" but issuing that bolus would result in an error.

Using this on a Pixel 8. I havent' run into any UI glitches or issues with space.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[databoy2k]

Feedback from iceman & ga-zelle on Discord proposed staggered if- statements to only show two decimals if reservoir < 10u to avoid showing "50.00"U. It's two more characters than the current "50U+" so I don't know if it really throws off other resolutions or use cases. I could try to implement the staggered numbers as well, but I figured the less I touch the code the better.

Also for discussion ;)

[Philoul]

I think we can't add 2 additional number in all situation

• Status Light row can be 100% full of information so 2 addition digits plus dot will lead to issue or double row for a lot of users (not only in small res screen).
• it make no sens to have 2 decimal when you have more than 50U, 100U or 200U in reservoir...
• I also don't think reservoir level accuracy is consistant with 2 digits...

My proposal would be to keep integer value above 10U, and add only one decimal below 10U.
-> This will not increase max width for res level information and should improve the precision when reservoir level is low.

[databoy2k]

To be clear, this modification doesn't care if the reservoir level report is consistently accurate; it's entirely how much remains in the omnipod's brain. It actually keeps a reserve long after the reservoir is exhausted (probably about 2U?) so it's overreporting, not under.

My proposal would be to keep integer value above 10U, and add only one decimal below 10U. -> This will not increase max width for res level information and should improve the precision when reservoir level is low.

Unfortunately that still isn't the right level of specificity. To be clear, the thing that I'm trying to stop is issuing a bolus based on the home screen and then getting an error saying that I can't actually issue that bolus due to rounding. Even if we rounded to one decimal, omnipod reports/thinks in two. E.g. if reservoir has 1.35, the screen reports 1.4, you issue 1.4, and you get an error.

Could we lose the unit "U" <5U or something like that? Now we're only adding one more character as proposed but we're still keeping specificity.

--Edits-- for clarity, but one more thought:
Would it make sense to make the two decimals contingent on the status light row only showing omnipod and a sensor? I don't know what else appears on the status light row, but if it's omnipod you get pod age, reservoir, and sensor age.

[Philoul]

Instead of rouding value, then you can use Math.floor(resLevel*10.0)/10.0 to always have value less or equal to resLevel with one decimal 🤔

As an example of status light (keep in mind that this example is not the worse case because you can have with some sensor an additional percentage for "sensor battery level" and some values can have one more character...)

[MilosKozak]

My personal opinion is that the reason (flushing out insulin to the last drop) is a nonsence. You never know what will happen at the end of reservoir

[databoy2k]

Instead of rouding value, then you can use Math.floor(resLevel*10.0)/10.0 to always have value less or equal to resLevel with one decimal 🤔

That would work. There's still something very cheap within me that doesn't like the idea of wasting 0.9U when it gets rounded down, but if we're at that kind of premium then I suppose it can't be helped. I would challenge that a patch pump still doesn't show more than two status lights (pump age and insulin reservoir) so even the screenshot shows enough real estate for one more character, but that was also my reason for raising this during a beta period as well or in dev for feedback to see if anyone was bothered by it.

My personal opinion is that the reason (flushing out insulin to the last drop) is a nonsence. You never know what will happen at the end of reservoir

As stated, I don't think the Dash's reservoir reports 100% of the insulin in it. I know that when I issue the final bolus on a pump (e.g. 2.25U yesterday after work), I can leave the pump on and it will continue my basal rate, including clicking and keeping me level for at least another two hours. So the reservoir report is clearly not every last drop.

Canada and the USA both pay for our insulin, many of us out of pocket. I'm particularly cheap - it would bother me to throw out up to 0.9U per pump that I could deliver easily with this PR. That's 164U/year thrown out - that's a whole pump fill for me. No reason to be wasteful if a rounding error can be corrected.

One other thought: would it make more sense (and be more space-respecting) to have the reservoir reflected in the bolus screen? I wouldn't even know where to begin adding that line, but at least then we're not issuing a bolus that AAPS reports that we can issue but we can't (again, e.g. if we have 2.75U in the reservoir and AAPS is reporting 3U on the home screen - you will get an error for issuing that 3U bolus).

[Philoul]

With my proposal, it's not 0.9U but 0.09U max that can be lost...

• reservoir level with one decimal only if level is below 10U, and rounded "floor"

Concerning Bolus (and/or calculator), you can open an issue as "enhancement or feature request", to provide a visual information when bolus amount is over remaining reservoir level.

Note that in my mind it should only be an information, but not more (no limitation or things like that...). But it could be with a little warning triangle, bolus amount in red color or something like that (again to not include additional information to windows or popup that are already full...)

[databoy2k]

It's up to you guys as the main developers. Happy to try the float solution or just close it and keep my little fork alive.

Considering the status lights are currently the only way to predict whether you will get an error of "not enough in reservoir" before issuing a bolus, it makes sense to have that be accurate or at worst not rounded up. It's not just for trying to extract the last 0.35U... yesterday at the end of my pump i needed to 5u bolus and if there were only 4.95u, without this change i would have errored out. I could tell that there was 4.95 left thanks to this so that's what i issued.

I propose merge and let the dev users let us know if it crowds the lights. But again: I'm just a potential contributor and you guys have a way better view of what the software needs.

[koelewij]

Keep in mind that the status light is not always a 100% up to date. The basal rate reduces the reservoir also, and you really need to refresh to get the latest reservoir update.
So even with 2 decimals visible on the status light you might run into a rejected bolus due the the mismatch between AAPS and the pods internal counter.
So the one digit with floor proposal from @Philoul would be a better solution in my opinion.
On the other hand, a short check of the Dash page with a refresh solves the issue.
And even then, between the check and the bolus, the Dash might have given 0.05U anyway and you still cannot bolus.

[Philoul]

Hum, I think you are trying to propose here a workaround concerning a pump limitation (or a pump driver limitation)...

I don't know how Dash pump and Dash driver works, but with my Insight pump, it is just a "no topic"...
When I want a bolus (whatever bolus amount and remaining insulin within reservoir) bolus is sent to the pump, and delivered until reservoir is empty.
Then I receive a warning to change reservoir.
I have 15min to change reservoir then when I restart the pump, I just have to resume current pending bolus and it's recorded to AAPS database.
If I take more time to change reservoir and restart the pump, then I can't resume the bolus but the partial amount delivered is recorded in AAPS database.

This way of working is inside Insight pump, and pump driver just manage pump history synchronization with AAPS to record delivered amount instead of requested amount.

I don't know in this specific use case how the other tube pump works (like Dana pumps), or how patch pump with reusable HW (like medtrum) works 🤔.
This feature could probably be included in pump driver if technically not possible within pump (dash, eros, ...).

[databoy2k]

So the one digit with floor proposal from @Philoul would be a better solution in my opinion.

Makes sense to me. I can safely say that I have yet to encounter a "basal rate reduced reservoir before status light updated so I don't have enough insulin to deliver the bolus" issue, but I suppose that it is theoretically possible. The only thing I've noticed is that the pump happily delivers basal insulin even when the reservoir (reported by Dash screen or status light) reads zero. I assumed that the report was of some sort of a "main" tank with a "reserve" tank that wasn't reported and limited to basal for safety. Anyone who's operated an ATV/Snowmobile/Jetski probably understands the analogy.

On the other hand, a short check of the Dash page with a refresh solves the issue. And even then, between the check and the bolus, the Dash might have given 0.05U anyway and you still cannot bolus.

The short check of the Dash page is exactly what I'm trying to avoid and this is exactly why. Thank you for highlighting the issue.

@Philoul your explanation of Insight's operation explains why this was so difficult. Frustratingly, the Dash simply errors out if you tell it to issue a bolus larger than what it reports is available. With the status light rounded to whole numbers, it's entirely too easy to issue too much of a bolus by 0.05U and get a stupid error. Not a lot of fun for a dad of three kids who's only had this disorder for a few years and is still somewhat irritated by the whole thing - when I tell it to prebolus, that's probably because I'm in the process of putting food on three plates while children do their thing. Absolutely zero chance that I'm taking the time to change pages, refresh, pray that it doesn't drain past its current estimate, and try to issue the bolus again.

In other words, I'm trying to avoid cussing at AAPS over something that's fairly easily changed in the code, and I'm guessing I'm not the only one who hates those moments.

I'll make the change in the proposal assuming I can figure out how.

--Edit--
Needing some feedback on how the change should be made. I'm planning to change the current "else" statement to an "else if level >=10 && level <maxReading..." but then the final "else" should fully replicate handleLevel except for the decimalFormatter line in line 114 (change that to math.floor)?

Or should I change handleLevel itself to consider whether it's a patchpump and then implement the new logic into it? It might make handlePatchReservoirLevel redundant that way.

[vanelsberg]

This proposal makes no sense to me.

1. Use case (emptying reservoir until the last drop) is an exception. During day-to-day use user "never" run into this.
2. Overview reservoir level imho is only ment as an indication. It is never accurate, especially when it would show 2 decimal digits. DASH f.i. is continuously doing multiple clicks of 0.05 for maintaining basal rate so showing 1 or 2 decimal digits will almost never show the actual reservoir level.
3. Even reservoir level (on the DASH tab) is never 100% accurate (is only showing value on last state refresh).

In general: showing 2 digits imho would only make overview "less accurate", i.e suggesting accuracy that isn't.