MQTT - Versionsgeschichte

Chris T. Ludwig: /* Installation */

2026-02-22T07:49:31Z

Installation

← Nächstältere Version		Version vom 22. Februar 2026, 09:49 Uhr
Zeile 6:		Zeile 6:
	Dieser Artikel dient mir in erster Linie als Leitfaden und Dokumentation der Konfiguartionsmöglichkeiten des mosquitto MQTT-Systems. Ob ich die Artikel der MQTT-Clients (Ardiuno, ESP8266, RasPi, ...) auch hier in den Artikel packe, habe ich noch nicht entschieden.		Dieser Artikel dient mir in erster Linie als Leitfaden und Dokumentation der Konfiguartionsmöglichkeiten des mosquitto MQTT-Systems. Ob ich die Artikel der MQTT-Clients (Ardiuno, ESP8266, RasPi, ...) auch hier in den Artikel packe, habe ich noch nicht entschieden.

			==Vorweg==
			* Ein fuehrendes Slash / zu Beginn des Topics ist eine ganz schlechte Idee.(Hoffentlich habe ich das ueberall korrigiert.)
			* Argumente (auch der Topic) sollten in Anfuehrungszeichen stehen.
			* Die Angabe des Servers mit -h nicht vergessen.

	==Installation==		==Installation==
	Als MQTT-Paket wird mosquitto bei openSuSE mitgeliefert. Ich habe mich bewußt erst mal gegen die integrierte Variante in FHEM (MQTT2_SERVER) entschieden, da ein Blick ins Wiki und ins Forum von FHEM wieder das übliche Durcheinander zeigt. Da verliert man sich zu schnell in irgendwelchen Spezialproblemen. Also mal nachschauen, ob ich das Paket auf dem Server schon installiert hatte.		Als MQTT-Paket wird mosquitto bei openSuSE mitgeliefert. Ich habe mich bewußt erst mal gegen die integrierte Variante in FHEM (MQTT2_SERVER) entschieden, da ein Blick ins Wiki und ins Forum von FHEM wieder das übliche Durcheinander zeigt. Da verliert man sich zu schnell in irgendwelchen Spezialproblemen. Also mal nachschauen, ob ich das Paket auf dem Server schon installiert hatte.
Zeile 11:		Zeile 16:
	zypper se MQTT		zypper se MQTT

	Es ist zum ~~Mäusemelken~~. Mosquitto wird so nicht gefunden, also besser immer gleich mit der Option -d (Search also in package summaries and descriptions. Default: false) suchen.		Es ist zum Maeusemelken. Mosquitto wird so nicht gefunden, also besser immer gleich mit der Option -d (Search also in package summaries and descriptions. Default: false) suchen.

	zypper se -d MQTT		zypper se -d MQTT

Chris T. Ludwig: /* mosquitto_sub */

2026-02-22T07:45:28Z

mosquitto_sub

← Nächstältere Version		Version vom 22. Februar 2026, 09:45 Uhr
Zeile 1.625:		Zeile 1.625:
	The following “simple” command subscribes to all topics of the mosquitto MQTT server and executes the date command for each message.		The following “simple” command subscribes to all topics of the mosquitto MQTT server and executes the date command for each message.

	mosquitto_sub -v -t /# \| xargs -d$'\n' -L1 bash -c 'date "+%Y-%m-%d %T.%3N $0"'		mosquitto_sub -v -t "#" \| xargs -d$'\n' -L1 bash -c 'date "+%Y-%m-%d %T.%3N $0"'

	Update: Thanks to Stewart C. Russell, who suggested to use ts from moreutils package, it can be achieved with a shorter expression:		Update: Thanks to Stewart C. Russell, who suggested to use ts from moreutils package, it can be achieved with a shorter expression:

	mosquitto_sub -v -t /# \| ts		mosquitto_sub -v -t "#" \| ts

	mosquitto_sub -v -t /# -F "%I %t %p"		mosquitto_sub -v -t "#" -F "%I %t %p"

	mosquitto_sub is a simple mqtt client that will subscribe to a set of topics and print all messages it receives.		mosquitto_sub is a simple mqtt client that will subscribe to a set of topics and print all messages it receives.

Chris T. Ludwig: /* MQTT Paketaufbau */

2026-02-18T19:56:01Z

MQTT Paketaufbau

