Nein, die Lösung ist hier eine andere.
Es ist wirklich wichtig, zu verstehen, wie die Rollen hier verteilt sind.
Gewöhnlich tritt openHAB gegenüber angeschlossenen Geräte wie ein Schalter auf. Das Gerät wird von openHAB geschaltet, das Gerät meldet seine neue Schaltstellung an openHAB, welches die neue Schaltstellung anzeigt.
Hier ist es aber (in Richtung knx) umgekehrt, das heißt, openHAB tritt gegenüber knx als Aktor auf. Das knx Device ist der Schalter, der openHAB schaltet, openHAB liefert den Status an knx.
Daraus ergeben sich zwei Dinge:
- Das Status kommt nicht von knx und darf auch nicht von dort gelesen werden (es darf kein < Zeichen gesetzt werden)
- Die Status-GA muss an 1. Stelle stehen, die Steuer-GA (welche den Befehl sendet), muss an 2. Stelle stehen, denn openHAB sendet (wie alle knx Geräte) ausschließlich auf der jeweils 1. GA.
Bei verschiedenen Bindings gibt es da durchaus Schwierigkeiten, ausgerechnet im Zusammenhang mit knx ist es aber sehr einfach, dieses Problem zu lösen, und zwar, indem der Channel korrekt konfiguriert wird, als switch-control Channel:
Code: Alles auswählen
Thing device BedienpanelZimmer "Bedienpanel Zimmer" @ "KNX" [
] {
Type switch-control : ch1 "Kanal 1" [ ga="1/7/1+1/1/1" ]
Es reicht nun streng genommen eine Verlinkung zwischen dem knx Channel und dem Item, welches bereits mit dem Shelly Aktor gekoppelt ist. Der knx Taster braucht kein eigenes Item!
Das Bedienpanel sendet GA 1/1/1 an openHAB. Dort kommt der Wert als Command an(!). Das Command wird an das zweite verknüpfte Addon weitergereicht, welches den Schaltbefehl ausführt. Daraufhin wechselt der Status des Items. Der Status wird umgehend an knx gesendet.
Möchtest Du es per Rule lösen, so brauchst Du auf jeden Fall zwei Rules, eine, die den Befehl von knx an den Aktor weiterleitet, eine weitere, die den Status des Aktors an knx sendet.
Die von Dir gepostete Rule hat allerdings nichts mit dem Panel zu tun
