MQTT Broker – was ist das eigentlich und warum braucht man ihn?

Bei MQTT bin ich anfangs über einen Begriff gestolpert, der irgendwie wichtiger klingt, als er eigentlich ist: Broker. Gleichzeitig merkt man ziemlich schnell, dass ohne diesen Broker bei MQTT nicht viel passiert. Also habe ich mir irgendwann genauer angeschaut, was dahintersteckt.

MQTT steht für Message Queuing Telemetry Transport und ist ein relativ schlankes Nachrichtenprotokoll. Ursprünglich wurde es für Umgebungen entwickelt, in denen Verbindungen langsam oder unzuverlässig sein können. Heute begegnet einem MQTT vor allem bei IoT-Projekten, Hausautomation, Sensoren und Mikrocontrollern.

Das Schöne an MQTT ist eigentlich das Prinzip dahinter: Die Geräte müssen nicht direkt miteinander reden.

Stattdessen gibt es einen zentralen Vermittler – den MQTT-Broker.

Ein Gerät schickt seine Nachricht an den Broker und ein anderes Gerät kann diese Nachricht dort abonnieren.

Das lässt sich ungefähr so vorstellen:

Temperatursensor
      │
      │ publish
      ▼
  MQTT Broker
      │
      │ subscribe
      ▼
  Home Assistant

Der Temperatursensor muss dabei überhaupt nicht wissen, wer die Temperatur später haben möchte. Er veröffentlicht einfach beispielsweise den Wert 21.7 unter einem bestimmten Topic.

Ein Topic könnte zum Beispiel haus/wohnzimmer/temperatur heißen.

Ein anderes Gerät abonniert genau dieses Topic und bekommt die Nachrichten zugestellt. Das ist für mich einer der interessantesten Punkte an MQTT: Sender und Empfänger sind voneinander entkoppelt.

Der Sensor könnte heute einen Raspberry Pi beliefern und morgen zusätzlich noch ein Smartphone, einen zweiten Server oder ein Dashboard. Am Sensor selbst muss dafür nichts geändert werden.

Der Broker kennt die Verbindungen und kümmert sich darum, die Nachrichten an die passenden Teilnehmer weiterzugeben.

Als MQTT-Broker kann beispielsweise mosquitto verwendet werden. Ein kleiner Rechner im Netzwerk reicht dafür meistens schon aus. Der Broker wartet typischerweise auf eingehende MQTT-Verbindungen und verwaltet die Topics sowie die angeschlossenen Clients.

Ein Client kann dabei gleichzeitig Publisher und Subscriber sein. Ein Mikrocontroller kann also beispielsweise seine Temperatur veröffentlichen und gleichzeitig auf ein Topic hören, über das ihm ein anderer Teilnehmer einen Befehl schickt.

Zum Beispiel könnte ein ESP32 regelmäßig Folgendes veröffentlichen:

Topic:
haus/wohnzimmer/temperatur

Payload:
21.7

Und ein anderes Gerät könnte auf haus/wohnzimmer/temperatur lauschen.

Wichtig ist dabei: Ein Topic ist keine Datei und auch keine Variable im klassischen Sinn. Es ist eher eine Art hierarchischer Nachrichtenkanal. Die Struktur kann man selbst festlegen. Man könnte beispielsweise haus/erdgeschoss/wohnzimmer/licht/status verwenden.

MQTT arbeitet außerdem nicht einfach nur nach dem Prinzip „Nachricht senden und fertig“. Interessant wird es bei den sogenannten QoS-Stufen.

QoS 0 bedeutet im Wesentlichen: Die Nachricht wird höchstens einmal zugestellt. Der Sender wartet nicht auf eine Bestätigung. Das ist schnell und genügt beispielsweise für einen Sensorwert, bei dem der nächste Messwert ohnehin kurz darauf kommt.

QoS 1 bedeutet: Die Nachricht soll mindestens einmal zugestellt werden. Dafür wird bestätigt. Allerdings kann eine Nachricht unter bestimmten Umständen doppelt beim Empfänger ankommen. Die Anwendung muss damit umgehen können.

QoS 2 geht noch einen Schritt weiter und sorgt für eine Zustellung genau einmal. Dafür ist der Ablauf aufwendiger und es werden mehr Nachrichten ausgetauscht. Deshalb ist QoS 2 nicht automatisch die beste Wahl für alles.

Gerade diesen Punkt finde ich wichtig, weil man bei MQTT schnell denkt: „Dann nehme ich einfach immer QoS 2, dann bin ich auf der sicheren Seite.“ In der Praxis sollte man sich aber überlegen, was die jeweilige Nachricht überhaupt bedeutet.

