MQTT Einführung Teil 2 - Versionsgeschichte

Baumbuwe: Kat

2018-11-23T17:26:44Z

Kat

← Nächstältere Version		Version vom 23. November 2018, 19:26 Uhr
Zeile 202:		Zeile 202:
	* [[MQTT Einführung Teil 3\|Teil 3 der MQTT Einführung: Hände schmutzig machen]]		* [[MQTT Einführung Teil 3\|Teil 3 der MQTT Einführung: Hände schmutzig machen]]

			[[Kategorie:MQTT\|Einführung]]


	[[Kategorie:Glossary]]		[[Kategorie:Glossary]]

Baumbuwe: Überschrift

2018-01-25T11:49:49Z

Überschrift

← Nächstältere Version		Version vom 25. Januar 2018, 13:49 Uhr
Zeile 198:		Zeile 198:
	Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].		Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].

	== Links ==		= Links =
	* [[MQTT_Einf%C3%BChrung\|Teil 1 der MQTT Einführung]]		* [[MQTT_Einf%C3%BChrung\|Teil 1 der MQTT Einführung]]
	* [[MQTT Einführung Teil 3\|Teil 3 der MQTT Einführung: Hände schmutzig machen]]		* [[MQTT Einführung Teil 3\|Teil 3 der MQTT Einführung: Hände schmutzig machen]]

Baumbuwe: Links

2018-01-25T11:48:14Z

Links

← Nächstältere Version		Version vom 25. Januar 2018, 13:48 Uhr
Zeile 197:		Zeile 197:

	Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].		Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].

			== Links ==
			* [[MQTT_Einf%C3%BChrung\|Teil 1 der MQTT Einführung]]
			* [[MQTT Einführung Teil 3\|Teil 3 der MQTT Einführung: Hände schmutzig machen]]




	[[Kategorie:Glossary]]		[[Kategorie:Glossary]]

Baumbuwe: /* Schlusswort */ Link zu Teil 3

2018-01-25T11:41:04Z

Schlusswort: Link zu Teil 3

← Nächstältere Version		Version vom 25. Januar 2018, 13:41 Uhr
Zeile 194:		Zeile 194:
	Weiterhin haben wir ganz neu [https://forum.fhem.de/index.php/board,94.0.html einen eigenen Forumsbereich für MQTT].		Weiterhin haben wir ganz neu [https://forum.fhem.de/index.php/board,94.0.html einen eigenen Forumsbereich für MQTT].

	Je nachdem wie gut die Artikelserie ankommt, werde ich einen Teil 3 auflegen. Dieser ist dann zum "get your hands dirty", zum Hände dreckig machen. Darin könnte ein kleiner Programmierkurs in der Arduino IDE kommen. Mir schwebt vor, einen kleinen Sketch zu nehmen, diesen mit MQTT auszurüsten und nach und nach die Dinge wie LWT, retained messages etc. einzubauen. Das ist im wesentlichen mit wenigen Änderungen möglich. Also durchaus anfängertauglich.		Je nachdem wie gut die Artikelserie ankommt, werde ich einen [[MQTT Einführung Teil 3\|Teil 3]] auflegen. Dieser ist dann zum "get your hands dirty", zum Hände dreckig machen. Darin könnte ein kleiner Programmierkurs in der Arduino IDE kommen. Mir schwebt vor, einen kleinen Sketch zu nehmen, diesen mit MQTT auszurüsten und nach und nach die Dinge wie LWT, retained messages etc. einzubauen. Das ist im wesentlichen mit wenigen Änderungen möglich. Also durchaus anfängertauglich.

	Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].		Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].

AndreasMohr: Typos/Spelling

2018-01-01T12:23:58Z

Typos/Spelling

← Nächstältere Version		Version vom 1. Januar 2018, 14:23 Uhr
Zeile 14:		Zeile 14:
	== Retained Messages ==		== Retained Messages ==
	=== Szenario ===		=== Szenario ===
	Stellen wir uns vor, wir starten FHEM neu. Wer ~~Homematic~~ Devices kennt weiß, spätestens nach einem Blick ins Logfile, dass nun zunächst ein Statusrequest aller Geräte erfolgt. Schließlich konnte sich zwischen Beenden und Neustart von FHEM etwas geändert haben.		Stellen wir uns vor, wir starten FHEM neu. Wer HomeMatic Devices kennt weiß, spätestens nach einem Blick ins Logfile, dass nun zunächst ein Statusrequest aller Geräte erfolgt. Schließlich konnte sich zwischen Beenden und Neustart von FHEM etwas geändert haben.
	* ~~Homematic~~		* HomeMatic
	* Es wird jedes Gerät angesprochen und abgefragt:		* Es wird jedes Gerät angesprochen und abgefragt:
	* "Lieber Lichtschalter, was tust du grade?"		* "Lieber Lichtschalter, was tust du grade?"
