Liebe Leser, im Internet of Things (IoT) gibt es verschiedene Protokolle, über die Geräte Daten austauschen. Eines der bekanntesten und im Smart-Home-Umfeld am häufigsten genutzten ist MQTT (Message Queuing Telemetry Transport). Viele Systeme wie ioBroker, openHAB, Home Assistant und Node-RED sprechen MQTT nativ oder per Add-on. In diesem Beitrag erklären wir MQTT verständlich, zeigen die wichtigsten Begriffe (Broker, Client, Topics, QoS) und richten anschließend einen MQTT-Broker mit Mosquitto ein – optional auf einem Raspberry Pi. Im nächsten Teil folgen einfache Praxisbeispiele mit Microcontrollern.
Voraussetzung für diesen Blog
Zur Veranschaulichung nutze ich einen Raspberry Pi 4 mit frisch installiertem Raspberry Pi OS. In Tabelle 1 habe ich einmal grob die Bauteile zusammengefasst, jedoch kann MQTT auch auf einem (Linux-basierten) Betriebssystem deiner Wahl unkompliziert eingerichtet werden.
Tabelle 1: Benötigte Hardware
| Pos. | Menge | Bauteil |
|---|---|---|
| 1 | 1 | Raspberry Pi (Modell egal) |
| 2 | 1 | Passendes Netzteil für den Raspberry Pi |
| 3 | 1 | Je nach Raspberry-Pi-Modell ein LAN-Kabel |
Tatsächlich ist bei dem Raspberry Pi das Modell egal, sofern man MQTT direkt installiert und nicht z. B. Docker dafür verwenden möchte! Der MQTT-Broker ist so sparsam, dass er nur wenig Ressourcen vom ausführenden System benötigt. Bei Nutzung von MQTT mit Docker ist mindestens ein Raspberry Pi 3B oder höher nötig!
Was ist MQTT?
MQTT steht für Message Queuing Telemetry Transport und ist auch noch unter dem älteren Namen WebSphere MQTT (WSMQTT) bekannt. Dabei handelt es sich um ein offenes Netzwerkprotokoll für eine Machine-to-Machine-Kommunikation, um z. B. Daten von Sensoren zu übermitteln und/oder Aktoren zu steuern. Teilweise wird es für IoT-Geräte auch dafür verwendet, um den aktuellen Status mitzuteilen.
MQTT wurde ursprünglich dafür entwickelt, dass die Übertragung auch in instabilen oder eingeschränkten Netzen funktioniert (z. B. hohe Latenz, Paketverlust, wenig Bandbreite) und Clients mit wenig Energieverbrauch zuverlässig kommunizieren können. Heute ist genau das im IoT weiter relevant – nicht weil WLAN „wie früher“ grundsätzlich schlecht wäre, sondern weil viele Geräte auf Batteriebetrieb, Mobilfunk, Funkstrecken oder energiearme Microcontroller ausgelegt sind.
Ports: MQTT lauscht standardmäßig auf 1883 (unverschlüsselt). Der Port 8883 wird üblicherweise für TLS-verschlüsselte Verbindungen verwendet. Für alles, was über reines Testen im lokalen Netz hinausgeht, ist TLS die richtige Basis. Eine Anmeldung per Benutzername/Passwort ohne TLS schützt nicht vor Mitschnitt, weil die Zugangsdaten dabei im Klartext übertragen werden. Wenn du MQTT nach außen erreichbar machst, brauchst du mindestens TLS, Authentifizierung und Topic-ACLs – und du solltest Port-Forwarding ohne diese Maßnahmen nicht einsetzen.
Damit Sie MQTT benutzen können, braucht es einen MQTT-Server, den sogenannten Broker, sowie die entsprechenden Endgeräte, welche die Daten senden und/oder empfangen, auch Clients genannt. Meist findet sich der Broker auf einem Linux-basierten Betriebssystem. Windows-Betriebssysteme sind jedoch ebenfalls möglich.
Die hier genutzte Protokollversion 3.1.1 (und die vorherige Version 3.1) wurde von OASIS spezifiziert und ist in der Praxis nach wie vor sehr verbreitet. Seit 2019 gibt es außerdem MQTT 5.0 mit Erweiterungen wie Reason Codes, Message Expiry und zusätzlichen Properties. Die Grundlagen (Broker, Topics, Publish/Subscribe) bleiben gleich – die Beispiele in diesem Beitrag funktionieren aber bewusst ohne MQTT-5-spezifische Features, damit der Einstieg übersichtlich bleibt.
Wie funktioniert MQTT
MQTT nutzt die ereignisgesteuerte Publish/Subscribe-Architektur. Einfach erklärt melden sich alle Sender-/Empfängergeräte (Clients) beim Server (Broker) an. Um diese Verbindungen besser zu verstehen, soll Abbildung 1 dies in vereinfachter Form darstellen.
Ein Client, in Abbildung 1 z. B. der Sensor, kann Daten senden und/oder empfangen; der Broker dient als Informationspuffer und leitet die Daten an die Clients weiter. Damit der Client eine entsprechende Nachricht vom Broker empfangen kann, muss dieser beim Verbindungsaufbau oder während des Betriebs beim Broker die sogenannten Topics abonnieren. Will hingegen der Client Daten senden, so muss er lediglich ein Topic mit der entsprechenden Information angeben. Sollte der Topic bisher nicht vorhanden sein, wird dieser vom Broker einfach angelegt.
Ein Topic kannst du dir wie eine Art URL vorstellen, der den gewünschten Inhalt wiedergibt. Ein Topic für einen Temperatursensor im Wohnzimmer könnte die Messwerte auf Daheim/Erdgeschoss/Wohnzimmer/Temperatur veröffentlichen. Es handelt sich nicht um eine Adresse zu dem Sensor, sondern um den Zugriff auf die zuletzt übermittelten Sensordaten.
An der Stelle muss auch erwähnt werden, dass es bei der Nachricht selbst keine Vorgaben gibt. Es kann ein einfacher Wert übermittelt werden, aber auch Text oder JSON. Letzteres findet z. B. Anwendung, wenn man die aktuellen Shelly-Geräte der aktuellen Generation mit einem MQTT-Broker verbindet.
Datenaustausch mit dem Broker (QoS)
Wie anfangs erwähnt, war MQTT für instabile Netzwerke gedacht, weswegen es drei unterschiedliche Servicequalitäten (Quality of Service, QoS) gibt – eine Art Prüfsystem, das sich die versendete Nachricht bestätigen lässt.
- QoS 0: Nachricht wird genau einmal gesendet, Bestätigung wird ignoriert → keine Garantien.
- QoS 1 („mindestens einmal geliefert“): Sender wartet auf PUBACK; bei ausbleibender Bestätigung wird erneut gesendet → kann doppelt ankommen.
- QoS 2 („genau einmal“): langsamste Variante; zweistufige Bestätigungen (PUBREC → PUBREL → PUBCOMP), damit exakt eine Zustellung garantiert ist.
Wichtig: Der effektiv genutzte QoS ergibt sich immer aus dem niedrigeren QoS-Wert von Publisher und Subscriber. Wenn ein Subscriber nur QoS 0 abonniert, kommt die Nachricht bei ihm auch dann höchstens mit QoS 0 an – selbst wenn der Publisher QoS 2 sendet.
Daten vom Broker abonnieren
- Exaktes Topic: Daheim/Erdgeschoss/Wohnzimmer/Temperatur → nur genau dieses Topic.
- +-Wildcard: Daheim/+/+/Temperatur → Temperaturdaten für alle Zimmer auf jeder Etage.
- #-Wildcard: Daheim/Erdgeschoss/# → alle verfügbaren Informationen für das Erdgeschoss.
- Wurzel /#: abonniert wirklich alles (nicht empfohlen).
Zuletzt die Frage: Was passiert, wenn ein Sender nicht mehr sendet?
Dafür gibt es in MQTT zwei unterschiedliche Mechanismen, die oft verwechselt werden: Retained Messages und Last Will and Testament (LWT). Eine Retained Message ist die zuletzt als „retain“ markierte Nachricht eines Topics, die der Broker speichert und neuen Abonnenten sofort ausliefert (z. B. letzter Temperaturwert). LWT ist dagegen eine Willensnachricht, die ein Client beim Verbindungsaufbau hinterlegt und die der Broker nur dann veröffentlicht, wenn der Client unerwartet offline geht (z. B. „sensor/wohnzimmer/status = offline“).
Der Raspberry Pi wird zum Broker
Viele scheuen sich, persönliche Daten oder Heim-Steuerungsdaten im Internet (z. B. bei mqtt-dashboard.com) öffentlich zu machen. Ein kleiner lokaler Broker auf dem Raspberry Pi oder anderem Mini-Computer ist daher naheliegend. Ohne Docker ist das Modell egal; mit Docker empfehle ich mindestens einen Raspberry Pi 3B oder höher.
MQTT-Broker direkt installieren
Öffne das Terminal deines Raspberry Pis (siehe Abbildung 3) und gib danach die Befehle aus Code 1 ein.
Code 1: Raspberry Pi OS aktualisieren
sudo apt upgrade && sudo apt dist-upgradeDamit aktualisierst du erst einmal den Raspberry Pi und alle installierten Pakete. Danach gibst du den Befehl aus Code 2 ein, um den beliebten mosquitto-broker zu installieren.
Code 2: Mosquitto-Server installieren
sudo apt install mosquittoCode 3: Service von mosquitto bei Neustart vom Pi mit starten
sudo systemctl enable mosquitto.serviceDa der Daemon auf dem Pi bisher ggf. noch nicht läuft, starte ihn mit Code 4.
Code 4: mosquitto starten
sudo mosquitto -dAb diesem Punkt hast du einen lokalen, unverschlüsselten MQTT-Broker im Heimnetzwerk. Für Tests und lokale Smart-Home-Setups ist das als Einstieg ok. Sobald du den Broker über Portweiterleitung oder in fremden Netzen erreichbar machst, brauchst du TLS, Authentifizierung und Topic-ACLs. Ohne Portweiterleitung ist er von außen nicht erreichbar. Vergib dem Pi idealerweise eine feste IP-Adresse im Router.
MQTT-Broker mit Docker verwenden
Ob via Kommandozeile oder Portainer – beides funktioniert. Eine Erklärung zu Portainer findest du im Blogbeitrag Docker auf dem Raspberry Pi Basics. Als Image setze ich Eclipse Mosquitto ein.
Für die Verbindung braucht es eine mosquitto.conf (siehe Code 5).
Code 5: Konfiguration der mosquitto.conf
allow_anonymous true
listener 1883
persistence true
persistence_location /mosquitto/data/
Jetzt muss der Container aufgebaut werden. An dieser Stelle verwende ich keine Compose-File (in Portainer unter Stacks zu finden), sondern die Option Add Container in Portainer.
Im nächsten Schritt werden die Basisinformationen eingetragen:
Port-Mapping: 1883:1883 sowie 9002:9001 (weil bei mir Port 9001 bereits belegt war).
Name des Containers (in meinem Fall „mqtt“)
Image: eclipse-mosquitto:latest
Zum Schluss wird noch die Restart-Policy auf Always gestellt. Danach lässt sich der Container über den Button Deploy the container starten.
Nach kurzer Zeit sollte das Image heruntergeladen sein und der Container – wie hier im Beispiel – im Running-Status angezeigt werden. Ab diesem Zeitpunkt kann jeder Client im Heimnetz mit dem MQTT-Broker kommunizieren.
Wenn der Subscriber gestartet wird (Code 7), zeigt die Terminalausgabe zuerst die erfolgreiche Verbindung (Markierung 1). Danach sieht man, wie das Topic /# abonniert und der gewünschte QoS ausgehandelt wurde. Nach einiger Zeit erscheint zusätzlich der Ping-Request vom Broker (Markierung 2), der prüft, ob der Client noch online ist.
Daten an den Broker senden und empfangen
Nun wird es Zeit, Nachrichten an den Broker zu senden und zu empfangen. Dazu braucht es einen MQTT-Client, der über Code 6 installiert wird.
Code 6: Mosquitto-Client installieren
sudo apt install mosquitto-clientsAnschließend die Terminalbefehle mosquitto_sub (subscribe) und mosquitto_pub (publish) nutzen. Willst du tiefer einsteigen, hilft das Linux-Handbuch (man mosquitto_sub, man mosquitto_pub, man mosquitto).
Um umfangreich zu sehen, was der Subscriber im Hintergrund macht, und um alle Nachrichten zu empfangen, nutze Code 7. (Tipp: Für reale Setups bitte gezielte Topics abonnieren.)
Code 7: Subscriber auf Wurzelknoten lauschen lassen
mosquitto_sub -h IP-VOM-BROKER -d -q 2 -t /#Tabelle 2: Optionen des mosquitto-Subscriber
-h Hostname/IP des Brokers • -d Debug-Modus • -q gewünschter QoS • -t Topic • -p Port (falls abweichend)
Nach Eingabe von Code 7 zeigt die Ausgabe die erfolgreiche Verbindung (siehe Abbildung 11, Markierung 1). Später siehst du die Keep-Alive-Abfragen (Ping Request/Response).
Abbildung 11: Terminalausgabe von mosquitto_sub
(Alt-Text: „mosquitto_sub: CONNECT, SUBSCRIBE /#, QoS 2, Ping-Austausch“)
Als Nächstes senden wir mit dem Publisher eine erste Nachricht („Hello world“) an /test/testpub (Code 8).
Code 8: mosquitto_pub „Hello world“
mosquitto_pub -h IP-VOM-BROKER -d -q 2 -t /test/testpub -m "Hello world"Tabelle 3: Optionen des mosquitto-Publisher
-h Hostname/IP • -d Debug-Modus • -q QoS • -t Topic • -m Nachricht
Wie der QoS-2-Handshake dabei aussieht, zeigt Abbildung 12. Direkt danach schickt der Broker die neue Nachricht an den Subscriber, der alle Topics abonniert hat.
Abbildung 12: Terminalausgabe von mosquitto_pub und mosquitto_sub
(Alt-Text: „QoS-2-Verlauf: PUBLISH → PUBREC → PUBREL → PUBCOMP, Nachricht empfangen“)
Abschließende Worte und Ausblick
In diesem Beitrag wurde gezeigt:
- Was MQTT und das MQTT-Protokoll ist
- Was der Unterschied zwischen MQTT-Broker und MQTT-Client ist
- Wie die Kommunikation zwischen MQTT-Broker und MQTT-Client stattfindet
- Wie man auf einem Raspberry Pi mit und ohne Docker schnell einen MQTT-Broker erstellt
Sicherheit: Mit der aktuellen Basiskonfiguration kann sich jeder im Heimnetz verbinden. Mindestens Benutzer/Passwort setzen, besser zusätzlich TLS aktivieren. Gute Referenz: die Dokumentation von mosquitto.org.
Hinsichtlich des nächsten Beitrags zeige ich ein kleines Projekt mit verschiedenen MicroControllern, die mit dem MQTT-Broker kommunizieren und teilweise Daten liefern, aber auch auf abonnierte Nachrichten mit Aktoren reagieren. Das verdeutlicht noch einmal, wie MQTT im Wesentlichen funktioniert.
FAQ zu MQTT
Was ist der Vorteil von MQTT gegenüber HTTP?
MQTT ist deutlich schlanker, benötigt weniger Bandbreite und eignet sich besser für instabile Netzwerke. HTTP ist schwergewichtiger und nicht für dauerhafte Verbindungen optimiert.
Kann ich MQTT auch auf Windows installieren?
Ja. Es gibt Pakete und Clients für Windows, die genauso funktionieren. In der Praxis wird MQTT aber fast immer auf Linux-Systemen betrieben, weil es dort stabiler und ressourcenschonender läuft.
Ist MQTT sicher?
In der Standardkonfiguration nicht. Jeder kann sich im Heimnetz anmelden. Für den produktiven Einsatz unbedingt Benutzername/Passwort setzen und möglichst auch TLS-Verschlüsselung aktivieren.
Welche Hardware brauche ich für einen MQTT-Broker?
Ein Raspberry Pi reicht vollkommen aus – sogar ältere Modelle. Wer Docker nutzen möchte, sollte mindestens ein Modell ab 3B einsetzen. Alternativ läuft MQTT auch auf jedem anderen Linux-Server.
Welche IoT-Plattformen unterstützen MQTT?
Sehr viele: Home Assistant, ioBroker, openHAB, Node-RED, aber auch zahlreiche Cloud-Dienste und Smart-Home-Geräte (z. B. Shelly).
