KNX Taster 8-fach plus IR Empfänger über openHAB ansteuern?

[tobiasr]

Kaskadenbetrieb aktivieren und Szenen-ID 0-7 an das neu erscheinende KO schicken.

[udo1toni]

Nein, Du musst nichts auslesen. Du musst lediglich eine GA mit KO 17 verbinden (Lichtszenennebenstelle). Dort ist momentan keine GA eingetragen, such Dir eine freie (also eine, die es im Projekt noch nicht gibt).
Die neue GA trägst Du in KO 17 ein und programmierst das Device mit den Gruppenadressen)

Anschließend trägst Du diese GA dann auch in openHAB ein, wie im Posting https://knx-user-forum.de/forum/supp...76#post1863676 beschrieben.

[Dummsel]

Vielen Dank für die Mühen. Ich werde das erstmal vertragen, bis ich ein wenig tiefer in die Materie eingedrungen bin.

Ich muss mal suchen, wo man brauchbare Informationen für openhab findet. Aktuell ist das alles doch ehr lückenhafte Überlieferung, die man sich zusammen googelt. Wo findet man z.B. Infos zur Angabe der GA? Welches Format, Verknüpfungen, Parameter, etc. sind da möglich, usw.?

[tobiasr]

Hast du es denn mit der ETS direkt getestet?

[udo1toni]

Wo findet man z.B. Infos zur Angabe der GA? Welches Format, Verknüpfungen, Parameter, etc. sind da möglich, usw.?

Es gibt eine sehr vollständige englische Dokumentation... https://www.openhab.org/docs/ die ist auch zum grundsätzlichen Verständnis, wie openHAB tickt sehr empfehlenswert.
Falls Du mit Englisch auf Kriegsfuß stehst, kann ich Dir eine Videoreihe empfehlen, die bei youtube von @bangertech erstellt wurde.
Eine systematische Dokumentation auf deutsch, die auch aktuell ist, wäre mir jetzt nicht bekannt - das ist eines der großen Probleme bei allen Ansätzen dazu, die Aktualität. Auch das Buch von Marianne Spiller kann man nicht mehr guten Gewissens empfehlen, weil es halt openHAB2 behandelt.
Das wäre so, wie ein Handbuch für Windows XP zu empfehlen, obwohl der Anwender Windows 10 verwendet.

Was das knx Binding betrifft: Du kannst beliebig viele GA an einen Parameter binden, das ist aber in den wenigsten Fällen sinnvoll. Gewöhnlich wird man entweder eine oder zwei GA an einen Parameter binden.
Die Schreibweise ist dann [DPT:][<]GA[+[<]GA][+[<]GA]..., also der DPT steht wenn, dann ganz vorne, mit einem Doppelpunkt von der GA getrennt, dann folgt die GA, welche mit dem < Zeichen wahlweise als lesbar gekennzeichnet werden kann. es sollte klar sein, dass man pro Channel (!) maximal eine GA als lesbar kennzeichnet, niemals mehrere GA, keinesfalls in mehreren Parametern des selben Channels. Konkretes Beispiel:

ga: 5.001:3/4/5+<4/5/6

Der DPT muss und soll nur angegeben werden, wenn er vom Default DPT abweicht (der ist abhängig vom Channel Typ und dem Parameter).
Wie bei knx üblich ist die erste GA in einem Parameter diejenige, über die Steuersignale gesendet werden. Alle anderen GA werden ausschließlich empfangen. Klitzekleine Ausnahme: Wenn eine GA als lesbar gekennzeichnet ist, wird openHAB beim Start einmalig einen Read Request auf dieser GA senden - kommt keine Antwort, so werden bis zu drei Versuche unternommen, bevor openHAB aufgibt.
Es sollte klar sein, dass die lesbare GA in knx unbedingt einem KO zugeordnet sein muss, welches dann exklusiv auf den read Request antwortet (L-Flag gesetzt).
openHAB merkt sich jeden Zustand intern, so dass es nicht notwendig ist, zyklisch abzufragen. Im Ausnahmefall (sehr alte/schlecht gemachte Hardware) kann man aber auch das zyklische Lesen konfigurieren, falls z.B. ein Sensor weder zyklisch noch bei Wertänderung senden kann, sondern nur auf Read Requests reagiert. Das geschieht dann im Thing, weil es entweder keine oder alle GA des Geräts betrifft.
Die Parameter sind abhängig vom Channel Typ, hier stehen die üblichen Sorten zur Verfügung, also switch, dimmer, rollershutter, contact, number, string und datetime. Jeden der Typen gibt es noch ein zweites mal, als *-control Version.
Der Unterschied: Gewöhnlich übernimmt openHAB die Rolle eines Schalters, der also einen Befehl an knx sendet. knx antwortet darauf mit einem Status. In openHAB kommt also ein Statusupdate an, welches eventuell auch eine Statusänderung ist.
Es kann aber sein, dass openHAB (gegenüber knx) die Rolle eines Aktors übernehmen muss, also ein knx Wandtaster steuert ein Gerät, welches nicht an knx angeschlossen, sondern nur über openHAB erreichbar ist. dafür gibt es dann die *control Channel. Ankommende GA werden nun als Command gewertet. Dafür sendet openHAB bei einem Status Update die Information an den Channel, der diese auf den Bus sendet. Eigentlich sollte es sogar möglich sein, solche Channel per Read Request aus knx heraus abzufragen (hab ich aber noch nie funktionieren gesehen...)
Ein typischer *-control Channel wäre tatsächlich datetime, um die per NTP Binding empfangene Zeit regelmäßig auf den knx Bus zu senden. Notation als Textkonfiguration:

Type datetime-control : dayTime "Wochentag und Zeit" [ ga="10.001:15/1/1" ]

Wenn man nun diesen Channel mit dem selben DateTime Item verlinkt, welches auch mit dem datetime Channel des NTP Binding verlinkt ist, wird die Zeit bei jedem Update auf den knx Bus gesendet und man kann auf eine Echtzeituhr in knx verzichten.
Ein switch, datetime, number, string oder contact Channel hat nur einen Parameter. rollershutter und dimmer haben mehrere Parameter, dort müssen also die zugehörigen GA in unterschiedliche Felder eingetragen werden. Notation als Textkonfiguration:

Type dimmer : ch1 "Dimmer" [ switch="1/1/1",position="1/1/2+<1/1/3"]

1/1/1 ist der Schalteingang des Dimmers
1/1/2 setzt den Absolutwert der Helligkeit
1/1/3 meldet die aktuelle Helligkeit des Dimmers zurück (und diese GA ist auch lesbar...)
In einer konventionellen knx Installation wird man meist mit relativem Dimmen arbeiten, nicht mit Absolutwerten. In openHAB ist das zum Teil möglich, aber eher nicht gewollt. Warum sollte man in einer Web UI eine Schaltfläche gedrückt halten, wenn man genauso gut einen Schiebesteller auf die gewünschte Position verschieben kann? openHAB kann sendend nicht mit Start/Stop Dimming umgehen, die meisten modernen Dimmer unterstützen ausschließlich Start/Stop Dimming, weil es Ressourcen schont. Umgekehrt kann openHAB sehr wohl ankommende Start/Stop Dimmbefehle in zyklische INCREASE/DECREASE Kommandos umwandeln, um z.B. mit einem knx Wandtaster eine HUE zu dimmen.
Bei rollershutter ist es ähnlich, nur das die Parameter hier upDown, stopMove und position heißen.

[Dummsel]

Wow, vielen Dank für die ausführliche Antwort. Das hilft mir schon sehr weiter.