Zeile 26:		Zeile 26:
	Sobald wir dieses Topic auf einem Gerät subscriben, bekommen wir den Status angezeigt. Ein neu startendes FHEM ist so ein Fall.		Sobald wir dieses Topic auf einem Gerät subscriben, bekommen wir den Status angezeigt. Ein neu startendes FHEM ist so ein Fall.

	Was bei ~~Homematic~~ erst über einen (zugegeben automatisierten Request) abläuft, kann MQTT mit den retained Messages auch so.		Was bei HomeMatic erst über einen (zugegeben automatisierten Request) abläuft, kann MQTT mit den retained Messages auch so.

	Trifft am Broker eine neue retained Message ein, so wird die alte Nachricht gelöscht. Zum absichtlichen Löschen einer retained Message, etwa weil man weiß, dass dieses Topic zukünftig nicht mehr benötigt wird, kann man eine leere Message posten.		Trifft am Broker eine neue retained Message ein, so wird die alte Nachricht gelöscht. Zum absichtlichen Löschen einer retained Message, etwa weil man weiß, dass dieses Topic zukünftig nicht mehr benötigt wird, kann man eine leere Message posten.
Zeile 76:		Zeile 76:

	=== Fazit ===		=== Fazit ===
	MQTT kann einen eleganten Weg bieten, über das Ende eines Gerätes zu informieren. Genau wie bei ~~Homematic~~ aber auch, muss man diese Meldungen auswerten um was sinnvolles damit anzufangen!		MQTT kann einen eleganten Weg bieten, über das Ende eines Gerätes zu informieren. Genau wie bei HomeMatic aber auch, muss man diese Meldungen auswerten um was sinnvolles damit anzufangen!
	Im Fall eines einfachen Sensors ist es recht easy, bei einem Arduino Mega mit 30 Sensoren wird es dann aufwendig (außer man liest weiter bei den Filtern)		Im Fall eines einfachen Sensors ist es recht easy, bei einem Arduino Mega mit 30 Sensoren wird es dann aufwendig (außer man liest weiter bei den Filtern)

Zeile 179:		Zeile 179:
	Tauscht man später den Controller aus, muss man ihn wieder so nennen. Fasst man später Arduino_1 und Arduino_2 auf einem Arduino Mega zusammen, stimmen die Topics schlicht nicht mehr und man muss seine ganzen Devicenamen anpassen.		Tauscht man später den Controller aus, muss man ihn wieder so nennen. Fasst man später Arduino_1 und Arduino_2 auf einem Arduino Mega zusammen, stimmen die Topics schlicht nicht mehr und man muss seine ganzen Devicenamen anpassen.

	== Der Artikel ~~hast~~ "Best Practices" versprochen - wo sind sie? ==		== Der Artikel hat "Best Practices" versprochen - wo sind sie? ==
	Schwierig. Was die Benennung der Topics betrifft, so vom Zeichensatz her, gibt es Regeln und best practices, die stehen oben.		Schwierig. Was die Benennung der Topics betrifft, so vom Zeichensatz her, gibt es Regeln und best practices, die stehen oben.

Zeile 190:		Zeile 190:
	Hier endet vorübergehend unser kleiner Exkurs zu MQTT.		Hier endet vorübergehend unser kleiner Exkurs zu MQTT.

	Wer Fragen ~~der~~ Anregungen hat, bitte im [https://forum.fhem.de/index.php/topic,69701.0.html Diskussionsthread dieses Artikels] stellen.		Wer Fragen oder Anregungen hat, bitte im [https://forum.fhem.de/index.php/topic,69701.0.html Diskussionsthread dieses Artikels] stellen.

	Weiterhin haben wir ganz neu [https://forum.fhem.de/index.php/board,94.0.html einen eigenen Forumsbereich für MQTT].		Weiterhin haben wir ganz neu [https://forum.fhem.de/index.php/board,94.0.html einen eigenen Forumsbereich für MQTT].

Jorge3711: /* Vorwort */ Link zu Teil 1 in einen internen Link verwandelt

2017-04-06T17:38:05Z

Vorwort: Link zu Teil 1 in einen internen Link verwandelt

← Nächstältere Version		Version vom 6. April 2017, 19:38 Uhr
Zeile 5:		Zeile 5:
	Wer den Teil 1 noch nicht gelesen hat, ist herzlich eingeladen das vorher noch schnell zu machen :)		Wer den Teil 1 noch nicht gelesen hat, ist herzlich eingeladen das vorher noch schnell zu machen :)

	[~~https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung~~ Hier ist Teil 1]		[[MQTT_Einführung\|Hier ist Teil 1]]

Rince: Kategorie Glossary zugeordnet

2017-04-01T18:35:03Z

Kategorie Glossary zugeordnet

← Nächstältere Version		Version vom 1. April 2017, 20:35 Uhr
Zeile 197:		Zeile 197:

	Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].		Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].



			[[Kategorie:Glossary]]

Rince: fertig

2017-03-27T18:19:50Z

fertig

← Nächstältere Version		Version vom 27. März 2017, 20:19 Uhr
Zeile 89:		Zeile 89:
	Theoretisch gehen also Umlaute, Leerzeichen etc. Praktisch kann es passieren, dass ein Endgerät mit Umlauten einfach nix anfangen kann. Leerzeichen sind auch ein Problem, weil UTF 8 davon doch recht viele Möglichkeiten bietet. Ich würde daher empfehlen, Topicbezeichnungen eher wie Gerätenamen in FHEM zu betrachten: Unterstriche statt Leerzeichen, Umlaute ausschreiben (=> ü => ue...)		Theoretisch gehen also Umlaute, Leerzeichen etc. Praktisch kann es passieren, dass ein Endgerät mit Umlauten einfach nix anfangen kann. Leerzeichen sind auch ein Problem, weil UTF 8 davon doch recht viele Möglichkeiten bietet. Ich würde daher empfehlen, Topicbezeichnungen eher wie Gerätenamen in FHEM zu betrachten: Unterstriche statt Leerzeichen, Umlaute ausschreiben (=> ü => ue...)

	Groß- und Kleinschreibung muss beachtet werden. Ein Topic muss mindestens ein Zeichen haben, um gültig zu sein.		Groß- und Kleinschreibung muss beachtet werden. Ein Topic muss mindestens ein Zeichen haben, um gültig zu sein. Oh, und $ gehen auch gar nicht. Die verwendet der Broker nämlich für Interna...

	~~Schlechte Beispiele~~:		Schlechtes Beispiel:
	*/zuHause/		* /zuHause/
	nicht ganz falsch, aber der / am Anfang ist nur zusätzlicher Overhead, daher weglassen		* nicht ganz falsch, aber der / am Anfang ist nur zusätzlicher Overhead, daher weglassen

			Wirklich falsch:
	*zuHause//1_OG		* zuHause//1_OG
	Hier wird ein leeres Topic definiert. Das ist ungültig.		* Hier wird ein leeres Topic definiert. Das ist ungültig.

	=== Basics, Strukturierung ===		=== Basics, Strukturierung ===
Zeile 110:		Zeile 110:
	Wenn da ein "on" steht, woher will man wissen ob es sich um einen Befehl oder um eine Statusmeldung handelt? Daher bauen wir die FHEM übliche Logik einfach nach:		Wenn da ein "on" steht, woher will man wissen ob es sich um einen Befehl oder um eine Statusmeldung handelt? Daher bauen wir die FHEM übliche Logik einfach nach:

	Etwas glücklicher (kann man machen, ~~sollte~~ man aber ~~nicht~~)		Etwas glücklicher (kann man machen, man kann es aber schwer filtern)
	* zuHause/1_OG/Kueche/Lichtschalter/set		* zuHause/1_OG/Kueche/Lichtschalter/set
	* zuHause/1_OG/Kueche/Lichtschalter/state		* zuHause/1_OG/Kueche/Lichtschalter/state
Zeile 122:		Zeile 122:
	auf dem set-Topic publishen wir immer Schaltbefehle. Mit oder ohne retained flag, darüber kann man streiten. Unser Arduino muss also dieses Topic abhören und auswerten.		auf dem set-Topic publishen wir immer Schaltbefehle. Mit oder ohne retained flag, darüber kann man streiten. Unser Arduino muss also dieses Topic abhören und auswerten.

	Das state-Topic nehmen wir um darauf zu publishen, wie der Zustand unserer Lampe gerade ist. Unser Arduino muss dieses Topic nur schreiben, niemals selber lesen.		Das state-Topic nehmen wir um darauf zu publishen (hier ist retained einfeutig praktisch), wie der Zustand unserer Lampe gerade ist. Unser Arduino muss dieses Topic nur schreiben, niemals selber lesen.

	Damit haben wir eine saubere Trennung von Befehl und Status erreicht.		Damit haben wir eine saubere Trennung von Befehl und Status erreicht.
