Ja, das ist es... Manchmal muss man das große Ganze sehen, um ein Detail zu erkennen...
Man sehr schön sehen, dass zunächst der Timer endet (z.B. 14:03:43) und unmittelbar tSched ausliest. ziemlich genau zu dem Zeitpunkt wird auch die erste Abfrage gestartet, welche in einem Log um 14:03:54 mündet. In der Zwischenzeit hat die timespan Rule nSoll und auch das zugehörige Item verstellt. Der Timer wurde erneut geplant. Der Timer-Code läuft zu diesem Zeitpunkt aber noch und die zweite Abfrage braucht auch noch mal 4 Sekunden. Anschließend plant sich der Timer selbst erneut ein, die Zeit ist aber die von vor 14 Sekunden...
Die Lösung ist deshalb denkbar einfach:
Verschiebe die Zeile
Code: Alles auswählen
val tSched = if(myTime.state instanceof Number) (myTime.state as Number).intValue else 0 // Zykluszeit in Minuten
unmittelbar vor das if(tSched > 0), seiht dann so aus:
Code: Alles auswählen
tMyTimer = createTimer(now.plusSeconds(1), [| // Timer anlegen und gleich starten
val results_status = executeCommandLine(Duration.ofSeconds(30), "sudo", "-u", "openhabian", "/usr/local/bin/pyze", "status", "--km")
logInfo("charge", "timer: results_Status Plugged {}", results_status)
val results_vehicle = executeCommandLine(Duration.ofSeconds(30),"sudo", "-u", "openhabian", "/usr/local/bin/pyze", "vehicles")
logInfo("charge", "timer: results_Vehicle Plugged {}", results_vehicle)
val tSched = if(myTime.state instanceof Number) (myTime.state as Number).intValue else 0 // Zykluszeit in Minuten
if(tSched > 0) {
logInfo("charge","timer: Timer scheduled in {} Minutes!",tSched)
tMyTimer.reschedule(now.plusMinutes(tSched))
} else {
logInfo("charge","timer: no reschedule for Timer!")
tMyTimer = null
}
])
Auf die Logzeile können wir dann auch verzichten, da im if-Block auf jeden Fall eine Ausgabe erfolgt.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.2.2, LXC), mit openHABian eingerichtet