@@ Zeile 2.927: / Zeile 2.927: @@
 Lässt man ARP erst mal außer Acht, ergibt sich beim Zusammenbauen eines Ethernetframes in der Firmware eines uPC die Notwendigkeit sowohl die eigene Ethernet-Adresse als auch die Ethernet-Adresse des Frame-Empfängers einzutragen. Die eigene Ethernet-Adresse (MAC) ist bekannt. Sie ist in der Regel im Ethernet-Controller oder in der Firmware (Treiber) fest hinterlegt. Die Ethernet-Adresse (MAC) des Zielrechners kennt man erst mal nicht.
 Befinden sich alle Kommunikationspartner mehr oder minder unverändert über einen längeren Zeitraum (z.B. Jahre) im gleichen Netzsegment könnte man auf die Idee kommen, alle in einem Netzsegment vorkommenden MAC/IP-Paare in einer Liste zu erfassen und in der Firmware zu hinterlegen. Da bei einem MQTT-Pub/Sub-Client nur der Broker (Server) von Interesse ist, würde die Liste sogar nur aus einem Eintrag bestehen. Man könnte also bei der Implementierung des MQTT-Clients bei den Setup-Parametern mit der IP des Borkers (Servers) die passende MAC gleich mit hinterlegen. Das hätte den angenehmen Vorteil, dass man sich über ARP-Spoofing/Poisoning/Flooding keinen Kopf zerbrechen müsste. Ein Nachteil wäre sicherlich, die Notwendigkeit bei einem Server/Broker-Wechsel alle beteiligten Clients neu zu konfigurieren. Sollte sich der Broker nicht im gleichen Netzsegment befinden würde im MQTT-Client aber auch die MAC-Adresse des Routers (IP-Gateway) genügen.
 ==MQTT Paketaufbau==

Chris T. Ludwig: /* mosquitto-tls */

2026-02-18T19:50:57Z

mosquitto-tls

← Nächstältere Version		Version vom 18. Februar 2026, 21:50 Uhr
Zeile 2.563:		Zeile 2.563:

	<div class="toccolours mw-collapsible mw-collapsed" style="width:600px; overflow:auto;">		<div class="toccolours mw-collapsible mw-collapsed" style="width:600px; overflow:auto;">
	<div style="font-weight:bold;line-height:1.6;">man mosquitto-~~tlls~~</div>		<div style="font-weight:bold;line-height:1.6;">man mosquitto-tls</div>
	<div class="mw-collapsible-content">		<div class="mw-collapsible-content">
	<syntaxhighlight lang="bash" line>		<syntaxhighlight lang="bash" line>

Chris T. Ludwig: /* Last Will */

2023-05-03T05:46:20Z

Last Will

← Nächstältere Version		Version vom 3. Mai 2023, 07:46 Uhr
Zeile 3.251:		Zeile 3.251:

	==Last Will==		==Last Will==
	Sozusagen das Testament oder auch letzter Wille genannt ist die Moeglichkeit eines Clients beim Connect beim Borker (sozusagen Notar) eine Nachricht zu hinterlegen die in einem Fall eines unerwarteten Disconnects gesendet (normaler publish) wird. Damit koennen die Subscriber der Topics ueber die Kommunikationsunterbrechung informiert werden. ~~Einer~~ "normaler" Disconnect loescht den Last Will beim Broker und muss beim Connect wieder neu angelegt werden.		Sozusagen das Testament oder auch letzter Wille genannt ist die Moeglichkeit eines Clients beim Connect beim Borker (sozusagen Notar) eine Nachricht zu hinterlegen die in einem Fall eines unerwarteten Disconnects gesendet (normaler publish) wird. Damit koennen die Subscriber der Topics ueber die Kommunikationsunterbrechung informiert werden. Ein "normaler" Disconnect loescht den Last Will beim Broker und muss beim Connect wieder neu angelegt werden.

	==Weitere Quellen==		==Weitere Quellen==

Chris T. Ludwig: /* Alle Control Pakets im Überbrlick */

2023-05-03T05:43:44Z

Alle Control Pakets im Überbrlick

