MQTT2 DEVICE - Schritt für Schritt - Versionsgeschichte

Beta-User: /* MQTT - Datenverkehr mitlesen */ Bild eingefügt

2025-02-21T07:51:15Z

MQTT - Datenverkehr mitlesen: Bild eingefügt

← Nächstältere Version		Version vom 21. Februar 2025, 09:51 Uhr
Zeile 56:		Zeile 56:

	=== MQTT - Datenverkehr mitlesen ===		=== MQTT - Datenverkehr mitlesen ===
			[[Datei:Show MQTT traffic.png\|mini\|466x466px\|Beispiel für einen erfolgreichen ''publish-''Test mit MQTT2_CLIENT mit anschließender Rückübermittlung derselben Message vom MQTT-Server.]]
	Sowohl MQTT2_SERVER wie MQTT2_CLIENT bieten in der Detailansicht die Option ''Show MQTT traffic''. Darüber läßt sich der ein- und ausgehende Datenverkehr bequem mitlesen. Bei MQTT2_CLIENT wird dabei allerdings vorausgesetzt, dass er überhaupt Daten vom MQTT-Server erhält, also insbesondere die ''subscriptions'' korrekt gesetzt sind (falls per Attribut eingeschränkt).		Sowohl MQTT2_SERVER wie MQTT2_CLIENT bieten in der Detailansicht die Option ''Show MQTT traffic''. Darüber läßt sich der ein- und ausgehende Datenverkehr bequem mitlesen. Bei MQTT2_CLIENT wird dabei allerdings vorausgesetzt, dass er überhaupt Daten vom MQTT-Server erhält, also insbesondere die ''subscriptions'' korrekt gesetzt sind (falls per Attribut eingeschränkt).

Beta-User: /* gute Reading-Namen - Klartext */

2024-10-28T05:19:06Z

gute Reading-Namen - Klartext

← Nächstältere Version		Version vom 28. Oktober 2024, 07:19 Uhr
Zeile 87:		Zeile 87:
	== readingList optimieren==		== readingList optimieren==
	=== gute Reading-Namen - Klartext ===		=== gute Reading-Namen - Klartext ===
			{{Randnotiz\|RNTyp=Info\|RNText=Beachte zur Vergabe von Reading-Namen v.a. auch [[DevelopmentGuidelinesReadings]] und [[DevelopmentGuidelinesAV]].}}
	Viele Gegenstellen senden z.B. einen online/offline-Status als "last will and testament" unter einem Topic, der mit "LWT" endet. Dieses hier sendet zwar passende Daten, aber an einen anderen Topic. In solchen Fällen man kann den von autocreate erzeugten Eintrag einfach anpassen:		Viele Gegenstellen senden z.B. einen online/offline-Status als "last will and testament" unter einem Topic, der mit "LWT" endet. Dieses hier sendet zwar passende Daten, aber an einen anderen Topic. In solchen Fällen man kann den von autocreate erzeugten Eintrag einfach anpassen:
	attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT		attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT
	~~{{Randnotiz\|RNTyp=Info\|RNText=Beachte zur Vergabe von Reading-Namen v.a. auch [[DevelopmentGuidelinesReadings]] und [[DevelopmentGuidelinesAV]].}}~~

	=== Bedingte Hash-Rückgaben ===		=== Bedingte Hash-Rückgaben ===

Beta-User: /* gute Reading-Namen - Klartext */

2024-10-28T05:18:40Z

gute Reading-Namen - Klartext

← Nächstältere Version		Version vom 28. Oktober 2024, 07:18 Uhr
Zeile 89:		Zeile 89:
	Viele Gegenstellen senden z.B. einen online/offline-Status als "last will and testament" unter einem Topic, der mit "LWT" endet. Dieses hier sendet zwar passende Daten, aber an einen anderen Topic. In solchen Fällen man kann den von autocreate erzeugten Eintrag einfach anpassen:		Viele Gegenstellen senden z.B. einen online/offline-Status als "last will and testament" unter einem Topic, der mit "LWT" endet. Dieses hier sendet zwar passende Daten, aber an einen anderen Topic. In solchen Fällen man kann den von autocreate erzeugten Eintrag einfach anpassen:
	attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT		attr DEVICE readingList /dingtian/DEVNAME/out/lwt_availability:.* LWT
			{{Randnotiz\|RNTyp=Info\|RNText=Beachte zur Vergabe von Reading-Namen v.a. auch [[DevelopmentGuidelinesReadings]] und [[DevelopmentGuidelinesAV]].}}

	=== Bedingte Hash-Rückgaben ===		=== Bedingte Hash-Rückgaben ===

