KNXIO - Versionsgeschichte

Erwin111: /* Definitions-Beispiele */ Korrektur knxd options

2026-02-28T07:23:41Z

Definitions-Beispiele: Korrektur knxd options

← Nächstältere Version		Version vom 28. Februar 2026, 09:23 Uhr
Zeile 60:		Zeile 60:
	<syntaxhighlight lang="text">		<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 -B 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>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! )		</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! )

Erwin111: /* Vorwort */

2026-01-15T13:44:43Z

Vorwort

← Nächstältere Version		Version vom 15. Januar 2026, 15:44 Uhr
Zeile 15:		Zeile 15:

	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.		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.

			Serielle- bzw. USB-KNX Gateways sind nicht direkt unterstützt. Empfohlen wird die Lösung mittels knxd<->KNX-Gateway und Verbindung knxd<->FHEM mittels mode KNXIO-M oder -T.
	== Anwendung ==		== Anwendung ==
	=== Define ===		=== Define ===

Erwin111: /* Bekannte Probleme */

2025-12-08T09:43:06Z

Bekannte Probleme

← Nächstältere Version		Version vom 8. Dezember 2025, 11:43 Uhr
Zeile 144:		Zeile 144:

	==== 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, Onewire, HTTPMOD, usw...		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. Der Vorteil: Es kann keine msg verloren gehen, ohne einen Eintrag im Logfile! Falls allerdings 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">
Zeile 150:		Zeile 150:
	2021.12.13 00:00:08.023 3: <device> [KNXIO_TunnelRequestTO 1224]: timeout - sending disconnect request		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: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		2021.12.15 13:12:10.012 3: <device> [KNXIO_ReadH 426]: TunnelRequest message out of sequence received: seqcntrRx received/expected= xxx/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.		</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.

Erwin111: /* Timing Problem Mode H */

2025-12-07T14:52:39Z

Timing Problem Mode H

@@ Zeile 155: / Zeile 155: @@
 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 zur Lösung führt, ist die Empfehlung, die Kommunikation über knxd zu lösen. Also: KNX-GW <-> knxd <-> FHEM (mode S, M od. T). Der knxd als eigenständiger Deamon ist nicht von Verzögerungen durch FHEM betroffen und hat bessere Fehler-Toleranz.
 == FHEM im Docker Environment & Multicast ==

Erwin111: /* KNXD im Docker & Multicast */ --device option

2024-10-30T10:15:26Z

KNXD im Docker & Multicast: --device option

← Nächstältere Version		Version vom 30. Oktober 2024, 12:15 Uhr
Zeile 346:		Zeile 346:
	define <name> KNXIO S UNIX:STREAM:/var/run/knx/knxd.sock <x.y.z>		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.		</syntaxhighlight>Multicast zwischen Docker-Containern (FHEM <.> knxd) funktioniert nicht, daher die Empfehlung KNXIO mode S zu verwenden.

			Falls KNXD Serielle oder USB Schnittstellen verwenden soll, muss im run cmd die device option verwendet werden, z.B:<syntaxhighlight lang="bash">
			sudo docker run ... --device=/dev/ttyUSB0 ...
			</syntaxhighlight>Alternativ kann der Container auch im privileged mode laufen, damit ist Zugriff auf '''alle''' Host devices gegeben!

	== Links ==		== Links ==

Erwin111: /* TUL-Modul */

2024-07-16T16:07:47Z

TUL-Modul

← Nächstältere Version		Version vom 16. Juli 2024, 18:07 Uhr
Zeile 125:		Zeile 125:
	..wird:		..wird:
	define myKNXGW KNXIO T 192.168.5.246:6720 5.1.251		define myKNXGW KNXIO T 192.168.5.246:6720 5.1.251
	</syntaxhighlight>		</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 ===		=== KNXTUL-Modul ===

Erwin111: /* Umstellung von TUL oder KNXTUL Modul */ Beschreibung vereinfacht

2024-07-16T15:53:00Z

Umstellung von TUL oder KNXTUL Modul: Beschreibung vereinfacht

← Nächstältere Version		Version vom 16. Juli 2024, 17:53 Uhr
Zeile 117:		Zeile 117:

	== Umstellung von TUL oder KNXTUL Modul ==		== Umstellung von TUL oder KNXTUL Modul ==
	Vorgangsweise: ~~Config~~ sichern! Bestehende TUL/KNXTUL - Definition löschen ~~und~~ neue KNXIO - Definition anlegen~~. FHEM restart!~~		Vorgangsweise: fhem.cfg sichern! Bestehende TUL/KNXTUL - Definition noch nicht löschen, neue KNXIO - Definition anlegen.

	~~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:<syntaxhighlight lang="text">~~
	~~attr TYPE=KNX IODev myKNXGW~~
	~~</syntaxhighlight>Das '''Attribut IODev''' kann nach einem weiteren restart vom FHEM wieder gelöscht werden! <syntaxhighlight lang="text">~~
	~~deleteattr TYPE=KNX IODev~~
	~~</syntaxhighlight>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 ===		=== TUL-Modul ===
Zeile 141:		Zeile 133:
	..wird:		..wird:
	define myKNXGW KNXIO M 224.0.23.12:3671 0.0.252		define myKNXGW KNXIO M 224.0.23.12:3671 0.0.252
	</syntaxhighlight>		</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 ==

Erwin111: /* Attribute */

2024-04-24T12:10:19Z

Attribute

← Nächstältere Version		Version vom 24. April 2024, 14:10 Uhr
Zeile 71:		Zeile 71:
	* '''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=de\|Anker=KNX-utilities\|Label=hier}}		* '''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 ==

Erwin111: /* Attribute */

2024-04-24T12:08:21Z

Attribute

← Nächstältere Version		Version vom 24. April 2024, 14:08 Uhr
Zeile 71:		Zeile 71:
	* '''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=de\|Anker=~~KNXIO#~~KNX-utilities\|Label=hier}}		* '''enableKNXscan''' - löst ein KNXscan cmd aus: nie -> 0 , Fhem Start -> 1 , bei jedem connect event -> 2. Details dazu: {{Link2CmdRef\|Lang=de\|Anker=KNX-utilities\|Label=hier}}

	== Matrix - Modes<->Produkte ==		== Matrix - Modes<->Produkte ==

Erwin111: /* Definitions-Beispiele */

2024-04-24T12:05:19Z

Definitions-Beispiele

← Nächstältere Version		Version vom 24. April 2024, 14:05 Uhr
Zeile 71:		Zeile 71:
	* '''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=de\|Anker=#KNX-utilities\|Label=hier}}		* '''enableKNXscan''' - löst ein KNXscan cmd aus: nie -> 0 , Fhem Start -> 1 , bei jedem connect event -> 2. Details dazu: {{Link2CmdRef\|Lang=de\|Anker=KNXIO#KNX-utilities\|Label=hier}}

	== Matrix - Modes<->Produkte ==		== Matrix - Modes<->Produkte ==