* origin/dev:
bulgarian removed non-translatable
synchronize interval access
nsclient remove debug data that puts stress on the broadcast system 3
nsclient remove debug data that puts stress on the broadcast system 2
nsclient remove debug data that puts stress on the broadcast system
Align OpenAS(A)MA fragments with layout of other fragments.
local broadcasts better setting title
setting to disable local broadcasts in NSClient
removed some "unneeded" translations
wear tdd weighted
wear TDD status
wear menu simplification
Translated latest additions strings.xml
ns client quickfix now catch all
NS client quickfix - catch even more
catch TransactionTooLargeException
TT new "old" logic for temp targets
TT refactor OverlappingIntervals to two classes with an abstract superclass Intervals
# Conflicts:
# app/src/main/res/values/strings.xml
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
