Teil 1 – Einführung in MQTT: Was ist das und wofür braucht man es?

Das „Internet of Things“ (IoT) hat in den letzten Jahren enorm an Bedeutung gewonnen. Von smarten Glühbirnen über Wetterstationen bis hin zu Industrieanlagen – immer mehr Geräte sind vernetzt und kommunizieren miteinander. Damit diese Kommunikation zuverlässig, leichtgewichtig und ressourcenschonend funktioniert, braucht es spezielle Protokolle. Eines der bekanntesten und erfolgreichsten ist MQTT.

In diesem ersten Teil der Serie erfährst du:

  • woher MQTT kommt,
  • wie es funktioniert,
  • warum es sich vom klassischen HTTP unterscheidet,
  • und in welchen Bereichen es besonders nützlich ist.

Ursprung von MQTT

MQTT steht für Message Queuing Telemetry Transport.
Es wurde 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper entwickelt – ursprünglich für die Öl- und Gasindustrie. Dort sollten Sensoren in abgelegenen Pipelines über teure Satellitenverbindungen Daten senden können.

Die Anforderungen waren:

  • Leichtgewichtig: so wenig Datenverkehr wie möglich.
  • Zuverlässig: Nachrichten dürfen nicht einfach verloren gehen.
  • Einfach: Geräte mit wenig Rechenleistung sollen es nutzen können.
  • Robust: auch bei instabilen Verbindungen (z. B. Satelliten oder Mobilfunk).

Genau diese Eigenschaften machen MQTT bis heute attraktiv.


Grundprinzip: Publish/Subscribe

Im Gegensatz zu HTTP, wo ein Client direkt einen Server anfragt („Request/Response“), arbeitet MQTT nach dem Publish/Subscribe-Modell.

Die Akteure

  1. Broker
    • Zentrale Instanz, die Nachrichten empfängt, sortiert und weiterleitet.
    • Er sorgt dafür, dass Daten vom Sender (Publisher) an die richtigen Empfänger (Subscriber) gehen.
  2. Publisher
    • Gerät oder Anwendung, die Daten „veröffentlicht“.
    • Beispiel: ein Temperatursensor sendet „22,3 °C“.
  3. Subscriber
    • Gerät oder Anwendung, die Nachrichten zu bestimmten Themen „abonniert“.
    • Beispiel: eine App, die die Temperatur anzeigt.

Topics

Jede Nachricht wird einem Topic zugeordnet, z. B.:

haus/wohnzimmer/temperatur
  • Publisher sendet die Nachricht an dieses Topic.
  • Alle Subscriber, die dieses Topic abonniert haben, erhalten die Nachricht.

So können beliebig viele Sender und Empfänger entkoppelt miteinander kommunizieren.


MQTT vs. HTTP

Warum nicht einfach HTTP nutzen? Ein Vergleich macht die Unterschiede deutlich:

MerkmalHTTPMQTT
KommunikationsmodellRequest/ResponsePublish/Subscribe
DatenmengeSchwergewichtiger (Header etc.)Sehr leichtgewichtig
VerbindungKurzlebig (pro Anfrage)Dauerhaft (über TCP)
ZuverlässigkeitNicht speziell geregeltQoS-Level steuerbar
ZielgruppeWeb & klassische ClientsIoT, Embedded, ressourcenschwach

Kurz gesagt:
HTTP ist super fürs Web, MQTT für kleine Geräte mit wenig Bandbreite und Energieverbrauch.


Typische Einsatzgebiete

1. Smart Home

  • Temperatur- und Luftfeuchtigkeitssensoren
  • Smarte Steckdosen, Lampen, Thermostate
  • Tür- und Fenstersensoren
    👉 Geräte tauschen Daten über einen MQTT-Broker aus, der alles koordiniert.

2. Industrie & Maschinenbau

  • Produktionsmaschinen melden Statuswerte (z. B. Drehzahlen, Temperaturen).
  • Condition Monitoring und Predictive Maintenance.

3. Mobilfunk & Fahrzeuge

  • Telematiksysteme in LKWs oder Autos melden Standort und Zustand.
  • Flottenmanagement in Echtzeit.

4. Cloud & Edge-Computing

  • Daten werden von Edge-Geräten gesammelt und über MQTT an Cloud-Dienste weitergeleitet.

5. Forschung & Bildung

  • Universitäten nutzen MQTT für Laborexperimente und Lernumgebungen.
  • Maker-Community (Arduino, ESP32, Raspberry Pi).

Vorteile von MQTT

  1. Effizient
    • Kaum Overhead, ideal für schmale Bandbreiten.
  2. Einfach
    • Klar strukturiert: Broker, Topics, Publisher, Subscriber.
  3. Zuverlässig
    • Quality-of-Service-Level (QoS) regeln, wie sicher Nachrichten zugestellt werden.
  4. Flexibel
    • Unabhängig von Sprache und Plattform (Python, C, Java, Node.js …).
  5. Skalierbar
    • Von Smart-Home-Projekten bis zu Industrieanlagen mit Tausenden Geräten.

Herausforderungen und Grenzen

Natürlich ist MQTT kein Allheilmittel. Typische Herausforderungen sind:

  • Sicherheit: Von Haus aus unverschlüsselt → TLS und Authentifizierung müssen eingerichtet werden.
  • Abhängigkeit vom Broker: Fällt der Broker aus, bricht die Kommunikation zusammen.
  • Nicht für alles geeignet: Für klassische Web-Apps mit komplexen Abfragen ist HTTP sinnvoller.

Erste MQTT-Nachricht – ein Blick in die Praxis

Damit du eine Vorstellung bekommst, wie einfach MQTT funktioniert, ein kleines Beispiel:

# 1. Publisher sendet Temperaturwert
mosquitto_pub -h test.mosquitto.org -t "haus/wohnzimmer/temperatur" -m "22.3"

# 2. Subscriber empfängt alle Nachrichten aus diesem Topic
mosquitto_sub -h test.mosquitto.org -t "haus/wohnzimmer/temperatur"

Ergebnis:
Sobald der Publisher „22.3“ sendet, zeigt der Subscriber die Nachricht an.


Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert