Timer Ablauf
- udo1toni
- Beiträge: 15242
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Timer Ablauf
Dann spielt da irgendwas verrückt... ist aber ohne weiter Logs nicht ganz einfach, das zu finden...
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 181
- Registriert: 1. Sep 2018 18:24
Re: Timer Ablauf
Dachte ich mir. Ich gehe davon aus, dass Du die /var/log/openhab/openhab.log Datei meinst?
Puh...da hagelt es von Java Meldungen...Muss mich da jetzt erstmal durchackern....
Puh...da hagelt es von Java Meldungen...Muss mich da jetzt erstmal durchackern....

- udo1toni
- Beiträge: 15242
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Timer Ablauf
Das ist immer ein schlechtes Zeichen...
Fehlereingrenzung grundsätzlich: Erst mal alle Rules abschalten (Dateiendung ändern, in der UI inaktiv schalten), Neustart, Log beobachten, alle Fehler, die durch Bindings usw. entstehen fixen. Anschließend Rules Stück für Stück dazu schalten und nach Fehlern schauen. Evtl. zwischendurch noch mal neu starten, um zu verifizieren, dass weiterhin keine Fehler auftreten.
Fehlereingrenzung grundsätzlich: Erst mal alle Rules abschalten (Dateiendung ändern, in der UI inaktiv schalten), Neustart, Log beobachten, alle Fehler, die durch Bindings usw. entstehen fixen. Anschließend Rules Stück für Stück dazu schalten und nach Fehlern schauen. Evtl. zwischendurch noch mal neu starten, um zu verifizieren, dass weiterhin keine Fehler auftreten.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
- udo1toni
- Beiträge: 15242
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Timer Ablauf
Ich habe mir beide Rules noch mal angeschaut und sie noch mal etwas überarbeitet.
Es gab da noch einen Klammerfehler ([ statt {) in einem logInfo Befehl.
Ich habe auch weitere log-Befehle eingebaut, einfach um genauer sehen zu können, was die Rules gerade machen.
Insbesondere habe ich die log-Befehle etwas klarer aufgebaut. Im log kann man nach charge filtern, in der Meldung steht zu Beginn, welcher Teil hier loggt (timespan, schedule oder timer)
Die meisten der logInfo Befehle könnte man stattdessen als logDebug() eintragen, dann muss man nur über die Karaf Konsole den LogLevel erhöhen, um sie zu sehen bzw. verringern, um sie zu unterdrücken.
Es gab da noch einen Klammerfehler ([ statt {) in einem logInfo Befehl.
Ich habe auch weitere log-Befehle eingebaut, einfach um genauer sehen zu können, was die Rules gerade machen.
Insbesondere habe ich die log-Befehle etwas klarer aufgebaut. Im log kann man nach charge filtern, in der Meldung steht zu Beginn, welcher Teil hier loggt (timespan, schedule oder timer)
Die meisten der logInfo Befehle könnte man stattdessen als logDebug() eintragen, dann muss man nur über die Karaf Konsole den LogLevel erhöhen, um sie zu sehen bzw. verringern, um sie zu unterdrücken.
Code: Alles auswählen
var Timer tMyTimer = null // Globale Variablen zu Beginn definieren
rule "update timespan and eventually stop charging"
when
Item RenaultZEServices_Zoe_ChargeLevel changed or
Item RenaultZEServices_Zoe_Charging_Target changed
then
if(KebaPower.state == 0){ // umgekehrte Logik für Abbruchbedingung
logInfo("charge","timespan: KebaPower = 0, cancel Rule")
return;
}
if(KebaState.state != 3){ // umgekehrte Logik für Abbruchbedingung
logInfo("charge","timespan: KebaState = {}, cancel Rule",KebaState.state)
return;
}
var Number nChargeLevel = 0 // Default Wert, falls kein gültiger Wert
if(RenaultZEServices_Zoe_ChargeLevel.state instanceof Number) // falls gültiger Wert
nChargeLevel = (RenaultZEServices_Zoe_ChargeLevel.state as Number).floatValue // übernimm diesen Wert
var Number nChargeTarget = 0 // Default Wert, falls kein gültiger Wert
if(RenaultZEServices_Zoe_Charging_Target.state instanceof Number) // falls gültiger Wert
nChargeTarget = (RenaultZEServices_Zoe_Charging_Target.state as Number).floatValue // übernimm diesen Wert
logInfo("charge","timespan: Level: {} Target: {}",nChargeLevel,nChargeTarget)
var Integer nSoll
if(nChargeLevel >= nChargeTarget) // Ziel überschritten?
nSoll = 0
else if(nChargeLevel >= nChargeTarget - 4) // Ziel - 4 überschritten?
nSoll = 2
else if(nChargeLevel >= nChargeTarget - 10) // Ziel - 10 überschritten?
nSoll = 5
else if(nChargeLevel >= nChargeTarget - 20) // Ziel - 20 überschritten?
nSoll = 10
else // sonst
nSoll = 20
logInfo("charge","timespan: sSoll: {}",nSoll)
if(nSoll == 0 ) { // Ziel überschritten?
tMyTimer?.cancel // laufenden Timer abbrechen (falls vorhanden)
tMyTimer = null // Zeiger löschen
myTime.postUpdate(5)
KebaSwitch.sendCommand(OFF) // Default Zyklus setzen
logInfo("charge", "timespan: Charging target ({} %) for Zoe achieved. Switching off.", nChargeTarget)
sendBroadcastNotification("Ladeziel (" + nChargeTarget.toString + " %) erreicht. Schalte Ladevorgang ab.")
} else if(myTime.state != nSoll) { // weniger als x % bis zum Ladeziel
myTime.postUpdate(nSoll) // Zyklus anpassen
tMyTimer.reschedule(now.plusMinutes(nSoll)) // und Timer neu planen (optional)
}
end
rule "schedule charging timer"
when
Item KebaState changed or
Item KebaPower changed
then
if(KebaPower.state == 0){ // Ladegerät aus
logInfo("charge","schedule: KebaPower {}, abort Rule",KebaPower.state)
return;
}
if(KebaState.state != 3){ // Laden inaktiv
logInfo("charge","schedule: KebaState {}, abort Rule",KebaState.state)
return;
}
if(tMyTimer !== null) { // Timer existiert
logInfo("charge","schedule: tMyTimer already scheduled, abort Rule")
return;
}
tMyTimer = createTimer(now.plusSeconds(1), [| // Timer anlegen und gleich starten
val tSched = if(myTime.state instanceof Number) (myTime.state as Number).intValue else 0 // Zykluszeit in Minuten
logInfo("charge","timer: tSched = {}",tSched)
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)
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
}
])
end
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 181
- Registriert: 1. Sep 2018 18:24
Re: Timer Ablauf
Danke Udo. Ich habe jetzt alles so übernommen und habe - wie Du vorgeschlagen hast - Die rules nach und nach ausschalten.
Eine Kleinigkeit nocht: Du solltest nsoll nicht als Number, sondern als Integer deklarieren. Sonst gibt es den Konvertierungsfehler.
Will keep you posted
Eine Kleinigkeit nocht: Du solltest nsoll nicht als Number, sondern als Integer deklarieren. Sonst gibt es den Konvertierungsfehler.
Will keep you posted
-
- Beiträge: 181
- Registriert: 1. Sep 2018 18:24
Re: Timer Ablauf
Ich habe jetzt alle anderen Rules abgeschaltet und die letzte Version verwendet und siehe da: Es funktionert!
Eine Sache ich ist mir aufgefallen.
Ich habe wie Du auch vorgeschlagen hast einen Zeitstempel eingeführt, sodass ich sehen kann wann das nächste Update gemacht wird.
Das habe ich hier gemacht:
Dabei ist aufgefallen, dass nSoll nicht mit dem Zeitstempel übereinstimmt. Es ist immer um eine Iteration versetzt. Das heißt, wenn es nSoll auf 5 sich ändert, steht das nächste Update bei t+10min an. Und erst wenn nSoll sich auf 2 ändert, wird der Zeitstempel auf t+5 gesetzt.
Eine Sache ich ist mir aufgefallen.
Ich habe wie Du auch vorgeschlagen hast einen Zeitstempel eingeführt, sodass ich sehen kann wann das nächste Update gemacht wird.
Das habe ich hier gemacht:
Code: Alles auswählen
val StringBuilder strNext = new StringBuilder
if(tSched > 0) {
logInfo("charge","timer: Timer scheduled in {} Minutes!",tSched)
tMyTimer.reschedule(now.plusMinutes(tSched))
strNext.append(String::format("%1$02d:%2$02d", now.plusMinutes(tSched).getHour ,now.plusMinutes(tSched).getMinute))
myUpdateTime.postUpdate(strNext.toString)
}
- udo1toni
- Beiträge: 15242
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Timer Ablauf
Da müsstest Du bitte mal einen Auszug aus dem Log zeigen. In meinem Code habe ich folgende Grenzen gesetzt:
nChargeLevel größer oder gleich nChargeTarget -> Ladeabbruch
nChargeLevel maximal 4 kleiner als nChargeTarget -> 2-Minuten-Schritte
nChargeLevel mindestens 4 und maximal 10 kleiner als nChargeTarget -> 5-Minuten-Schritte
nChargeLevel mindestens 10 und maximal 20 kleiner als nChargeTarget -> 10-Minuten-Schritte
nChargeLevel mindestens 20 kleiner als nChargeTarget -> 20-Minuten-Schritte.
Die Schritte und die Schwellwerte habe ich rein willkürlich gewählt, dabei ging es nur um Beispielcode. Sobald nSoll neu berechnet wurde, wird der Timer neu gestartet, Dein beschriebenes Verhalten ist also eigentlich nicht möglich.
nChargeLevel größer oder gleich nChargeTarget -> Ladeabbruch
nChargeLevel maximal 4 kleiner als nChargeTarget -> 2-Minuten-Schritte
nChargeLevel mindestens 4 und maximal 10 kleiner als nChargeTarget -> 5-Minuten-Schritte
nChargeLevel mindestens 10 und maximal 20 kleiner als nChargeTarget -> 10-Minuten-Schritte
nChargeLevel mindestens 20 kleiner als nChargeTarget -> 20-Minuten-Schritte.
Die Schritte und die Schwellwerte habe ich rein willkürlich gewählt, dabei ging es nur um Beispielcode. Sobald nSoll neu berechnet wurde, wird der Timer neu gestartet, Dein beschriebenes Verhalten ist also eigentlich nicht möglich.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 181
- Registriert: 1. Sep 2018 18:24
Re: Timer Ablauf
Ich hatte keine Log-Ausgabe der Zeiten. Ich füge diese ein und beim nächsten Ladevorgang schicke ich den Auszug. Dauert ein paar Tage bis die Zoe wieder leer wird 

- udo1toni
- Beiträge: 15242
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Timer Ablauf
Im Log steht immer die Zeit mit drin, ganz vorne... im Klartext... da musst Du nichts mit einfügen. Oder meinst Du die geplante Zeit für die nächste Timer-Ausführung? Wie erwähnt musst Du dabei bedenken, dass Du das bei Dir am Ende des Timers eingebaut hast. Das heißt, Der teimer läuft bereits mit der neuen Zeit und verkündet dann den nächsten Startzeitpunkt.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 181
- Registriert: 1. Sep 2018 18:24
Re: Timer Ablauf
Seltsam. In der LOG passt es:
Ich werde das nochmal in der UI beobachten und berichten
Code: Alles auswählen
2022-02-07 14:03:47.926 [INFO ] [org.openhab.core.model.script.charge] - timer: tSched = 20
2022-02-07 14:03:54.221 [INFO ] [org.openhab.core.model.script.charge] - timespan: Level: 67.0 Target: 80.0
2022-02-07 14:03:54.227 [INFO ] [org.openhab.core.model.script.charge] - timespan: sSoll: 10
2022-02-07 14:03:54.237 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Status Plugged null
2022-02-07 14:03:58.642 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Vehicle Plugged Found 1 vehicle
2022-02-07 14:03:58.644 [INFO ] [org.openhab.core.model.script.charge] - timer: Timer scheduled in 20 Minutes!
2022-02-07 14:23:58.649 [INFO ] [org.openhab.core.model.script.charge] - timer: tSched = 10
2022-02-07 14:24:05.364 [INFO ] [org.openhab.core.model.script.charge] - schedule: tMyTimer already scheduled, abort Rule
2022-02-07 14:24:05.556 [INFO ] [org.openhab.core.model.script.charge] - timespan: Level: 75.0 Target: 80.0
2022-02-07 14:24:05.561 [INFO ] [org.openhab.core.model.script.charge] - timespan: sSoll: 5
2022-02-07 14:24:05.572 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Status Plugged null
2022-02-07 14:24:09.912 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Vehicle Plugged Found 1 vehicle
2022-02-07 14:24:09.915 [INFO ] [org.openhab.core.model.script.charge] - timer: Timer scheduled in 10 Minutes!
2022-02-07 14:34:09.918 [INFO ] [org.openhab.core.model.script.charge] - timer: tSched = 5
2022-02-07 14:34:15.498 [INFO ] [org.openhab.core.model.script.charge] - timespan: Level: 79.0 Target: 80.0
2022-02-07 14:34:15.507 [INFO ] [org.openhab.core.model.script.charge] - timespan: sSoll: 2
2022-02-07 14:34:15.519 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Status Plugged null
2022-02-07 14:34:19.859 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Vehicle Plugged Found 1 vehicle
2022-02-07 14:34:19.863 [INFO ] [org.openhab.core.model.script.charge] - timer: Timer scheduled in 5 Minutes!
2022-02-07 14:39:19.867 [INFO ] [org.openhab.core.model.script.charge] - timer: tSched = 2
2022-02-07 14:39:26.121 [INFO ] [org.openhab.core.model.script.charge] - timespan: Level: 81.0 Target: 80.0
2022-02-07 14:39:26.124 [INFO ] [org.openhab.core.model.script.charge] - timespan: sSoll: 0
2022-02-07 14:39:26.128 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Status Plugged null
2022-02-07 14:39:26.129 [INFO ] [org.openhab.core.model.script.charge] - timespan: Charging target (80.0 %) for Zoe achieved. Switching off.
2022-02-07 14:39:30.930 [INFO ] [org.openhab.core.model.script.charge] - timer: results_Vehicle Plugged Found 1 vehicle
2022-02-07 14:39:30.932 [INFO ] [org.openhab.core.model.script.charge] - timer: Timer scheduled in 2 Minutes!