MQTT ist das Nachrichtenprotokoll, das einen riesigen Teil der vernetzten Welt still antreibt — von Smart-Home-Sensoren über Industriemaschinen bis zu Millionen von IoT-Geräten. Es ist leichtgewichtig, elegant und, sobald der Groschen fällt, überraschend einfach. Dieser Leitfaden setzt voraus, dass Sie nichts darüber wissen. Am Ende verstehen Sie nicht nur, wie MQTT bis ins Detail funktioniert — Sie haben einen echten Broker betrieben, live Nachrichten gesendet und empfangen, funktionierenden Python-Code geschrieben und einen physischen Sensor angebunden. Mit anderen Worten: Sie können selbst ein echtes MQTT-Projekt bauen.

Was MQTT wirklich ist

MQTT (Message Queuing Telemetry Transport) ist ein Protokoll, um kleine Nachrichten zwischen Geräten über ein Netzwerk zu senden. Es wurde für Situationen entworfen, in denen Bandbreite knapp, Verbindungen unzuverlässig und Geräte klein und stromsparend sind — genau die Bedingungen des Internets der Dinge. Statt dass jedes Gerät direkt mit jedem anderen spricht, führt MQTT ein zentrales Postamt ein, mit dem sich alle verbinden. Diese eine Idee macht alles Weitere einfach.

Die große Idee: Publish und Subscribe

Die meisten lernen zuerst das Modell des Webs: Ein Client fragt einen Server nach etwas und bekommt eine Antwort (Request/Response). MQTT funktioniert anders. Es nutzt Publish/Subscribe:

  • Ein Gerät mit einer Information veröffentlicht sie (publish), versehen mit einem Betreff.
  • Ein Gerät, das eine Information will, abonniert diesen Betreff (subscribe).
  • Keiner muss wissen, dass der andere existiert.

Stellen Sie sich einen Radiosender vor. Der Sender sendet auf einer Frequenz; wer darauf eingestellt ist, hört ihn. Der Sender weiß nicht und kümmert sich nicht darum, wer zuhört. Diese Entkopplung ist MQTTs Superkraft: Sie können neue Geräte hinzufügen, die vorhandene Daten hören, oder neue Sensoren, die neue Daten veröffentlichen, ohne etwas zu ändern, das bereits läuft.

Die drei Rollen: Broker, Publisher, Subscriber

  • Der Broker ist das zentrale Postamt. Jede Nachricht läuft durch ihn. Er empfängt alles, was Publisher senden, und liefert es an die richtigen Subscriber. Bekannte Broker sind Mosquitto, EMQX und HiveMQ.
  • Ein Publisher ist jeder Client, der eine Nachricht sendet.
  • Ein Subscriber ist jeder Client, der Nachrichten zu bestimmten Betreffen empfangen möchte.

Entscheidend: Dasselbe Gerät ist meist beides: Ein smartes Thermostat veröffentlicht die Temperatur und abonniert Befehle. "Publisher" und "Subscriber" beschreiben, was ein Client gerade tut, nicht was er dauerhaft ist.

Topics: die Adresse jeder Nachricht

Jede Nachricht in MQTT trägt ein Topic — eine einfache Textzeichenkette, die wie ein Ordnerpfad wirkt. Zum Beispiel:

home/livingroom/temperature
home/kitchen/humidity
factory/line1/motor/current

Die Schrägstriche bilden eine Hierarchie. Ein Publisher sendet einen Wert an ein Topic; ein Subscriber bittet den Broker um alle Nachrichten eines Topics. Gutes Topic-Design ist ein Zeichen eines professionellen MQTT-Projekts: eine klare, konsistente Struktur von allgemein zu speziell (Ort, dann Gerät, dann Messgröße), klein geschrieben und nie mit führendem Schrägstrich. Ein gut entworfener Topic-Baum macht ein System über Jahre verständlich und erweiterbar.

Wildcards: viele Topics auf einmal abonnieren

