Bug notes.
(cherry picked from commit c553626)
This commit is contained in:
parent
8487364aa0
commit
b03202f3d3
|
@ -17,11 +17,12 @@ Limitations:
|
|||
- Setting a basal profile other than 1 on the pump, or delivering extended boluses or multiwave
|
||||
boluses from the pump will disable the loop functionality for 6h as the the loop can't run
|
||||
safely under those conditions.
|
||||
- If multiple boluses are given within a single minute, only one might
|
||||
- If multiple boluses are given within a single minute, only one will
|
||||
be recognized. This is due to the Combo saving history records with
|
||||
minute-precision only. However, this case is only possible for very
|
||||
small boluses and is unlikely to occur in non-testing scenarios
|
||||
(e.g. bolusing from the pump and then immediately bolusing from AAPS).
|
||||
(e.g. bolusing from the pump and then immediately bolusing from AAPS
|
||||
or giving smaller boluses in the pump in quick succession).
|
||||
- If a TBR is set on the pump, AAPS will cancel it. This is because it's not possible to determine
|
||||
the start point of a TBR until it is finished or was cancelled at which point a record in the
|
||||
pump's history is created. Before that, there is none and it's simply not possible to determine
|
||||
|
|
|
@ -1,4 +1,18 @@
|
|||
- [x] Bugs
|
||||
- [ ] Bugs
|
||||
- [ ] Pump becoming unresponsive every 8-20 or so, only reacting
|
||||
again when physically pressing a button on the pump ...
|
||||
- [ ] Temp basal history shows TBRs twice, once with a 1 min
|
||||
duration and then with the reminder; caused by clock not
|
||||
being within ~30s of the phone.
|
||||
Cancelling TBR or overriding a running one with a new one
|
||||
(both cases require a TBR end record) require an end TBR record.
|
||||
checkTbrMismatch causes history read and TBR is right in AAPS
|
||||
so far and any TBR set on the pump is cancelled, so it works,
|
||||
but isn't clean. Needs some rethink - with a fresh mind -
|
||||
maybe understanding what DanaR does, how to translate it to
|
||||
the Combo.
|
||||
Explicit end records when adding pump history records;
|
||||
and/or: logic to detect time differences and align data
|
||||
- [x] Deleting a bolus from the history re-adds it from the pump's
|
||||
history. Deleting it again, flags it as invalid at which point
|
||||
it will not be added to IOB and not be re-added.
|
||||
|
@ -88,13 +102,6 @@
|
|||
- [x] Option to raise overview notifications as android notification with noise (for urgent ones?)
|
||||
- [ ] Next version(s)
|
||||
- [ ] State in ComboPump is not safely shared among threads
|
||||
- [ ] Cancelling TBR or overriding a running one with a new one
|
||||
is likely buggy (in both cases requiring a TBR end record)
|
||||
checkTbrMismatch causes history read and TBR is right in AAPS
|
||||
so far and any TBR set on the pump is cancelled, so it works,
|
||||
but isn't clean. Needs some rethink - with a fresh mind -
|
||||
maybe understanding what DanaR does, how to translate it to
|
||||
the Combo
|
||||
- [x] Naming is messed up: pump has warnings and errors, which cause alerts; W+E are thus alerts,
|
||||
e.g. pumpAlertHistory should be renamed to alertHistory
|
||||
- [ ] Enable BT if disabled? does dana does this?
|
||||
|
|
|
@ -825,8 +825,7 @@ public class ComboPlugin implements PluginBase, PumpInterface, ConstraintsInterf
|
|||
long lastViolation = 0;
|
||||
if (commandResult.state.unsafeUsageDetected) {
|
||||
lastViolation = System.currentTimeMillis();
|
||||
}
|
||||
if (commandResult.lastBolus != null && !commandResult.lastBolus.isValid) {
|
||||
} else if (commandResult.lastBolus != null && !commandResult.lastBolus.isValid) {
|
||||
lastViolation = commandResult.lastBolus.timestamp;
|
||||
} else if (commandResult.history != null) {
|
||||
for (Bolus bolus : commandResult.history.bolusHistory) {
|
||||
|
|
Loading…
Reference in a new issue