MQTT & JSON im IoT - Effiziente Daten für Ihr System

Für IoT-Systeme ist nicht nur wichtig, dass Daten ankommen, sondern auch, dass sie schnell, sparsam und für verschiedene Komponenten verständlich bleiben. MQTT übernimmt dabei den leichten Versand über den Broker, während JSON die Nutzdaten in eine Struktur bringt, die sich in Gateways, Dashboards und APIs ohne großen Übersetzungsaufwand verarbeiten lässt. Gerade bei knapper Bandbreite, wechselnder Verbindung oder vielen kleinen Sensorpaketen zahlt sich diese Kombination aus, wenn man sie sauber aufsetzt.

Warum MQTT und JSON im IoT gut zusammenpassen

Ich setze MQTT dort ein, wo Geräte kleine Nachrichten an viele Empfänger verteilen sollen. Der Standard ist bewusst payload-agnostisch, und JSON ist ein textbasiertes Format für strukturierte Daten. Zusammen ergibt das eine Mischung, die für Geräte, Broker, Backend und Frontend gut anschlussfähig bleibt.

Der praktische Vorteil liegt nicht im Protokoll selbst, sondern in der Arbeitsweise dahinter: Sensoren senden Messwerte, ein Broker verteilt sie, und verschiedene Systeme lesen dieselbe Nachricht ohne proprietäre Umwandlung. Das ist für Telemetrie, Zustandsdaten, Alarme und einfache Steuerbefehle oft die pragmatischste Lösung. Gerade bei Infrastruktur- und Telekommunikationsprojekten in Regionen mit knapper oder wechselnder Konnektivität ist diese Reduktion von Overhead kein Luxus, sondern ein echter Betriebsfaktor. Im nächsten Schritt lohnt sich deshalb ein Blick darauf, wie eine solche Nachricht sauber aufgebaut ist.

So sieht eine saubere Nachricht mit JSON-Payload aus

Ich trenne immer drei Ebenen: Topic für das Routing, Payload für die Fachdaten und Properties für Metadaten. Wer diese Trennung sauber hält, vermeidet später viel Reibung beim Skalieren, Debuggen und Integrieren.

Topic: tl/dili/gateway-07/telemetry

Payload:
{
  "device_id": "gw-07",
  "ts": "2026-06-10T12:15:00Z",
  "temp_c": 28.4,
  "humidity_rh": 71,
  "battery_v": 3.78,
  "status": "ok"
}

Welche JSON-Strukturen sich im Feld bewähren

JSON über Netzwerke gehört in UTF-8. Werte wie `NaN` oder `Infinity` gehören nicht hinein, und auf die Reihenfolge von Objektmitgliedern sollte man sich nicht verlassen. Arrays nutze ich nur dann, wenn die Reihenfolge wirklich Bedeutung hat, etwa bei Messreihen oder historischen Daten. So bleibt das Format auch dann noch zuverlässig, wenn mehrere Systeme daran andocken. Daraus folgt die nächste praktische Frage: Reicht JSON immer aus, oder ist ein binäres Format manchmal die bessere Wahl?

Wann JSON reicht und wann ein binäres Format besser ist

JSON ist oft der beste Startpunkt, aber nicht immer das Endformat. Sobald Bandbreite, Energieverbrauch oder Parser-Last messbar werden, schaue ich mir ernsthaft Alternativen an.

Ich bleibe bei JSON, wenn Menschen die Daten direkt lesen oder mehrere Systeme schnell andocken sollen. Ich wechsle erst dann auf ein binäres Format wie CBOR, MessagePack oder Protobuf, wenn der praktische Nutzen messbar wird. Das ist im Alltag fast immer eine Frage von Datenvolumen, Latenz und Wartbarkeit, nicht von Ideologie. Und genau an dieser Stelle passieren in echten Projekten die meisten vermeidbaren Fehler.

Typische Fehler, die ich in IoT-Projekten immer wieder sehe