Sie müssen nicht jedes Topic einzeln abonnieren. MQTT bietet zwei Platzhalter:

  • + passt auf genau eine Ebene. home/+/temperature empfängt die Temperatur aus jedem Raum.
  • # passt auf alles unterhalb eines Punktes. home/# empfängt jede Nachricht irgendwo unter "home".

Wildcards gelten nur fürs Abonnieren, nie fürs Veröffentlichen — Sie publizieren immer auf genau ein Topic. Dieses einfache System lässt ein Dashboard mit einem einzigen Abonnement einer ganzen Fabrik zuhören.

Der Payload: was Sie tatsächlich senden

Der Inhalt einer Nachricht heißt Payload. MQTT ist es gleichgültig, was darin steht — es kann eine Zahl, ein Wort oder ein strukturiertes Format wie JSON sein. Für eine Temperatur senden Sie vielleicht 22.5; für etwas Reicheres {"temp": 22.5, "unit": "C"}. Payloads klein und konsistent zu halten ist gute Praxis, besonders auf ressourcenarmen Geräten.

Quality of Service (QoS): wie sehr MQTT sich anstrengt

Netzwerke verlieren Nachrichten. MQTT lässt Sie pro Nachricht wählen, wie viel Aufwand in die Zustellung fließt, mit drei Stufen:

  • QoS 0 — "höchstens einmal": abschicken und vergessen. Am schnellsten und leichtesten, aber eine Nachricht kann verloren gehen. Perfekt für häufige Sensorwerte, bei denen der nächste ohnehin bald kommt.
  • QoS 1 — "mindestens einmal": die Nachricht kommt garantiert an, könnte aber doppelt ankommen. Ein guter Standard für wichtige Daten, bei denen ein seltenes Duplikat harmlos ist.
  • QoS 2 — "genau einmal": garantiert genau einmal, mit mehr Handshaking. Nutzen Sie es, wenn Duplikate echte Probleme verursachen würden, etwa ein Abrechnungsereignis oder ein kritischer Befehl.

Höheres QoS kostet mehr Bandbreite und Zeit. Für jede Nachricht die richtige Stufe zu wählen, kennzeichnet einen Ingenieur, der das Protokoll versteht, statt es nur zu benutzen.

Retained Messages: der letzte bekannte Wert

Normalerweise hören Sie, wenn Sie ein Topic abonnieren, nur Nachrichten, die nach dem Abonnieren gesendet werden. Manchmal aber braucht ein neuer Subscriber sofort den aktuellen Zustand — die letzte Temperatur oder ob eine Maschine an ist. Markiert ein Publisher eine Nachricht als retained, speichert der Broker diese eine Nachricht und gibt sie jedem künftigen Subscriber sofort. Es ist der Unterschied zwischen "sag es mir ab jetzt" und "sag mir den aktuellen Wert in dem Moment, in dem ich mich verbinde".

Last Will and Testament: erkennen, wann ein Gerät stirbt

Was passiert, wenn ein Gerät den Strom verliert oder die Verbindung still abbricht? MQTT hat eine elegante Antwort: das Last Will and Testament (LWT). Beim Verbinden kann ein Client dem Broker eine Nachricht übergeben, die dieser an seiner Stelle veröffentlicht, falls er unerwartet die Verbindung verliert — etwa offline an ein Status-Topic. So erkennt der Rest des Systems ein ausgefallenes Gerät automatisch, ganz ohne Abfragen. Es ist eines der am meisten unterschätzten Merkmale von MQTT.

Keep-Alive und Sessions

Um eine stille Trennung zu bemerken, vereinbart jeder Client ein Keep-Alive-Intervall mit dem Broker und sendet darin ein winziges "Ping"; hört der Broker nichts, gilt der Client als weg (und das LWT wird ausgelöst). Sessions steuern das Gedächtnis: Mit einer persistenten Session merkt sich der Broker die Abonnements eines Clients und puffert Nachrichten, während dieser kurz offline ist; mit einer Clean Session beginnt jedes Mal alles neu. Hier richtig zu wählen sorgt dafür, dass ein Gerät sich nach einem Netzaussetzer sauber wieder verbindet.

