OpenHab 3: Regel triggern wenn GA ausgelöst wird

[enrico80]

Hallo zusammen.

Ich kenne mich mit KNX mittlerweile ganz gut aus aber noch nicht so sehr mit OpenHab. Ich habe das KNX binding soweit am Laufen, möchte nun aber eine Regel triggern, wenn immer eine bestimmte GA ausgelöst wird.

Ich klicke also auf...

Rules -> Add Trigger -> Thing Event -> [Entsprechendes Thing] -> "a trigger channel fired"

... jedoch kann ich da den entsprechend konfigurierten Channel nicht auswählen, weil das KNX Binding offenbar gar keine Channels vom Typ "Trigger" unterstützt. Wie habt Ihr das denn gelöst? Geht das nur mit der UI nicht? Oder muss ich doch erst ein Item anlegen und verküpfen, damit das geht? Über Hilfe wäre ich sehr dankbar.

[udo1toni]

So ist es.
Die Trigger Channel haben eine besondere Funktion. dabei geht es um Channel, die eigentlich immer Zustand A haben und nur extrem kurz (wenige Millisekunden bis hin zu wenigen Sekunden) einen anderen Zustand als Zustand A.
Zum Beispiel Sonnenaufgang: Der passende Trigger Channel heißt z.B. astro:sun:local:rise#event. Er triggert zu Beginn vom Sonnenaufgang START und am Ende des Sonnenaufgangs END. Der Sonnenaufgang ist der Zeitpunkt, zu dem die Sonne die 0° Höhenlinie passiert. Da die Sonne ein Kreis ist, gibt es hier also zwei Zeitpunkte, die Sonne berührt die Höhenlinie und die Sonne löst sich von der Höhenlinie. Beide Ereignisse sind Zeitpunkte ohne eine Dauer, es gibt lediglich die Dauer zwischen START und END (die im passenden Channel astro:sun:local:rise#duration angezeigt wird).

Die normale Art, mit Channels zu interagieren läuft aber über Items. Du verknüpfst den Channel mit einem Item und lässt die Rule dann auf das Item triggern.

KNX kennt überhaupt nur Gruppenadressen (bezogen auf die normale Kommunikation).
Mit den Gruppenadressen können Befehle übertragen werden oder aber Status, wobei man der GA nicht ansehen kann, was sie beinhaltet.
Für den KNX Anwender spielt die Trennung zwischen Befehl und Status meist auch nur eine untergeordnete Rolle (was dann regelmäßig zu Problemen führt, wenn beides aus Versehen vermischt wurde).
Das openHAB knx Binding sorgt nun dafür, dass hier ein wenig Ordnung geschaffen werden kann.
Grundsätzlich werden empfangene GA als Status gewertet, wenn man etwas an den Bus senden will, so geschieht das grundsätzlich als Befehl.

Grundsätzlich heißt hier aber: es gibt auch eine Ausnahme und zwar gibt es jede Channel-Art zweimal, also z.B. switch (ein knx Schaltaktor) und switch-control (ein knx Taster) Alles, was in knx ein Aktor oder ein Sensor ist, wird mit einem "nicht-control-Channel" abgebildet, nur wenn man z.B. einen Wandtaster verwenden will, um ein Gerät zu steuern, welches eben kein knx Gerät ist, wird man den entsprechenden Taster mit einem *-control-Channel verbinden. *-control Channel werden bei ankommenden GA Telegrammen als Befehl gewertet und weitergeleitet, eine Statusänderung wird an knx gesendet.
Auf diese Weise kann man z.B. einfach eine WLAN-Steckdose, die per mqtt über openHAB steuerbar ist mit einem Wandtaster von knx aus steuern, indem man beide Channel mit dem selben (!) Item verlinkt (OHNE Rule)
Natürlich kann man auch genauso gut zwei Items verwenden und vom knx-Item eine Rule triggern lassen, welche dann den Befehl an das mqtt Item sendet. Das ist vor allem dann sinnvoll, wenn es keine einfache 1:1 Verknüpfung der Befehle gibt.

Der Punkt für Dich ist aber vor allem: verknüpfe den betreffenden Channel mit einem passenden Item und verwende dieses Item als Trigger für die Rule..
Denke dabei aber auch daran, dass der Trigger von einem knx ITem für ankommende Telegramme meist received update oder changed lautet, es sei denn, Du hast einen *-control-Channel angelegt, dann lautet der Trigger received command.

[enrico80]

Danke für die ausführliche Erklärung, das werde ich mal versuchen!

[enrico80]

Das hat tatsächlich funktioniert, danke! Wenn es jetzt nur noch eine einfache Art gäbe, einen ETS-Export von GAs in Things/Channels und Items umzuwandeln...

[udo1toni]

Es gab mal den Versuch, die knx-project-Datei auszulesen, das ist aber schon viele Jahre her und wurde nie vollständig umgesetzt.
Letztlich ist es die Mühe nicht wert, zu individuell sind die Konfigurationen, so dass der Anwender am Ende doch manuell eingreifen muss, um alles korrekt zu implementieren.

Vergiss dabei bitte nicht, dass es in openHAB Bezüge zwischen GA gibt, die man nicht unbedingt einfach aus dem knx Projekt ableiten kann (z.B. ein Dimmer Item benötigt drei GA, wahlweise könnte man auch eine vierte GA setzen, man kann aber nur am Dimmaktor überhaupt erkennen, welche GA dafür in Frage kommen. Dabei sind zwei der drei GA eventuell noch gar nicht definiert, weil sie in einer konventionellen knx Umgebung nicht gebraucht werden (absoluter Dimmwert), aber bei einer GA (ein/aus) können in einem Dimmer KO durchaus mehrere GA hinterlegt sein (z.B. für Zentral Aus), so dass es nicht ausreicht, die GA-Liste nach Device-KO zu sortieren.
Ja, könnte man alles automatisieren, und dann kommt jemand mit einem fehlerhaften knx Projekt (in dem Sinne, dass dort Dinge falsch gemacht wurden, die in einer konventionellen knx Umgebung erst mal keine Auswirkungen haben,m aber sehr wohl, wenn man beginnt, das Ganze mit einem Smart Home zu verbinden - ich spreche aus eigener Erfahrung...). Könnte aber durchaus auch legitim und beabsichtigt sein. Wie soll sich das Programm dann verhalten?
Weitaus einfacher ist es, als Anwender die Daten einmal durchzuflöhen und dabei vielleicht gleich auf ein paar Ungereimtheiten zu stoßen...
Und spätestens wenn der Anwender gezwungen ist, sein knx Projekt auf eine ganz bestimmte Weise aufzubauen, damit die Übersetzung erfolgreich verläuft, ist das Ganze ad absurdum geführt, da wackelt dann der Schwanz mit dem Hund...