Counter ist vermutlich kein Item (die vollständige Meldung besagt ja, dass postUpdate kein Member von java.lang.Integer ist)
Ganz unabhängig davon ist die Umsetzung aber ziemlich ineffizient.
Punkt eins in der "dummen" Version: Du triggerst auf
received update, die Rule müsste aber nur auf
changed reagieren (streng genommen sogar nur auf
changed to ON).
Punkt zwei ist das stumpfe Reagieren auf Zeit.
Besser: reagiere auf Änderungen von Messwerten. Prüfe dann vor dem Schalten der Pumpe, ob sie in den letzten fünf Minuten geschaltet wurde. Ist das der Fall, verschiebst Du das Schalten mittels Timer, etwa so:
Code: Alles auswählen
var Timer tPumpe = null
rule "Wartung Poolfilter"
when
Item pumpswitch changed
then
var strMessage = "Betriebsbereit"
if(newState == ON) {
strMessage = "Wartung"
if(Shelly03_switch.state != OFF) Shelly03_switch.sendCommand(OFF)
}
logInfo("Pool", strMessage)
end
rule "Pool Pumpe"
when
Item House_PowerOut changed
then
val iPower = if(newState instanceof Number) (newState as Number).intValue else 0
if(tPumpe !== null) {
logDebug("pool","Taktsperre, Abbruch")
return;
}
if(pumpswitch.state != OFF){
logDebug("pool","Wartung aktiv, Abbruch")
return;
}
var soll = Shelly03_switch.state
if(iPower >= 1200) soll = ON
if(iPower <= 100) soll = OFF
if(Shelly03_switch.state != soll) {
logInfo("pool","Pool Pumpe {}",if(soll == ON) "an" else "aus")
Shelly03_switch.sendCommand(soll.toString)
tPumpe = createTimer(now.plusMinutes(5),[|tPumpe = null])
}
end
Die erste Rule kümmert sich wie gehabt um den Wartungsmodus. Mit dem Unterschied, dass der Shelly nur dann ausgeschaltet wird, wenn dies auch tatsächlich notwendig sein sollte.
Die zweite Rule prüft bei jeder Änderung des aktuellen Wertes von House_PowerOut, ob ein Timer tPumpe existiert. Ist das der Fall, so bricht die Rule ab. Im weiteren Verlauf prüft die Rule, ob der Wartungsschalter aktiv ist und bricht gegebenenfalls ab.
Danach setzt die Rule eine lokale Variable
soll auf den aktuellen Status des Shelly. Anschließend prüft es die Grenzwerte ab und ändert gegebenenfalls die lokale Variable.
Zum Abschluss prüft die Rule, ob die lokale Variable vom Istzustand abweicht und schaltet gegebenenfalls den Shelly um. Nur in diesem Fall wird der Timer gesetzt, dessen einzige Funktion es ist, den Zeiger auf sich selbst zu löschen.
Da durch die PV der Wert im Item House_PowerOut ohnehin ständig wechseln dürfte, wir die Rule immer zeitnah erneut ausgeführt.
Wenn der Betriebszähler korrekt eingerichtet ist, reicht es, die OFF-Bedingung passend zu ergänzen:
Für den Counter gibt es letztlich zwei Möglichkeiten, nämlich entweder mit Variable oder mit Item. Beide Optionen sind gut, aber die Befehle sind unterschiedlich.
Für die Variante mit Item spricht, dass Du ohne Umweg das Item in der UI anzeigen lassen kannst. Die Option mit der Variablen könnte dafür unterm Strich mit weniger Code auskommen.
Auch hier wäre vermutlich ein anderer Trigger besser:
Code: Alles auswählen
var iCounter = 0 // löschen, falls Item
rule "Reset Laufzeit"
when
Time cron "0 0 0 * * ?" // täglich, 0:00:00 Uhr
then
iCounter = 0 // löschen, falls Item
Counter.postUpdate(0) // löschen, falls globale Variable
end
rule "Laufzeit"
when
Item Shelly03_switch changed
then
if(newState == OFF) {
var iCounter = 0 // löschen, falls globale Variable
if(Counter.state instanceof Number) // löschen, falls globale Variable
iCounter = (Counter.state as Number).intValue // löschen, falls globale Variable
iCounter += (now.toEpochSecond - Shelly03_switch.lastChange.toEpochSecond).intValue
logInfo("pool", "Filter Laufzeit heute {} Sekunden", iCounter)
}
end
Hier mit der globalen Variablen
und mit einem Item, Du solltest Dich für eine der beiden Varianten entscheiden.
Alle globalen Definitionen (also sowohl iCounter als auch tPumpe) müssen wenn, dann vor der ersten Rule der *.rules Datei stehen, also gewöhnlich in den ersten paar Zeilen der Datei.
Die Methode .lastChange steht erst im aktuellen OH4.2 zur Verfügung, sie liefert den Zeitstempel des letzten Changed Ereignisses
vor dem aktuellen Change.
Nachteil: die Rule bekommt während die Pumpe läuft nicht mit, wenn die gewünschte Betriebsdauer überschritten wird.
openHAB4.2.0 stable in einem Debian-Container (bookworm) (Proxmox 8.2.4, LXC), mit openHABian eingerichtet
