openhabforum.de

Hallo Mitstreiter,

wenn bei einem Item eine Änderung stattfindet, wie in folgendem Beispiel:
Wird dann die Aktion, welche mit dem Item/Channel verbunden ist nach/vor der Regel ausgeführt
und kann diese auch unterbunden werden ?

Grund: Wenn ich hier einen "sendCommand" ausführe, dann möchte ich ja diesen
praktisch als Alternative zur Standardaktion ausführen.

Ich hoffe die Frage wurde verstanden.

Danke für Tips

Torsten

Du kannst ein Item per sendCommand oder oder postUpdate steuern.

sendCommand sendet ein Kommando an alle verlinkten Channel.
postUpdate ändert den Staus des Items.

Wenn Du in der UI ein Item steuerst, wird immer ein sendCommand ausgelöst.
Wenn ein Item ein sendCommand empfängt (egal woher), wird openHAB als Standard Verhalten versuchen, zu erraten, welches der wahrscheinlichste neue Status des Items sein wird und umgehend ein postUpdate dazu ergänzen. Dabei geht es vor allem darum, die gefühlte Geschwindigkeit des Systems zu verbessern.
Dieses Verhalten kann über die Metadaten abgeschaltet werden, autoUpdate wird dazu auf false gesetzt.

Was Du beschreibst, wirst Du so aber vermutlich nicht lösen können (oder Deine Beschreibung ist bei mir nicht richtig angekommen...).

Hallo Udo,

danke für die Ausführung, das habe ich verstanden.
Ja Du hast meine Frage richtig verstanden, dann geht mein Gedanke nicht.

Trotzdem noch zum Verständnis:

Nehmen wir z.B. einen Dimmer.

Der Benutzer schiebt den Dimmer und ein rule reagiert auf "Item xy changed".
Reagiert jetzt die Rule bevor der Channel/Item den Befehl ausführt oder erst danach ?

Das gleiche dann bei "Item xy received command". Hier vermute ich, dass die Rule
greift, noch bevor die Änderung an das Item übergeben wird ?

Also wie muss man sich das Zusammenspiel vorstellen ?

Grüße

Torsten

changed tritt immer nach received command auf. Wir reden hier aber von einem Zeitfenster von typisch unter zwei ms.
Da openHAB asynchron arbeitet, gibt es ohnehin keine Garantie für eine exakte Reihenfolge.
Das System triggert received command, womit der entsprechende Task gestartet wird (Benachrichtigung der Channel und das postUpdate wird ausgelöst).
Eventuell existieren Rules, die den Trigger haben, werden natürlich auch unmittelbar gestartet.
Inzwischen ist aber das Item vermutlich schon upgedatet, und falls der Status sich geändert hat wird changed getriggert und eventuell entpsrechende Rules gestartet.
Die ersten Rules (mit received command als Trigger) haben aber vielleicht durch einen unglücklichen Umstand noch nicht genug Rechenzeit bekommen, die neue Rule (mit changed als Trigger) aber bekommt nun mehr Rechenzeit zugewiesen und "überholt" die anderen Rules.
Wie gesagt... asynchron.
Wenn Du autoupdate = false setzt, wird der Status nur noch vom Binding durch den Channel gesetzt, oder eben, wenn Du ein gezieltes postUpdate sendest. Damit gibt es dann die Garantie, dass der Befehl bereits vollständig ausgeführt wurde, denn der Statuswechsel ist Resultat des Befehls, keine Vorhersage.
Das Command kannst Du aber nicht aufhalten, Du kannst höchstens ein gegenteiliges Kommando hinterherschicken um die Aktion wieder rückgängig zu machen.

Wenn Du die Bedienung zeitweise verhindern willst, musst Du eine Rule verwenden, um Beim Empfang über ein Proxy Item den Befehl an das echte Item weiterzuleiten, dann hast Du in der Rule volle Kontrolle über das Verhalten.

Hallo Udo,

danke für die Ausführung - verstanden.
Du hast mich auf eine Idee gebracht. Gibt es die Möglichkeit ein Dummy-Item zu erstellen.
Also der Bediener nutzt z.B. den Dummy-Dimmer, hinter dem kein echtes Thing/Channel steht.
Dann könne man doch über dieses Dummy-Item den Befehl "abfreifen" und das "echte" Item damit steuern.
D.h. der Bediener sieht nur das Dummy-Item, das "echte" Item bleibt ihm "optisch verborgen".

Geht sowas ?

Schönen Abend

Torsten

Genau, allerdings bevorzuge ich den Begriff Proxyitem. Du legst einfach ein passendes Item an, nach Belieben über die UI, per Textdatei...
Dabei verbindest Du das Item aber mit keinem Channel, es bleibt also "ungebunden".
Dieses ungebundene Item packst Du in die UI. Wenn Du nun das Item über die UI bedienst, gibt es jedes Mal ein received command Ereignis.
Dann brauchst Du noch zwei Rules: Das Betätigen des Items löst den Befehl aus, der an das eigentliche Item weitergeleitet wird.
Ändert sich der Status des "echten" Items, so wird der neue Status an das Proxy Item geleitet, damit die Anzeige korrekt ist.

Es ist essenziell, dass sendCommand und postUpdate genau wie gezeigt verwendet werden, da sich sonst eine Endlosschleife bilden könnte (abgesehen davon, dass es nicht funktionieren würde...)
Da der Befehl zum eigentlichen Item nun von der Rule kommt, hast Du alle Freiheten, vor dem sendCommand() Bedingungen zu setzen.

Die Rules können genauso auch über die UI angelegt werden, in jeder beliebigen Form.

Hallo Udo,

das ist doch eine geniale Lösung, damit kann ich arbeiten.
Damit lassen sich z.B. die RGB / HSB - Color - Probleme bei den Funzeln
wunderbar lösen.
Das Proxy-Item nimmt die Bedienerwerte auf, und über eine Rule werden sie umgerechnet und an das "Ausführende"-Item weitergeleitet und umgekehrt.

Danke

Torsten