Dora71: /* json2nameValue() */ Erklärung des 4. und 5. Parameters ergänzt inklusive Codebeispiel

2024-05-15T07:22:13Z

json2nameValue(): Erklärung des 4. und 5. Parameters ergänzt inklusive Codebeispiel

← Nächstältere Version		Version vom 15. Mai 2024, 09:22 Uhr
Zeile 101:		Zeile 101:
	* "gute Reading-Namen" auch aus JSON-Payloads erzeugen (2. und 3. Argument)		* "gute Reading-Namen" auch aus JSON-Payloads erzeugen (2. und 3. Argument)
	* unnötige Readings vorab ausfiltern (3., 4. und 5. Argument)		* unnötige Readings vorab ausfiltern (3., 4. und 5. Argument)
	Beispiele für die Verwendung der Argumente 1 bis 3 sind der commandref in der Erläuterung des Attributs ''jsonMap'' bei MQTT2_DEVICE zu entnehmen, die (wie die Argumente 2 und 3 optionalen) Argumente 4 und 5 entsprechen einem Positiv- bzw.- Negativ-Filter~~, gefiltert wird, wenn die jeweils übergebene regexp matcht (5. Argument) bzw. nicht matcht (4. Argument)~~.		Beispiele für die Verwendung der Argumente 1 bis 3 sind der commandref in der Erläuterung des Attributs ''jsonMap'' bei MQTT2_DEVICE zu entnehmen, die (wie die Argumente 2 und 3 optionalen) Argumente 4 und 5 entsprechen einem Positiv- bzw.- Negativ-Filter.
	Wird (übergangsweise!) ''autocreate'' in der ''complex''-Variante eingestellt, werden für alle (bisher nicht bekannten) Topics Einträge wie dieser erzeugt:		Wird (übergangsweise!) ''autocreate'' in der ''complex''-Variante eingestellt, werden für alle (bisher nicht bekannten) Topics Einträge wie dieser erzeugt:
	attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT,'STATE_',$JSONMAP) }		attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT,'STATE_',$JSONMAP) }
	* Das zweite Argument (''STATE_'') ist ein "Präfix", der allen aus dem JSON erzeugten Readings aus diesem Topic (zunächst) vorangestellt wird. Mit dessen Hilfe läßt sich rekonsturieren, aus welchem Topic die betreffende Information ursprünglich kam. In der Regel ist dies nach der Einrichtung nicht mehr wichtig, und dieses Argument kann auf "nichts" (zwei einfache Quotes) gestellt werden. Allerdings kann es in Einzelfällen sinnvoll sein, Präfixe zu verwenden, um zwischen scheinbar gleichen Werte aus unterschiedlichen Quellen zu unterscheiden. Dies kann man erst abschließend entscheiden, wenn alle von der Gegenstelle gelieferten Daten bekannt sind.		* Das zweite Argument (''STATE_'') ist ein "Präfix", der allen aus dem JSON erzeugten Readings aus diesem Topic (zunächst) vorangestellt wird. Mit dessen Hilfe läßt sich rekonsturieren, aus welchem Topic die betreffende Information ursprünglich kam. In der Regel ist dies nach der Einrichtung nicht mehr wichtig, und dieses Argument kann auf "nichts" (zwei einfache Quotes) gestellt werden. Allerdings kann es in Einzelfällen sinnvoll sein, Präfixe zu verwenden, um zwischen scheinbar gleichen Werte aus unterschiedlichen Quellen zu unterscheiden. Dies kann man erst abschließend entscheiden, wenn alle von der Gegenstelle gelieferten Daten bekannt sind.
	* Das dritte Argument ''$JSONMAP'' kann in der Regel so belassen werden. Dann kann mit Hilfe des Attributs ''jsonMap'' eine Zuordnungstabelle für Namensänderungen für die zu generierenden Readingnamen erzeugt und/oder Werte schlicht gelöscht werden.		* Das dritte Argument ''$JSONMAP'' kann in der Regel so belassen werden. Dann kann mit Hilfe des Attributs ''jsonMap'' eine Zuordnungstabelle für Namensänderungen für die zu generierenden Readingnamen erzeugt und/oder Werte schlicht gelöscht werden.
			<syntaxhighlight lang="perl6">
			json2nameValue($EVENT,'STATE_',$JSONMAP,'positiv')
			json2nameValue($EVENT,'STATE_',$JSONMAP,'','negativ')
			</syntaxhighlight>
			* Das vierte Argument ist optional. Es ist ein (Positiv) Filter, der nur Readings in der Liste erscheinen lässt, die diesem Argument entsprechen, im Beispiel oben wären das alle Readings, die den Ausdruck "positiv" enthalten. Das Argument selber ist eine regexp. '''Achtung:''' Wird dieses Argument zusammen mit dem Attribut jsonMap benutzt, so wird zuerst das Mapping auf die neuen Readings-Bezeichnungen ausgeführt und erst dann dieser Filter ausgeführt, d. h. es muss auf die ersetzten Readings-Bezeichnungen gefiltert werden!
			* Das fünfte Argument ist ebenfalls optional. Es ist ein (Negativ) Filter. Im obigen Beispiel werden alle Readings, die den Ausdruck "negativ" enthalten, aus den Readings ausgefiltert. Ebenso wie das 4. Argument ist es eine regexp. Im Zusammenspiel mit jsonMap wird hier zuerst der Filter ausgewertet und erst anschließend erfolgt das Mapping auf die neuen Readings-Namen.

	=== Auswertung unterbinden ===		=== Auswertung unterbinden ===

