Also zuerst mal: knxd Ist ein Software Stack, um auf den knx Bus zuzugreifen. Der Stack unterstützt verschiedenste Zugriffsverfahren und stellt im Gegenzug selbst den knx Bus über IP Tunnel und/oder Router sowie einem Socket zur Verfügung.
Solange aber nur eine Verbindung über das Tunnel Interface aufgebaut wird, sollte die Kommunikation auch ohne knxd stabil sein. Ich nutze hier ein Weinzierl 730 mit fünf Tunneln und weiß daher aus eigener Erfahrung, dass die Tunnel nicht so stabil sind, wenn mehrere parallel betrieben werden. Andererseits braucht es gewöhnlich auch nur eine Verbindung.
Zu knxd: das lässt sich einfach über openhabian-config nachinstallieren. Was die Konfiguration von knxd betrifft, so ist die leider nicht ganz trivial. Zudem kommt es auf die exakte Version von knxd an, wie es zu konfigurieren ist, und ich habe den Eindruck, dass openhabian-config das nicht zuverlässig korrekt macht.
Du müsstest knxd über die Datei /etc/knxd.ini konfigurieren (siehe letzte Zeile der Ausgabe von
systemctl status knxd)
Zur Adresslogik in knx:
Jedes Gerät (genauer jeder Buskoppler) hat eine physikalische Adresse (im englischen individual address... die unterschiedlichen Bezeichnungen machen es auch nicht einfacher...). Im Auslieferungszustand ist jedes Gerät auf die Adresse 15.15.255 eingestellt. Die Adresse ist insgesamt 16 Bit breit, unterteilt in 4.4.8 Bit. Die physikalische Adresse spielt in der gewöhnlichen Kommunikation eine untergeordnete Rolle, allerdings gibt es "besondere" Adressen für besondere Geräte. x.y.0 ist beispielsweise immer ein Linien- oder Bereichskoppler. Innerhalb einer Linie können bis zu 256 Geräte adressiert werden, wobei aber nur bis zu 64 Geräte physisch an einer Linie angeschlossen werden dürfen. Möchte man mehr Geräte an einer Linie anschließen, so benötigt man einen Linienverstärker, letztlich verwendet man in einer Linie bis zu drei Linienverstärker, um bis zu vier mal 63 Geräte anzuschließen (Linienkoppler und Linienverstärker zählen als Gerät am Bus) und bis zu 15 Lnien können zu einem Bereich gekoppelt werden, bis zu 15 Bereiche können an einem Backbone angebunden werden.
Heutzutage werden gewöhnlich immer IP-Router verbaut und direkt auf den Backbone verbunden, weil der Datendurchsatz auf IP-Seite mit 10MBit/s tausendmal höher ist als die 10kBit/s, die auf der TP-Seite (Twisted Pair...) verwendet werden - knx (bzw. EIB, das ist der ursprüngliche Name) wurde bereits in den 80er Jahren entwickelt, da war IP noch unerschwinglich...
Wie gesagt, die physikalische Adresse spielt ansonsten eine untergeordnete bei der normalen Kommunikation, sie ist vor allem beim programmieren der Geräte wichtig, natürlich wird auch im Normalbetrieb immer die physikalische Adresse mit übertragen (kann man in der ETS im Gruppen-/Busmonitor sehen), wichtiger ist jedoch die GruppenAdresse.
Jedes Gerät am knx Bus hat Kommunikationsobjekte, und diese Kommunikationsobjekte werden mit GA verknüpft, dabei kann ein KO mit mehreren GA verknüpft werden. Die Kommunikation des KO wird über Flags gesteuert, welche darüber bestimmen, ob ein KO überhaupt kommuniziert (K), senden darf (Ü), empfangen darf (R), Read Requests beantworten darf (L), Antworten auf Read Requests als Befehl interpretieren soll (A) oder selbst Read Requests senden darf (I).
Sollte das KO Daten senden dürfen, wird es das aber ausschließlich auf der ersten verknüpften GA tun (gleich ob Ü-,L- oder I-Flag).
Die GA sind ebenfalls 16 Bit breit, aber gewöhnlich in 5/3/8 Bit aufgeteilt. GA sind universell, es gibt keinerlei Regeln, welche GA wozu verwendet wird. In aktuellen ETS Versionen kann man die Aufteilung der Bits beliebig setzen, z.B. 4/12 oder auch 16, das spielt aber ebenfalls nur eine untergeordnete Rolle. Die Aufteilung ist rein virtuell, im Gerät geht es nur um 16 Bit, deshalb können die GA einfach ineinander umgerechnet werden, es ist also egal, ob man bei 5/3/8-Aufteilung als GA 0/1/1 sendet oder mit Aufteilung 4/12 als GA 0/257.
So oder so sind GA die zentrale Form der Kommunikation auf dem knx Bus.
Die Kommunikation ist grundsätzlich gerichtet, ein Gerät sollte also auf einer GA entweder senden oder empfangen, aber nur im Ausnahmefall beides (das wäre, wenn z.B. openHAB einen Read Request auf einer GA sendet, was vom Gerät registriert wird und mit dem Status des KO quittiert wird. Deshalb darf auch nur ein KO pro GA auf Read Requests antworten, das ist quasi oberstes Gesetz. Nur Status-GA dürfen lesbar sein (diverse Hersteller halten sich nicht an diese Regel und setzen L-Flags in KO, die nicht exklusiv senden
)
Wenn ein Channel in beiden Richtungen funktioniert, werden also immer zwei GA im Spiel sein, wobei openHAB auf der ersten GA sendet und auf allen GA empfängt (identisch zum restlichen knx-System). Es geht hierbei aber um zwei GA innerhalb eines Parameters. Ein Channel kann mehrere Parameter haben, z.B. ein Rollershutter verwendet lang, kurz und position, ein Dimmer switch und position, optional auch increaseDecrease, die doppelte GA ist immer dort einzutragen, wo der vollständige Status zu erwarten ist, im Beispiel also jeweils position, weil hier 0% - 100% übertragen werden.
