KNXIO

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.

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 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 Schnittstellen	-	Nur über knxd unterstützt

Umstellung von TUL oder KNXTUL Modul

Vorgangsweise: Config sichern! Bestehende TUL/KNXTUL - Definition löschen und neue KNXIO - Definition anlegen. FHEM restart!

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 definieren vom Attribut IODev für alle KNX-Geräte, z.B so:

attr TYPE=KNX IODev myKNXGW

Das Attribut IODev kann nach einem weiteren restart vom FHEM wieder gelöscht werden!

deleteattr TYPE=KNX IODev

Es sollte jetzt das Reading IODev in den KNX-Geräten auf das neue KNXIO-Gerät gesetzt sein! Das wird ab jetzt auch für künftige FHEM Starts verwendet.

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

KNXTUL-Modul

Aus:
define myKNXTUL KNXTUL 0.0.252 
..wird:
define myKNXGW KNXIO M 224.0.23.12:3671 0.0.252

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 4: KNXIO_TunnelRequestTO hit - attempt resend
2021.12.13 00:00:08.023 3: KNXIO_TunnelRequestTO hit - sending disconnect request
2021.12.15 13:12:09.045 3: KNXIO_Read: TunnelRequest received: duplicate message received (seqcntr=67) - ack it
2021.12.15 13:12:10.012 3: KNXIO_Read: TunnelRequest received: out of sequence, (seqcntrRx=99, seqcntrTx= 45) - 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. 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.

Links

Info zum Thema KNXD Konfiguration (beim Author): KNXD Wiki

Knxd-Wiki

FHEM2FHEM-Wiki