Stopp.
Also, der Code ist erst mal etwas unkonventionell, sollte aber so durchlaufen. Die Formatierung ist hier im Forum unglücklich, weil die Forensoftware einen Tab alle acht Zeichen setzt, während der normale Tab-Abstand in den diversen Editoren gewöhnlich vier beträgt.
Hast Du tatsächlich ein Item namens EventLog? Wozu?
Thread::sleep(100) hält die Rule für 100 Millisekunden an. Das ist - in diesem Zeitrahmen - in Ordnung.
Allerdings bringt es rein gar nichts, außer natürlich eine längere Ausführungszeit der Rule. Pushover hat Laufzeiten von mehreren Sekunden, so dass die 100 Millisekunden ganz weit in die Schwankungen rein fallen. Innerhalb der Rule gibt es keinen Grund zu warten, das ist höchstens sinnvoll, wenn man ein Item beschreibt (mit postUpdate) und direkt im Anschluss dieses Item wieder verwendet. Da openHAB asynchron arbeitet, ist mit hoher Wahrscheinlichkeit das postUpdate noch nicht fertig ausgeführt, wenn das Item wieder gelesen wird. Beispielcode:
Code: Alles auswählen
logInfo("test","Status 1 von MyItem: {}",MyItem.state)
MyItem.postUpdate(if(MyItem.state != ON) ON else OFF)
logInfo("test","Status 2 von MyItem: {}",MyItem.state)
Thread::sleep(100)
logInfo("test","Status 3 von MyItem: {}",MyItem.state)
MyItem ist ein Switch Item. Der Status des Items wird durch den Code gewechselt. Ist der Status ungleich ON, so wird der Status auf ON gesetzt, ansonsten auf OFF.
Im Log wird unmittelbar vor und nach dem postUpdate der Status ausgegeben, dann noch mal nach 100 Millisekunden.
Es gibt nun kein garantiertes Verhalten, aber mit einiger Wahrscheinlichkeit werden die erste und die zweite log-Zeile den gleichen Status anzeigen, während die dritte log-Zeile einen anderen Status anzeigt. Das liegt daran, dass die DSL das postUpdate delegiert und unmittelbar die nächste Codezeile ausführt.
Wie gesagt hast Du im Beispielcode rein gar nichts von dieser Verzögerung.
Warum das pushover nicht zuverlässig funktioniert, kann ich allerdings auch nicht sagen.
Bei der zweiten Testrule kannst Du die lokale Konstante
actions leider nicht an einer Stelle definieren, denn der Inhalt ist unterschiedlich (einmal mit, einmal ohne Ton)
Dennoch ist der Code so eher suboptimal. Du kannst als Namen für das Objekt übrigens beliebige Begriffe nehmen also z.B.
Code: Alles auswählen
rule "Pushover Test"
when
Item pushover received command
then
val pushNone = getActions("pushover", "pushover:pushover-account:soundNone")
val pushSound = getActions("pushover", "pushover:pushover-account:soundPushover")
logInfo("PUSHOVER", "--> {}",if(receivedCommand == ON) "on" else "off")
switch(receivedCommand) {
case ON : pushSound.sendHtmlMessage("Pushover <font color='green'>ON</font>! soundNone", "openHAB3")
case OFF: pushNone.sendHtmlMessage("Pushover <font color='green'>OFF</font>! soundPushover", "openHAB3")
}
end
Die beiden Objekte pushNone und pushSound sind Handles, um aus der Rule heraus auf die Action im Binding zugreifen zu können. Der Name ist gleichgültig.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet