MQTTT
DE
English简体中文Español日本語DeutschFrançaisPortuguês
Guides

MQTT-Protokollversionen

Detaillierter Guide zu MQTT 3.1, MQTT 3.1.1, MQTT 5.0, MQTT-SN, Kompatibilität, Funktionen und Migration.

Protokollversionen

MQTT-Protokollversionen

MQTT-Versionen sind keine reinen Release-Namen. Sie bestimmen CONNECT-Pakete, Broker-Kompatibilität, Fehlerdiagnose, Session-Lebensdauer, Nachrichtenmetadaten und Observability. Praktisch relevant sind MQTT 3.1, MQTT 3.1.1, MQTT 5.0 und das verwandte MQTT-SN. Stand Mai 2026 listet OASIS MQTT 3.1.1 und MQTT 5.0 als Hauptstandards, nicht MQTT 5.1.

Kurzantwort

  • Nutze MQTT 5.0 für neue Systeme mit Reason Codes, Properties, Message Expiry, Request-Response, Flow Control oder besserer Diagnose.
  • Nutze MQTT 3.1.1 als Kompatibilitätsbasis für ältere Geräte, günstige Module, bestehende SDKs und Industrieumgebungen.
  • Behandle MQTT 3.1 als historische Kompatibilität, nicht als Ziel für neue Produkte.
  • Nutze MQTT-SN nur, wenn dein Netzwerk Sensor-Network-Verhalten statt normalem TCP/TLS oder WebSocket braucht.
VersionStatusLevelPasst fürEmpfehlung
MQTT 3.1Historisch3Legacy-Geräte, alte Broker, frühe IBM-KompatibilitätNur bei Legacy-Zwang
MQTT 3.1.1OASIS / ISO4Breite IoT-Kompatibilität, Gateways, leichte TelemetrieSolide Kompatibilitätsbasis
MQTT 5.0OASIS5Moderne Broker, Cloud, Multi-Tenant, bessere DiagnoseBevorzugt für neue Systeme
MQTT-SN 1.2Verwandte SpezifikationEigenständigSensornetze, Nicht-TCP/IP, eingeschränkte GeräteNur wenn das Netzwerk es verlangt

MQTT 3.1: historische Version für Legacy-Kompatibilität

MQTT 3.1 ist die wichtige Grundlage vor OASIS und enthält bereits Client, Broker, CONNECT, PUBLISH, SUBSCRIBE, QoS, Retain, Will, Keep Alive und Topic Filter.

Heute erklärt es vor allem alte Protocol Names, CONNECT-Pakete und Broker-Kompatibilitätsmodi.

Für neue Produkte sollte MQTT 3.1 nicht Zielversion sein, außer Firmware oder Gateways können nicht aktualisiert werden.

Prüfpunkte

  • MQTT-3.1-Kompatibilität am Broker prüfen.
  • Protocol Name und Protocol Level in CONNECT ansehen.
  • Version Negotiation nicht mit Netzwerkfehlern verwechseln.

MQTT 3.1.1: die praktische Kompatibilitätsbasis

MQTT 3.1.1 ist weit standardisiert und die gemeinsame Sprache vieler IoT-Geräte, Gateways, Open-Source-Broker, Cloud-Dienste und WebSocket-Clients.

Für Publish, Subscribe, QoS, Retain und Last Will reicht es oft völlig aus.

Grenzen zeigen sich bei grober Fehlerdiagnose, fehlenden Standard-Properties, schwächerer Session Expiry, Message Expiry, Flow Control und Disconnect-Diagnose.

Wann 3.1.1 richtig ist

  • SDKs oder Module unterstützen MQTT 5.0 nicht.
  • Das Nachrichtenmodell ist einfach.
  • Maximale Kompatibilität zählt mehr als neue Features.
  • Feld-Updates sind teuer.

MQTT 5.0: moderne MQTT-Version

MQTT 5.0 behält Publish/Subscribe bei und erweitert Verbindung, Publish, Subscribe, Acknowledgements und Disconnects mit Properties und Reason Codes.

Properties beschreiben Session Expiry, Message Expiry, Maximum Packet Size, Receive Maximum, Topic Alias, Response Topic, Correlation Data, User Properties und Content Type.

Reason Codes helfen, Auth-Fehler, Berechtigungen, Paketgrößen, Server-Migration und administrative Disconnects sauber zu unterscheiden.

Wichtige Fähigkeiten

  • Reason Codes für präzise Diagnose.
  • Properties für Metadaten.
  • Message Expiry gegen veraltete Commands.
  • Receive Maximum und Packet Size für Schutz.
  • Response Topic und Correlation Data für Request-Response.

MQTT-SN: verwandtes Protokoll für Sensornetze

MQTT-SN ersetzt nicht MQTT über TCP, sondern bringt Publish/Subscribe in Nicht-TCP/IP-Netze und stark eingeschränkte Sensorumgebungen.

Typisch ist ein Gateway, das kurze Adressen und Topic IDs in die normale MQTT-Broker-Welt übersetzt.

Wenn TCP/TLS oder WebSocket zuverlässig verfügbar ist, brauchst du meist kein MQTT-SN.

Auswahl

  • Cloud IoT und WebSocket: MQTT 3.1.1 oder 5.0.
  • Nicht-TCP/IP und Sleep-heavy Devices: MQTT-SN prüfen.
  • Integration in bestehende Broker: Gateway sorgfältig designen.

Migration von MQTT 3.1.1 zu MQTT 5.0

  1. Support in Broker, SDKs, Gateways, Cloud und Testtools prüfen.
  2. Mit Reason Codes, DISCONNECT Reasons, Message Expiry, Session Expiry und Maximum Packet Size starten.
  3. 3.1.1-Semantik zuerst stabil halten, danach User Properties, Response Topic und Topic Alias nutzen.
  4. Gemischte Flotten nach Tenant, Produktlinie oder Firmware migrieren.

FAQ

Ist MQTT 5.0 kompatibel mit MQTT 3.1.1?

Das Publish/Subscribe-Modell ist gleich, aber der CONNECT Protocol Level ist anders. Ein Broker kann beide Versionen unterstützen, eine Session nutzt aber genau eine Version.

Gibt es MQTT 5.1?

Stand Mai 2026 listet OASIS für MQTT die Hauptversionen 3.1.1 und 5.0, nicht MQTT 5.1.

Muss jedes neue Projekt MQTT 5.0 nutzen?

Nein. Wenn Geräte und Plattform es unterstützen, ist 5.0 besser. Wenn Feldgeräte nur 3.1.1 sprechen, ist 3.1.1 pragmatisch.

Offizielle Referenzen

Weiter zum QoS-Guide MQTT Client öffnen