Sicherheit: niemals überspringen

Standardmäßig ist eine einfache MQTT-Verbindung unverschlüsselt und ohne Authentifizierung — in Ordnung zum Lernen, inakzeptabel für ein echtes Produkt. Ein professioneller Einsatz ergänzt immer:

  • TLS-Verschlüsselung, damit niemand den Verkehr lesen oder manipulieren kann (MQTT über TLS nutzt typischerweise Port 8883).
  • Authentifizierung mit Benutzername/Passwort oder, besser, Client-Zertifikaten, damit sich nur vertraute Geräte verbinden.
  • Zugriffskontrolle (ACLs), damit jedes Gerät nur die Topics veröffentlichen und abonnieren darf, die ihm erlaubt sind.

Sicherheit von Anfang an als Teil des Designs zu behandeln — nicht als Nachgedanke — unterscheidet genau ein Bastelprojekt von einem System, auf das sich ein Unternehmen verlassen kann.

Den Broker wählen

Der Broker ist das Herz des Systems. Zum Lernen und für kleine Projekte ist Mosquitto kostenlos, leicht und überall. Für größere oder kommerzielle Systeme skalieren EMQX und HiveMQ auf Millionen Verbindungen und bieten Clustering und Verwaltungswerkzeuge. Cloud-Anbieter bieten ebenfalls gehostetes MQTT. Fangen Sie einfach an; das Schöne an MQTT ist, dass sich Ihr Code kaum ändert, wenn Sie später auf einen größeren Broker umziehen.

Praxis, Teil 1: einen Broker betreiben und per Kommandozeile mit ihm sprechen

Machen wir es konkret. Installieren Sie Mosquitto (es enthält den Broker und zwei Kommandozeilen-Werkzeuge, mosquitto_pub und mosquitto_sub). Öffnen Sie danach zwei Terminalfenster.

Im ersten Terminal ein Topic abonnieren und warten:

mosquitto_sub -h localhost -t "home/livingroom/temperature"

Im zweiten Terminal einen Wert auf dasselbe Topic veröffentlichen:

mosquitto_pub -h localhost -t "home/livingroom/temperature" -m "22.5"

Die Zahl 22.5 erscheint sofort im ersten Terminal. Sie haben gerade Ihre erste MQTT-Nachricht gesendet. Probieren Sie ein Wildcard-Abonnement, um die Kraft der Topics zu sehen:

mosquitto_sub -h localhost -t "home/#" -v

(Das -v gibt auch das Topic aus, sodass Sie genau sehen, was wo ankommt.) Wollen Sie noch keinen Broker installieren, ersetzen Sie localhost durch den kostenlosen öffentlichen Test-Broker test.mosquitto.org.

Praxis, Teil 2: mit Python veröffentlichen und abonnieren

Kommandozeilen-Werkzeuge sind super zum Testen, doch echte Projekte brauchen Code. Die Standard-Python-Bibliothek ist paho-mqtt. Installieren Sie sie mit pip install paho-mqtt. Hier ein vollständiger Subscriber, der jede empfangene Temperatur ausgibt:

import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected, result:", reason_code)
    client.subscribe("home/livingroom/temperature")

def on_message(client, userdata, msg):
    print(msg.topic, "->", msg.payload.decode())

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_connect = on_connect
client.on_message = on_message

client.connect("localhost", 1883, keepalive=60)
client.loop_forever()

Und hier ein vollständiger Publisher, der alle fünf Sekunden einen neuen Wert sendet:

import paho.mqtt.client as mqtt
import time

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.connect("localhost", 1883, keepalive=60)
client.loop_start()

while True:
    temperature = 22.5
    client.publish("home/livingroom/temperature", str(temperature))
    print("published", temperature)
    time.sleep(5)

Starten Sie den Subscriber, dann den Publisher, und Sie sehen live Daten zwischen zwei Programmen durch den Broker fließen. Das ist im Kleinen genau, wie große IoT-Systeme arbeiten.

Praxis, Teil 3: ein echter Sensor mit einem ESP32