F Klee: /* periodicCmd */

2023-10-28T16:20:31Z

periodicCmd

← Nächstältere Version		Version vom 28. Oktober 2023, 18:20 Uhr
Zeile 180:		Zeile 180:

	== periodicCmd ==		== periodicCmd ==
	Für regelmäßige Aufgaben (mit mind. minütlicher Frequenz) kann eine Liste ~~con~~ get- oder set-Kommandos angegeben werden. Dies kann für regelmäßige Abfragen ebenso genutzt werden wie z.B. zum Löschen veralteter Informationen/Readings.		Für regelmäßige Aufgaben (mit mind. minütlicher Frequenz) kann eine Liste von get- oder set-Kommandos angegeben werden. Dies kann für regelmäßige Abfragen ebenso genutzt werden wie z.B. zum Löschen veralteter Informationen/Readings.

	== Abschließende Aufgaben ==		== Abschließende Aufgaben ==

F Klee: /* readingList */

2023-10-28T16:03:05Z

readingList

← Nächstältere Version		Version vom 28. Oktober 2023, 18:03 Uhr
Zeile 59:		Zeile 59:

	=== readingList ===		=== readingList ===
	Zunächst empfiehlt es sich, einfach die Gegenstelle neu zu starten und (ggf. über ein FileLog) ~~auzuzuzeichnen~~, was über welchen Topic wie oft an Informationen gesendet wird. Dabei kann und sollte durchaus - sofern dies möglich ist - der eine oder andere Schaltvorgang (z.B. über das Web-Interface der Gegenstelle) durchgeführt werden, sofern dies möglich ist (oder allgemeiner: möglichst viele bekannte Anweisungen ausführen lassen). Am Ende sollte man eine möglichst vollständige Auflistung in der readingList erhalten haben.		Zunächst empfiehlt es sich, einfach die Gegenstelle neu zu starten und (ggf. über ein FileLog) aufzuzuzeichnen, was über welchen Topic wie oft an Informationen gesendet wird. Dabei kann und sollte durchaus - sofern dies möglich ist - der eine oder andere Schaltvorgang (z.B. über das Web-Interface der Gegenstelle) durchgeführt werden, sofern dies möglich ist (oder allgemeiner: möglichst viele bekannte Anweisungen ausführen lassen). Am Ende sollte man eine möglichst vollständige Auflistung in der readingList erhalten haben.
	Falls strukturierte Daten im JSON-Format als Payload verwendet werden, kann man diese auch zusätzlich ohne die Verarbeitung durch ''json2nameValue()'' aufzeichnen, z.B. indem man die betreffende Zeile in der readingList doppelt:		Falls strukturierte Daten im JSON-Format als Payload verwendet werden, kann man diese auch zusätzlich ohne die Verarbeitung durch ''json2nameValue()'' aufzeichnen, z.B. indem man die betreffende Zeile in der readingList doppelt:
	<syntaxhighlight lang="text">		<syntaxhighlight lang="text">

