MQTT-Protokoll für IoT: QoS, Retained Messages und Last Will erklärt

MQTT ist das maßgebliche Protokoll für die IoT-Kommunikation. Leichtgewichtig, binär, für unzuverlässige Netze konzipiert — es läuft auf Mikrocontrollern mit 64 KB RAM und skaliert auf Azure IoT Hub bis zu Millionen von Verbindungen.

QoS-Stufen

• QoS 0 — Höchstens einmal (At most once): Fire and forget. Kein ACK. Für hochfrequente Telemetrie, bei der gelegentlich verpasste Messwerte akzeptabel sind.
• QoS 1 — Mindestens einmal (At least once): Der Broker sendet PUBACK; das Gerät überträgt erneut, bis das ACK eintrifft. Kann Duplikate liefern — gestalten Sie die Cloud-Verarbeitung idempotent.
• QoS 2 — Genau einmal (Exactly once): Vierstufiger Handshake. Nur einsetzen, wenn Duplikate echten Schaden anrichten (Finanztransaktionen).

Last Will and Testament (LWT)

// On connect: configure LWT (sent on unexpected disconnect)
.lwt_topic  = "devices/dev-001/status",
.lwt_msg    = "{"online":false,"reason":"unexpected"}",
.lwt_qos    = 1,
.lwt_retain = 1,
// After connect: publish online status (retained)
mqtt_publish(“devices/dev-001/status”,
”{“online”:true,“firmware”:“2.1.0”}”, QOS_1, RETAIN);

Topic-Design für Skalierung

Eine gut gestaltete Topic-Hierarchie macht Routing, Filterung und Zugriffssteuerung unkompliziert. Eine schlecht gestaltete wird mit wachsender Flotte zur Wartungslast. Unsere empfohlene Struktur nutzt die Geräte-ID als Primärschlüssel, mit dem Nachrichtentyp als Sub-Topic:

devices/{deviceId}/telemetry        # sensor readings (QoS 0/1)
devices/{deviceId}/status           # online/offline (retained, QoS 1)
devices/{deviceId}/commands/{cmd}   # cloud to device commands
devices/{deviceId}/responses/{cmd}  # device command responses
fleet/{productLine}/config          # fleet-wide config broadcast

Vermeiden Sie tiefe Topic-Hierarchien über 4–5 Ebenen hinaus. Vermeiden Sie es, Payload-Inhalte in Topic-Pfaden zu verwenden — halten Sie die Topic-Struktur statisch und legen Sie variable Daten in die Payload. Das macht Routing-Regeln einfacher und die Broker-Leistung besser.

MQTT vs. HTTPS für IoT

Einige IoT-Geräte verwenden HTTPS statt MQTT — typischerweise, wenn das Gerät ausschließlich Daten sendet (keine Befehle nötig) und Einfachheit höher bewertet wird als Effizienz. HTTPS hat einen größeren Overhead pro Nachricht (TLS-Handshake + HTTP-Header), funktioniert aber durch Firewalls hindurch, die Port 8883 blockieren. MQTT über WebSockets (Port 443) verbindet die MQTT-Semantik mit Firewall-Freundlichkeit.

Azure IoT Hub unterstützt sowohl MQTT als auch HTTPS sowie AMQP für Szenarien mit hohem Durchsatz. Für die meisten vernetzten Produkte ist MQTT auf Port 8883 mit mTLS-Authentifizierung die richtige Wahl — es ist effizient, gut unterstützt und semantisch reichhaltig genug, um Telemetrie, Befehle, OTA-Trigger und Geräte-Präsenzverfolgung in einer einzigen Verbindung abzuwickeln.

Broker-Auswahl

Für Entwicklung und On-Premises-Deployments ist Mosquitto der branchenübliche Open-Source-MQTT-Broker — leichtgewichtig, zuverlässig und einfach zu konfigurieren. Für produktive Cloud-Deployments übernehmen verwaltete Dienste wie Azure IoT Hub, AWS IoT Core oder HiveMQ Cloud die TLS-Terminierung, Authentifizierung und horizontale Skalierung automatisch. Wir empfehlen für die Produktion verwaltete Dienste — der Betrieb eines eigenen MQTT-Brokers im großen Maßstab bringt eine operative Komplexität mit sich, die die Kosteneinsparungen selten rechtfertigt.

Prüfen Sie bei der Broker-Bewertung: maximale Verbindungen, Speichergrenzen für Retained Messages, QoS-2-Unterstützung (falls benötigt), Nachrichtengrößenlimits und Zugriffssteuerung pro Gerät (kann Gerät A die Topics von Gerät B lesen?). Azure IoT Hub erzwingt standardmäßig eine geräteweise Topic-Namensraumtrennung — Geräte können nur in ihren eigenen Topic-Pfad publizieren, was eine ganze Klasse von Sicherheitslücken eliminiert.