Jetzt der spannende Teil — ein physisches Gerät. Ein ESP32-Mikrocontroller mit WLAN kann echte Sensordaten an denselben Broker veröffentlichen. Mit der beliebten Arduino-Bibliothek PubSubClient sieht der Kern so aus:

#include <WiFi.h>
#include <PubSubClient.h>

WiFiClient espClient;
PubSubClient client(espClient);

void setup() {
  WiFi.begin("your-wifi-name", "your-wifi-password");
  client.setServer("192.168.1.10", 1883);   // IP Ihres Brokers
}

void loop() {
  if (!client.connected()) {
    client.connect("esp32-livingroom");      // eindeutige Client-ID
  }
  client.loop();

  float temperature = readTemperature();     // Ihr Sensor-Code
  client.publish("home/livingroom/temperature",
                 String(temperature).c_str());
  delay(5000);
}

In dem Moment, in dem das läuft, empfängt der Python-Subscriber aus Teil 2 — oder ein Dashboard oder eine Datenbank — echte Temperaturen von echter Hardware, ganz ohne Änderung auf der Empfängerseite. Das ist die Entkopplung von Publish/Subscribe, die genau wie beabsichtigt funktioniert.

Alles zusammen: die Architektur eines echten Projekts

Sie haben nun jedes Teil für eine echte Anwendung. Ein typisches MQTT-Projekt sieht so aus:

  • Geräte (ESP32s, Industriesensoren) veröffentlichen Werte auf gut benannte Topics.
  • Ein Broker (Mosquitto oder EMQX), mit TLS und Authentifizierung gesichert, leitet alles.
  • Ein Backend-Dienst abonniert die Daten und schreibt sie in eine Datenbank (oft eine Zeitreihen-Datenbank).
  • Ein Dashboard abonniert ebenfalls und zeigt Live-Werte und Diagramme.
  • Befehle fließen andersherum: Das Dashboard veröffentlicht auf ein Befehls-Topic, und Geräte abonnieren es — dasselbe Protokoll, umgekehrt.

Jedes Konzept dieses Leitfadens — Topics, QoS, Retained Messages, LWT, Sicherheit — hat eine klare Rolle in dieser Architektur. Zu verstehen, wie sie zusammenpassen, ist der Unterschied zwischen dem Zusammenstecken einer Demo und dem Entwickeln eines Systems, das jahrelang zuverlässig läuft.

Best Practices und häufige Fehler

  • Entwerfen Sie Ihren Topic-Baum bewusst, bevor Sie Code schreiben; er ist später schwer zu ändern.
  • Passen Sie QoS an die Daten an — nicht alles "sicherheitshalber" auf QoS 2; das verschwendet Ressourcen.
  • Geben Sie jedem Client eine eindeutige ID; zwei Clients mit gleicher ID trennen sich ständig gegenseitig.
  • Nutzen Sie Retained Messages für Zustände, nicht für Ströme häufiger Messwerte.
  • Gehen Sie nie ohne TLS und Authentifizierung in Betrieb.
  • Verwenden Sie das Last Will, damit Ihr System stets weiß, welche Geräte leben.

Wie es weitergeht

Sie verstehen MQTT nun von der Grundidee bis zu einem funktionierenden, gesicherten Projekt und haben es auf der Kommandozeile, in Python und auf echter Hardware betrieben. Die natürlichen nächsten Schritte sind: TLS an Ihrem Broker aktivieren, Payloads als JSON strukturieren, Daten in einer Datenbank speichern und ein Live-Dashboard darauf aufbauen. Jeder dieser Schritte baut direkt auf dem Fundament auf, das Sie jetzt haben.

MQTT ist täuschend einfach zu beginnen und tief zu meistern — und Architektur, QoS-Strategie und Sicherheit über eine echte Geräteflotte richtig zu machen, ist genau die Arbeit, die ich täglich tue. Wenn Sie ein IoT- oder Industriesystem bauen und es von der ersten Nachricht bis zur vollen Plattform sauber entwickelt haben möchten, nehmen Sie Kontakt auf — ich helfe Ihnen gern.