Hier habe ich nun eine Motion rule, bei dem ich das gleiche Problem mit dem "Blank" Luminance Wert über Nacht habe.
Ich habe versucht die gleiche Logik einzubauen, jedoch bezieht sich "nstate" ja nicht auf dieses device, somit wirft er mir eine Warnung im Log:
newState ist eine implizite Variable. Diese wird bei changed mit dem neuen Wert des Items gesetzt, welches die Rule getriggert hat.
Wenn eine Rule mehrere Items als Trigger nutzt, muss man das triggernde Item über triggeringItem ermitteln, eine weitere implizite Variable. newState ist hier halt viel kürzer als der absurde Itemname...
nState wiederum ist eine lokale Variable, bzw in der ersten Variante eine lokale Konstante. Wenn die Rule abgelaufen ist, existiert sie nicht länger...
Zu Deiner Rule kann ich grade nichts sagen, das ist am Telefon fehlerträchtig.
Gesendet von meinem SM-G973F mit Tapatalk
openHAB4.3.5 stable in einem Debian-Container (bookworm) (Proxmox 8.4.1, LXC), mit openHABian eingerichtet
Rule sieht gut aus. Allerdings... da es hier ja um drei Items geht, lohnt sich ein Group Item. Nehmen wir an, Du legst ein Group Item vom Typ Switch an, mit dem Namen gWohnMotion und ordnest die drei Items diesem Group Item zu, dann kannst Du alle drei Items so schalten:
Das Gruppenitem wird als Liste abgerufen (.members) und nach Items gefiltert, deren Status nicht ON ist - das entspricht dem if(). Das Ergebnis ist wieder eine Liste. Nun wird für jedes Item der Liste der Befehl ON gesendet. Die Liste kann auch 0 Items enthalten, dann wird halt kein einziges ON gesendet (also wie bisher).
Die gleiche Zeile (nur jeweils mit OFF) kannst Du auch in den Timer packen...
openHAB4.3.5 stable in einem Debian-Container (bookworm) (Proxmox 8.4.1, LXC), mit openHABian eingerichtet
OK Problem gelöst,
ich habe dein 2. Beispiel genommen und das funktioniert (also mit der lokalen Variablen)
Das bedeutet das 1. Beispiel kann OH nicht sauber interpretieren!
Raspberry 4, Rev.1.2b, 4GB, Openhab 2.5.12 (OH3 kommt im Winter dran:-))