rule "Update Terrasse"
when
Item HLightNorth received update
then
var String NewState = HLightNorth.state.toString
logInfo("HLightNorth", "Status "+NewState)
switch(NewState) {
case "OFF" : {
val dimVal = (IntensityNorth.state as Number)
.
.
Ist das nur ein Startproblem? Die Regel funktioniert sonst.
Viele Grüße
Ach ja. Ich habe noch zwei weitere gleiche Regeln, nur für andere Geräte. Die werden nicht moniert .
Ja, das Problem dürfte sein ,dass IntensityNorth zum Zeitpunkt des ersten Updates von HLightNorth noch nicht initialisiert ist.
Wenn Du Itemstates in einen bestimmten Datentyp castest (...as ...) musst Du vorher sicherstellen, dass der Status auch diesen Datentyp enthält. Dafür gibt es den Operator instanceof. Je nach Anwendung kannst Du entweder einen default Wert setzen oder die Rule kontrolliert abbrechen.
Aber es fängt noch vorher an. Warum der Trigger received upüdate?
Warum überhaupt eine Variable NewState?
Vielen Dank für die Infos.
Das Ganze ist Teil der Steuerung meiner Netatmo Presence Geräte. Die Steuerung kann sowohl über Sitemaps als auch über Habpanel und Fernsteuerung erfolgen. Dafür benötige ich einige Variablen.
Die Regel ist "irgendwie" gewachsen. Wahrscheinlich wusste ich nicht, wie ich sonst die Fälle unterscheiden kann. Die Zeile, die Ärger macht, hast Du ja freundlicherweise schon erläutert.
Aber wenn wir schon dabei sind, wie würdest Du es denn schreiben :
rule "Update Terrasse"
when
Item HLightNorth changed
then
if(newState == OFF) {
sendHttpGetRequest("http://192.168.2.222/presence_state.php?camera=Norden&state=off")
LightNorth.postUpdate(OFF)
LastLight = 0
} else {
val dimVal = IntensityNorth.state.toString
sendHttpGetRequest("http://192.168.2.222/presence_intensity.php?camera=Norden&intensity=" + dimVal)
Thread::sleep(1000)
sendHttpGetRequest("http://192.168.2.222/presence_state.php?camera=Norden&state=on")
LightNorth.postUpdate(dimVal)
LastLight = 1
}
end
switch() bringt hier keinen Vorteil, es gibt ohnehin nur zwei mögliche Zustände (wenn man mal vom gezielten Umsteuern per Rule absieht)
jeder Status kann immer als String ausgedrückt werden, die Fehlermeldung bekommt man also leicht weg. Bleibt noch die Frage, was passiert, wenn die Adresse mit leerem Parameter aufgerufen wird. Ansosnten musst Du halt sicherstellen, dass IntensityNorth immer eine gültige Zahl enthält, unter allen Umständen...
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
Hmm. Müsste statt <newstate> nicht <HLightNorth.state> stehen?
Die HTTP-Aufrufe rufen über ein PHP-Script das API von Netatmo auf und steuern so die Presence Kameras, die ja auch LED-Strahler sind. Mittlerweile gibt es auch ein Binding dafür, aber über dieses kann man nicht die Lichtintensität steuern.
kaloschke hat geschrieben: ↑27. Nov 2022 17:46
Hmm. Müsste statt <newstate> nicht <HLightNorth.state> stehen?
Nein, das ist ja der Witz. Die Rule triggert über changed (nicht über received update)
Jede Rule, die über changed getriggert wurde, hat drei implizite Variablen:
triggeringItemName (nicht zu verwechseln mit triggeringItem.name!) previousState (nicht zu verwechseln mit Item.previousState!)
und newState.
Die Namen sind sprechend
Natürlich kannst Du auch HLightNorth.state verwenden, das ist in diesem Fall das Gleiche, aber newState ist kürzer
Die Verwendung von newState hat allerdings eine direkte Folge, man kann die Rule dann nicht über den run-Knopf in der UI starten (bzw. es kommt dann zu einem Fehler).
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
Ach das ist ja ein witziger Zufall (? erinnere mich nicht mehr), dass ich meine Variable auch fast so genannt hatte. Habe die Kleinschreibung gar nicht mitbekommen .
<newstate> kannte ich gar nicht. Sehr schön. Wieder was gelernt.
Vielen Dank und schönen Abend noch.
Und es lohnt auch als ganz alter Hase, ab und zu mal wieder einen tieferen Blick in die Doku zu werfen (also nach großen Updates...)
Was da in den letzten Jahren alles an neuen Funktionen dazu gekommen ist (auch und gerade bei den impliziten Variablen).
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
Ab 3.4 gibt es übrigens einen Cache für beliebige Werte, der zwischen UI rules, file-based Rules und verschiedenen Sprachen geteilt wird. Nur schonmal als Vorwarnung, sind ja nur noch 2 Wochen.