Die Probleme sind selten spektakulär, aber sie kosten Zeit. Meist entstehen sie dort, wo Transport, Datenmodell und Betrieb zu wenig sauber voneinander getrennt werden.

• Zu viele Fachdetails im Topic - Wenn das Topic selbst schon wie ein Datensatz aussieht, wird das Routing fragil und später schwer zu ändern.
• Wildcard-Zeichen in Publish-Topics - `+` und `#` gehören in Subscriptions, nicht in veröffentlichte Topic-Namen.
• Retained Messages für Live-Telemetrie - Retain ist sinnvoll für den letzten Zustand, nicht für jede einzelne Messung.
• Doppelte Schlüssel im JSON - Unterschiedliche Parser können auf denselben Payload verschieden reagieren.
• Falsche Kodierung - Wenn JSON nicht sauber in UTF-8 vorliegt, entstehen schnell schwer diagnostizierbare Fehler.
• Zu große oder ungenaue Zahlen - Präzisionswerte, IDs oder Summen sollten mit Blick auf die Zielumgebung modelliert werden, nicht nur für den schnellen Prototyp.
• Keine Ablaufzeit für temporäre Nachrichten - Befehle und Warnungen können veralten; ohne `Message Expiry` bleiben sie zu lange relevant.
• Unklare Semantik zwischen Topic und Payload - Wenn dieselbe Information an zwei Stellen steckt, entstehen Inkonsistenzen.

Wenn ich diese Punkte früh prüfe, sinkt die Zahl der Feldprobleme deutlich. Der nächste Hebel liegt dann nicht mehr im Schema, sondern in der Art, wie man das Setup für schmale Netze und reale Betriebsbedingungen auslegt.

Wie ich ein robustes Setup für schmale Netze aufbaue

In Netzen mit knapper oder schwankender Konnektivität optimiere ich zuerst die Zustellung, dann die Nutzlast und erst danach die Feinheiten. Gerade in IoT-Umgebungen mit vielen kleinen Nachrichten bringt diese Reihenfolge mehr als jede kosmetische Änderung am Datenmodell.

Der kleine, aber oft entscheidende Punkt ist hier `Topic Alias`: Wenn Topic-Namen lang sind und immer wieder auftauchen, spart das in MQTT 5 spürbar Platz. In einem Netz mit knappen Datenbudgets wirkt sich das schneller aus, als man auf den ersten Blick erwartet. Ich optimiere deshalb zuerst Nutzlast, Zustellweg und Lebensdauer der Nachricht, nicht die Ästhetik der Feldnamen. Bleibt nur noch die Frage, wie man daraus eine belastbare Arbeitsweise für echte Projekte ableitet.

Womit sich stabile MQTT-JSON-Pipelines schneller bauen lassen

Wenn ich ein neues IoT-Projekt aufsetze, definiere ich zuerst den Nachrichtenvertrag: Topic-Hierarchie, Feldnamen, Einheiten, Zeitformat und Zustandslogik. Erst danach kommen Broker, Visualisierung und Automatisierung, weil spätere Änderungen sonst unnötig teuer werden.

• Halte Topic-Namen kurz, stabil und eindeutig.
• Versioniere das Payload-Schema, statt Felder stillschweigend umzubenennen.
• Dokumentiere Einheiten direkt am Feld oder in einem klaren Datenvertrag.
• Prüfe eingehende JSON-Nachrichten sowohl am Consumer als auch an der Integrationskante.

So entsteht eine Kommunikationsschicht, die nicht nur heute funktioniert, sondern auch dann noch wartbar bleibt, wenn aus ein paar Sensoren ein echter Betrieb mit Gateways, Alarmsystemen und mehreren Standorten wird. Genau an dieser Stelle treffen effiziente Übertragung und saubere Datenstruktur aufeinander, und dort spielt die Kombination aus MQTT und JSON ihre größte Stärke aus.