Bei einem Temperaturwert ist es meistens nicht dramatisch, wenn einmal ein Messwert verloren geht. Bei einem Befehl wie „Heizung ausschalten“ kann die Situation schon anders aussehen.

Dann gibt es noch das sogenannte Retain-Flag.

Das ist eine ziemlich praktische Funktion. Wenn ein Gerät beispielsweise den aktuellen Zustand einer Lampe veröffentlicht und die Nachricht als Retained Message markiert, merkt sich der Broker die letzte Nachricht für dieses Topic. Ein neuer Subscriber bekommt diesen letzten bekannten Wert dann sofort, ohne darauf warten zu müssen, dass die Lampe ihren Status erneut sendet.

Dadurch kann ein System nach dem Start beispielsweise sofort wissen, welchen Zustand ein Gerät zuletzt gemeldet hat.

Eine weitere Funktion, die ich bei MQTT besonders clever finde, ist das Last Will and Testament, kurz LWT.

Ein Client kann dem Broker beim Verbinden mitteilen, welche Nachricht veröffentlicht werden soll, falls die Verbindung unerwartet abbricht. Ein ESP32 könnte beispielsweise seinen Status als online melden. Wenn er plötzlich ausfällt oder die Verbindung verliert, kann der Broker automatisch offline auf dem entsprechenden Status-Topic veröffentlichen.

Damit lässt sich relativ einfach erkennen, ob ein Gerät noch erreichbar ist.

Ein typischer Aufbau könnte also so aussehen:

                 ┌─────────────────┐
                 │   MQTT Broker   │
                 │    Mosquitto    │
                 └────────┬────────┘
                          │
          ┌───────────────┼────────────────┐
          │               │                │
          ▼               ▼                ▼
       ESP32           Home Assistant    Dashboard
      Sensoren           Subscriber       Subscriber

Der große Vorteil ist, dass die Geräte nicht untereinander IP-Adressen kennen müssen. Sie müssen lediglich wissen, wo der Broker erreichbar ist und welche Topics sie veröffentlichen oder abonnieren.

Natürlich bedeutet das nicht, dass MQTT automatisch sicher ist. Gerade wenn ein Broker nicht nur im lokalen Netzwerk erreichbar sein soll, sollte man sich mit Authentifizierung, TLS und Berechtigungen beschäftigen. Ein offen erreichbarer MQTT-Broker ohne vernünftige Zugriffskontrolle wäre keine besonders gute Idee.

Auch bei den Topics lohnt sich ein bisschen Planung. Wenn ein Projekt wächst, kann aus ein paar Topics schnell eine ziemlich große Struktur werden. Eine sinnvolle Namensgebung macht später einen gewaltigen Unterschied.

Was mir an MQTT letztendlich gefällt, ist die Einfachheit, obwohl dahinter erstaunlich viel steckt. Ein Sensor muss nicht wissen, wer seine Daten benötigt. Ein Verbraucher muss nicht wissen, woher die Daten kommen. Beide kennen nur den Broker und die entsprechenden Topics.

Und plötzlich kann man aus relativ kleinen Bausteinen ein ganzes System aufbauen: Mikrocontroller veröffentlichen Messwerte, Home Assistant verarbeitet sie, ein Dashboard zeigt sie an und andere Geräte können über MQTT Befehle zurückschicken.

Gerade zusammen mit ESP32, Raspberry Pi oder Home Assistant wird MQTT deshalb ziemlich mächtig. Und gleichzeitig bleibt das Grundprinzip erstaunlich überschaubar:

Publisher
   │
   │  publish(topic, payload)
   ▼
Broker
   │
   │  message
   ▼
Subscriber

Je mehr ich mich damit beschäftigt habe, desto weniger sehe ich MQTT als „Programm“, das man einfach installiert. Eher ist es eine gemeinsame Sprache beziehungsweise ein Nachrichtenmodell, über das ganz unterschiedliche Geräte miteinander kommunizieren können.

Und vielleicht ist genau das der Grund, warum MQTT in vielen IoT-Projekten so beliebt ist: Ein kleiner Mikrocontroller mit wenig Rechenleistung kann damit Teil eines ziemlich komplexen Systems werden, ohne selbst besonders viel über dieses System wissen zu müssen.

Mich würde deshalb interessieren, wie ihr MQTT einsetzt. Läuft bei euch ein eigener Mosquitto-Broker? Verwendet ihr MQTT nur für Sensorwerte oder auch für Schaltbefehle und Zustände? Und habt ihr eure Topic-Struktur von Anfang an geplant oder ist sie – wie vermutlich bei vielen Projekten – einfach mit dem Projekt mitgewachsen?