KNXIO: Unterschied zwischen den Versionen
(matrix Modes->Produkte eingefügt) |
K (→TUL-Modul) |
||
(35 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 14: | Zeile 14: | ||
Die Idee zu diesem Modul ist: ein Modul für (fast) alle möglichen Kommunikations-Varianten zu haben, das auch vernünftig wartbar ist. Dieses Modul soll langfristig die bisherigen Module TUL und KNXTUL ablösen. | Die Idee zu diesem Modul ist: ein Modul für (fast) alle möglichen Kommunikations-Varianten zu haben, das auch vernünftig wartbar ist. Dieses Modul soll langfristig die bisherigen Module TUL und KNXTUL ablösen. | ||
KNX-secure ist nicht unterstüzt, weil bisher m.W. keine frei zugängliche Dokumentation des Prokotolls verfügbar ist und ich dzt. kein GW besitze, dass KNX-secure unterstützt. | |||
== Anwendung == | == Anwendung == | ||
=== Define === | === Define === | ||
Zeile 25: | Zeile 24: | ||
==== Definitions-Felder im Detail ==== | ==== Definitions-Felder im Detail ==== | ||
[[Datei:KNXIO.png|gerahmt|KNXIO Connectivity]] | |||
====== Mode: ====== | ====== Mode: ====== | ||
* '''H -Host Mode:''' Verbindung zu einem KNX-Gateway mit UDP Point-Point Protokoll. Dieser Protokoll wird auch von der ETS verwendet (KNXNET/IP). Das Protokoll ist sehr kritisch in Bezug auf Timing, Verzögerungen in FHEM (durch andere Tasks...) größer 1 Sekunde führen zu Verbindungsabbrüchen! Die Verbindung wird zwar unmittelbar wieder hergestellt, allerdings können einige Messages verloren gehen. | * '''H -Host Mode:''' Verbindung zu einem KNX-Gateway mit UDP Point-Point Protokoll. Dieser Protokoll wird auch von der ETS verwendet (KNXNET/IP). Das Protokoll ist sehr kritisch in Bezug auf Timing, Verzögerungen in FHEM (durch andere Tasks...) größer 1 Sekunde führen zu Verbindungsabbrüchen! Die Verbindung wird zwar unmittelbar wieder hergestellt, allerdings können einige Messages verloren gehen. | ||
* '''M -Multicast mode:''' Verbindung zu knxd-Daemon oder | * '''M -Multicast mode:''' Verbindung zu knxd-Daemon oder KNX-Router mit Multicast Protokoll. Dieses Protokoll wird auch von der ETS verwendet (KNXNET/Routing). Falls ein KNX-Gateway Multicast unterstützt, braucht man keine knxd Installation! Dieser Modus ist der Nachfolger des KNXTUL-Moduls. | ||
* '''T -TCP Mode:''' Verbindet mittels TCP-Protokoll mit knxd | * '''T -TCP Mode:''' Verbindet mittels TCP-Protokoll mit knxd. Dieser Modus ist der Nachfolger des TUL-Moduls.. Eine direkte Unterstützung von Seriellen/USB Gateways ist nicht implementiert! Falls ein Serielles / USB -Gateway verwendet wird ist die Empfehlung, das via knxd-daemon einzubinden und die Modes: M,S oder T zur Verbindung knxd->FHEM zu verwenden. | ||
* '''S -Socket Mode:''' Verbindet mittels UNIX_Socket zum knxd - Funktionert nur wenn sowohl FHEM als auch knxd am selben System laufen | * '''S -Socket Mode:''' Verbindet mittels UNIX_Socket zum knxd - Funktionert nur wenn sowohl FHEM als auch knxd am selben System laufen! Getestet wurde mit knxd-Verion 0.14.30. (Funktioniert definitiv NICHT mit knxd Version 0.10.0) | ||
* '''X - Dummy Mode:''' Mode zum Testen ohne KNX-GW (und für ganz spezielle Fälle...) | * '''X - Dummy Mode:''' Mode zum Testen ohne KNX-GW (und für ganz spezielle Fälle...) | ||
=====IP-Adresse/Hostname:Port===== | =====IP-Adresse/Hostname:Port===== | ||
Hostnamen sind unterstützt im Mode H und T. | Hostnamen sind unterstützt im Mode H und T. | ||
Default/Standard Multicast Adresse (Mode M) ist: 244.0.23.12 | |||
Default/Standard Port für Mode H und M ist 3671, für Mode T 6720. | |||
Default Socket path (Mode S) : /var/run/knxd (knxd-Version: 0.10.0) oder /run/knx (knxd-Version: 0.14.46) oder /var/run/knx (knxd-Version: 0.14.46), am besten in /etc/knxd.conf nachschauen! | |||
=====Phy-Adresse===== | =====Phy-Adresse===== | ||
Das ist die Physikalische Adresse, die das KNX-Gateway bzw. knxd für Clients am LAN (also auch FHEM) bereitstellt. Der Wert sollte (bei Verwendung knxd) dem -E Parameter in der knxd-Konfiguration entsprechen. | Das ist die Physikalische Adresse, die das KNX-Gateway bzw. knxd für Clients am LAN (also auch FHEM) bereitstellt. Der Wert sollte (bei Verwendung knxd) dem -E Parameter (Pool) in der knxd-Konfiguration entsprechen. | ||
Alle Parameter sind verpflichtend! Bitte sicherstellen, dass es nur einen Kommunikationspfad zwischen dem KNX-Gateway und FHEM gibt! | Alle Parameter sind verpflichtend! Bitte sicherstellen, dass es nur einen Kommunikationspfad zwischen dem KNX-Gateway und FHEM gibt! Das ist am sichersten erreichbar, wenn es in FHEM '''nur ein IO-Device''' (TUL/KNXTUL/KNXIO) für den KNX-Bus gibt. | ||
====Definitions-Beispiele==== | ====Definitions-Beispiele==== | ||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
Zeile 45: | Zeile 52: | ||
define myKNXGW KNXIO S /var/run/knx 0.0.51 | define myKNXGW KNXIO S /var/run/knx 0.0.51 | ||
define myKNXGW KNXIO T 192.168.1.200:6720 0.0.51 | define myKNXGW KNXIO T 192.168.1.200:6720 0.0.51 | ||
</syntaxhighlight>Siehe auch {{Link2CmdRef|Anker=KNXIO}}. | </syntaxhighlight> | ||
Siehe auch {{Link2CmdRef|Anker=KNXIO}}. | |||
Empfohlene Parameter für knxd Konfiguration:<syntaxhighlight lang="text"> | Empfohlene Parameter für knxd Konfiguration: (üblicherweise zu finden: /etc/knxd.conf) | ||
<syntaxhighlight lang="text"> | |||
KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -R -S -b ipt:192.168.xx.yy" # connect to a knx-GW with ip-addr | KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -R -S -b ipt:192.168.xx.yy" # connect to a knx-GW with ip-addr | ||
KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -R -S -single -b tpuarts:/dev/ttyxxx" # connect to a serial/USB KNX GW | KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -R -S -single -b tpuarts:/dev/ttyxxx" # connect to a serial/USB KNX GW | ||
KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -S -b ip:" # knxd acts as multicast client (connect to other knxd or KNX-Router with MC support) | KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -S -b ip:" # knxd acts as multicast client (connect to other knxd or KNX-Router with MC support) | ||
</syntaxhighlight>Siehe auch [[Knxd|knxd-Wiki]] | </syntaxhighlight>Der Parameter '''-e 0.0.50''' definiert die phy-Addresse des Gateways, '''-E 0.0.51:8''' definiert einen Pool von 8 Phy-Addr. für Clients am LAN! (FHEM ist ein Client am LAN aus KNX Sicht! ) | ||
Die Parameter '''-R -S''' aktivieren den Multicast Support, '''-T -S''' den Tunnel Support im knxd. '''-D''' aktiviert Autodiscovery, wird allerdings von FHEM/KNXIO nicht verwendet, aber von der ETS-Software! | |||
Der '''-S''' Parameter muss immer als letztes der Server Parameter (-D -T -R) stehen! | |||
Siehe auch [[Knxd|knxd-Wiki]] | |||
=== Attribute === | === Attribute === | ||
* '''disable''' - ident zum FHEM Standard - kein Senden / Empfangen möglich. | * '''disable''' - ident zum FHEM Standard - kein Senden / Empfangen möglich. | ||
* '''verbose''' - ident zum FHEM Standard - bestimmt welche/wieviele Meldungen ins Log geschrieben werden. | * '''verbose''' - ident zum FHEM Standard - bestimmt welche/wieviele Meldungen ins Log geschrieben werden. | ||
* '''enableKNXscan''' - löst ein KNXscan cmd aus: nie -> 0 , Fhem Start -> 1 , bei jedem connect event -> 2. Details dazu: {{Link2CmdRef|Lang=|Anker=KNX-utilities|Label=hier}} | |||
== Matrix - Modes<->Produkte == | == Matrix - Modes<->Produkte == | ||
Die Tabelle soll die möglichen KNXIO-modes für KNX-GW' | Die Tabelle soll die möglichen KNXIO-modes für KNX-GW's bzw. KNX-Router zeigen. Entstanden (und hoffentlich erweitert...) durch eigene Erfahrung und Tests bzw. auch aus Feedback aus dem Forum. Verwendete Produkt-Bezeichnungen können geschützte Namen sein, Diese werden hier ausschließlich verwendet um die Kompatibilität zum KNXIO-Modul darzustellen. Info über Produkte und ErfolgsMeldungen, aber auch Korrekturen sind willkommen, entweder direkt hier hinzufügen oder via Forum! | ||
{| class="wikitable" | {| class="wikitable" | ||
|+ | |+ | ||
Zeile 67: | Zeile 83: | ||
|knxd | |knxd | ||
|M S T | |M S T | ||
|knxd -daemon (getestet ab V.0.10.0, Mode S ab V.0.14.30) | |knxd -daemon (getestet ab V.0.10.0), | ||
Mode S nur falls knxd am selben host läuft. (getested ab ab V.0.14.30) | |||
|- | |- | ||
|Weinzierl IP731 | |Weinzierl IP731 | ||
|H | |H | ||
|4 Tunnel | |4 Tunnel | ||
|- | |- | ||
|Hager TYF120 | |Hager TYF120 | ||
|H | |H | ||
| | |? Tunnel | ||
|- | |- | ||
|MDT SCN-IP000.02 | |MDT SCN-IP000.02 | ||
| | |H | ||
|4 Tunnel | |4 Tunnel | ||
|- | |- | ||
|MDT SCN-IP100.02 | |MDT SCN-IP100.02 | ||
|M | |M H | ||
|4 Tunnel | |4 Tunnel | ||
|- | |||
|Enertex® KNX IP Secure Router | |||
|M H | |||
|kein support im secure Mode - H untested | |||
|- | |- | ||
| | | | ||
Zeile 89: | Zeile 110: | ||
| | | | ||
|- | |- | ||
|Produkte mit seriellen Schnittstellen | |Produkte mit seriellen od. USB Schnittstellen | ||
z.B: TUL-Stick, ROT; usw... | |||
| - | | - | ||
|Nur über knxd unterstützt | |Nur über knxd unterstützt | ||
|} | |} | ||
== Umstellung von TUL oder KNXTUL Modul == | |||
Vorgangsweise: fhem.cfg sichern! Bestehende TUL/KNXTUL - Definition noch nicht löschen, neue KNXIO - Definition anlegen. | |||
=== TUL-Modul === | |||
<syntaxhighlight lang="text"> | |||
Aus: | |||
define myTUL TUL eibd:192.168.5.246:6720 5.1.251 | |||
..wird: | |||
define myKNXGW KNXIO T 192.168.5.246:6720 5.1.251 | |||
</syntaxhighlight>Serielle Gateways (USB Stick / TPUART) werden vom KNXIO-Modul nicht direkt unterstützt. Für diese Varianten ist die Empfehlung, das via knxd-Daemon einzubinden und die Modes: M,S oder T zur Verbindung knxd->FHEM zu verwenden. (Der knxd-Daemon braucht weniger Resourcen und bietet eine wesentlich bessere Fehlertoleranz - für serielle Scnittstellen). | |||
=== KNXTUL-Modul === | |||
<syntaxhighlight lang="text"> | |||
Aus: | |||
define myKNXTUL KNXTUL 0.0.252 | |||
..wird: | |||
define myKNXGW KNXIO M 224.0.23.12:3671 0.0.252 | |||
</syntaxhighlight>Auf Grund der Änderung des Namens kann es passieren, dass im '''Reading IODev''' der KNX-Geräte nach wie vor das bisherige IO-Device (z.b: myTUL) steht. Damit würde das Senden von FHEM -> KNX nicht funktionieren. Abhilfe schaftt das löschen vom '''Attribut IODev''' für alle KNX-Geräte, z.B so:<syntaxhighlight lang="text"> | |||
deleteattr TYPE=KNX IODev | |||
</syntaxhighlight>Danach save - FHEM restart! Den fhem-start mit einem Blick ins Log-file beobachten. | |||
Danach die bisherige TUL/KNXTUL definition löschen. | |||
Es sollte jetzt das '''Reading IODev''' in allen KNX-Geräten auf das neue KNXIO-Gerät gesetzt sein! Das wird ab jetzt auch für künftige FHEM Starts verwendet. | |||
== Bekannte Probleme == | == Bekannte Probleme == | ||
==== Timing Problem Mode H ==== | ==== Timing Problem Mode H ==== | ||
Wie bereits erwähnt, dieser Mode stellt hohe Ansprüche an das Antwortzeitverhalten von FHEM. Jede empfangene und gesendete Message muss in weniger als 1 Sekunde bestätigt werden. Falls FHEM länger mit anderen Modulen beschäftigt ist, gibt das Probleme. Typische Module, die Probleme machen können, sind (u.A.): SVG | Wie bereits erwähnt, dieser Mode stellt hohe Ansprüche an das Antwortzeitverhalten von FHEM. Jede empfangene und gesendete Message muss in weniger als 1 Sekunde bestätigt werden. Falls FHEM länger mit anderen Modulen beschäftigt ist, gibt das Probleme. Typische Module, die Probleme machen können, sind (u.A.): SVG, Onewire, HTTPMOD, usw... | ||
Typische Meldungen im Log:<syntaxhighlight lang="text"> | Typische Meldungen im Log:<syntaxhighlight lang="text"> | ||
2021.12.13 00:00:06.506 | 2021.12.13 00:00:06.506 3: <device> [KNXIO_TunnelRequestTO 1216]: timeout - attempt resend | ||
2021.12.13 00:00:08.023 3: KNXIO_TunnelRequestTO | 2021.12.13 00:00:08.023 3: <device> [KNXIO_TunnelRequestTO 1224]: timeout - sending disconnect request | ||
2021.12.15 13:12:09.045 3: | 2021.12.15 13:12:09.045 3: <device> [KNXIO_ReadH 414]: TunnelRequest received: duplicate message received (seqcntr= xxx) - ack it | ||
</syntaxhighlight>Eine mögliche Lösung: Mittels | 2021.12.15 13:12:10.012 3: <device> [KNXIO_ReadH 426]: TunnelRequest received: out of sequence, (seqcntrRx= xxx seqcntrTx= yyy ) - no ack & discard | ||
</syntaxhighlight>Eine mögliche Lösung: Mittels [[Apptime]] cmd: "apptime average" bzw. "apptime max" jene Funktionen/Module herausfinden, die viel Zeit in FHEM beanspruchen... Werte größer 500ms können die Kommunikation zwischen FHEM und dem KNX-GW massiv stören. Werte die mit "tmr_" beginnen, sind nicht ganz so kritisch, sollten aber jedenfalls unter 900ms sein. | |||
Evtl hilft auch, die Anzahl Events zu reduzieren (Stichwort: event-on-change-reading). | |||
Falls das nicht funktioniert, gibts noch die Möglichkeit, für das KNXIO-Modul eine eigene FHEM Instanz zu installieren und mittels FHEM2FHEM mit der Hauptinstanz zu verbinden.. In diesem Beispiel auf zwei Raspberrys im selben LAN. Sinnvollerweise beginnt man mit der Konfiguration von FHEM-B. | Falls das nicht funktioniert, gibts noch die Möglichkeit, für das KNXIO-Modul eine eigene FHEM Instanz zu installieren und mittels FHEM2FHEM mit der Hauptinstanz zu verbinden.. In diesem Beispiel auf zwei Raspberrys im selben LAN. Sinnvollerweise beginnt man mit der Konfiguration von FHEM-B. | ||
Zeile 115: | Zeile 165: | ||
attr <name_F2F> reportConnected 1 | attr <name_F2F> reportConnected 1 | ||
</syntaxhighlight>'''Wichtig:''' <remoteDevice> muss in allen Definitionen '''der gleiche Name''' sein! <ip-addr:port> ist die Adresse von FHEM-B, port ist der port aus der telnet-Definition. | </syntaxhighlight>'''Wichtig:''' <remoteDevice> muss in allen Definitionen (FHEM-A, FHEM-B) '''der gleiche Name''' sein! <ip-addr:port> ist die Adresse von FHEM-B, port ist der port aus der telnet-Definition. | ||
Ändern des Attr IODev in allen KNX-definitionen: Attr IODev muss auf das FHEM2FHEM <name_F2F> Device zeigen. Entweder jedes KNX-device einzeln ändern, oder alle IODev Attribute in allen KNX-devices auf einmal löschen, mittels:<syntaxhighlight lang="text"> | Ändern des Attr IODev in allen KNX-definitionen: Attr IODev muss auf das FHEM2FHEM <name_F2F> Device zeigen. Entweder jedes KNX-device einzeln ändern, oder alle IODev Attribute in allen KNX-devices auf einmal löschen, mittels:<syntaxhighlight lang="text"> | ||
Zeile 121: | Zeile 171: | ||
</syntaxhighlight>Das ist kein Problem, (solange man nur EIN IO-device für KNX definiert hat), FHEM sucht beim start / defmod sich ein passendes IO-Device automatisch aus. | </syntaxhighlight>Das ist kein Problem, (solange man nur EIN IO-device für KNX definiert hat), FHEM sucht beim start / defmod sich ein passendes IO-Device automatisch aus. | ||
Die bisherige KNXIO-Definition löschen! | Die bisherige KNXIO-Definition löschen. Die sollte jetzt bereits in FHEM-B aktiv sein ! | ||
===== Konfiguration FHEM-B: ===== | ===== Konfiguration FHEM-B: ===== | ||
Starten mit minimal (default) Konfiguration, am besten nach Neu-Installation und fhem-update. | Starten mit minimal (default) Konfiguration, am besten nach Neu-Installation und fhem-update. | ||
Hier wird das KNXIO-Modul konfiguriert, das mit dem KNX Gateway kommuniziert. | Hier wird das KNXIO-Modul konfiguriert, das mit dem KNX Gateway kommuniziert. Das ist exakt die gleiche def wie bisher in FHEM-A ! | ||
Es braucht aber zusätzlich noch einige Definitionen zur Kommunikation mit FHEM-A:<syntaxhighlight lang="text"> | |||
define <remoteDevice> KNXIO <mode> <GW-IP:GW-port> <phy-addr> # exakt gleiche Definition wie bisher in FHEM-A | |||
define telnetPortKNX telnet <port> global # das kommuniziert mit dem FHEM2FHEM device auf FHEM-A | |||
define | attr telnetPortKNX allowfrom (127.0.0.1|192.168.x) # little bit of security, replace x with yr. local network... | ||
attr | |||
define | define allowed_telnetPortKNX allowed # little bit of security | ||
attr | attr allowed_telnetPortKNX allowedCommands iowrite,inform,trigger,quit | ||
attr | attr allowed_telnetPortKNX allowedIfAuthenticatedByMe 0 | ||
attr allowed_telnetPortKNX validFor telnetPortKNX | |||
attr initialUsbCheck disable 1 # stört alle seriellen IO's (ausser CUL....) | attr initialUsbCheck disable 1 # stört alle seriellen IO's (ausser CUL....) | ||
attr autocreate | attr autocreate ignoreTypes KNX_.* # we dont need/want KNX-devices on this FHEM | ||
</syntaxhighlight>'''Empfohlen:''' Für die telnet definition nicht den Standard-port 7072 verwenden, sondern z.B: 7073. | |||
'''Wichtig:''' Nach der Definition: save und shutdown/restart auf beiden FHEMs! Danach sollte das FHEM2FHEM-device connected zeigen, das KNXIO-device auf FHEM-A <remoteDevice> ebenfalls connected, wenn es ein passendes FHEM2FHEM Device gibt! | |||
'''Keine weiteren Verbindungen''' zwischen den beiden FHEM machen, e.g: FHEM2FHEM im Log Modus, RFHEM, notifies., Telnet connections,...., -Das ergibt Chaos! | '''Keine weiteren Verbindungen''' zwischen den beiden FHEM machen, e.g: FHEM2FHEM im Log Modus, RFHEM, notifies., Telnet connections,...., -Das ergibt Chaos! | ||
Zeile 147: | Zeile 200: | ||
Es werden alle KNX-Messages zwischen FHEM-A und FHEM-B ausgetauscht! | Es werden alle KNX-Messages zwischen FHEM-A und FHEM-B ausgetauscht! | ||
Zur Verbesserung der Sicherheit könnte man das telnet-device UND das FHEM2FHEM-device jeweils mit Passwort (globalpassword) versehen. | Zur Verbesserung der Sicherheit könnte man das telnet-device UND das FHEM2FHEM-device jeweils mit Passwort (globalpassword) und/oder SSL versehen. | ||
== FHEM im Docker Environment & Multicast == | |||
Wie bekannt, unterstützt Docker in Bridge Konfiguration '''kein Broadcast / Multicast.''' Daher funktioniert KNXIO Mode M nicht im Docker! In diversen Foren wird daher Docker host-mode empfohlen.Alle anderen KNXIO-modes funktionieren im bridge Modus! | |||
Der Host mode hat jedoch einige Nachteile, daher basierend auf {{Link2Forum|Topic=114284|LinkText=diesem Forum post}}, folgenden Lösung mittels macvlan:<syntaxhighlight lang="text"> | |||
docker network create -d macvlan -o parent=eth0 --subnet=192.168.5.0/24 --gateway=192.168.5.254 --ip-range=192.168.5.144/28 mymacvlannetwork | |||
docker run -d --name fhemdocker --network=mymacvlannetwork --ip=192.168.5.144 -h cl-RPI4-d1 -v /opt/volumes/fhem:/opt/fhem fhem/fhem | |||
</syntaxhighlight>Erstellen macvlan Network: | |||
* '''eth0''' ist der name des Ethernet Interfaces an docker-host | |||
* '''subnet / gateway''' dem Netzwerk Environment entsprechend. | |||
* '''ip-range''' ein Adress-Bereich aus dem Netzwerk, (in diesem Beispiel 16 Addressen 192.168.5.144 - .159), diese '''dürfen nicht''' im DHCP Range oder durch statische Adressen bereits vergeben sein! | |||
* '''mymacvlannetwork''' Name des macvlan | |||
Docker run cmd: | |||
* '''--name''' des containers | |||
* '''--network''' referenz auf macvlan | |||
* '''--ip''' (optional) eine statische Adresse aus dem definierten ip-range. Falls nicht angegeben, vergibt Docker eine Adresse aus diesem Bereich. | |||
* '''-v''' Mapping von /opt/volumes/fhem (am Docker host) auf /opt/fhem (im Container) - dort wird z.B auch die fhem.cfg / logs / ... permanent gespeichert. | |||
* '''fhem/fhem''' standard Image von docker hub | |||
Erreichbar ist FHEM auf: <nowiki>http://192.168.5.144:8083/fhem</nowiki> Alle ports die FHEM öffnet sind von überall (Ausnahme Docker-host) im eigenen Netz erreichbar. Von anderen Containern im gleichen macvlan ist der FHEM-container unter ''fhemdocker.mymacvlannetwork'' erreichbar. | |||
Nicht erreichbar ist vom docker host der FHEM Container und umgekehrt! Das ist eine Docker/macvlan Einschränkung. Container <-> Container connectivity ist gegeben, wenn die Container im gleichen macvlan sind. | |||
Falls die Namensauflösung (--name fhemdocker) im Netz nicht funktioniert, kann der name z.B. in der Fritzbox statisch definiert werden. | |||
== KNXD im Docker & Multicast == | |||
KNXD Docker Images gibit es einige am docker.hub, die meisten davon kompilieren knxd aus den sourcen, was nicht mehr nötig ist. Daher hier eine Anleitung, wie knxd im Docker funktionieren kann, inklusive MC-support: | |||
Ein Verzeichnis erstellen und in dieses wechseln:, z.B: | |||
''mkdir ~/knxd && cd ~/knxd'' | |||
'''Dockerfile in diesem Verzeichnis erstellen:'''<syntaxhighlight lang="dockerfile"> | |||
FROM debian:bullseye-slim AS knxd | |||
ENV TZ="Europe/Vienna" | |||
RUN date | |||
RUN apt-get update \ | |||
&& apt-get upgrade -y \ | |||
&& apt-get install -y \ | |||
knxd \ | |||
knxd-tools \ | |||
net-tools \ | |||
iproute2 \ | |||
iputils-ping \ | |||
nano \ | |||
procps \ | |||
&& rm -rf /var/lib/apt/lists/* /var/log/* /var/tmp/* /tmp/* /usr/share/doc/* /usr/share/man/*/* /var/cache/apt \ | |||
&& adduser knxd tty | |||
COPY --chmod=755 ./startknxd.sh / | |||
COPY --chmod=666 ./knxd.ini / | |||
RUN mkdir /var/run/knx | |||
RUN chmod 777 /var/run/knx | |||
EXPOSE 3671/udp | |||
EXPOSE 6720 | |||
ENTRYPOINT ["/startknxd.sh"] | |||
</syntaxhighlight>'''startknxd.sh erstellen:'''<syntaxhighlight lang="bash"> | |||
#!/bin/bash | |||
# wait for knxd started and create socks file | |||
#sleep 10 && chmod 777 /var/run/knx/knxd.sock & | |||
SOCKSFILE="/var/run/knx/knxd.sock" | |||
waitForSocksFile() { | |||
local sFile="$1" | |||
local dt=$(date '+%F %H:%M:%S.%3N') | |||
echo -en "${dt} waiting for knxd start " | |||
for i in {1..20} | |||
do | |||
if test -S "$sFile"; then | |||
echo -e "\n$(date '+%F %H:%M:%S.%3N') socks file updated\n" | |||
chmod 777 $sFile | |||
break | |||
else | |||
echo -en "." | |||
fi | |||
sleep 0.5 | |||
done | |||
} | |||
if test -e "$SOCKSFILE"; then | |||
rm "$SOCKSFILE" # delete old file | |||
fi | |||
waitForSocksFile "$SOCKSFILE" & | |||
sleep 0.2 | |||
exec knxd /knxd.ini | |||
</syntaxhighlight>'''knxd.ini erstellen:'''<syntaxhighlight lang="ini"> | |||
[A.tcp] | |||
server = knxd_tcp | |||
filters = retryFilter | |||
systemd-ignore = true | |||
[B.unix] | |||
path = /var/run/knx/knxd.sock | |||
server = knxd_unix | |||
systemd-ignore = true | |||
[C.ipt] | |||
driver = ipt | |||
filters = retryFilter | |||
ip-address = 192.168.10.232 | |||
[debug-server] | |||
name = mcast:knxd | |||
[main] | |||
addr = 0.0.20 | |||
client-addrs = 0.0.21:8 | |||
connections = server,A.tcp,B.unix,C.ipt | |||
systemd = systemd | |||
[server] | |||
debug = debug-server | |||
discover = true | |||
multicast-address = 224.0.23.12 | |||
port = 3671 | |||
router = router | |||
server = ets_router | |||
tunnel = tunnel | |||
[retryFilter] | |||
filter = retry | |||
max-retries = 0 | |||
retry-delay = 60 | |||
start-timeout = 10 | |||
may-fail = true | |||
</syntaxhighlight>Diese knxd.ini ist als Beispiel zu sehen, muß jedenfalls an die eigenen Anfordeungen angepasst werden. Es gibt ein Utility um eine knxd.ini aus dem commandline-syntax zu erstellen:<syntaxhighlight lang="shell"> | |||
/usr/lib/knxd_args -e 0.0.20 -E 0.0.21:8 -D -T -R .... >knxd.ini | |||
</syntaxhighlight>Wichtig: Nachdem in diesem docker-image '''kein systemd''' läuft, alle Einräge auf: ''systemd-ignore = true'' ändern! Weiters ist der Abschnitt retryFilter sinnvoll, wel sonst der knxd unmittelbar terminiert (Error: F00000105), falls ein x.ipt oder x.tcp nicht erreichbar sein sollte! | |||
'''create image & run knxd:'''<syntaxhighlight lang="bash"> | |||
sudo docker build -t MH/knxd . | |||
sudo docker run -d --name knxd --network=mymacvlannetwork --ip=192.168.5.145 -h cl-RPI4-knxd -v /var/run/knx:/var/run/knx --restart=unless-stopped MH/knxd | |||
</syntaxhighlight>build muss bei jeder Änderung in knxd.ini und startknxd.sh aufgerufen werden. Name / Host-name / ImageName / ip sind als Beispiel zu sehen. | |||
Das ''--network=mymacvlannetwork'' ist nur notwendig, falls der knxd auch '''Multicas'''t oder '''discovery''' (verwendet von ETS) unterstützen soll. | |||
Das ''-v /var/run/knx:/var/run/knx'' ermöglicht die Kommunikation via socks file zu einem FHEM (im Docker Container) mittels KNXIO mode S ! Die dazu passende FHEM Definition:<syntaxhighlight lang="text"> | |||
define <name> KNXIO S UNIX:STREAM:/var/run/knx/knxd.sock <x.y.z> | |||
</syntaxhighlight>Multicast zwischen Docker-Containern (FHEM <.> knxd) funktioniert nicht, daher die Empfehlung KNXIO mode S zu verwenden. | |||
== Links == | == Links == |
Aktuelle Version vom 16. Juli 2024, 18:07 Uhr
KNXIO | |
---|---|
Zweck / Funktion | |
Unterstützung des KNX Feldbus in FHEM | |
Allgemein | |
Typ | Gerätemodul |
Details | |
Dokumentation | EN / DE |
Support (Forum) | KNX/EIB |
Modulname | 00_KNXIO.pm |
Ersteller | Erwin (Forum /Wiki) |
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref! |
Das Modul KNXIO implementiert die Unterstützung für den Gebäudeautomations-Feldbus KNX (eine Weiterentwicklung von EIB) innerhalb von FHEM.
Vorwort
KNX ist in FHEM nach dem 2-stufigen Modell implementiert. Das KNXIO-Modul unterstützt die Kommunikation mit einem KNX-Gateway, der "Aussenwelt", während das KNX-Modul die logische Schnitstelle zum Anwender ist.
Die Idee zu diesem Modul ist: ein Modul für (fast) alle möglichen Kommunikations-Varianten zu haben, das auch vernünftig wartbar ist. Dieses Modul soll langfristig die bisherigen Module TUL und KNXTUL ablösen.
KNX-secure ist nicht unterstüzt, weil bisher m.W. keine frei zugängliche Dokumentation des Prokotolls verfügbar ist und ich dzt. kein GW besitze, dass KNX-secure unterstützt.
Anwendung
Define
define <name> KNXIO <[MHT]> <IP-Adresse/Hostname>:<Port> <Phy-Adresse> bzw.
define <name> KNXIO S <socket-path> <Phy-Adresse>
Wie in FHEM üblich, alles was hier zwischen <...> dargestellt ist, sind verpflichtende Angaben! Optionales wird zwischen [...] dargestellt.
Definitions-Felder im Detail
Mode:
- H -Host Mode: Verbindung zu einem KNX-Gateway mit UDP Point-Point Protokoll. Dieser Protokoll wird auch von der ETS verwendet (KNXNET/IP). Das Protokoll ist sehr kritisch in Bezug auf Timing, Verzögerungen in FHEM (durch andere Tasks...) größer 1 Sekunde führen zu Verbindungsabbrüchen! Die Verbindung wird zwar unmittelbar wieder hergestellt, allerdings können einige Messages verloren gehen.
- M -Multicast mode: Verbindung zu knxd-Daemon oder KNX-Router mit Multicast Protokoll. Dieses Protokoll wird auch von der ETS verwendet (KNXNET/Routing). Falls ein KNX-Gateway Multicast unterstützt, braucht man keine knxd Installation! Dieser Modus ist der Nachfolger des KNXTUL-Moduls.
- T -TCP Mode: Verbindet mittels TCP-Protokoll mit knxd. Dieser Modus ist der Nachfolger des TUL-Moduls.. Eine direkte Unterstützung von Seriellen/USB Gateways ist nicht implementiert! Falls ein Serielles / USB -Gateway verwendet wird ist die Empfehlung, das via knxd-daemon einzubinden und die Modes: M,S oder T zur Verbindung knxd->FHEM zu verwenden.
- S -Socket Mode: Verbindet mittels UNIX_Socket zum knxd - Funktionert nur wenn sowohl FHEM als auch knxd am selben System laufen! Getestet wurde mit knxd-Verion 0.14.30. (Funktioniert definitiv NICHT mit knxd Version 0.10.0)
- X - Dummy Mode: Mode zum Testen ohne KNX-GW (und für ganz spezielle Fälle...)
IP-Adresse/Hostname:Port
Hostnamen sind unterstützt im Mode H und T.
Default/Standard Multicast Adresse (Mode M) ist: 244.0.23.12
Default/Standard Port für Mode H und M ist 3671, für Mode T 6720.
Default Socket path (Mode S) : /var/run/knxd (knxd-Version: 0.10.0) oder /run/knx (knxd-Version: 0.14.46) oder /var/run/knx (knxd-Version: 0.14.46), am besten in /etc/knxd.conf nachschauen!
Phy-Adresse
Das ist die Physikalische Adresse, die das KNX-Gateway bzw. knxd für Clients am LAN (also auch FHEM) bereitstellt. Der Wert sollte (bei Verwendung knxd) dem -E Parameter (Pool) in der knxd-Konfiguration entsprechen.
Alle Parameter sind verpflichtend! Bitte sicherstellen, dass es nur einen Kommunikationspfad zwischen dem KNX-Gateway und FHEM gibt! Das ist am sichersten erreichbar, wenn es in FHEM nur ein IO-Device (TUL/KNXTUL/KNXIO) für den KNX-Bus gibt.
Definitions-Beispiele
define myKNXGW KNXIO H 192.168.1.201:3671 0.0.51
define myKNXGW KNXIO M 224.0.23.12:3671 0.0.51
define myKNXGW KNXIO S /var/run/knx 0.0.51
define myKNXGW KNXIO T 192.168.1.200:6720 0.0.51
Siehe auch commandref/KNXIO.
Empfohlene Parameter für knxd Konfiguration: (üblicherweise zu finden: /etc/knxd.conf)
KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -R -S -b ipt:192.168.xx.yy" # connect to a knx-GW with ip-addr
KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -R -S -single -b tpuarts:/dev/ttyxxx" # connect to a serial/USB KNX GW
KNXD_OPTS="-e 0.0.50 -E 0.0.51:8 -D -T -S -b ip:" # knxd acts as multicast client (connect to other knxd or KNX-Router with MC support)
Der Parameter -e 0.0.50 definiert die phy-Addresse des Gateways, -E 0.0.51:8 definiert einen Pool von 8 Phy-Addr. für Clients am LAN! (FHEM ist ein Client am LAN aus KNX Sicht! )
Die Parameter -R -S aktivieren den Multicast Support, -T -S den Tunnel Support im knxd. -D aktiviert Autodiscovery, wird allerdings von FHEM/KNXIO nicht verwendet, aber von der ETS-Software!
Der -S Parameter muss immer als letztes der Server Parameter (-D -T -R) stehen!
Siehe auch knxd-Wiki
Attribute
- disable - ident zum FHEM Standard - kein Senden / Empfangen möglich.
- verbose - ident zum FHEM Standard - bestimmt welche/wieviele Meldungen ins Log geschrieben werden.
- enableKNXscan - löst ein KNXscan cmd aus: nie -> 0 , Fhem Start -> 1 , bei jedem connect event -> 2. Details dazu: hier
Matrix - Modes<->Produkte
Die Tabelle soll die möglichen KNXIO-modes für KNX-GW's bzw. KNX-Router zeigen. Entstanden (und hoffentlich erweitert...) durch eigene Erfahrung und Tests bzw. auch aus Feedback aus dem Forum. Verwendete Produkt-Bezeichnungen können geschützte Namen sein, Diese werden hier ausschließlich verwendet um die Kompatibilität zum KNXIO-Modul darzustellen. Info über Produkte und ErfolgsMeldungen, aber auch Korrekturen sind willkommen, entweder direkt hier hinzufügen oder via Forum!
Produkt | KNXIO-mode | Kommentar |
---|---|---|
knxd | M S T | knxd -daemon (getestet ab V.0.10.0),
Mode S nur falls knxd am selben host läuft. (getested ab ab V.0.14.30) |
Weinzierl IP731 | H | 4 Tunnel |
Hager TYF120 | H | ? Tunnel |
MDT SCN-IP000.02 | H | 4 Tunnel |
MDT SCN-IP100.02 | M H | 4 Tunnel |
Enertex® KNX IP Secure Router | M H | kein support im secure Mode - H untested |
Produkte mit seriellen od. USB Schnittstellen
z.B: TUL-Stick, ROT; usw... |
- | Nur über knxd unterstützt |
Umstellung von TUL oder KNXTUL Modul
Vorgangsweise: fhem.cfg sichern! Bestehende TUL/KNXTUL - Definition noch nicht löschen, neue KNXIO - Definition anlegen.
TUL-Modul
Aus:
define myTUL TUL eibd:192.168.5.246:6720 5.1.251
..wird:
define myKNXGW KNXIO T 192.168.5.246:6720 5.1.251
Serielle Gateways (USB Stick / TPUART) werden vom KNXIO-Modul nicht direkt unterstützt. Für diese Varianten ist die Empfehlung, das via knxd-Daemon einzubinden und die Modes: M,S oder T zur Verbindung knxd->FHEM zu verwenden. (Der knxd-Daemon braucht weniger Resourcen und bietet eine wesentlich bessere Fehlertoleranz - für serielle Scnittstellen).
KNXTUL-Modul
Aus:
define myKNXTUL KNXTUL 0.0.252
..wird:
define myKNXGW KNXIO M 224.0.23.12:3671 0.0.252
Auf Grund der Änderung des Namens kann es passieren, dass im Reading IODev der KNX-Geräte nach wie vor das bisherige IO-Device (z.b: myTUL) steht. Damit würde das Senden von FHEM -> KNX nicht funktionieren. Abhilfe schaftt das löschen vom Attribut IODev für alle KNX-Geräte, z.B so:
deleteattr TYPE=KNX IODev
Danach save - FHEM restart! Den fhem-start mit einem Blick ins Log-file beobachten.
Danach die bisherige TUL/KNXTUL definition löschen.
Es sollte jetzt das Reading IODev in allen KNX-Geräten auf das neue KNXIO-Gerät gesetzt sein! Das wird ab jetzt auch für künftige FHEM Starts verwendet.
Bekannte Probleme
Timing Problem Mode H
Wie bereits erwähnt, dieser Mode stellt hohe Ansprüche an das Antwortzeitverhalten von FHEM. Jede empfangene und gesendete Message muss in weniger als 1 Sekunde bestätigt werden. Falls FHEM länger mit anderen Modulen beschäftigt ist, gibt das Probleme. Typische Module, die Probleme machen können, sind (u.A.): SVG, Onewire, HTTPMOD, usw...
Typische Meldungen im Log:
2021.12.13 00:00:06.506 3: <device> [KNXIO_TunnelRequestTO 1216]: timeout - attempt resend
2021.12.13 00:00:08.023 3: <device> [KNXIO_TunnelRequestTO 1224]: timeout - sending disconnect request
2021.12.15 13:12:09.045 3: <device> [KNXIO_ReadH 414]: TunnelRequest received: duplicate message received (seqcntr= xxx) - ack it
2021.12.15 13:12:10.012 3: <device> [KNXIO_ReadH 426]: TunnelRequest received: out of sequence, (seqcntrRx= xxx seqcntrTx= yyy ) - no ack & discard
Eine mögliche Lösung: Mittels Apptime cmd: "apptime average" bzw. "apptime max" jene Funktionen/Module herausfinden, die viel Zeit in FHEM beanspruchen... Werte größer 500ms können die Kommunikation zwischen FHEM und dem KNX-GW massiv stören. Werte die mit "tmr_" beginnen, sind nicht ganz so kritisch, sollten aber jedenfalls unter 900ms sein.
Evtl hilft auch, die Anzahl Events zu reduzieren (Stichwort: event-on-change-reading).
Falls das nicht funktioniert, gibts noch die Möglichkeit, für das KNXIO-Modul eine eigene FHEM Instanz zu installieren und mittels FHEM2FHEM mit der Hauptinstanz zu verbinden.. In diesem Beispiel auf zwei Raspberrys im selben LAN. Sinnvollerweise beginnt man mit der Konfiguration von FHEM-B.
Konfiguration FHEM-A (Hauptinstanz):
Das ist jenes FHEM, wo bisher das KNXIO Modul und alle KNX-Devices definiert sind.
define <remoteDevice> KNXIO X # das ist ein dummy device,wird aber für die FHEM2FHEM definition benötigt
define <name_F2F> FHEM2FHEM <ip-addr:port> RAW:<remoteDevice> # verbindet zum telnet-dev auf FHEM-B
attr <name_F2F> keepaliveInterval 60
attr <name_F2F> reportConnected 1
Wichtig: <remoteDevice> muss in allen Definitionen (FHEM-A, FHEM-B) der gleiche Name sein! <ip-addr:port> ist die Adresse von FHEM-B, port ist der port aus der telnet-Definition. Ändern des Attr IODev in allen KNX-definitionen: Attr IODev muss auf das FHEM2FHEM <name_F2F> Device zeigen. Entweder jedes KNX-device einzeln ändern, oder alle IODev Attribute in allen KNX-devices auf einmal löschen, mittels:
deleteattr TYPE=KNX IODev
Das ist kein Problem, (solange man nur EIN IO-device für KNX definiert hat), FHEM sucht beim start / defmod sich ein passendes IO-Device automatisch aus.
Die bisherige KNXIO-Definition löschen. Die sollte jetzt bereits in FHEM-B aktiv sein !
Konfiguration FHEM-B:
Starten mit minimal (default) Konfiguration, am besten nach Neu-Installation und fhem-update.
Hier wird das KNXIO-Modul konfiguriert, das mit dem KNX Gateway kommuniziert. Das ist exakt die gleiche def wie bisher in FHEM-A !
Es braucht aber zusätzlich noch einige Definitionen zur Kommunikation mit FHEM-A:
define <remoteDevice> KNXIO <mode> <GW-IP:GW-port> <phy-addr> # exakt gleiche Definition wie bisher in FHEM-A
define telnetPortKNX telnet <port> global # das kommuniziert mit dem FHEM2FHEM device auf FHEM-A
attr telnetPortKNX allowfrom (127.0.0.1|192.168.x) # little bit of security, replace x with yr. local network...
define allowed_telnetPortKNX allowed # little bit of security
attr allowed_telnetPortKNX allowedCommands iowrite,inform,trigger,quit
attr allowed_telnetPortKNX allowedIfAuthenticatedByMe 0
attr allowed_telnetPortKNX validFor telnetPortKNX
attr initialUsbCheck disable 1 # stört alle seriellen IO's (ausser CUL....)
attr autocreate ignoreTypes KNX_.* # we dont need/want KNX-devices on this FHEM
Empfohlen: Für die telnet definition nicht den Standard-port 7072 verwenden, sondern z.B: 7073.
Wichtig: Nach der Definition: save und shutdown/restart auf beiden FHEMs! Danach sollte das FHEM2FHEM-device connected zeigen, das KNXIO-device auf FHEM-A <remoteDevice> ebenfalls connected, wenn es ein passendes FHEM2FHEM Device gibt!
Keine weiteren Verbindungen zwischen den beiden FHEM machen, e.g: FHEM2FHEM im Log Modus, RFHEM, notifies., Telnet connections,...., -Das ergibt Chaos!
Es werden alle KNX-Messages zwischen FHEM-A und FHEM-B ausgetauscht!
Zur Verbesserung der Sicherheit könnte man das telnet-device UND das FHEM2FHEM-device jeweils mit Passwort (globalpassword) und/oder SSL versehen.
FHEM im Docker Environment & Multicast
Wie bekannt, unterstützt Docker in Bridge Konfiguration kein Broadcast / Multicast. Daher funktioniert KNXIO Mode M nicht im Docker! In diversen Foren wird daher Docker host-mode empfohlen.Alle anderen KNXIO-modes funktionieren im bridge Modus!
Der Host mode hat jedoch einige Nachteile, daher basierend auf diesem Forum post, folgenden Lösung mittels macvlan:
docker network create -d macvlan -o parent=eth0 --subnet=192.168.5.0/24 --gateway=192.168.5.254 --ip-range=192.168.5.144/28 mymacvlannetwork
docker run -d --name fhemdocker --network=mymacvlannetwork --ip=192.168.5.144 -h cl-RPI4-d1 -v /opt/volumes/fhem:/opt/fhem fhem/fhem
Erstellen macvlan Network:
- eth0 ist der name des Ethernet Interfaces an docker-host
- subnet / gateway dem Netzwerk Environment entsprechend.
- ip-range ein Adress-Bereich aus dem Netzwerk, (in diesem Beispiel 16 Addressen 192.168.5.144 - .159), diese dürfen nicht im DHCP Range oder durch statische Adressen bereits vergeben sein!
- mymacvlannetwork Name des macvlan
Docker run cmd:
- --name des containers
- --network referenz auf macvlan
- --ip (optional) eine statische Adresse aus dem definierten ip-range. Falls nicht angegeben, vergibt Docker eine Adresse aus diesem Bereich.
- -v Mapping von /opt/volumes/fhem (am Docker host) auf /opt/fhem (im Container) - dort wird z.B auch die fhem.cfg / logs / ... permanent gespeichert.
- fhem/fhem standard Image von docker hub
Erreichbar ist FHEM auf: http://192.168.5.144:8083/fhem Alle ports die FHEM öffnet sind von überall (Ausnahme Docker-host) im eigenen Netz erreichbar. Von anderen Containern im gleichen macvlan ist der FHEM-container unter fhemdocker.mymacvlannetwork erreichbar.
Nicht erreichbar ist vom docker host der FHEM Container und umgekehrt! Das ist eine Docker/macvlan Einschränkung. Container <-> Container connectivity ist gegeben, wenn die Container im gleichen macvlan sind.
Falls die Namensauflösung (--name fhemdocker) im Netz nicht funktioniert, kann der name z.B. in der Fritzbox statisch definiert werden.
KNXD im Docker & Multicast
KNXD Docker Images gibit es einige am docker.hub, die meisten davon kompilieren knxd aus den sourcen, was nicht mehr nötig ist. Daher hier eine Anleitung, wie knxd im Docker funktionieren kann, inklusive MC-support:
Ein Verzeichnis erstellen und in dieses wechseln:, z.B:
mkdir ~/knxd && cd ~/knxd
Dockerfile in diesem Verzeichnis erstellen:
FROM debian:bullseye-slim AS knxd
ENV TZ="Europe/Vienna"
RUN date
RUN apt-get update \
&& apt-get upgrade -y \
&& apt-get install -y \
knxd \
knxd-tools \
net-tools \
iproute2 \
iputils-ping \
nano \
procps \
&& rm -rf /var/lib/apt/lists/* /var/log/* /var/tmp/* /tmp/* /usr/share/doc/* /usr/share/man/*/* /var/cache/apt \
&& adduser knxd tty
COPY --chmod=755 ./startknxd.sh /
COPY --chmod=666 ./knxd.ini /
RUN mkdir /var/run/knx
RUN chmod 777 /var/run/knx
EXPOSE 3671/udp
EXPOSE 6720
ENTRYPOINT ["/startknxd.sh"]
startknxd.sh erstellen:
#!/bin/bash
# wait for knxd started and create socks file
#sleep 10 && chmod 777 /var/run/knx/knxd.sock &
SOCKSFILE="/var/run/knx/knxd.sock"
waitForSocksFile() {
local sFile="$1"
local dt=$(date '+%F %H:%M:%S.%3N')
echo -en "${dt} waiting for knxd start "
for i in {1..20}
do
if test -S "$sFile"; then
echo -e "\n$(date '+%F %H:%M:%S.%3N') socks file updated\n"
chmod 777 $sFile
break
else
echo -en "."
fi
sleep 0.5
done
}
if test -e "$SOCKSFILE"; then
rm "$SOCKSFILE" # delete old file
fi
waitForSocksFile "$SOCKSFILE" &
sleep 0.2
exec knxd /knxd.ini
knxd.ini erstellen:
[A.tcp]
server = knxd_tcp
filters = retryFilter
systemd-ignore = true
[B.unix]
path = /var/run/knx/knxd.sock
server = knxd_unix
systemd-ignore = true
[C.ipt]
driver = ipt
filters = retryFilter
ip-address = 192.168.10.232
[debug-server]
name = mcast:knxd
[main]
addr = 0.0.20
client-addrs = 0.0.21:8
connections = server,A.tcp,B.unix,C.ipt
systemd = systemd
[server]
debug = debug-server
discover = true
multicast-address = 224.0.23.12
port = 3671
router = router
server = ets_router
tunnel = tunnel
[retryFilter]
filter = retry
max-retries = 0
retry-delay = 60
start-timeout = 10
may-fail = true
Diese knxd.ini ist als Beispiel zu sehen, muß jedenfalls an die eigenen Anfordeungen angepasst werden. Es gibt ein Utility um eine knxd.ini aus dem commandline-syntax zu erstellen:
/usr/lib/knxd_args -e 0.0.20 -E 0.0.21:8 -D -T -R .... >knxd.ini
Wichtig: Nachdem in diesem docker-image kein systemd läuft, alle Einräge auf: systemd-ignore = true ändern! Weiters ist der Abschnitt retryFilter sinnvoll, wel sonst der knxd unmittelbar terminiert (Error: F00000105), falls ein x.ipt oder x.tcp nicht erreichbar sein sollte!
create image & run knxd:
sudo docker build -t MH/knxd .
sudo docker run -d --name knxd --network=mymacvlannetwork --ip=192.168.5.145 -h cl-RPI4-knxd -v /var/run/knx:/var/run/knx --restart=unless-stopped MH/knxd
build muss bei jeder Änderung in knxd.ini und startknxd.sh aufgerufen werden. Name / Host-name / ImageName / ip sind als Beispiel zu sehen.
Das --network=mymacvlannetwork ist nur notwendig, falls der knxd auch Multicast oder discovery (verwendet von ETS) unterstützen soll.
Das -v /var/run/knx:/var/run/knx ermöglicht die Kommunikation via socks file zu einem FHEM (im Docker Container) mittels KNXIO mode S ! Die dazu passende FHEM Definition:
define <name> KNXIO S UNIX:STREAM:/var/run/knx/knxd.sock <x.y.z>
Multicast zwischen Docker-Containern (FHEM <.> knxd) funktioniert nicht, daher die Empfehlung KNXIO mode S zu verwenden.
Links
Info zum Thema KNXD Konfiguration (beim Author): KNXD Wiki