Ph1959de: syntaxhighlight korrigiert

2022-11-04T18:30:29Z

syntaxhighlight korrigiert

← Nächstältere Version		Version vom 4. November 2022, 20:30 Uhr
Zeile 20:		Zeile 20:
	=== Begrifflichkeiten ===		=== Begrifflichkeiten ===
	Ein typisches, von "autocreate" erstelltes Gerät sieht dann z.b. (mit autocreate = simple am MQTT2_SERVER) so aus:		Ein typisches, von "autocreate" erstelltes Gerät sieht dann z.b. (mit autocreate = simple am MQTT2_SERVER) so aus:
	<syntaxhighlight lang="~~txt~~">		<syntaxhighlight lang="text">
	defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD		defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
	attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\		attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
Zeile 61:		Zeile 61:
	Zunächst empfiehlt es sich, einfach die Gegenstelle neu zu starten und (ggf. über ein FileLog) auzuzuzeichnen, was über welchen Topic wie oft an Informationen gesendet wird. Dabei kann und sollte durchaus - sofern dies möglich ist - der eine oder andere Schaltvorgang (z.B. über das Web-Interface der Gegenstelle) durchgeführt werden, sofern dies möglich ist (oder allgemeiner: möglichst viele bekannte Anweisungen ausführen lassen). Am Ende sollte man eine möglichst vollständige Auflistung in der readingList erhalten haben.		Zunächst empfiehlt es sich, einfach die Gegenstelle neu zu starten und (ggf. über ein FileLog) auzuzuzeichnen, was über welchen Topic wie oft an Informationen gesendet wird. Dabei kann und sollte durchaus - sofern dies möglich ist - der eine oder andere Schaltvorgang (z.B. über das Web-Interface der Gegenstelle) durchgeführt werden, sofern dies möglich ist (oder allgemeiner: möglichst viele bekannte Anweisungen ausführen lassen). Am Ende sollte man eine möglichst vollständige Auflistung in der readingList erhalten haben.
	Falls strukturierte Daten im JSON-Format als Payload verwendet werden, kann man diese auch zusätzlich ohne die Verarbeitung durch ''json2nameValue()'' aufzeichnen, z.B. indem man die betreffende Zeile in der readingList doppelt:		Falls strukturierte Daten im JSON-Format als Payload verwendet werden, kann man diese auch zusätzlich ohne die Verarbeitung durch ''json2nameValue()'' aufzeichnen, z.B. indem man die betreffende Zeile in der readingList doppelt:
	<syntaxhighlight lang="~~txt~~">		<syntaxhighlight lang="text">
	defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD		defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
	attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\		attr MQTT2_DVES_9B01BD readingList tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\

Beta-User: Show MQTT traffic ergänzt

2022-04-13T11:13:52Z

Show MQTT traffic ergänzt

