openhabforum.de

Hallo!

Ich habe Heizkörperthermostate, die ich sowohl manuell am Gerät, als auch per Rules steuere. Für die Soll-Temperatur habe ich einen Channel und ein damit verbundenes Item. In einer Rule reagiere ich auf Änderungen am Item (Item changed). Das Item wird auch durch andere Rules beeinflusst (item.SendCommand()). Ist es möglich, in der Item-Changed-Rule zu ermitteln, was die Quelle für die Änderung war? Also ob jemand am Thermostat gedreht hat, oder ein Command zum Item Change Event geführt hat?

Mir ist bewusst, dass es das Received Command Event gibt. Genau das interessiert mich in der Rule aber nicht, sondern der andere Fall. Also wenn das Event durch das Binding ausgelöst wurde. (Kann man das so sagen?)

Received Update habe ich auch probiert, wird aber immer getriggered.

Falls es relevant ist: Es handelt sich um das Homematic Binding, Homegear und ein CUL-Stick sowie eQ-3 Thermostate.

Danke im Voraus.

Direkt kannst Du das leider nicht feststellen. Du kannst aber auf received command triggern und einen Merker aktivieren. der Merker muss dann nach einer definierten Zeit wieder zurückgesetzt werden.

Grundsätzlich kannst Du in den Metadaten des Items den Parameter autoupdate auf false setzen (über die UI ist das dann ein leeres Kästchen). Damit verhinderst Du, dass openHAB in vorauseilendem Gehorsam bei einem sendCommand autoamtisch auch ein postUpdate absetzt.

Erläuterung: Standardverhalten von openHAB, gegeben ein Switch Item. Wenn Du in der UI denSwitch betätigst, wird daraus ein sendCommand(Befehl) generiert, was in einem received command <Befehl> resultiert. openHAB erkennt, dass sich der Status des Items vermutlich ebenfalls ändern wird, und zwar passend zum Befehl. Bei ON wird also unmittelbar noch ein postUpdate(ON) hinterher geschickt, bei OFF ein postUpdate(OFF). Das führt dann zu einem received update und eventuell (je nach vorherigem Zustand) zu einem changed from ... to.
Die Idee hinter diesem autoupdate ist, dass die UI schneller reagiert.
Eigentlich möchte man aber zu jedem Zeitpunkt den realen Zustand des Schaltaktors sehen, nicht, welchen Befehl man zuletzt abgesetzt hat. Wenn man also autoupdate = false setzt, sendet openHAB nur noch das Kommando. Irgendwann antwortet das externe Gerät dann mit einem Update des Zustands, welcher umgehend im Item als Status gespeichert wird. Das "irgendwann" ist stark vom verwendeten Bussystem und der Auslastung abhängig. z.B. bei mir mit knx kommt die Antwort innerhalb weniger Millisekunden. Ein Dimmer, der per Definition bei mir 5 Sekunden zum Dimmen braucht, antwortet natürlich mit bis zu 5 Sekunden Verzögerung, ein Rollershutter antwortet, nachdem der Motor gestoppt hat, also teilweise erst nach 30 oder gar 40 Sekunden (bodentiefe Fenster).

Es könnte in Deinem Fall helfen, die beiden Möglichkeiten auseinander zu halten. Wird ein received command getriggert (und mit einem Merker gemerkt) kannst Du bei einem changed Ereignis nachschauen, ob der Merker gerade gesetzt ist. Ist das der Fall, so wurde die Änderung höchstwahrscheinlich durch einen Befehl innerhalb openHAB ausgelöst. Ist der Merker nicht gesetzt, so wurde das Gerät vermutlich vor Ort verstellt.

udo1toni hat geschrieben: ↑7. Jan 2022 15:08 Du kannst aber auf received command triggern und einen Merker aktivieren. der Merker muss dann nach einer definierten Zeit wieder zurückgesetzt werden.

Damit habe ich auch schon experimentiert und am Ende läuft es wohl auf diese Lösung hinaus.

Grundsätzlich kannst Du in den Metadaten des Items den Parameter autoupdate auf false setzen (über die UI ist das dann ein leeres Kästchen). Damit verhinderst Du, dass openHAB in vorauseilendem Gehorsam bei einem sendCommand autoamtisch auch ein postUpdate absetzt. Erläuterung: ...

Vielen Dank für deine Erklärung des Zusammenhangs von autoupdate, langsam reagierenden Geräten und der GUI. Das war mir bisher nie so bewusst und hatte mich schon immer gefragt, wozu eigentlich genau dieses autoupdate nützlich sein soll.