Ein MQTT-Broker ist der zentrale Server, der jede MQTT-Nachricht empfängt und an die Clients ausliefert, die sie angefordert haben. In diesem Einsteigerleitfaden erfahren Sie, wie das Publish/Subscribe-Modell funktioniert, was ein MQTT-Broker im Hintergrund leistet, wie Topics und Wildcards aufgebaut sind, worin sich MQTT 3.1.1 und 5.0 unterscheiden und wie Sie Ihre ersten Nachrichten über die Kommandozeile und mit Python senden.
Was ist MQTT?
MQTT ist ein schlankes Messaging-Protokoll für Geräte mit begrenzter Bandbreite, Energie oder Rechenleistung. Es läuft über TCP (und für Browser über WebSocket), hat einen winzigen festen Header von nur zwei Bytes und hält eine einzige, langlebige Verbindung offen, statt ständig abzufragen. Damit passt es ideal zu Sensoren, Gateways, Fahrzeugen, Smart Metern und Industriemaschinen – und ist genauso nützlich für Dashboards und Backend-Dienste, die deren Daten verarbeiten.
MQTT ist ein offener OASIS-Standard; die offizielle Heimat des Protokolls ist mqtt.org.
Das Publish/Subscribe-Modell
In einem klassischen Request/Response-System wie HTTP ruft ein Client einen bestimmten Server auf und wartet auf die Antwort. MQTT setzt stattdessen auf Publish/Subscribe:
- Ein Publisher sendet eine Nachricht an ein Topic, zum Beispiel
home/livingroom/temperature. - Ein Subscriber teilt dem Broker mit, für welche Topics er sich interessiert.
- Der Broker sitzt in der Mitte und leitet jede Nachricht an alle Subscriber weiter, deren Abonnement zum Topic passt.
So sieht der Ablauf aus:
[Temperature sensor] --PUBLISH home/livingroom/temperature 22.5--> [MQTT broker]
[MQTT broker] --deliver--> [Mobile app] (subscribed to home/+/temperature)
[MQTT broker] --deliver--> [Analytics service] (subscribed to home/#)
Drei Arten der Entkopplung machen dieses Modell so leistungsfähig:
- Raum: Der Sensor kennt die Adresse der App nicht und die App nicht die des Sensors. Beide kennen nur den Broker.
- Zeit: Mit persistenten Sessions und Retained Messages muss ein Subscriber nicht genau in dem Moment online sein, in dem eine Nachricht veröffentlicht wird.
- Skalierung: Ob ein zehnter oder ein tausendster Subscriber hinzukommt – am Publisher ändert sich nichts.
Was macht ein MQTT-Broker?
Ein MQTT-Broker ist weit mehr als ein Relais. Er erledigt mehrere Aufgaben gleichzeitig.
Verbindungen verwalten
Jeder Client öffnet eine TCP-, TLS- oder WebSocket-Verbindung und sendet ein CONNECT-Paket mit Client ID, optionalem Benutzernamen und Passwort, einem Keep-Alive-Intervall und Session-Flags. Der Broker authentifiziert den Client, antwortet mit CONNACK und überwacht die Verbindung anschließend per PINGREQ/PINGRESP, um tote Clients zu erkennen.
Sessions vorhalten
Eine Session enthält die Abonnements eines Clients und alle Nachrichten, die während seiner Offline-Zeit aufgelaufen sind. Bei einer Clean Session wird der Zustand beim Trennen verworfen. Bei einer persistenten Session hält der Broker ihn vor, sodass ein Gerät, das aus dem Mobilfunknetz fällt, bei seiner Rückkehr erhält, was es verpasst hat. MQTT 5 ersetzt das alte Ein/Aus-Flag durch ein Session Expiry Interval in Sekunden.
Routing nach Topic
Jedes eingehende PUBLISH wird mit allen aktiven Abonnements einschließlich Wildcard-Filtern abgeglichen und an die passenden Clients ausgeliefert. Das Routing ist das Herzstück des MQTT-Brokers – und der Grund, warum das Topic-Design so wichtig ist.
Retained Messages
Ein Publisher kann das Retain-Flag setzen. Der Broker speichert pro Topic die letzte Retained Message und sendet sie sofort an jeden neuen Subscriber. Das ist ideal für Zustände wie device/42/status = online oder die aktuelle Konfiguration: Ein Dashboard, das erst später geöffnet wird, sieht trotzdem den aktuellen Wert, ohne auf das nächste Update zu warten.
Last Will and Testament
Beim Verbindungsaufbau kann ein Client eine „Last Will“-Nachricht hinterlegen, zum Beispiel device/42/status = offline. Verschwindet der Client ohne sauberes DISCONNECT (Stromausfall, Netzwerkfehler, Keep-Alive-Timeout), veröffentlicht der Broker diese Nachricht in seinem Namen. Zusammen mit einer Retained Message online erhalten Sie so eine zuverlässige Präsenzerkennung.
Quality of Service
MQTT definiert drei Zustellgarantien, die der Broker auf beiden Teilstrecken durchsetzt (Publisher zum Broker, Broker zum Subscriber):
| QoS | Name | Garantie | Typischer Einsatz |
|---|---|---|---|
| 0 | At most once | Fire and Forget, keine Bestätigung | Häufige Sensorwerte, bei denen ein verlorener Messwert unkritisch ist |
| 1 | At least once | Bestätigt per PUBACK, Duplikate möglich | Die meisten Telemetriedaten und Ereignisse |
| 2 | Exactly once | Vierstufiger Handshake, keine Duplikate | Abrechnung, Befehle, die sich nicht wiederholen dürfen |
Die effektive QoS für einen Subscriber ist der niedrigere Wert aus Publish-QoS und Abonnement-QoS. Mehr dazu lesen Sie in MQTT QoS-Stufen erklärt.
MQTT-Topics und Wildcards
Topics sind UTF-8-Zeichenketten, die durch Schrägstriche in Ebenen gegliedert werden. Sie entstehen spontan – vorab muss nichts deklariert werden.
factory1/line1/cnc1/temperature
factory1/line1/cnc1/spindle_rpm
factory1/line2/press3/status
home/kitchen/light/state
Gutes Topic-Design verläuft vom Allgemeinen zum Speziellen, vermeidet führende Schrägstriche und Leerzeichen und packt keine sensiblen Daten in Topic-Namen. Topics, die mit $ beginnen, sind für den Broker reserviert; ConnectMQ veröffentlicht zum Beispiel $SYS/broker/connection/{clientId}/state.
Einstufige Wildcard: +
Das Pluszeichen steht für genau eine Ebene.
| Abonnement-Filter | Passt auf | Passt nicht auf |
|---|---|---|
factory1/+/cnc1/temperature |
factory1/line1/cnc1/temperature |
factory1/line1/cell2/cnc1/temperature |
home/+/light/state |
home/kitchen/light/state |
home/light/state |
Mehrstufige Wildcard:
Die Raute steht für beliebig viele Ebenen, auch für keine, und muss das letzte Zeichen des Filters sein.
| Abonnement-Filter | Passt auf |
|---|---|
factory1/# |
factory1, factory1/line1/cnc1/temperature, factory1/line2/press3/status |
factory1/line1/# |
Alles unterhalb von factory1/line1 |
# |
Jedes Topic ohne $, das der Client sehen darf |
Wildcards sind nur beim Abonnieren erlaubt; veröffentlicht wird immer auf ein konkretes Topic. In Industrieprojekten wird aus einer konsistenten Hierarchie wie ISA-95 (Enterprise, Site, Area, Line, Cell) ein Unified Namespace (UNS): Jede ISA-95-Ebene wird zu einer Topic-Ebene auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und SPS, MES und Dashboards finden alle Daten an einem vorhersehbaren Ort. Dieses Muster beschreibt Sparkplug B und Unified Namespace.
MQTT 3.1.1 vs. MQTT 5.0
Die meisten Broker und Bibliotheken unterstützen heute beide Versionen. MQTT 5.0 behält das Modell bei und ergänzt Funktionen, die große Installationen leichter beherrschbar machen.
| Fähigkeit | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| Fehlerrückmeldung | Begrenzte Return Codes | Reason Codes bei den meisten Bestätigungen (zum Beispiel 0x97 Quota exceeded) |
| Session-Lebensdauer | Clean Session an/aus | Session Expiry Interval |
| Nachrichten-Lebensdauer | Nicht verfügbar | Message Expiry Interval |
| Lastverteilung | Nicht im Standard | Shared Subscriptions $share/{group}/{filter} |
| Bandbreite sparen | Jedes Mal das vollständige Topic | Topic Aliases |
| Request/Response | Eigene Konventionen | Response Topic und Correlation Data |
| Broker-Limits | Implizit | Im CONNACK angekündigt (Maximum QoS, Receive Maximum usw.) |
| Metadaten | Nur Payload | User Properties |
Wenn Sie ein neues Projekt beginnen, verwenden Sie MQTT 5.0 – es sei denn, eine Gerätebibliothek unterstützt nur 3.1.1. Die vollständige Spezifikation veröffentlicht OASIS unter docs.oasis-open.org, und unser Überblick über die Funktionen von MQTT 5 fasst die praktischen Highlights zusammen.
Praxis: Einen MQTT-Broker in fünf Minuten ausprobieren
Am schnellsten verstehen Sie einen MQTT-Broker, indem Sie ihn benutzen. Unter broker.connectmq.com steht ein öffentlicher MQTT-Broker für anonyme Tests bereit.
| Protokoll | Port | URL |
|---|---|---|
| MQTT (TCP) | 1883 | mqtt://broker.connectmq.com:1883 |
| MQTT über TLS | 8883 | mqtts://broker.connectmq.com:8883 |
| WebSocket | 8083 | ws://broker.connectmq.com:8083/mqtt |
| Secure WebSocket | 8084 | wss://broker.connectmq.com:8084/mqtt |
Regeln für den öffentlichen MQTT-Broker: Verbinden Sie sich ohne Benutzername und Passwort, verwenden Sie eine eindeutige, nicht leere Client ID (eine leere wird abgelehnt), und denken Sie daran, dass alles, was Sie veröffentlichen, für jeden lesbar ist. Wählen Sie ein zufälliges Präfix wie connectmq/demo/<your-random-id>/ und senden Sie niemals personenbezogene oder vertrauliche Daten. Die Limits liegen bei 64 KB pro Nachricht, 10 Nachrichten pro Sekunde und 10 Abonnements pro Client sowie bis zu 8 Topic-Ebenen.
Mit mosquitto abonnieren und veröffentlichen
Installieren Sie die Kommandozeilen-Clients von Eclipse Mosquitto, öffnen Sie ein Terminal und abonnieren Sie mit einer Wildcard. Ersetzen Sie k9x2 durch eine eigene Zufallszeichenfolge:
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-k9x2 \
-t "connectmq/demo/k9x2/#" -v
Veröffentlichen Sie in einem zweiten Terminal einen Messwert:
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-k9x2 \
-t "connectmq/demo/k9x2/room1/temp" -m '{"temp":22.5}' -q 1
Das erste Terminal gibt aus:
connectmq/demo/k9x2/room1/temp {"temp":22.5}
Probieren Sie jetzt eine Retained Message. Veröffentlichen Sie einen Status mit -r und starten Sie danach einen neuen Subscriber, der nur die einstufige Wildcard verwendet:
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-k9x2 \
-t "connectmq/demo/k9x2/room1/status" -m "online" -r
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub2-k9x2 \
-t "connectmq/demo/k9x2/+/status" -v -C 1
Der neue Subscriber erhält sofort online, obwohl er sich erst nach dem Senden der Nachricht verbunden hat. Hier speichert der Broker den Retained-Wert und spielt ihn erneut aus. Zum Löschen veröffentlichen Sie eine leere Retained Message mit -r -n.
Für verschlüsselten Datenverkehr wechseln Sie auf Port 8883, verweisen den Client auf die CA-Zertifikate Ihres Systems (zum Beispiel --capath /etc/ssl/certs unter Linux) und ergänzen -V mqttv5, um MQTT 5.0 zu sprechen.
Python-Beispiel mit Last Will
Installieren Sie paho-mqtt 2.x mit pip install paho-mqtt und führen Sie Folgendes aus:
import json
import uuid
import paho.mqtt.client as mqtt
BROKER = "broker.connectmq.com"
PREFIX = f"connectmq/demo/{uuid.uuid4().hex[:8]}"
CLIENT_ID = f"py-{uuid.uuid4().hex[:8]}"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(f"{PREFIX}/#", qos=1)
client.publish(f"{PREFIX}/sensor1/status", "online", qos=1, retain=True)
client.publish(f"{PREFIX}/sensor1/temp", json.dumps({"temp": 21.8}), qos=1)
def on_message(client, userdata, msg):
print(f"{msg.topic} -> {msg.payload.decode()}")
client = mqtt.Client(
mqtt.CallbackAPIVersion.VERSION2,
client_id=CLIENT_ID,
protocol=mqtt.MQTTv5,
)
client.will_set(f"{PREFIX}/sensor1/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=30)
client.loop_forever()
Das Skript hinterlegt einen Last Will, meldet sich mit einer Retained Message als online an und veröffentlicht einen Temperaturwert, den es über sein eigenes Wildcard-Abonnement zurückerhält. Beenden Sie den Prozess abrupt, veröffentlicht der Broker nach Ablauf des Keep-Alive offline auf dem Status-Topic.
Lieber im Browser? Derselbe Broker akzeptiert WebSocket-Verbindungen auf 8083 und 8084; siehe MQTT über WebSocket.
Vom öffentlichen MQTT-Broker zur Produktion
Ein öffentlicher MQTT-Broker ist perfekt zum Lernen und für Prototypen, doch in der Produktion brauchen Sie private Zugangsdaten, TLS und Isolation von anderen Nutzern. Als verwalteter MQTT-Broker übernimmt ConnectMQ den Betrieb für Sie: Legen Sie im Portal einen an, erhalten Sie Benutzername, Passwort und Client ID und verbinden Sie sich über mqtts:// auf Port 8883. Ihre Topics bleiben von anderen Mandanten und vom öffentlichen MQTT-Broker isoliert, und das Portal bietet Ihnen einen Live-Topic-Explorer, Dashboards und Alarmregeln. In Was ist ein verwalteter MQTT-Broker? vergleichen wir die Hosting-Optionen.
Starten Sie mit ConnectMQ
Registrieren Sie sich unter app.connectmq.com und legen Sie im kostenlosen Serverless-Plan Ihren eigenen MQTT-Broker an – ganz ohne Kreditkarte. In wenigen Minuten senden Sie Nachrichten über TLS, mit denselben Befehlen, die Sie gerade ausprobiert haben.
Häufig gestellte Fragen
Was ist ein MQTT-Broker, einfach erklärt?
Ein MQTT-Broker ist ein Server, der Nachrichten von publizierenden Clients empfängt und an alle Clients weiterleitet, die ein passendes Topic abonniert haben. Geräte sprechen nie direkt miteinander, sondern immer nur mit dem Broker.
Was ist der Unterschied zwischen einem MQTT-Broker und einem MQTT-Client?
Ein Client ist jedes Gerät und jede Anwendung, die veröffentlicht oder abonniert, etwa ein Sensor oder ein Dashboard. Der Broker ist der Server in der Mitte, der Clients authentifiziert, Sessions vorhält und Nachrichten zwischen ihnen weiterleitet.
Welchen Port verwendet ein MQTT-Broker?
Die Standardports sind 1883 für unverschlüsseltes MQTT und 8883 für MQTT über TLS. WebSocket-Verbindungen nutzen meist eigene Ports; bei broker.connectmq.com sind das 8083 und 8084 mit dem Pfad /mqtt.
Gibt es einen kostenlosen MQTT-Broker zum Testen?
Ja. broker.connectmq.com ist als öffentlicher MQTT-Broker anonym zum Testen nutzbar, und der kostenlose Serverless-Plan von ConnectMQ bietet Ihnen einen privaten Broker mit Zugangsdaten und TLS.
Sollte ich MQTT 3.1.1 oder MQTT 5.0 verwenden?
Verwenden Sie für neue Projekte MQTT 5.0, denn es bringt Reason Codes, Session und Message Expiry, Shared Subscriptions und Topic Aliases mit. Greifen Sie nur dann auf 3.1.1 zurück, wenn eine Gerätebibliothek Version 5 nicht unterstützt.