← Nächstältere Version		Version vom 13. April 2022, 13:13 Uhr
Zeile 54:		Zeile 54:
	=== Projektseiten finden ===		=== Projektseiten finden ===
	Viele Geräte, die das MQTT-Protokoll verwenden, haben eigene Projektseiten oder API-Beschreibungen, denen man entnehmen kann, wie mit dieser Gegenstelle Daten ausgetauscht werden können. Diese sollte man bei allen weiteren Schritten stets zur Hand haben. Dabei kann es neben der allgemeinen Beschreibung auch ein oder mehrere Detail-Seiten geben, auf denen nähere Informationen zu den spezifischen Geräte zu finden sein können.		Viele Geräte, die das MQTT-Protokoll verwenden, haben eigene Projektseiten oder API-Beschreibungen, denen man entnehmen kann, wie mit dieser Gegenstelle Daten ausgetauscht werden können. Diese sollte man bei allen weiteren Schritten stets zur Hand haben. Dabei kann es neben der allgemeinen Beschreibung auch ein oder mehrere Detail-Seiten geben, auf denen nähere Informationen zu den spezifischen Geräte zu finden sein können.

			=== MQTT - Datenverkehr mitlesen ===
			Sowohl MQTT2_SERVER wie MQTT2_CLIENT bieten in der Detailansicht die Option ''Show MQTT traffic''. Darüber läßt sich der ein- und ausgehende Datenverkehr bequem mitlesen. Bei MQTT2_CLIENT wird dabei allerdings vorausgesetzt, dass er überhaupt Daten vom MQTT-Server erhält, also insbesondere die ''subscriptions'' korrekt gesetzt sind (falls per Attribut eingeschränkt).

	=== readingList ===		=== readingList ===
Zeile 181:		Zeile 184:
	== Abschließende Aufgaben ==		== Abschließende Aufgaben ==
	Um das finale Aussehen des Gerätes zu beeinflussen, stehen dann noch die weiteren allgemeinen Attribute zur Verfügung, die in [[DeviceOverview anpassen]] beschrieben sind.		Um das finale Aussehen des Gerätes zu beeinflussen, stehen dann noch die weiteren allgemeinen Attribute zur Verfügung, die in [[DeviceOverview anpassen]] beschrieben sind.

			== Hinweise ==
			<references />
			[[Kategorie:HOWTOS]]
			[[Kategorie:MQTT]]

Beta-User: Topic mit Doppelpunkt, https://forum.fhem.de/index.php/topic,126287.0.html

2022-02-20T08:02:31Z

Topic mit Doppelpunkt, https://forum.fhem.de/index.php/topic,126287.0.html

← Nächstältere Version		Version vom 20. Februar 2022, 10:02 Uhr
Zeile 37:		Zeile 37:
	Dies ist die Gerätekennung (hier: DVES_9B01BD). Diese ist auch Bestandteil des ''define'', über diese wird ermittelt, zu welchem FHEM-Gerät via MQTT eingehende Informationen zugeordnet werden sollen. Diese Angabe ist weder im define noch in der readingList zwingend, aber in der Definition für den Hauptkanal eines Gerätes empfohlen. Es empfiehlt sich, die CID-Angaben bei eigenen readingList-Einträgen wegzulassen bzw. diese zu löschen. So kann einfacher zwischen automatisch generierten und eigenen Angaben unterschieden werden und die Geräte sind leichter zwischen verschiedenen IO-Modulen zu verschieben.		Dies ist die Gerätekennung (hier: DVES_9B01BD). Diese ist auch Bestandteil des ''define'', über diese wird ermittelt, zu welchem FHEM-Gerät via MQTT eingehende Informationen zugeordnet werden sollen. Diese Angabe ist weder im define noch in der readingList zwingend, aber in der Definition für den Hauptkanal eines Gerätes empfohlen. Es empfiehlt sich, die CID-Angaben bei eigenen readingList-Einträgen wegzulassen bzw. diese zu löschen. So kann einfacher zwischen automatisch generierten und eigenen Angaben unterschieden werden und die Geräte sind leichter zwischen verschiedenen IO-Modulen zu verschieben.
	==== Topic ====		==== Topic ====
	Datenpunkt, an den eine Information gesendet wird. Empfangsseitig sind dies hier z.B. ''tele/DVES_9B01BD/STATE'' oder ''tele/DVES_9B01BD/LWT''		Datenpunkt, an den eine Information gesendet wird. Empfangsseitig sind dies hier z.B. ''tele/DVES_9B01BD/STATE'' oder ''tele/DVES_9B01BD/LWT''.
			Enthält der Topic Doppelpunkte oder Sonderzeichen, kann dies zu Problemen führen. Da der Topic intern als ''regex'' behandelt wird, kann man sich das in solchen Sonderfälle dadurch zu nutze machen, dass man z.B problematische Zeichen durch Punkte oder "beliebige Zeichenfolgen" ersetzt. So kann z.B. aus dem per autocreate erstellten <code>attr reader readingList SMLReader/Strom/sensor/1/obis/1-0:1.8.0/255/value:.* Strombezug_tariflos</code> folgendes abgeleitet werden: <code>attr reader readingList SMLReader/Strom/sensor/1/obis/1-0.1.8.0/255/value:.* Strombezug_tariflos</code>,

	==== Payload ====		==== Payload ====
	Der jeweilige Nachrichteninhalt. Da dieser nicht im vorhinein bekannt ist, wird er in der readingList typischerweise als "beliebige Zeichenfolge" (".*") notiert.		Der jeweilige Nachrichteninhalt. Da dieser nicht im vorhinein bekannt ist, wird er in der readingList typischerweise als "beliebige Zeichenfolge" (".*") notiert.

