KNX - Versionsgeschichte

Ph1959de: Sichtung der letzten Änderungen; kleinere Korrekturen

2025-12-09T19:35:01Z

Sichtung der letzten Änderungen; kleinere Korrekturen

← Nächstältere Version		Version vom 9. Dezember 2025, 21:35 Uhr
Zeile 11:		Zeile 11:
	== Voraussetzungen ==		== Voraussetzungen ==
	{{Randnotiz\|RNText=Hinweis: Das EIB-Modul ist seit 2018 deprecated und wird auch nicht mehr gewartet. Es ist daher dringend empfohlen, auf das KNX-Modul umzusteigen!		{{Randnotiz\|RNText=Hinweis: Das EIB-Modul ist seit 2018 deprecated und wird auch nicht mehr gewartet. Es ist daher dringend empfohlen, auf das KNX-Modul umzusteigen!
	Unterstützung ~~gibst hier: https://wiki.fhem.de/wiki/~~KNX#Umstellung_von_EIB_auf_KNX_Modul oder diesem Thread~~: https://forum.fhem.de/index.php/topic,126994.0.html~~ im Forum\|RNTyp=Warn\|style=}}		Unterstützung gibt es auf der Wiki Seite [[KNX#Umstellung_von_EIB_auf_KNX_Modul\|Umstellung von EIB auf KNX]] oder in {{Link2Forum\|Topic=126994\|LinkText=diesem Thread im Forum}}\|RNTyp=Warn\|style=}}

	Der KNX support ist in FHEM als 2stufiges Modul konzipiert, braucht daher zusätzlich zu diesem Modul ein sog. IO-Modul, das mit der "Aussenwelt" spricht. Das IO-Modul: [[KNXIO\|'''KNXIO''']] ersetzt die bisher verfügbaren Module '''TUL''' und '''KNXTUL''', es unterstützt die (meisten) Funktionen der bisherigen IO-Module und bietet zusätzlich weitere Kommunikationsoptionen.		Der KNX support ist in FHEM als 2stufiges Modul konzipiert, braucht daher zusätzlich zu diesem Modul ein sog. IO-Modul, das mit der "Aussenwelt" spricht. Das IO-Modul: [[KNXIO\|'''KNXIO''']] ersetzt die bisher verfügbaren Module '''TUL''' und '''KNXTUL''', es unterstützt die (meisten) Funktionen der bisherigen IO-Module und bietet zusätzlich weitere Kommunikationsoptionen.
Zeile 38:		Zeile 38:

	==== Define mittels autocreate ====		==== Define mittels autocreate ====
	Autocreate wird unterstützt. Ankommende Messages erhalten DeviceNamen nach dem Schema: '''KNX_nnmmooo'''. "nn" bezeichnet die Hauptlinie, "mm" die Bereichsline und "ooo" das KNX-Gerät (= die GA_Addresse). Als dpt-Typ wird dptRAW gesetzt, weil autocreate keinen richtigen dpt vergeben kann . Wichtig ist, einen korrekten dpt-Typ zu definieren, damit valides en- / de-coding von Messages möglich ist. Es wird auch keine FileLog- oder SVG-Definition erstellt. Sinnvollerweise ändert man auch den DeviceName auf etwas "sprechendes" (z.B. Licht_Wohnzimmer). Man kann das definieren durch autocreate beeinflussen, mit ~~dem~~ Attributen: '''autocreateThreshold''' und '''ignoreTypes''' im globalen autocreate-device.		Autocreate wird unterstützt. Ankommende Messages erhalten DeviceNamen nach dem Schema: '''KNX_nnmmooo'''. "nn" bezeichnet die Hauptlinie, "mm" die Bereichsline und "ooo" das KNX-Gerät (= die GA_Addresse). Als dpt-Typ wird dptRAW gesetzt, weil autocreate keinen richtigen dpt vergeben kann. Wichtig ist, einen korrekten dpt-Typ zu definieren, damit valides en-/de-coding von Messages möglich ist. Es wird auch keine FileLog- oder SVG-Definition erstellt. Sinnvollerweise ändert man auch den DeviceName auf etwas "sprechendes" (z.B. Licht_Wohnzimmer). Man kann das definieren durch autocreate beeinflussen, mit den Attributen: '''autocreateThreshold''' und '''ignoreTypes''' im globalen autocreate-device.

	Falls man einen FileLog für ALLE KNX-Geräte haben will, die mittels Autocreate angelegt wurden - oder künftig werden, könnte das so aussehen: <syntaxhighlight lang="text">		Falls man einen FileLog für ALLE KNX-Geräte haben will, die mittels Autocreate angelegt wurden - oder künftig werden, könnte das so aussehen: <syntaxhighlight lang="text">
Zeile 47:		Zeile 47:

	==== ESF-import oder: Wie bekomme ich alle GA's aus der ETS in FHEM definiert? ====		==== ESF-import oder: Wie bekomme ich alle GA's aus der ETS in FHEM definiert? ====
	Dazu gibts ein XLSX ~~[https://forum.fhem.de/index.php/topic,~~128532~~.msg1231776.html#msg1231776~~ im Forum] , welches automatisiert FHEM ~~definitionen~~ erstellt. Danke an JooNey, der dafür auch Unterstützung im Forum leistet!		Dazu gibts ein XLSX {{Link2Forum\|Topic=128532\|Message=1231776\|LinkText=im Forum}}, welches automatisiert FHEM Definitionen erstellt. Danke an JooNey, der dafür auch Unterstützung im Forum leistet!

	=== Attribute ===		=== Attribute ===

Erwin111: /* Define mittels autocreate */

2025-12-09T12:18:16Z

Define mittels autocreate

← Nächstältere Version		Version vom 9. Dezember 2025, 14:18 Uhr
Zeile 38:		Zeile 38:

	==== Define mittels autocreate ====		==== Define mittels autocreate ====
	Autocreate wird unterstützt. Ankommende Messages erhalten DeviceNamen nach dem Schema: '''KNX_nnmmooo'''. "nn" bezeichnet die Hauptlinie, "mm" die Bereichsline und "ooo" das KNX-Gerät (= die GA_Addresse). ~~Allerdings~~ wird ~~automatisch das disable Attribut~~ gesetzt, weil autocreate keinen dpt vergeben kann ~~und~~ damit en- / de-coding von Messages ~~nicht~~ möglich ist. Es wird auch keine FileLog- oder SVG-Definition erstellt~~. Um das disable attribut zu löschen, muß man vorher einen gültigen dpt in die Definition einfügen~~. Sinnvollerweise ändert man auch den DeviceName auf etwas "sprechendes" (z.B. Licht_Wohnzimmer). Man kann das definieren durch autocreate beeinflussen, mit dem Attributen: '''autocreateThreshold''' und '''ignoreTypes''' im globalen autocreate-device.		Autocreate wird unterstützt. Ankommende Messages erhalten DeviceNamen nach dem Schema: '''KNX_nnmmooo'''. "nn" bezeichnet die Hauptlinie, "mm" die Bereichsline und "ooo" das KNX-Gerät (= die GA_Addresse). Als dpt-Typ wird dptRAW gesetzt, weil autocreate keinen richtigen dpt vergeben kann . Wichtig ist, einen korrekten dpt-Typ zu definieren, damit valides en- / de-coding von Messages möglich ist. Es wird auch keine FileLog- oder SVG-Definition erstellt. Sinnvollerweise ändert man auch den DeviceName auf etwas "sprechendes" (z.B. Licht_Wohnzimmer). Man kann das definieren durch autocreate beeinflussen, mit dem Attributen: '''autocreateThreshold''' und '''ignoreTypes''' im globalen autocreate-device.

	Falls man einen FileLog für ALLE KNX-Geräte haben will, die mittels Autocreate angelegt wurden - oder künftig werden, könnte das so aussehen: <syntaxhighlight lang="text">		Falls man einen FileLog für ALLE KNX-Geräte haben will, die mittels Autocreate angelegt wurden - oder künftig werden, könnte das so aussehen: <syntaxhighlight lang="text">

Ph1959de: Tippfehler bereinigt

2025-12-07T16:12:54Z

Tippfehler bereinigt

← Nächstältere Version		Version vom 7. Dezember 2025, 18:12 Uhr
Zeile 53:		Zeile 53:
	* '''disable''' - ident zum FHEM Standard - kein Senden oder Empfangen möglich!		* '''disable''' - ident zum FHEM Standard - kein Senden oder Empfangen möglich!
	* '''format''' - hängt den Inhalt dieses Attr. an den Wert an, - im state Reading! Diese Attribut ist abgekündigt, nicht mehr verwenden. Besser stateCmd, stateRegex oder stateFormat verwenden.		* '''format''' - hängt den Inhalt dieses Attr. an den Wert an, - im state Reading! Diese Attribut ist abgekündigt, nicht mehr verwenden. Besser stateCmd, stateRegex oder stateFormat verwenden.
	* '''stateRegex''' - beeinflusst welcher Wert in das Reading state gesetzt wird, und zwar durch string-substitution. Siehe auch Beispiele.		* '''stateRegex''' - beeinflusst, welcher Wert in das Reading state gesetzt wird, und zwar durch string-substitution. Siehe auch Beispiele.
	* '''stateCmd''' - beeinflusst welcher Wert in das Reading state gesetzt wird, mittels perl-funktion. Siehe auch Beispiele.		* '''stateCmd''' - beeinflusst, welcher Wert in das Reading state gesetzt wird, mittels perl-funktion. Siehe auch Beispiele.
	* '''putCmd''' - Falls dieses Attr gesetzt ist wird ein read-request vom KNX Gerät beantwortet. Der Rückgabe-Wert wird mit einer perl Funktion bestimmt.		* '''putCmd''' - Falls dieses Attr gesetzt ist, wird ein read-request vom KNX Gerät beantwortet. Der Rückgabe-Wert wird mit einer perl Funktion bestimmt.
	* '''KNX_toggle''' - Bei einem "toggle-cmd" muss das Device den aktuellen Status des Gerätes wissen. Mit diesem Attr. kann das "Status Device" definiert werden.		* '''KNX_toggle''' - Bei einem "toggle-cmd" muss das Device den aktuellen Status des Gerätes wissen. Mit diesem Attr. kann das "Status Device" definiert werden.
	* '''readingNmap''' - ändert reading Name(n) ~~mittes~~ regex. Beispiele in der cmd-ref. ~~Diese~~ Attribut wird vor allen anderen Attributen verarbeitet, daher müssen readingNamen die in z.B. stateCmd,..., notifies... verwendet werden, angepasst werden.		* '''readingNmap''' - ändert reading Name(n) mittels regex. Beispiele in der cmd-ref. Dieses Attribut wird vor allen anderen Attributen verarbeitet, daher müssen readingNamen die in z.B. stateCmd,..., notifies... verwendet werden, angepasst werden.
	* '''IODev''' - Auf Grund von Änderungen im IO-Handling durch FHEM (-core) ist dieses Attribut in den allermeisten Fällen nicht mehr nötig und evtl. sogar kontraproduktiv! Die Ausnahme ist: Falls mehrere KNX-IO (TUL,KNXTUL,KNXIO) devices definiert sind. Hier ist jedoch extreme Vorsicht geboten, es kann zu endlosen msg-loops kommen!		* '''IODev''' - Auf Grund von Änderungen im IO-Handling durch FHEM (-core) ist dieses Attribut in den allermeisten Fällen nicht mehr nötig und evtl. sogar kontraproduktiv! Die Ausnahme ist: Falls mehrere KNX-IO (TUL,KNXTUL,KNXIO) devices definiert sind. Hier ist jedoch extreme Vorsicht geboten, es kann zu endlosen msg-loops kommen!

Erwin111: /* Attribute */ readingNmap neu

2025-12-07T11:46:29Z

Attribute: readingNmap neu

← Nächstältere Version		Version vom 7. Dezember 2025, 13:46 Uhr
Zeile 57:		Zeile 57:
	* '''putCmd''' - Falls dieses Attr gesetzt ist wird ein read-request vom KNX Gerät beantwortet. Der Rückgabe-Wert wird mit einer perl Funktion bestimmt.		* '''putCmd''' - Falls dieses Attr gesetzt ist wird ein read-request vom KNX Gerät beantwortet. Der Rückgabe-Wert wird mit einer perl Funktion bestimmt.
	* '''KNX_toggle''' - Bei einem "toggle-cmd" muss das Device den aktuellen Status des Gerätes wissen. Mit diesem Attr. kann das "Status Device" definiert werden.		* '''KNX_toggle''' - Bei einem "toggle-cmd" muss das Device den aktuellen Status des Gerätes wissen. Mit diesem Attr. kann das "Status Device" definiert werden.
	* '''readingNmap''' - ~~blblabla~~		* '''readingNmap''' - ändert reading Name(n) mittes regex. Beispiele in der cmd-ref. Diese Attribut wird vor allen anderen Attributen verarbeitet, daher müssen readingNamen die in z.B. stateCmd,..., notifies... verwendet werden, angepasst werden.
	* '''IODev''' - Auf Grund von Änderungen im IO-Handling durch FHEM (-core) ist dieses Attribut in den allermeisten Fällen nicht mehr nötig und evtl. sogar kontraproduktiv! Die Ausnahme ist: Falls mehrere KNX-IO (TUL,KNXTUL,KNXIO) devices definiert sind. Hier ist jedoch extreme Vorsicht geboten, es kann zu endlosen msg-loops kommen!		* '''IODev''' - Auf Grund von Änderungen im IO-Handling durch FHEM (-core) ist dieses Attribut in den allermeisten Fällen nicht mehr nötig und evtl. sogar kontraproduktiv! Die Ausnahme ist: Falls mehrere KNX-IO (TUL,KNXTUL,KNXIO) devices definiert sind. Hier ist jedoch extreme Vorsicht geboten, es kann zu endlosen msg-loops kommen!

Erwin111: /* Attribute */

2025-12-07T11:38:38Z

Attribute

← Nächstältere Version		Version vom 7. Dezember 2025, 13:38 Uhr
Zeile 52:		Zeile 52:
	Zusätzlich zu den FHEM-standard Attributen sind folgende Attribute verfügbar:		Zusätzlich zu den FHEM-standard Attributen sind folgende Attribute verfügbar:
	* '''disable''' - ident zum FHEM Standard - kein Senden oder Empfangen möglich!		* '''disable''' - ident zum FHEM Standard - kein Senden oder Empfangen möglich!
	* '''format''' - hängt den Inhalt dieses Attr. an den Wert an, - im state Reading! ~~Sinnvoll um z~~.~~B. Einheiten hinzuzufügen~~.		* '''format''' - hängt den Inhalt dieses Attr. an den Wert an, - im state Reading! Diese Attribut ist abgekündigt, nicht mehr verwenden. Besser stateCmd, stateRegex oder stateFormat verwenden.
	* '''stateRegex''' - beeinflusst welcher Wert in das Reading state gesetzt wird, und zwar durch string-substitution. Siehe auch Beispiele.		* '''stateRegex''' - beeinflusst welcher Wert in das Reading state gesetzt wird, und zwar durch string-substitution. Siehe auch Beispiele.
	* '''stateCmd''' - beeinflusst welcher Wert in das Reading state gesetzt wird, mittels perl-funktion. Siehe auch Beispiele.		* '''stateCmd''' - beeinflusst welcher Wert in das Reading state gesetzt wird, mittels perl-funktion. Siehe auch Beispiele.
	* '''putCmd''' - Falls dieses Attr gesetzt ist wird ein read-request vom KNX Gerät beantwortet. Der Rückgabe-Wert wird mit einer perl Funktion bestimmt.		* '''putCmd''' - Falls dieses Attr gesetzt ist wird ein read-request vom KNX Gerät beantwortet. Der Rückgabe-Wert wird mit einer perl Funktion bestimmt.
	* '''KNX_toggle''' - Bei einem "toggle-cmd" muss das Device den aktuellen Status des Gerätes wissen. Mit diesem Attr. kann das "Status Device" definiert werden.		* '''KNX_toggle''' - Bei einem "toggle-cmd" muss das Device den aktuellen Status des Gerätes wissen. Mit diesem Attr. kann das "Status Device" definiert werden.
			* '''readingNmap''' - blblabla
	* '''IODev''' - Auf Grund von Änderungen im IO-Handling durch FHEM (-core) ist dieses Attribut in den allermeisten Fällen nicht mehr nötig und evtl. sogar kontraproduktiv! Die Ausnahme ist: Falls mehrere KNX-IO (TUL,KNXTUL,KNXIO) devices definiert sind. Hier ist jedoch extreme Vorsicht geboten, es kann zu endlosen msg-loops kommen!		* '''IODev''' - Auf Grund von Änderungen im IO-Handling durch FHEM (-core) ist dieses Attribut in den allermeisten Fällen nicht mehr nötig und evtl. sogar kontraproduktiv! Die Ausnahme ist: Falls mehrere KNX-IO (TUL,KNXTUL,KNXIO) devices definiert sind. Hier ist jedoch extreme Vorsicht geboten, es kann zu endlosen msg-loops kommen!

Erwin111: /* Umstellung EIB -> KNX Modul */

2024-07-29T10:56:41Z

Umstellung EIB -> KNX Modul

← Nächstältere Version		Version vom 29. Juli 2024, 12:56 Uhr
Zeile 83:		Zeile 83:
	Ein Get command ist nur erlaubt, wenn die option im define nicht set oder listenonly ist! Die Syntax ist analog zum Set command (ohne <wert>). Kommt eine Antwort vom KNX-Gerät wird dieser Wert im entsprechenden Reading gespeichert.		Ein Get command ist nur erlaubt, wenn die option im define nicht set oder listenonly ist! Die Syntax ist analog zum Set command (ohne <wert>). Kommt eine Antwort vom KNX-Gerät wird dieser Wert im entsprechenden Reading gespeichert.

	== Umstellung EIB -> KNX Modul ==		== Umstellung von EIB auf KNX Modul ==
	Nachdem das EIB-Modul seit März 2018 nicht mehr aktualisiert wurde und abgekündigt ist, möchte ich dazu motivieren, auf das aktuelle KNX-Modul umzustellen.		Nachdem das EIB-Modul seit März 2018 nicht mehr aktualisiert wurde und abgekündigt ist, möchte ich dazu motivieren, auf das aktuelle KNX-Modul umzustellen.

Erwin111: /* Anwendung */

2024-07-29T10:56:10Z

Anwendung

← Nächstältere Version		Version vom 29. Juli 2024, 12:56 Uhr
Zeile 11:		Zeile 11:
	== Voraussetzungen ==		== Voraussetzungen ==
	{{Randnotiz\|RNText=Hinweis: Das EIB-Modul ist seit 2018 deprecated und wird auch nicht mehr gewartet. Es ist daher dringend empfohlen, auf das KNX-Modul umzusteigen!		{{Randnotiz\|RNText=Hinweis: Das EIB-Modul ist seit 2018 deprecated und wird auch nicht mehr gewartet. Es ist daher dringend empfohlen, auf das KNX-Modul umzusteigen!
	Unterstützung gibst hier: https://wiki.fhem.de/wiki/KNX#~~Umstellung_EIB_->_KNX_Modul~~ oder diesem Thread: https://forum.fhem.de/index.php/topic,126994.0.html im Forum\|RNTyp=Warn\|style=}}		Unterstützung gibst hier: https://wiki.fhem.de/wiki/KNX#Umstellung_von_EIB_auf_KNX_Modul oder diesem Thread: https://forum.fhem.de/index.php/topic,126994.0.html im Forum\|RNTyp=Warn\|style=}}

	Der KNX support ist in FHEM als 2stufiges Modul konzipiert, braucht daher zusätzlich zu diesem Modul ein sog. IO-Modul, das mit der "Aussenwelt" spricht. Das IO-Modul: [[KNXIO\|'''KNXIO''']] ersetzt die bisher verfügbaren Module '''TUL''' und '''KNXTUL''', es unterstützt die (meisten) Funktionen der bisherigen IO-Module und bietet zusätzlich weitere Kommunikationsoptionen.		Der KNX support ist in FHEM als 2stufiges Modul konzipiert, braucht daher zusätzlich zu diesem Modul ein sog. IO-Modul, das mit der "Aussenwelt" spricht. Das IO-Modul: [[KNXIO\|'''KNXIO''']] ersetzt die bisher verfügbaren Module '''TUL''' und '''KNXTUL''', es unterstützt die (meisten) Funktionen der bisherigen IO-Module und bietet zusätzlich weitere Kommunikationsoptionen.

Erwin111: /* Anwendung */

2024-07-29T10:51:29Z

Anwendung

← Nächstältere Version		Version vom 29. Juli 2024, 12:51 Uhr
Zeile 11:		Zeile 11:
	== Voraussetzungen ==		== Voraussetzungen ==
	{{Randnotiz\|RNText=Hinweis: Das EIB-Modul ist seit 2018 deprecated und wird auch nicht mehr gewartet. Es ist daher dringend empfohlen, auf das KNX-Modul umzusteigen!		{{Randnotiz\|RNText=Hinweis: Das EIB-Modul ist seit 2018 deprecated und wird auch nicht mehr gewartet. Es ist daher dringend empfohlen, auf das KNX-Modul umzusteigen!
	Unterstützung gibst in diesem Thread: https://forum.fhem.de/index.php/topic,126994.0.html im Forum\|RNTyp=Warn\|style=}}		Unterstützung gibst hier: https://wiki.fhem.de/wiki/KNX#Umstellung_EIB_->_KNX_Modul oder diesem Thread: https://forum.fhem.de/index.php/topic,126994.0.html im Forum\|RNTyp=Warn\|style=}}

	Der KNX support ist in FHEM als 2stufiges Modul konzipiert, braucht daher zusätzlich zu diesem Modul ein sog. IO-Modul, das mit der "Aussenwelt" spricht. Das IO-Modul: [[KNXIO\|'''KNXIO''']] ersetzt die bisher verfügbaren Module '''TUL''' und '''KNXTUL''', es unterstützt die (meisten) Funktionen der bisherigen IO-Module und bietet zusätzlich weitere Kommunikationsoptionen.		Der KNX support ist in FHEM als 2stufiges Modul konzipiert, braucht daher zusätzlich zu diesem Modul ein sog. IO-Modul, das mit der "Aussenwelt" spricht. Das IO-Modul: [[KNXIO\|'''KNXIO''']] ersetzt die bisher verfügbaren Module '''TUL''' und '''KNXTUL''', es unterstützt die (meisten) Funktionen der bisherigen IO-Module und bietet zusätzlich weitere Kommunikationsoptionen.

Ph1959de: Sichtung/Korrektur der letzen Änderung

2023-10-04T15:36:56Z

Sichtung/Korrektur der letzen Änderung

← Nächstältere Version		Version vom 4. Oktober 2023, 17:36 Uhr
Zeile 84:		Zeile 84:

	== Umstellung EIB -> KNX Modul ==		== Umstellung EIB -> KNX Modul ==
	Nachdem das EIB-Modul seit März 2018 nicht mehr ~~upgedatet~~ wurde und ~~deprecated~~ ist, möchte ich dazu motivieren auf das aktuelle KNX-Modul umzustellen.		Nachdem das EIB-Modul seit März 2018 nicht mehr aktualisiert wurde und abgekündigt ist, möchte ich dazu motivieren, auf das aktuelle KNX-Modul umzustellen.

	Ausführliche Erklärungen, Beispiele ~~im [https://forum.fhem.de/index.php?topic~~=126994.~~0 FHEM Forum]~~		Ausführliche Erklärungen und Beispiele sind in {{Link2Forum\|Topic=126994\|LinkText=diesem Forenthema}} zu finden.

	== Anwendungsbeispiele ==		== Anwendungsbeispiele ==

Erwin111: Migration EIB -> KNX

2023-10-04T11:54:56Z

Migration EIB -> KNX

← Nächstältere Version		Version vom 4. Oktober 2023, 13:54 Uhr
Zeile 82:		Zeile 82:
	=== Get Command ===		=== Get Command ===
	Ein Get command ist nur erlaubt, wenn die option im define nicht set oder listenonly ist! Die Syntax ist analog zum Set command (ohne <wert>). Kommt eine Antwort vom KNX-Gerät wird dieser Wert im entsprechenden Reading gespeichert.		Ein Get command ist nur erlaubt, wenn die option im define nicht set oder listenonly ist! Die Syntax ist analog zum Set command (ohne <wert>). Kommt eine Antwort vom KNX-Gerät wird dieser Wert im entsprechenden Reading gespeichert.

			== Umstellung EIB -> KNX Modul ==
			Nachdem das EIB-Modul seit März 2018 nicht mehr upgedatet wurde und deprecated ist, möchte ich dazu motivieren auf das aktuelle KNX-Modul umzustellen.

			Ausführliche Erklärungen, Beispiele im [https://forum.fhem.de/index.php?topic=126994.0 FHEM Forum]

	== Anwendungsbeispiele ==		== Anwendungsbeispiele ==