Clean up using warning codes instead of message.

This commit is contained in:
Johannes Mockenhaupt 2017-10-30 21:47:44 +01:00
parent 522b5e9e1b
commit 1658ed14c9
No known key found for this signature in database
GPG key ID: 9E1EA6AF7BBBB0D1
6 changed files with 20 additions and 17 deletions

View file

@ -23,6 +23,7 @@ import org.slf4j.LoggerFactory;
import java.util.Date;
import java.util.List;
import java.util.Objects;
import de.jotomo.ruffy.spi.BasalProfile;
import de.jotomo.ruffy.spi.BolusProgressReporter;
@ -766,29 +767,29 @@ public class RuffyScripter implements RuffyCommands {
long timeout = System.currentTimeMillis() + maxWaitMs;
while (System.currentTimeMillis() < timeout) {
if (getCurrentMenu().getType() == MenuType.WARNING_OR_ERROR) {
// Note that the message is permanently displayed, while the error code is blinking.
// A wait till the error code can be read results in the code hanging, despite
// menu updates coming in, so just check the message.
WarningOrErrorCode warningOrErrorCode = readWarningOrErrorCode();
if (warningOrErrorCode.errorCode != 0) {
// TODO proper way to display such things in the UI;
throw new CommandException("Pump is in error state");
}
int displayedWarningCode = warningOrErrorCode.warningCode;
String errorMsg = (String) getCurrentMenu().getAttribute(MenuAttribute.MESSAGE);
String errorMsg = null;
try {
errorMsg = (String) getCurrentMenu().getAttribute(MenuAttribute.MESSAGE);
} catch (Exception e) {
// ignore
}
if (displayedWarningCode != warningCode) {
throw new CommandException("An alert other than the expected warning " + warningCode+ " was raised by the pump: "
throw new CommandException("An alert other than the expected warning " + warningCode + " was raised by the pump: "
+ displayedWarningCode + "(" + errorMsg + "). Please check the pump.");
}
// confirm alert
verifyMenuIsDisplayed(MenuType.WARNING_OR_ERROR);
pressCheckKey();
// dismiss alert
verifyMenuIsDisplayed(MenuType.WARNING_OR_ERROR);
pressCheckKey();
/* // TODO multiple alerts in a row ... can this occur in non-freak circumstances?
waitForMenuToBeLeft(MenuType.WARNING_OR_ERROR);*/
return true;
}
SystemClock.sleep(10);

View file

@ -26,11 +26,12 @@ public abstract class BaseCommand implements Command {
// error message ist still needed to cancel TBR though, let next-gen ruffy take care of that?
/**
* An alarm (or null) caused by a disconnect we can safely confirm on reconnect,
* A warning id (or null) caused by a disconnect we can safely confirm on reconnect,
* knowing it's not severe as it was caused by this command.
* @see de.jotomo.ruffy.spi.PumpWarningCodes
*/
@Override
public String getReconnectAlarm() {
public Integer getReconnectWarningId() {
return null;
}

View file

@ -48,8 +48,8 @@ public class BolusCommand extends BaseCommand {
}
@Override
public String getReconnectAlarm() {
return "BOLUS CANCELLED";
public Integer getReconnectWarningId() {
return PumpWarningCodes.BOLUS_CANCELLED;
}
@Override

View file

@ -5,6 +5,7 @@ import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import de.jotomo.ruffy.spi.PumpState;
import de.jotomo.ruffy.spi.PumpWarningCodes;
// TODO robustness: can a TBR run out, whilst we're trying to cancel it?
// Hm, we could just ignore TBRs that run out within the next 60s (0:01 or even 0:02
@ -13,8 +14,8 @@ public class CancelTbrCommand extends BaseCommand {
private static final Logger log = LoggerFactory.getLogger(CancelTbrCommand.class);
@Override
public String getReconnectAlarm() {
return "TBR CANCELLED";
public Integer getReconnectWarningId() {
return PumpWarningCodes.TBR_CANCELLED;
}
@Override

View file

@ -18,5 +18,5 @@ public interface Command {
boolean needsRunMode();
void execute();
CommandResult getResult();
String getReconnectAlarm();
Integer getReconnectWarningId();
}

View file

@ -52,8 +52,8 @@ public class SetTbrCommand extends BaseCommand {
}
@Override
public String getReconnectAlarm() {
return "TBR CANCELLED";
public Integer getReconnectWarningId() {
return PumpWarningCodes.TBR_CANCELLED;
}
@Override