Beta-User: Weitere Ergänzungen, Baustelle abgebaut

2022-02-16T13:43:10Z

Weitere Ergänzungen, Baustelle abgebaut

← Nächstältere Version		Version vom 16. Februar 2022, 15:43 Uhr
Zeile 1:		Zeile 1:
	~~{{Baustelle}}~~

	== Einführung ==		== Einführung ==
	Das Protokoll [[MQTT]] ermöglicht einen flexiblen Datenaustausch zwischen unterschiedlichsten Geräten und FHEM und insbesondere auch bidirektionale Kommunikation von und zu FHEM. Es gibt dabei jedoch nur einen geringen Grad der Standardisierung des Datenaustauschs. In der Praxis sind daher relative viele unterschiedliche Wege aufzufinden, wie die Kommunikation via MQTT in den externen Geräten und Diensten konkret umgesetzt wurde - jeder Autor einer firmware oder Software kann dies so lösen, wie es ihm beliebt, und nicht jeder beherzigt dabei den Grundsatz, dass die Kommunikation via MQTT "leichtgewichtig" sein sollte.		Das Protokoll [[MQTT]] ermöglicht einen flexiblen Datenaustausch zwischen unterschiedlichsten Geräten und FHEM und insbesondere auch bidirektionale Kommunikation von und zu FHEM. Es gibt dabei jedoch nur einen geringen Grad der Standardisierung des Datenaustauschs. In der Praxis sind daher relative viele unterschiedliche Wege aufzufinden, wie die Kommunikation via MQTT in den externen Geräten und Diensten konkret umgesetzt wurde - jeder Autor einer firmware oder Software kann dies so lösen, wie es ihm beliebt, und nicht jeder beherzigt dabei den Grundsatz, dass die Kommunikation via MQTT "leichtgewichtig" sein sollte.
Zeile 91:		Zeile 89:
	attr DEVICE readingList DEVNAME/relay/0:.* { $EVENT ? {state=>'on'} : {state=>'off'} }\		attr DEVICE readingList DEVNAME/relay/0:.* { $EVENT ? {state=>'on'} : {state=>'off'} }\
	DEVNAME/status:.* { $EVENT ? {LWT=>'Online'} : {LWT=>'Offline'} }		DEVNAME/status:.* { $EVENT ? {LWT=>'Online'} : {LWT=>'Offline'} }
			Weiteres Beispiel: Der "state" kommt in Großschreibung und soll in Kleinschreibung geändert werden:
			attr DEVICE readingList switchbot/esp32_2/bot/switchbottwo/state:.* { { state => lc $EVENT } }

	=== json2nameValue() ===		=== json2nameValue() ===
