MQTT

Die wichtigsten Befehle zum Merken

• mosquitto_sub — ein Topic abonnieren.
• mosquitto_pub — eine Nachricht darauf veröffentlichen.

Befehle und Optionen

Befehl oder Option	Bedeutung
-h localhost -p 1883	Den vorhandenen lokalen Klartextbroker wählen.
-t 'lab/temperature'	Genau diesen Topicnamen verwenden.
-q 1	QoS 1 für Abonnement / Veröffentlichung anfordern.
-v	Topic und Inhalt beim Empfänger ausgeben.
-C 1 -W 30	Nach einer Nachricht oder dreißig Sekunden Wartefrist stoppen.
-m '21.5'	Diese Textbytes als Inhalt senden.

Die Temperatureinheit ist eine Anwendungsvereinbarung. MQTT leitet sie nicht aus der Zahl ab. Die Befehle verlangen weder Retained-Veröffentlichung noch dauerhafte Offline-Sitzung.

Die entscheidenden Konzepte

1. Publisher und Subscriber treffen sich über Topics

MQTT ist ein schlankes Publish/Subscribe-Protokoll. Publisher senden an Topicnamen; der Broker verteilt an passende Abonnements. Direkte Verbindungen zu allen Empfängern sind nicht erforderlich.

Topicnamen unterscheiden Groß- und Kleinschreibung. Hierarchisch wirkende Namen organisieren Nachrichten; Filter können mehrere Topics erfassen. Das Topic definiert aber kein Datenformat. Beide Anwendungen müssen die Bedeutung der Bytes vereinbaren.

2. QoS beschreibt Protokollzustellung

MQTT definiert QoS 0 als höchstens einmal, QoS 1 als mindestens einmal und QoS 2 als exakt einmal auf Protokollebene. Höhere Stufen brauchen mehr Zustand und Bestätigungen.

Publisher–Broker und Broker–Subscriber sind getrennte Abschnitte. Eine Bestätigung beweist keine Datenbankänderung oder Geräteaktion beim Empfänger. Fachliche Wiederholungen brauchen gegebenenfalls eigene Identität und Duplikatbehandlung.

3. Eine Retained Message ist aktueller Wert, keine Historie

Bei einer Retained-Veröffentlichung kann der Broker den letzten entsprechenden Wert eines Topics speichern und späteren passenden Abonnenten nach den Protokollregeln liefern. Ein neues Dashboard erhält so einen Zustandswert.

Das ist kein Log aller Temperaturmessungen. Ein sofort nach Abonnement erhaltener Wert kann gespeicherter Zustand statt frischer Messung sein. Die Anwendung muss seine weitere Brauchbarkeit beurteilen.

4. Sitzungen und Wills behandeln Verbindungsänderungen

Sitzungsregeln bestimmen, welcher Abonnement- und Zustellzustand eine Trennung überlebt. Eine dauerhafte Sitzung betrifft einen Client; eine Retained Message betrifft den gespeicherten Topicwert. Das sind verschiedene Mechanismen.

Ein Last Will lässt den Broker bei unerwartetem Verbindungsende unter den Protokollbedingungen eine konfigurierte Nachricht senden. Das ist ein Signal, kein sicherer Beweis eines ausgeschalteten Geräts. Netzverlust, Erkennungsdauer und Sitzungsregeln beeinflussen das Ergebnis.

Ein kleines Beispiel

Optional: Starte Block eins in Terminal A und während seiner Wartezeit Block zwei in Terminal B, innerhalb von dreißig Sekunden. Nutze ausschließlich das eigene Testtopic auf dem laufenden Broker.

mosquitto_sub -h localhost -p 1883 -t 'lab/temperature' -q 1 -v -C 1 -W 30

mosquitto_pub -h localhost -p 1883 -t 'lab/temperature' -q 1 -m '21.5'

Terminal A sollte Topic und 21.5 zeigen und beenden. Wurde vor Bereitschaft des Abonnements gesendet, wiederhole mit zuerst gestarteten Subscriber. Ein Timeout beweist keine Ablehnung durch den Broker.

Der Publisher erzeugt keinen Retained-Wert. Ein erst später gestarteter Subscriber erhält diese Probe deshalb nicht allein wegen ihrer früheren Veröffentlichung. QoS 1 erlaubt Duplikate; hier endet der Empfang nach einer Nachricht. Offline-Zustellung und Geräteaktion sind nicht geprüft. Ein Retained-Wert muss nicht gelöscht werden.

Merke dir: MQTT verteilt Topicnachrichten über einen Broker. Zustellqualität, gespeicherter Zustand und Anwendungswirkung sind verschiedene Garantien.