The previous behavior was reading the profile correctly, but the progress
report was off by one factor. Also, blinking screens were considered as
separate ones, causing the short button press based fallback to kick in
unnecessarily often because that blinking screen behavior caused the
main long button press based reading loop to miss the last profile factor.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
* device is unpaired while discovery is ongoing" does not happen because
discovery only occurs if no device is paired.
* Using the second offered BluetoothDevice works reliably on all tested
phones so far.
* AndroidBluetoothDevice throws a BluetoothException if all of its
internal connect attempts fail.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
When exiting the basal profile screens by pressing CHECK twice, a
vibration happens. This can be avoided by instead pressing BACK until
the main screen is reached.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
* Don't set a fake 100% TBR again if the current fake 100% TBR
is finished within 15 minutes (reduces number of TBR operations
and allows the Combo to return to a non-TBR state).
* If the expected TBR percentage was a non-100% one, but not we see
a non-TBR main screen, check if the expected TBR duration was <= 2
minutes. This covers the edge case when the TBR ends at the same
time when we run this check.
* Inform callers about the exact outcome of the setTbr() call. It could
be that it set the TBR normally. Or, it might have set a fake 100% TBR
(if the user requested a 100% TBR and force100Percent was set to false),
and so on.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
After a long button press, short button presses may be necessary to
fix "overshoots". An alert screen may appear during those short button
presses, so look at the screens to make sure alerts are not missed.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
The code in adjustQuantityOnScreen() needs an current quantity. This is
determined during the long button press. If no such long button press
happens, get the quantity by explicitly receiving parsed frames. But
don't read those parsed frames if a long button press happened; this
is redundant and just slows down the function.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
In particular, if a bolus brings the reservoir level below the low
threshold, a W1 warning shows up on the pump itself during bolus delivery.
Once delivery is done, the W1 shows up in the RT mode as well. Bolus
delivery is special in that the deliverBolus() function has to manually
switch back to RT mode to get the reservoir level post-bolus to update
the reservoirLevel value. When that is done, the aforementioned alert
screen can show up. Add code to handle alert screen handling to that
special post-bolus check.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
This is important for example if the Combo is not properly configured
and the user tries to set a TBR percentage beyond the configured limit.
The RT UI will then clamp the percentage to that limit, and the quantity
won't increase anymore. Without this new check, this causes the code
to be stuck in an endless loop.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
The new implementation overshoots less often, runs generally faster,
and correctly forwards exceptions thrown by the checkScreen callback.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
There's no reason to use the full navigation function to switch from the
TBR percentage to the TBR duration screen, since these are next to each
other, and switching over is done by pressing MENU once.
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