← Nächstältere Version		Version vom 3. Mai 2023, 07:43 Uhr
Zeile 2.929:		Zeile 2.929:

	==MQTT Paketaufbau==		==MQTT Paketaufbau==
	===Alle Control Pakets im ~~Überbrlick~~===		===Alle Control Pakets im Überblick===
	{\| class="wikitable" id="mqttpaket"		{\| class="wikitable" id="mqttpaket"
	\|+ Paketaufbau im Detail		\|+ Paketaufbau im Detail

Chris T. Ludwig am 3. Mai 2023 um 05:40 Uhr

2023-05-03T05:40:27Z

← Nächstältere Version		Version vom 3. Mai 2023, 07:40 Uhr
Zeile 4:		Zeile 4:
	Schnell mal die aktuelle Installationssituation gecheckt und den Rahmen für die anstehenden Tests abgesteckt.		Schnell mal die aktuelle Installationssituation gecheckt und den Rahmen für die anstehenden Tests abgesteckt.

	Dieser Artikel dient mir ~~als~~ erster Linie als Leitfaden und Dokumentation der Konfiguartionsmöglichkeiten des mosquitto MQTT-Systems. Ob ich die Artikel der MQTT-Clients (Ardiuno, ESP8266, RasPi, ...) auch hier in den Artikel packe, habe ich noch nicht entschieden.		Dieser Artikel dient mir in erster Linie als Leitfaden und Dokumentation der Konfiguartionsmöglichkeiten des mosquitto MQTT-Systems. Ob ich die Artikel der MQTT-Clients (Ardiuno, ESP8266, RasPi, ...) auch hier in den Artikel packe, habe ich noch nicht entschieden.

	==Installation==		==Installation==

Chris T. Ludwig: /* Weitere Quellen */

2022-08-08T11:33:22Z

Weitere Quellen

← Nächstältere Version		Version vom 8. August 2022, 13:33 Uhr
Zeile 3.249:		Zeile 3.249:

	[[Datei:MQTT QoS2 Diagramm.png\|800px]]		[[Datei:MQTT QoS2 Diagramm.png\|800px]]

			==Last Will==
			Sozusagen das Testament oder auch letzter Wille genannt ist die Moeglichkeit eines Clients beim Connect beim Borker (sozusagen Notar) eine Nachricht zu hinterlegen die in einem Fall eines unerwarteten Disconnects gesendet (normaler publish) wird. Damit koennen die Subscriber der Topics ueber die Kommunikationsunterbrechung informiert werden. Einer "normaler" Disconnect loescht den Last Will beim Broker und muss beim Connect wieder neu angelegt werden.

	==Weitere Quellen==		==Weitere Quellen==

Chris T. Ludwig: /* Alle Control Pakets im Überbrlick */

2022-08-08T09:07:17Z

Alle Control Pakets im Überbrlick

← Nächstältere Version		Version vom 8. August 2022, 11:07 Uhr
Zeile 2.980:		Zeile 2.980:
	* RETAIN (Bit 7) Die Nachricht soll aufbewahrt werden.		* RETAIN (Bit 7) Die Nachricht soll aufbewahrt werden.

	DUP: Das DUP-Flag dient dazu dem Broker/Subscriber zu signalisieren, dass diese Nachricht schon einmal gesendet (published) wurde. In der Spezifikation gibt es einen Hinweis, dass das Flag nur bei QOS 1 oder 2 von Bedeutung ist.		'''DUP''': Das DUP-Flag dient dazu dem Broker/Subscriber zu signalisieren, dass diese Nachricht schon einmal gesendet (published) wurde. In der Spezifikation gibt es einen Hinweis, dass das Flag nur bei QOS 1 oder 2 von Bedeutung ist. Das liegt wohl daran nur bei QOS=1\|2 eine Speicherung der Nachricht bis zum ACK stattfindet. Wuerde das DUP-Flag also nicht gesetzt, wuerde das zu einer weiteren Speicherung fuehren.

	QOS:[[#Quality of Service\|siehe unten]]		'''QOS''':[[#Quality of Service\|siehe unten]]

	RETAIN: Wenn ein Publischer eine Nachricht sendet und (gleichzeitig) kein Subscriber den Topic "abonniert" hat wird die Nachricht vom Server (Broker) verworfen. Es wird immer nur eine Nachricht pro Topic aufbewahrt. D. h erst eine neue retainte Nachricht mit NULL als Inhalt loescht/ueberschreibt eine retainte Nachricht. Dabei ist wohl unerheblich, von welchem Client der Publish kommt. So koennte auch ein Subscriber eine retainte Nachricht loeschen. Getestet habe ich das noch nicht, aber eine entsprechende Option (--remove-retained) in mosquitto_sub (SUB!) laesst darauf schleiszen. Zum erzeugen der NUULL-Nachricht hat mosquitto_pub die Option '-n'. RETAIN ist ideal fuer Statusmeldungen eines Devices. Der (letzte) Status bleibt erhalten und ist auch zeitversetzt noch erhaltbar (sorry mir ist kein besseres Wort eingefallen). Besser finde ich den Einsatz von RETAIN aber noch bei unzuverlaessig angebundenen Devices (alle Arten von Funk, ...) oder welche erst fuer eine Aktivaet aus dem DeepSleep/StandBy geholt werden muessen oder gar erst gestartet werden muessen. Beispiel: Ein Funk-Schaltaktor ist stromlos. Nach dem Einschalten beginnt der Bootprozess und die Kontaktaufnahme (z.B. WLAN) dauert bei einem ESP8266 ca. 10 Sekunden. Diese 10 Sekunden muesste eine Publisher warten bis er erkennt, dass der Schaltaktor bereit ist um seine Nachricht zu senden. Mit Retain kann er sie zeitgleich mit dem PowerUp absetzen und sobald der Schaltaktor aktiv ist erhaelt er seine Nachricht(en). Da pro Topic immmer nur eine Nachricht retained sein kann empfiehlt es sich topics aufzuschluesseln und moeglichst nur einen Wert/Nachricht daran zu senden. D.h. also nicht alle Werte eines Teilnehmers in einen Topic, sondern jeweils einen "Untertopic" fuer z.B. Temperatur, Feuchte, Status, ... und dann dort die Wert hineinsenden.		'''RETAIN''': Wenn ein Publischer eine Nachricht sendet und (gleichzeitig) kein Subscriber den Topic "abonniert" hat wird die Nachricht vom Server (Broker) verworfen. Es wird immer nur eine Nachricht pro Topic aufbewahrt. D. h erst eine neue retainte Nachricht mit NULL als Inhalt loescht/ueberschreibt eine retainte Nachricht. Dabei ist wohl unerheblich, von welchem Client der Publish kommt. So koennte auch ein Subscriber eine retainte Nachricht loeschen. Getestet habe ich das noch nicht, aber eine entsprechende Option (--remove-retained) in mosquitto_sub (SUB!) laesst darauf schleiszen. Zum erzeugen der NUULL-Nachricht hat mosquitto_pub die Option '-n'. RETAIN ist ideal fuer Statusmeldungen eines Devices. Der (letzte) Status bleibt erhalten und ist auch zeitversetzt noch erhaltbar (sorry mir ist kein besseres Wort eingefallen). Besser finde ich den Einsatz von RETAIN aber noch bei unzuverlaessig angebundenen Devices (alle Arten von Funk, ...) oder welche erst fuer eine Aktivaet aus dem DeepSleep/StandBy geholt werden muessen oder gar erst gestartet werden muessen. Beispiel: Ein Funk-Schaltaktor ist stromlos. Nach dem Einschalten beginnt der Bootprozess und die Kontaktaufnahme (z.B. WLAN) dauert bei einem ESP8266 ca. 10 Sekunden. Diese 10 Sekunden muesste eine Publisher warten bis er erkennt, dass der Schaltaktor bereit ist um seine Nachricht zu senden. Mit Retain kann er sie zeitgleich mit dem PowerUp absetzen und sobald der Schaltaktor aktiv ist erhaelt er seine Nachricht(en). Da pro Topic immmer nur eine Nachricht retained sein kann empfiehlt es sich topics aufzuschluesseln und moeglichst nur einen Wert/Nachricht daran zu senden. D.h. also nicht alle Werte eines Teilnehmers in einen Topic, sondern jeweils einen "Untertopic" fuer z.B. Temperatur, Feuchte, Status, ... und dann dort die Wert hineinsenden.

	===Remaining Field===		===Remaining Field===

Chris T. Ludwig: /* Alle Control Pakets im Überbrlick */

2022-08-08T09:01:43Z

Alle Control Pakets im Überbrlick

← Nächstältere Version		Version vom 8. August 2022, 11:01 Uhr
Zeile 2.980:		Zeile 2.980:
	* RETAIN (Bit 7) Die Nachricht soll aufbewahrt werden.		* RETAIN (Bit 7) Die Nachricht soll aufbewahrt werden.

	DUP:		DUP: Das DUP-Flag dient dazu dem Broker/Subscriber zu signalisieren, dass diese Nachricht schon einmal gesendet (published) wurde. In der Spezifikation gibt es einen Hinweis, dass das Flag nur bei QOS 1 oder 2 von Bedeutung ist.

	QOS:		QOS:[[#Quality of Service\|siehe unten]]

	RETAIN: Wenn ein Publischer eine Nachricht sendet und (gleichzeitig) kein Subscriber den Topic "abonniert" hat wird die Nachricht vom Server (Broker) verworfen. Es wird immer nur eine Nachricht pro Topic aufbewahrt. D. h erst eine neue Nachricht ~~egal ob relained oder nicht,~~ loescht/ueberschreibt eine retainte Nachricht. RETAIN ist ideal fuer Statusmeldungen eines Devices. Der (letzte) Status bleibt erhalten und ist auch zeitversetzt noch erhaltbar (sorry mir ist kein besseres Wort eingefallen). Besser finde ich den Einsatz von RETAIN aber noch bei unzuverlaessig angebundenen Devices (alle Arten von Funk, ...) oder welche erst fuer eine Aktivaet aus dem DeepSleep/StandBy geholt werden muessen oder gar erst gestartet werden muessen. Beispiel: Ein Funk-Schaltaktor ist stromlos. Nach dem Einschalten beginnt der Bootprozess und die Kontaktaufnahme (z.B. WLAN) dauert bei einem ESP8266 ca. 10 Sekunden. Diese 10 Sekunden muesste eine Publisher warten bis er erkennt, dass der Schaltaktor bereit ist um seine Nachricht zu senden. Mit Retain kann er sie zeitgleich mit dem PowerUp absetzen und sobald der Schaltaktor aktiv ist erhaelt er seine Nachricht(en). Da pro Topic immmer nur eine Nachricht retained sein kann empfiehlt es sich topics aufzuschluesseln und moeglichst nur einen Wert/Nachricht daran zu senden. D.h. also nicht alle Werte eines Teilnehmers in einen Topic, sondern jeweils einen "Untertopic" fuer z.B. Temperatur, Feuchte, Status, ... und dann dort die Wert hineinsenden.		RETAIN: Wenn ein Publischer eine Nachricht sendet und (gleichzeitig) kein Subscriber den Topic "abonniert" hat wird die Nachricht vom Server (Broker) verworfen. Es wird immer nur eine Nachricht pro Topic aufbewahrt. D. h erst eine neue retainte Nachricht mit NULL als Inhalt loescht/ueberschreibt eine retainte Nachricht. Dabei ist wohl unerheblich, von welchem Client der Publish kommt. So koennte auch ein Subscriber eine retainte Nachricht loeschen. Getestet habe ich das noch nicht, aber eine entsprechende Option (--remove-retained) in mosquitto_sub (SUB!) laesst darauf schleiszen. Zum erzeugen der NUULL-Nachricht hat mosquitto_pub die Option '-n'. RETAIN ist ideal fuer Statusmeldungen eines Devices. Der (letzte) Status bleibt erhalten und ist auch zeitversetzt noch erhaltbar (sorry mir ist kein besseres Wort eingefallen). Besser finde ich den Einsatz von RETAIN aber noch bei unzuverlaessig angebundenen Devices (alle Arten von Funk, ...) oder welche erst fuer eine Aktivaet aus dem DeepSleep/StandBy geholt werden muessen oder gar erst gestartet werden muessen. Beispiel: Ein Funk-Schaltaktor ist stromlos. Nach dem Einschalten beginnt der Bootprozess und die Kontaktaufnahme (z.B. WLAN) dauert bei einem ESP8266 ca. 10 Sekunden. Diese 10 Sekunden muesste eine Publisher warten bis er erkennt, dass der Schaltaktor bereit ist um seine Nachricht zu senden. Mit Retain kann er sie zeitgleich mit dem PowerUp absetzen und sobald der Schaltaktor aktiv ist erhaelt er seine Nachricht(en). Da pro Topic immmer nur eine Nachricht retained sein kann empfiehlt es sich topics aufzuschluesseln und moeglichst nur einen Wert/Nachricht daran zu senden. D.h. also nicht alle Werte eines Teilnehmers in einen Topic, sondern jeweils einen "Untertopic" fuer z.B. Temperatur, Feuchte, Status, ... und dann dort die Wert hineinsenden.

	===Remaining Field===		===Remaining Field===