MQTT begegnet dir häufig, sobald du dich mit Smart Home, Sensoren oder kleinen IoT-Projekten beschäftigst. Hinter dem kurzen Namen steckt ein Nachrichtenprotokoll, mit dem Geräte und Programme Daten austauschen können, ohne direkt miteinander verbunden sein zu müssen.
Ein Temperatursensor kann beispielsweise regelmäßig seinen Messwert senden. Eine Hausautomation empfängt diesen Wert und entscheidet anschließend, ob eine Heizung eingeschaltet werden soll. MQTT kümmert sich dabei um den Transport der Nachrichten zwischen den beteiligten Geräten.
Das Grundprinzip ist deutlich einfacher, als viele Fachbegriffe zunächst vermuten lassen. Wenn du Broker, Clients und Topics verstanden hast, kennst du bereits die wichtigsten Bausteine.
Was ist MQTT?
MQTT ist ein standardisiertes Nachrichtenprotokoll und wird vor allem für das Internet der Dinge, kurz IoT, eingesetzt. Es arbeitet nach dem Publish/Subscribe-Prinzip und wurde so konzipiert, dass Geräte mit vergleichsweise geringem Datenverkehr miteinander kommunizieren können. MQTT ist ein OASIS-Standard; die offiziellen MQTT-Spezifikationen führen MQTT 5.0 als aktuelle Version.
Für die Übertragung setzt MQTT in typischen Netzwerken auf TCP/IP.
Ein entscheidender Unterschied zu vielen anderen Kommunikationsverfahren besteht darin, dass Sender und Empfänger keine direkte Verbindung zueinander benötigen. Beide kommunizieren mit einer zentralen Stelle, dem sogenannten MQTT-Broker.
Der Broker nimmt Nachrichten entgegen und verteilt sie an die passenden Empfänger. Dadurch muss ein Sensor beispielsweise nicht wissen, welche Programme seinen Temperaturwert benötigen.
MQTT legt dabei nicht fest, was eine Nachricht enthalten muss. Ein Messwert kann als einfache Zahl übertragen werden, während andere Anwendungen Texte, JSON-Daten oder binäre Inhalte verwenden. Für den Broker zählt in erster Linie, unter welchem Topic die Nachricht veröffentlicht wurde.
So funktioniert MQTT mit Broker, Publisher und Subscriber
Bei MQTT tauchen drei Begriffe besonders häufig auf: Broker, Publisher und Subscriber. Hinter diesen Bezeichnungen stecken recht einfache Aufgaben.
Der Broker ist die zentrale Vermittlungsstelle. Alle MQTT-Clients verbinden sich mit ihm. Er nimmt Nachrichten entgegen und prüft, welche verbundenen Clients diese Nachrichten erhalten sollen.
Ein Publisher veröffentlicht eine Nachricht. Das könnte beispielsweise ein Temperatursensor sein, der den Wert 22.4 sendet.
Ein Subscriber hat ein bestimmtes Thema abonniert und bekommt passende Nachrichten vom Broker zugestellt. Ein Client kann gleichzeitig Publisher und Subscriber sein. Eine Smart-Home-Zentrale kann also Sensordaten empfangen und selbst Steuerbefehle veröffentlichen.
Ein vereinfachtes Beispiel sieht so aus:
- Ein Temperatursensor verbindet sich mit dem MQTT-Broker.
- Die Hausautomation verbindet sich ebenfalls mit dem Broker.
- Die Hausautomation abonniert das Topic
haus/wohnzimmer/temperatur. - Der Sensor veröffentlicht unter diesem Topic den Wert
22.4. - Der Broker leitet die Nachricht an die Hausautomation weiter.
Der Sensor kennt die Adresse der Hausautomation nicht. Er weiß auch nicht, wie viele andere Clients den Temperaturwert abonniert haben. Genau diese Trennung macht das Publish/Subscribe-Prinzip für viele Automatisierungsaufgaben praktisch.
Topics: So sortiert MQTT seine Nachrichten
Topics kannst du dir als Namen oder Pfade vorstellen, unter denen Nachrichten veröffentlicht werden. Sie sorgen dafür, dass der Broker weiß, welche Nachricht zu welchem Abonnement gehört.
Eine sinnvolle Topic-Struktur für ein Smart Home könnte beispielsweise so aussehen:
haus/wohnzimmer/temperatur
haus/wohnzimmer/licht
haus/keller/luftfeuchtigkeit
Der Schrägstrich trennt einzelne Ebenen voneinander. Wie du deine Topics aufbaust, bestimmt deine Anwendung selbst. MQTT schreibt keine feste Struktur wie haus/raum/gerät vor.
Groß- und Kleinschreibung spielen eine Rolle. haus/wohnzimmer/licht und Haus/Wohnzimmer/Licht sind aus Sicht von MQTT unterschiedliche Topics.
Bei einem Abonnement kannst du auch Platzhalter verwenden. Das Pluszeichen + steht für genau eine Topic-Ebene. Ein Abonnement auf
haus/+/temperatur
kann damit beispielsweise Temperaturwerte aus verschiedenen Räumen erfassen.
Das Doppelkreuz # umfasst dagegen mehrere nachfolgende Ebenen. Mit
haus/#
lassen sich alle passenden Topics unterhalb von haus abonnieren. Diese Platzhalter werden nur in Topic-Filtern für Abonnements verwendet, nicht in den Namen veröffentlichter Nachrichten.
Eine saubere Topic-Struktur lohnt sich schon bei kleinen Projekten. Namen wie sensor1 funktionieren zwar, werden aber unübersichtlich, sobald weitere Geräte hinzukommen.
QoS: Wie zuverlässig sollen MQTT-Nachrichten ankommen?
MQTT kennt drei Quality-of-Service-Stufen, meist nur QoS genannt. Sie bestimmen, mit welchem Aufwand eine Nachricht zwischen Sender und Empfänger übertragen wird.
| QoS | Bedeutung | Typischer Einsatz |
|---|---|---|
| 0 | Nachricht wird höchstens einmal gesendet | Regelmäßige Sensordaten |
| 1 | Nachricht kommt mindestens einmal an, Duplikate sind möglich | Wichtige Zustandsmeldungen |
| 2 | Nachricht wird genau einmal zugestellt | Fälle, bei denen Duplikate vermieden werden müssen |
QoS 0 verursacht den geringsten Aufwand. Eine Nachricht wird versendet, aber nicht bestätigt. Geht sie unterwegs verloren, erfolgt auf dieser MQTT-Ebene keine erneute Zustellung. Bei einem Temperatursensor ist das häufig kein Problem, weil kurze Zeit später bereits der nächste Messwert folgt.
QoS 1 arbeitet mit einer Bestätigung. Dadurch wird sichergestellt, dass die Nachricht mindestens einmal beim jeweiligen Empfänger ankommt. Unter bestimmten Umständen kann dieselbe Nachricht jedoch mehrmals eintreffen.
QoS 2 verwendet einen aufwendigeren Bestätigungsablauf und verhindert eine doppelte Zustellung auf dieser Übertragungsstrecke. Dafür entstehen mehr Datenverkehr und zusätzliche Verarbeitungsschritte.
Für viele Anwendungen im privaten Smart Home reichen QoS 0 und QoS 1 aus. QoS 2 würde ich nur verwenden, wenn eine Anwendung diese Zustellgarantie tatsächlich benötigt.
Retained Messages: Den letzten Zustand speichern
Ein Subscriber bekommt normalerweise Nachrichten, die veröffentlicht werden, während sein Abonnement besteht. Das kann ungünstig sein, wenn ein Client direkt nach dem Verbindungsaufbau den aktuellen Zustand eines Geräts benötigt.
Dafür gibt es Retained Messages. Setzt ein Publisher beim Senden das Retain-Kennzeichen, speichert der Broker die betreffende Nachricht für dieses Topic. Ein neuer Subscriber kann dadurch sofort den zuletzt gespeicherten Wert erhalten.
Das eignet sich beispielsweise für Zustände wie:
- aktuelle Raumtemperatur
- Ein/Aus-Zustand einer Lampe
- letzter bekannter Betriebszustand eines Geräts
- Verfügbarkeit eines Dienstes
Retained Messages solltest du gezielt einsetzen. Der gespeicherte Wert bleibt auf dem Broker vorhanden, bis er durch eine neue retained Nachricht ersetzt oder entsprechend gelöscht wird.
Last Will: Wenn ein Gerät plötzlich verschwindet
Ein MQTT-Client kann dem Broker beim Verbindungsaufbau eine sogenannte Will Message übergeben. Oft findest du dafür auch die Bezeichnungen Last Will oder Last Will and Testament.
Diese Nachricht ist für unerwartete Verbindungsabbrüche gedacht. Verschwindet ein Gerät plötzlich aus dem Netzwerk, kann der Broker die zuvor hinterlegte Nachricht veröffentlichen. Andere Clients erfahren dadurch beispielsweise, dass ein Sensor nicht mehr erreichbar ist.
Ein mögliches Topic wäre:
haus/keller/sensor/status
Während des normalen Betriebs könnte dort online stehen. Fällt der Sensor unerwartet aus, veröffentlicht der Broker seine hinterlegte Will Message mit dem Zustand offline.
Gerade bei Automatisierungen ist das nützlich. Ein System kann dadurch unterscheiden, ob ein Gerät tatsächlich einen bestimmten Zustand meldet oder überhaupt nicht mehr erreichbar ist.
Wo MQTT im Heimnetz sinnvoll ist
MQTT spielt seine Vorteile besonders dort aus, wo mehrere Geräte oder Programme regelmäßig kleine Informationen austauschen.
Typische Anwendungen sind:
- Übertragung von Temperatur-, Feuchtigkeits- oder Stromverbrauchswerten
- Austausch von Gerätezuständen im Smart Home
- Steuerbefehle für Lampen, Relais oder andere Aktoren
- Verbindung verschiedener Automatisierungsprogramme und eigener Projekte
Ein weiterer Vorteil zeigt sich, wenn später neue Empfänger hinzukommen. Der Temperatursensor muss nicht verändert werden, nur weil neben der Hausautomation nun auch ein Programm zur Aufzeichnung der Messwerte das gleiche Topic abonnieren soll.
Für eine normale Dateiübertragung oder das Streamen großer Mediendateien ist MQTT dagegen nicht gedacht. Sein Schwerpunkt liegt auf Nachrichten und Zustandsinformationen zwischen Anwendungen und Geräten.
Was du für einen Einstieg in MQTT brauchst
Für einen einfachen Test benötigst du keinen umfangreichen Gerätepark. Zwei Bestandteile reichen bereits aus: einen Broker und mindestens einen MQTT-Client.
Der Broker kann je nach eingesetzter Software beispielsweise auf einem PC, einem kleinen Heimserver, einem NAS oder einem Einplatinencomputer laufen. Es gibt auch Broker im Internet. Für ein dauerhaftes Smart-Home-System würde ich einen lokalen Broker im eigenen Heimnetz bevorzugen, sofern kein Zugriff über einen externen Dienst benötigt wird.
Als Client eignet sich eine MQTT-Anwendung auf deinem Windows-PC. Damit kannst du dich mit dem Broker verbinden, Topics abonnieren und selbst Testnachrichten veröffentlichen. Für erste Versuche ist es hilfreich, zwei Client-Instanzen zu verwenden: Eine sendet Nachrichten, die andere empfängt sie.
Auch zahlreiche Smart-Home-Geräte und Automatisierungsprogramme können selbst als MQTT-Client auftreten. Ob ein bestimmtes Gerät MQTT unterstützt, hängt jedoch vom Hersteller und von der verwendeten Software ab.
MQTT sicher betreiben
Eine MQTT-Verbindung ist nicht automatisch verschlüsselt. Für eine geschützte Übertragung kann MQTT über TLS betrieben werden. Im Portregister der IANA sind TCP-Port 1883 für MQTT und TCP-Port 8883 für Secure MQTT registriert. Ein Broker kann jedoch auch andere Ports verwenden. Ein Broker kann jedoch auch andere Ports verwenden.
Clients können sich je nach Broker und Konfiguration authentifizieren. MQTT unterstützt unter anderem die Übermittlung von Anmeldeinformationen beim Verbindungsaufbau. Welche Rechte ein Benutzer anschließend für bestimmte Topics besitzt, wird durch die jeweilige Broker-Konfiguration geregelt.
Für ein privates Heimnetz würde ich mindestens folgende Punkte berücksichtigen:
- keinen frei erreichbaren Broker ohne Zugangsschutz ins Internet stellen
- getrennte Benutzerkonten verwenden, wenn mehrere Geräte unterschiedliche Rechte benötigen
- Schreib- und Leserechte auf die benötigten Topics begrenzen
- bei Verbindungen über nicht vertrauenswürdige Netze TLS verwenden
- Broker und Client-Software aktuell halten
Ein MQTT-Broker muss für ein typisches Smart Home häufig gar nicht direkt aus dem Internet erreichbar sein. Bleibt die gesamte Kommunikation im lokalen Netzwerk, lässt sich die Angriffsfläche deutlich kleiner halten.
MQTT 3.1.1 oder MQTT 5.0?
Bei Software und Geräten wirst du hauptsächlich auf MQTT 3.1.1 und MQTT 5.0 stoßen. MQTT.org führt Version 5.0 als aktuelle Spezifikation, während 3.1.1 als ältere Standardversion aufgeführt wird.
MQTT 5.0 behält das Grundprinzip der vorherigen Version bei, erweitert das Protokoll aber unter anderem um bessere Fehlerrückmeldungen und zusätzliche Eigenschaften für Nachrichten und Verbindungen.
Für den Einstieg musst du diese Unterschiede nicht im Detail kennen. Entscheidend ist zunächst, dass Broker und Clients dieselbe Version unterstützen. Wenn du ein neues Projekt aufsetzt und alle beteiligten Komponenten MQTT 5.0 beherrschen, würde ich diese Version bevorzugen.
Fazit: MQTT ist einfacher, als es zunächst aussieht
MQTT besteht im Kern aus einem gut nachvollziehbaren Prinzip: Clients veröffentlichen Nachrichten unter bestimmten Topics, andere Clients abonnieren diese Topics, und der Broker übernimmt die Verteilung.
Mit QoS kannst du die gewünschte Zustellsicherheit beeinflussen. Retained Messages speichern den letzten bekannten Zustand, während eine Last-Will-Nachricht dabei hilft, unerwartet ausgefallene Clients zu erkennen.
Für Smart Home, Sensoren und eigene IoT-Projekte ist MQTT deshalb eine praktische Lösung. Für den Einstieg würde ich mit einem lokalen Broker und einem einfachen MQTT-Client beginnen und zunächst mit wenigen Topics experimentieren. Damit lässt sich das Zusammenspiel schnell nachvollziehen, ohne gleich ein komplettes Automatisierungssystem aufbauen zu müssen.
Wofür möchtest du MQTT in deinem Heimnetz einsetzen, und welche Geräte oder Programme sollen dabei Nachrichten miteinander austauschen?