Zeile 125:		Zeile 125:

	=== event-on-change-reading und Co. ===		=== event-on-change-reading und Co. ===
			Da die firmwares häufig recht gesprächig programmiert sind, sollte man auf eine sinnvolle Begrenzung der durch Aktualisierungen verursachten Events besonderen Wert legen. Dazu ist in erster Linie das Attribut [[Event-on-change-reading\|event-on-change-reading]] zu bearbeiten und ggf. passende threshold-Werte zu setzen, es empfiehlt sich allerdings, dabei auch zu untersuchen, inwieweit die weiteren, funktional ergänzenden Attribute zu setzen sind:
			* [[Event-min-interval\|event-min-interval]]
			* [[Event-on-update-reading\|event-on-update-reading]]
			* timestamp-on-change-reading und
			* [[Event-aggregator\|event-aggregator]]

	=== gute Reading-Namen - userReadings ===		=== gute Reading-Namen - userReadings ===
Zeile 135:		Zeile 140:

	=== Allgemeines ===		=== Allgemeines ===
			Die setList ist dazu gedacht, Kommandos zu definieren, welche an die Gegenstelle gesendet werden können.

	=== Syntax ===		=== Syntax ===
			In der Regel besteht jede Zeile aus folgenden, per Leerzeichen getrennten Argumenten:
			* einem setter-Namen, ggf. ergänzt durch ein widget (s.u.)
			* einem Topic, unter dem die Payload gesendet werden soll und
			* der Payload.
			Es können diverse Variablen genutzt werden, u.A. auch $EVENT und $EVTPARTx-Elemente, die der Rückgabe (setter-Name und ggf. gesetzter Wert) aus dem jeweiligen "widget" entsprechen.

	=== on und off ===		=== on und off ===
			Damit die weitergehenden Befehle wie ''on-for-timer'' aus den [[DevelopmentModuleIntro#X_Set\|SetExtensions]] funktionieren, muss ein MQTT2_DEVICE die Befehle "on" und "off" kennen. Diese sollten also - wenn es eine Art "Hauptschalter" gibt - gesondert für diesen Hauptschalter angegeben werden.
			Hat ein Gerät mehrerer solcher "Hauptschalter", empfiehlt es sich, für jeden dieser Schalter eine eigene MQTT2_DEVICE-Instanz anzulegen.

	==== setStateList ====		==== setStateList ====
			Gibt es in einem Device neben dem "Hauptschalter" weitere setzbare Readings (z.B. für Helligkeit und Farbe oder eine Temperatur), empfiehlt es sich v.a. dann, wenn das Gerät den Empfang (bzw. die Ausführung) von Befehlen bestätigt, nur die auf den jeweiligen Hauptschalter bezogenen ''set''-Anweisungen in ''state'' zu schreiben. Diese (z.B. on, off und toggle) wären dann in das ''setStateList''-Attribut aufzunehmen.

	==== setExtensionsEvent ====		==== setExtensionsEvent ====
			Will man per SetExtensions realisierte laufende Timer visualisieren, empfiehlt es sich, dieses Attribut zu setzen.

	=== widgets ===		=== widgets ===
Zeile 151:		Zeile 166:

	== getList ==		== getList ==
			Die getList ist dazu gedacht, asynchrone Abfragen an die Gegenstelle zu ermöglichen.
			Die Syntax dabei ist
			* einem getter-Namen, ggf. ergänzt durch ein widget (s.u.)
			* Reading-Name, unter dem die Antwort erwartet wird
			* einem Topic, unter dem die Payload gesendet werden soll und
			* (optional) der Payload.
			Auch hier können diverse Variablen genutzt werden, und/oder das ganze für die Ausführung von Perl-Code genutzt werden.

	== periodicCmd ==		== periodicCmd ==
			Für regelmäßige Aufgaben (mit mind. minütlicher Frequenz) kann eine Liste con get- oder set-Kommandos angegeben werden. Dies kann für regelmäßige Abfragen ebenso genutzt werden wie z.B. zum Löschen veralteter Informationen/Readings.

			== Abschließende Aufgaben ==
			Um das finale Aussehen des Gerätes zu beeinflussen, stehen dann noch die weiteren allgemeinen Attribute zur Verfügung, die in [[DeviceOverview anpassen]] beschrieben sind.