Zeile 131:		Zeile 131:
	Ungünstig:		Ungünstig:
	* zuHause/state/1_OG/Kueche		* zuHause/state/1_OG/Kueche
	=> In diesem Topic Licht, Temperatur, Luftfeuchte, Bewegungsmelder etc zu publishen ist eine nicht schlaue Idee; das Problem beginnt damit, dass man erst mal selber rausfinden muss, welchen Wert man gerade hat. Viel Programmcode für quasi umsonst.		* => In diesem Topic Licht, Temperatur, Luftfeuchte, Bewegungsmelder etc zu publishen ist eine nicht schlaue Idee; das Problem beginnt damit, dass man erst mal selber rausfinden muss, welchen Wert man gerade hat. Viel Programmcode für quasi umsonst; "on 20.3 66 motion" ist nun nicht wirklich toll.

	Besser:		Besser:
Zeile 138:		Zeile 138:
	* zuHause/state/1_OG/Kueche/Luftfeuchte		* zuHause/state/1_OG/Kueche/Luftfeuchte
	* zuHause/state/1_OG/Kueche/Bewegungsmelder		* zuHause/state/1_OG/Kueche/Bewegungsmelder
	=> Auf diese Weise weiß man vorher, welche ~~Zahlenwerte~~ in einem Topic stehen und was sie bedeuten. Das hat man automatisch durch die geschickte Topic Wahl festgelegt.		=> Auf diese Weise weiß man vorher, welche (Zahlen)werte in einem Topic stehen und was sie bedeuten. Das hat man automatisch durch die geschickte Topic Wahl festgelegt.

	=== Filter ===		=== Filter ===
