Rarely there seem to be timing issues and e.g.
10 button down presses to go from 100% to 0% only goes down to 20%.
Retry two more times in that case, restarting the input process on the
active screen (bolus input, tbr percent/duration input).
AAPS seems to still try to issue commands (like cancel TBR,
though none is running?)), despite showing "Pump suspended"
on the home screen.
With the DanaR, AAPS also tries to run commands when the
pump is suspended, but there, the treatment is logged
as being administered despite the pump not having done that.
Here, the pump response with success=false, enacted=false,
which causes the ComboPlugin class to NOT create any
treatments. No errors are raised, as this is considered a regular
state: no treatments are enacted, overview screen shows
"pump suspended" and the combo beeping away.
That AAPS still tries to issue TBR commands ... that's AAPS'
problem for now. Buttons to issue boluses are hiden though.
Otherwise the disconnect thread will close the connection
due to inactivity. We could add a variable 'isConnecting',
but I'm not sure if adding another (ruffy-) global state
variable will make things simpler to grasp.
Note: connection timeouts are also dealt with. They're now (cleanly)
separated: connect- and command-timeouts.
If the pump's display is one due to the user interacting with the pump
directly, the pump needs a display timeout before being ready for an
incoming connection. What I'm trying to say is, it might take some time,
maybe up to 30s to establish a connection in that cause and can thus
easily create a false timeout error.
* Add info about last command ran to the Combo tab
* Don't refresh data more than once a minute.
* Specify not only error, but also command that raised the error in
alert notification
* Keep track of connection status rather than relying in IRuffyService.isConnected
* Abort running command if pump stops sending menu updates
* Fail if ruffy goes away (binding becomes invalid), currently only if this happens during disconnect attempts
