MQTT-SN erklärt: MQTT für Sensornetzwerke

MQTT-SN ist eine Variante von MQTT für Sensornetzwerke, in denen TCP zu schwergewichtig oder schlicht nicht verfügbar ist. In diesem Artikel erfahren Sie, wie sich MQTT-SN von regulärem MQTT unterscheidet, was Topic-IDs, Gateways und schlafende Clients sind und wie Sie MQTT-SN-Geräte an einen Standard-Broker anbinden, sodass der Rest Ihres Stacks nie wissen muss, dass es sie gibt.

Was ist MQTT-SN?

MQTT-SN steht für MQTT for Sensor Networks. Das Protokoll wurde ursprünglich Ende der 2000er-Jahre von IBM-Forschern veröffentlicht (zunächst als MQTT-S), um Publish/Subscribe in drahtlose Sensornetzwerke wie Zigbee zu bringen, deren Knoten winzige Funkmodule, winzige Batterien und keinen TCP/IP-Stack haben. Die weit verbreitete Version ist MQTT-SN 1.2; OASIS arbeitet inzwischen an einem standardisierten Nachfolger.

Das Designziel ist einfach: das Programmiermodell von MQTT (Topics, Publish, Subscribe, QoS) beibehalten, aber alles entfernen, was auf einer eingeschränkten Verbindung teuer ist. MQTT-SN benötigt keinen verbindungsorientierten Transport. Es funktioniert über UDP und über nicht IP-basierte Datagramm-Netze wie Zigbee oder BLE-basierte Mesh-Schichten, solange das Netzwerk adressierte Datagramme zustellen kann.

Die wichtige Konsequenz: Ein MQTT-SN-Client kann nicht direkt mit einem normalen MQTT-Broker sprechen. Er benötigt ein Gateway, das auf der einen Seite MQTT-SN und auf der anderen MQTT über TCP spricht.

MQTT-SN und MQTT im Überblick

Merkmal	MQTT (3.1.1 / 5.0)	MQTT-SN 1.2
Transport	TCP, TLS, WebSocket	UDP oder andere Datagramm-Netze
Topic im PUBLISH	Vollständiger UTF-8-String	2-Byte-Topic-ID oder 2-Zeichen-Kurzname
Gateway-Erkennung	Nicht zutreffend	ADVERTISE, SEARCHGW, GWINFO
Schlafende Clients	Nicht integriert	Zustände ASLEEP und AWAKE mit Pufferung
QoS-Stufen	0, 1, 2	0, 1, 2 und QoS -1 (Publish ohne Verbindung)
Einrichtung der Will-Nachricht	Im CONNECT	Separate WILLTOPIC- und WILLMSG-Austausche
Sicherheit	TLS und Authentifizierung	Der Netzwerkschicht oder DTLS überlassen

Topic-IDs: Bytes sparen bei jedem Publish

Ein Topic wie factory/izmir/hall2/line4/temperature kostet in jedem PUBLISH-Paket Dutzende Bytes. Auf einer Verbindung, bei der ein ganzer Frame vielleicht rund hundert Bytes transportiert, ist das inakzeptabel. MQTT-SN ersetzt den String durch eine Zwei-Byte-Zahl.

Es gibt drei Wege, eine solche ID zu erhalten:

Registrierte Topic-IDs. Der Client sendet REGISTER mit dem vollständigen Topic-Namen; das Gateway antwortet mit REGACK und einer ID. Anschließend publiziert der Client mit dieser ID. Die Zuordnungen gelten für die Dauer der Session.
Vordefinierte Topic-IDs. Client und Gateway vereinbaren die IDs vorab per Konfiguration, sodass keine Registrierung nötig ist. Das ist die effizienteste Option für feste Firmware.
Kurze Topic-Namen. Genau zwei Zeichen, etwa t1, die direkt im ID-Feld übertragen werden.

Abonniert ein Client mit einem vollständigen Topic-Namen, liefert das Gateway die ID zurück, die es beim Weiterleiten passender Nachrichten verwenden wird. Wildcard-Subscriptions werden unterstützt, doch dann muss das Gateway jedes konkrete Topic vor der Zustellung beim Client registrieren, was zusätzliche Round-Trips verursacht.

Beim Nachrüsten von Bestandsanlagen mit Funksensoren ist das besonders praktisch: Vordefinierte Topic-IDs werden im Gateway auf vollständige Pfade im Unified Namespace (UNS) abgebildet, etwa ID 17 auf acme/werk-stuttgart/halle-2/linie-4/temperatur. Der Sensor kennt nur die Zahl, während MES, Historian und Dashboards die ISA-95-Struktur aus Werk, Bereich, Linie und Zelle sehen.

Gateways und Forwarder

Das Gateway ist das Herzstück jedes MQTT-SN-Deployments. Die Spezifikation beschreibt zwei Varianten:

Transparentes Gateway. Für jeden MQTT-SN-Client öffnet das Gateway eine eigene MQTT-Verbindung zum Broker. Einfach und treu zur Semantik pro Client, aber der Broker sieht so viele Verbindungen, wie Sie Sensoren haben.
Aggregierendes Gateway. Das Gateway hält eine einzige MQTT-Verbindung zum Broker und bündelt den gesamten Sensorverkehr darüber. Weniger Broker-Verbindungen, mehr Logik im Gateway.

Ein Forwarder ist ein noch einfacherer Knoten, der MQTT-SN-Nachrichten lediglich kapselt und zwischen Clients und einem Gateway weiterreicht, ohne sie zu verstehen. Das ist nützlich, wenn Clients mehrere Funk-Hops entfernt sind.

Gateways kündigen sich mit periodischen ADVERTISE-Nachrichten an. Ein Client, der noch keine empfangen hat, kann SEARCHGW per Broadcast senden, und Gateways (oder andere Clients, die ein Gateway kennen) antworten mit GWINFO.

Schlafende Clients

Batteriebetriebene Sensoren verbringen den Großteil ihrer Lebenszeit mit ausgeschaltetem Funkmodul. MQTT-SN bildet das explizit ab:

Der Client sendet DISCONNECT mit einer Schlafdauer und wechselt in den Schlafzustand.
Während er schläft, puffert das Gateway an ihn adressierte Nachrichten.
Der Client wacht auf, sendet PINGREQ mit seiner Client-ID, empfängt gepufferte Nachrichten und erhält PINGRESP, sobald der Puffer leer ist.
Er schläft wieder ein.

Klassisches MQTT hat nichts Vergleichbares: Ein Gerät, das seine TCP-Verbindung trennt, ist einfach offline, und nur persistente Sessions auf dem Broker können Nachrichten für es aufbewahren.

QoS -1: Publish ohne Verbindung

MQTT-SN ergänzt eine Stufe, die oft als QoS -1 (in späteren Entwürfen QoS 3) bezeichnet wird. Ein Client kann ein PUBLISH mit vordefinierter Topic-ID oder Kurznamen an eine bekannte Gateway-Adresse senden, ohne sich je zu verbinden. Es gibt keine Bestätigung und keine Session. Ideal für sehr einfache Beacons, die alle paar Minuten einen Wert hinausrufen.

MQTT-SN an einen Standard-MQTT-Broker weiterleiten

Da das Gateway MQTT-SN in reguläres MQTT umwandelt, kann auf der Cloud-Seite jeder standardkonforme Broker stehen. Eine verbreitete Open-Source-Wahl ist das Eclipse Paho MQTT-SN Gateway (aus dem Projekt paho.mqtt-sn.embedded-c), das unter Linux läuft, MQTT-SN über UDP entgegennimmt und sich mit einem Upstream-Broker verbindet.

Eine Konfiguration, die das Gateway auf einen verwalteten MQTT-Broker wie ConnectMQ zeigt, sieht ungefähr so aus. Die Schlüsselnamen stammen aus der Beispieldatei gateway.conf des Gateways; prüfen Sie die README der Version, die Sie bauen, da sich Optionen zwischen Releases ändern.

# gateway.conf (Paho MQTT-SN Gateway, Auszug)
GatewayID=1
GatewayName=site1-mqttsn-gw
KeepAlive=60

# Upstream-MQTT-Broker (ConnectMQ, TLS)
BrokerName=broker.connectmq.com
BrokerPortNo=1883
BrokerSecurePortNo=8883
LoginID=YOUR_USERNAME
Password=YOUR_PASSWORD

# Eine TLS-Verbindung für alle Sensoren verwenden
AggregatingGateway=YES
TransparentGateway=NO

# MQTT-SN-Seite: UDP-Listener für Sensoren
GatewayPortNo=10000
MulticastIP=225.1.1.1
MulticastPortNo=1883

Speziell bei ConnectMQ sollten Sie zwei Dinge beachten:

Client-IDs sind an Zugangsdaten gebunden. Jeder Satz Broker-Zugangsdaten hat seine eigene Client-ID. Ein transparentes Gateway, das pro Sensor eine Upstream-Verbindung öffnet, braucht also pro Sensor einen Satz Zugangsdaten. Ein aggregierendes Gateway mit einer einzigen Upstream-Identität passt meist besser.
Verbindungskontingente. Der kostenlose Serverless-Plan erlaubt bis zu 25 Verbindungen, der kostenpflichtige Serverless-Plan bis zu 1.000. Mit Aggregation bleiben Sie selbst bei großen Sensorfeldern deutlich innerhalb dieser Grenzen.

Die Cloud-Seite prüfen

Sobald das Gateway läuft, abonnieren Sie vom Laptop aus, um die Sensordaten als gewöhnliches MQTT eintreffen zu sehen. Während eines Proof of Concept können Sie das Gateway stattdessen auf den öffentlichen MQTT-Broker zeigen lassen (anonym, Port 1883, eindeutiges Topic-Präfix; nur für Tests, nicht für Produktionsdaten):

mosquitto_sub -h broker.connectmq.com -p 1883 -i mqttsn-check-4d1e \
  -t "connectmq/demo/4d1e/#" -v

Mit Produktionszugangsdaten ergänzen Sie -p 8883 --capath /etc/ssl/certs -u YOUR_USERNAME -P YOUR_PASSWORD und die Client-ID aus dem Portal. Alles Nachgelagerte (Dashboards, Node-RED-Flows, Historians) verarbeitet die Daten genau so, als sprächen die Sensoren nativ MQTT.

Wann MQTT-SN die richtige Wahl ist (und wann nicht)

Gehen Sie diese Checkliste durch, bevor Sie sich festlegen:

Hat das Gerät einen IP-Stack mit TCP? Verfügt das Gerät über WLAN oder Mobilfunk mit TCP, ist klassisches MQTT über TLS einfacher und besser unterstützt. Das ESP32-MQTT-Tutorial ist ein gutes Beispiel.
Überträgt die Funkstrecke nur Datagramme? Zigbee, 6LoWPAN, rohe LoRa-artige Verbindungen oder eigene Sub-GHz-Funkmodule sind klassisches MQTT-SN-Terrain.
Ist die Batterielaufzeit die wichtigste Einschränkung? Schlafende Clients und Topic-IDs zahlen sich aus, wenn jedes gesendete Byte Energie kostet.
Können Sie ein Gateway betreiben und absichern? Das Gateway wird zur kritischen Komponente. Planen Sie Monitoring, Neustarts und seine Upstream-Zugangsdaten ein.
Wie steht es um die Sicherheit? MQTT-SN hat keine eingebaute Verschlüsselung. Setzen Sie auf Sicherheit der Sicherungsschicht oder DTLS auf der Sensorseite und TLS auf der Strecke vom Gateway zum Broker.
Verfügbarkeit von Bibliotheken. Es gibt Client-Bibliotheken für C und Embedded-Plattformen, doch das Ökosystem ist weit kleiner als bei MQTT.

Für viele Projekte ist ein hybrider Ansatz am besten: Eingeschränkte Knoten sprechen MQTT-SN mit einem lokalen Gateway, während alles andere, einschließlich der Upstream-Verbindung des Gateways, Standard-MQTT spricht. Wenn Sie das Basisprotokoll noch lernen, beginnen Sie mit dem MQTT-Tutorial und der Erklärung, ob MQTT TCP oder UDP verwendet.

Häufige Fallstricke bei MQTT-SN

Abweichende Topic-IDs. Registrierte IDs gelten pro Session. Nach einem Gateway-Neustart müssen Clients neu registrieren, sonst publizieren sie auf das falsche Topic. Vordefinierte IDs vermeiden das, müssen aber zwischen Firmware und Gateway-Konfiguration synchron gehalten werden.
UDP-Paketverlust. QoS 0 über UDP kann tatsächlich Daten verlieren. Verwenden Sie QoS 1 für alles Wichtige und dimensionieren Sie die Retry-Timer passend zu Ihrer Funkstrecke.
Fragmentierung. Halten Sie Payloads klein; MQTT-SN-Nachrichten sollen in einen einzigen Netzwerk-Frame passen.
Gateway als Single Point of Failure. Fällt das Gateway aus, puffern die Sensoren nichts. Planen Sie für schnelle Neustarts und Alarmierung.

Bringen Sie Ihr Sensornetzwerk zu ConnectMQ

Das Gateway gehört Ihnen; der Broker muss es nicht. ConnectMQ bietet Ihrem MQTT-SN-Gateway einen TLS-Endpunkt auf Port 8883, Unterstützung für MQTT 3.1.1 und 5.0 sowie einen Live-Topic-Explorer, mit dem Sie prüfen, ob Daten fließen. Erstellen Sie unter app.connectmq.com ohne Kreditkarte einen kostenlosen Serverless-Broker, übernehmen Sie die generierten Zugangsdaten in Ihre Gateway-Konfiguration, und Ihre Sensoren sind in der Cloud.

Häufig gestellte Fragen

Kann sich ein MQTT-SN-Client direkt mit einem MQTT-Broker verbinden?

Nicht mit einem Standard-Broker. MQTT-SN verwendet ein anderes Paketformat und einen anderen Transport, daher muss ein Gateway es für den Broker in MQTT über TCP übersetzen.

Unterstützt MQTT-SN QoS 2?

Ja. MQTT-SN 1.2 unterstützt QoS 0, 1 und 2 sowie den verbindungslosen Modus QoS -1 für einfache Publisher.

Ist MQTT-SN sicher?

Das Protokoll selbst hat keine Verschlüsselung. Nutzen Sie Sicherheit der Sicherungsschicht oder DTLS zwischen Sensoren und Gateway und TLS zwischen Gateway und Broker.

Welchen Port verwendet MQTT-SN?

Es gibt keinen einzelnen registrierten Port; er hängt von der Gateway-Konfiguration ab. Viele Beispiele verwenden einen UDP-Port wie 10000 oder nutzen 1883 über UDP.