Zeile 159:		Zeile 159:
	"#" => muss immer der letzte Filter sein (es gibt Broker, die die # auch als Platzhalter innerhalb eines Topics erlauben, aber Standard ist das nicht)		"#" => muss immer der letzte Filter sein (es gibt Broker, die die # auch als Platzhalter innerhalb eines Topics erlauben, aber Standard ist das nicht)

	* zuHause/state/# => gibt uns alle oben genannten Topics zurück		* zuHause/state/# => gibt uns alle oben genannten Beispiel-Topics zurück
	* zuHause/state/1_OG/+/Licht => gibt uns das Licht der Küche, des Wohn- und des Schlafzimmers		* zuHause/state/1_OG/+/Licht => gibt uns das Licht der Küche, des Wohn- und des Schlafzimmers
	* zuHause/state/1_OG/+/Temperatur => gibt nur die Küchentemperatur (+ steht für genau 1 Topic)		* zuHause/state/1_OG/+/Temperatur => gibt nur die Küchentemperatur (+ steht für genau 1 Topic, der Kühlschrank fällt also nicht in das Muster)

			=== Diskussionspunkt, Devicenamen ===
			Manchmal liest man auch den Tip, eine eindeutige Gerätebezeichnung in das Topic mit aufzunehmen.
			* Arduino_1/state/Zimmer_1/Licht
			* Arduino_1/state/Zimmer_1/Temperatur
			* Arduino_1/state/Zimmer_2/Licht
			* Arduino_2/state/Zimmer_3/Licht

			Hat im wesentlichen folgenden Vorteil:

			Wenn ich mir nur ansehen will, was ein bestimmter Mikrocontroller published, kann ich ihn sehr einfach filtern.
			* Arduino_1/# => perfekt um alle Werte des Arduino_1 zu lesen und sonst nichts

			Nachteilig:

			Tauscht man später den Controller aus, muss man ihn wieder so nennen. Fasst man später Arduino_1 und Arduino_2 auf einem Arduino Mega zusammen, stimmen die Topics schlicht nicht mehr und man muss seine ganzen Devicenamen anpassen.

			== Der Artikel hast "Best Practices" versprochen - wo sind sie? ==
			Schwierig. Was die Benennung der Topics betrifft, so vom Zeichensatz her, gibt es Regeln und best practices, die stehen oben.

			Ob man jetzt eindeutige Gerätenamen vorne weg schreibt, oder ob man state und set weiter vorne im Topic Tree unterbringt oder hinten, ich fürchte da gibt es keine allgemein gültigen Regeln. MQTT lässt einem hier alle Freiheiten.

			Das eine sieht eher nach FHEM aus (set und state am Ende), das andere lässt sich besser filtern.
			Hardcoreuser könnten auch auf die Idee kommen, einfach beide Varianten gleichzeitig zu nutzen. Für FHEM alleine ist das sicherlich nicht hilfreich (aber auch nicht störend).

			== Schlusswort ==
			Hier endet vorübergehend unser kleiner Exkurs zu MQTT.

			Wer Fragen der Anregungen hat, bitte im [https://forum.fhem.de/index.php/topic,69701.0.html Diskussionsthread dieses Artikels] stellen.

			Weiterhin haben wir ganz neu [https://forum.fhem.de/index.php/board,94.0.html einen eigenen Forumsbereich für MQTT].

			Je nachdem wie gut die Artikelserie ankommt, werde ich einen Teil 3 auflegen. Dieser ist dann zum "get your hands dirty", zum Hände dreckig machen. Darin könnte ein kleiner Programmierkurs in der Arduino IDE kommen. Mir schwebt vor, einen kleinen Sketch zu nehmen, diesen mit MQTT auszurüsten und nach und nach die Dinge wie LWT, retained messages etc. einzubauen. Das ist im wesentlichen mit wenigen Änderungen möglich. Also durchaus anfängertauglich.

			Ich werde einen Arduino Uno oder Mega nehmen, sowie ein Ethernetshield mit W5100 Chip benutzen. Die Dinger kosten keine 6 € auf eBay. Die ENC28J60 (oder ähnliche) Chips werden explizit NICHT unterstützt werden! Wer lieber einen ESP8266 nimmt, der sei an dieser Stelle auf das Template von Pf@nne verwiesen [https://forum.fhem.de/index.php/topic,50238.0.html hier zu finden].

Rince: /* Filter */

2017-03-27T17:26:06Z

Filter

← Nächstältere Version		Version vom 27. März 2017, 19:26 Uhr
Zeile 141:		Zeile 141:

	=== Filter ===		=== Filter ===
			Eine witzige Sache von MQTT sind Filter. Das ist in etwa wie in FHEM eine readingsGroup für Arme. Wir möchten schnell einen Überblick haben, welchen Status bestimmte Devices haben.

	~~AB HIER NOCH NICHT FERTIG~~

	Eine witzige Sache von MQTT sind Filter. Das ist in etwa wie in FHEM eine readingsGroup für Arme.

	Es gibt zwei Arten von Filtern:		Es gibt zwei Arten von Filtern:
Zeile 161:		Zeile 157:
	Jetzt filtern wir:		Jetzt filtern wir:

	"#" => muss immer der letzte Filter sein		"#" => muss immer der letzte Filter sein (es gibt Broker, die die # auch als Platzhalter innerhalb eines Topics erlauben, aber Standard ist das nicht)

	* zuHause/state/# gibt uns alle oben genannten Topics zurück		* zuHause/state/# => gibt uns alle oben genannten Topics zurück
	* zuHause/state/1_OG/+/Licht		* zuHause/state/1_OG/+/Licht => gibt uns das Licht der Küche, des Wohn- und des Schlafzimmers
			* zuHause/state/1_OG/+/Temperatur => gibt nur die Küchentemperatur (+ steht für genau 1 Topic)

Rince: /* MQTT Teil 2 */

2017-03-27T16:11:47Z

MQTT Teil 2

← Nächstältere Version		Version vom 27. März 2017, 18:11 Uhr
Zeile 3:		Zeile 3:

	== Vorwort ==		== Vorwort ==
			Wer den Teil 1 noch nicht gelesen hat, ist herzlich eingeladen das vorher noch schnell zu machen :)

			[https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung Hier ist Teil 1]


	Dieser Artikel beschreibt, etwas trocken, weiterführend Konzepte und Denkweisen des Übertragungsprotokolls MQTT. Es wird etwas technischer als die Einführung und der ein oder andere Vergleich zu anderen Protokollen wird auch gezogen. Vieles davon kann man auch so nachlesen, wenngleich nicht immer auf deutsch. Ich gehe davon aus, dass der Leser MQTT vornehmlich mit FHEM einsetzen will.		Dieser Artikel beschreibt, etwas trocken, weiterführend Konzepte und Denkweisen des Übertragungsprotokolls MQTT. Es wird etwas technischer als die Einführung und der ein oder andere Vergleich zu anderen Protokollen wird auch gezogen. Vieles davon kann man auch so nachlesen, wenngleich nicht immer auf deutsch. Ich gehe davon aus, dass der Leser MQTT vornehmlich mit FHEM einsetzen will.