MQTT Topic-Hierarchie-Beispiele für echte IoT-Projekte

Diese MQTT Topic-Hierarchie-Beispiele liefern Ihnen fertige Bäume für vier gängige Projekttypen: ein Smart Home, eine Fahrzeugflotte, eine Fabrik und ein Energiemonitoring-System. Zu jedem sehen Sie den Baum, die Subscriptions, für die er ausgelegt ist, und die Entscheidungen dahinter, sodass Sie ihn anpassen können, statt bei einem leeren Blatt anzufangen.

Prinzipien guter MQTT-Topic-Hierarchien

Jeder der folgenden Bäume folgt denselben wenigen Regeln. Wenn Sie sie kennen, fällt es leichter, die Beispiele an Ihr eigenes Projekt anzupassen.

Vom Breiten zum Engen. Setzen Sie die allgemeinste Ebene an den Anfang (Standort, Zuhause, Flotte) und die spezifischste ans Ende (ein einzelner Messwert oder Befehl).
Feste Tiefe pro Datenart. Liegt die Telemetrie jedes Geräts auf derselben Ebene, findet ein einziges +-Muster sie alle.
Daten nach Richtung trennen. Telemetrie fließt nach oben, Befehle nach unten. Geben Sie ihnen verschiedene Zweige, damit Geräte nur abonnieren, was sie brauchen.
Kleinschreibung, keine Leerzeichen, kein führender Schrägstrich. home/kitchen/temp und Home/Kitchen/Temp sind verschiedene Topics; ein führendes / erzeugt eine leere erste Ebene.
Kennungen, die Änderungen überdauern. Verwenden Sie Asset-Tags oder Seriennummern, keine menschlichen Bezeichnungen, die umbenannt werden.
Für die Subscriptions entwerfen, nicht für den Publisher. Schreiben Sie die Wildcard-Abfragen der Consumer auf, bevor Sie den Baum festlegen.

Die ausführliche Begründung finden Sie unter MQTT Topic-Namenskonventionen. Hier konzentrieren wir uns auf konkrete Bäume.

Beispiel für eine Smart-Home-Topic-Hierarchie

Ein Zuhause hat eine natürliche Struktur: Räume enthalten Geräte, Geräte stellen ihren Zustand bereit und nehmen Befehle entgegen.

home/<room>/<device>/state         # aktueller Zustand, retained
home/<room>/<device>/set           # Befehl an das Gerät
home/<room>/<device>/availability  # online/offline (Last Will)
home/<room>/<sensor>/<measurement> # numerische Messwerte

home/livingroom/lamp/state          -> {"on": true, "brightness": 70}
home/livingroom/lamp/set            -> {"on": false}
home/kitchen/climate/temperature    -> 21.4
home/kitchen/climate/humidity       -> 48
home/garage/door/state              -> "closed"
home/garage/door/availability       -> "online"

Bedarf des Consumers	Subscription
Alles in der Küche	`home/kitchen/#`
Jeder Gerätezustand	`home/+/+/state`
Jeder Temperaturwert	`home/+/+/temperature`
Welche Geräte offline sind	`home/+/+/availability`

Veröffentlichen Sie state und availability als Retained Messages, damit ein später gestartetes Dashboard sofort die aktuelle Lage kennt. Befehle sollten nicht retained sein, sonst spielt ein neu startendes Gerät das gestrige „Garagentor öffnen“ erneut ab. Eine tiefere Behandlung von Räumen, Integrationen und Home-Assistant-Discovery finden Sie im Leitfaden zur MQTT-Topic-Struktur im Smart Home.

Beispiel für eine Fahrzeugflotten-Topic-Hierarchie

Flottendaten sind um Fahrzeuge herum organisiert, und Consumer wollen meist entweder das Gesamtbild eines Fahrzeugs oder einen Datentyp über die ganze Flotte.

fleet/<region>/<vehicleId>/telemetry/<stream>
fleet/<region>/<vehicleId>/events/<eventType>
fleet/<region>/<vehicleId>/cmd/<command>
fleet/<region>/<vehicleId>/status

fleet/eu-west/van-0142/telemetry/gps      -> {"lat": 51.51, "lon": -0.12, "spd": 34}
fleet/eu-west/van-0142/telemetry/engine   -> {"rpm": 1800, "coolant": 88}
fleet/eu-west/van-0142/events/harsh-brake -> {"ts": 1792130400, "g": 0.52}
fleet/eu-west/van-0142/cmd/locate         -> {}
fleet/eu-west/van-0142/status             -> "online"

Bedarf des Consumers	Subscription
Live-Karte aller Fahrzeuge	`fleet/+/+/telemetry/gps`
Alles von einem Transporter	`fleet/+/van-0142/#`
Fahrverhaltensereignisse in einer Region	`fleet/eu-west/+/events/#`

Entscheidungen, die sich zum Übernehmen lohnen:

Region vor Fahrzeug. So können Sie die Verarbeitung später nach Region aufteilen, etwa mit Shared Subscriptions pro regionaler Worker-Gruppe.
Streams statt einer riesigen Payload. GPS im Sekundentakt und Motordaten alle dreißig Sekunden sollten nicht in dieselbe Nachricht gezwängt werden.
Befehle pro Fahrzeug. Jedes Fahrzeug abonniert fleet/<region>/<its id>/cmd/# und sonst nichts.

Beispiel für eine Fabrik-Topic-Hierarchie

In der Fertigung existiert die Anlagenhierarchie bereits in der Dokumentation des Werks, also sollte der Baum sie abbilden. Eine vereinfachte Version:

<site>/<area>/<line>/<machine>/<namespace>/<detail>

plant1/assembly/line1/robot2/telemetry/joint-temps
plant1/assembly/line1/robot2/state
plant1/assembly/line1/robot2/alarms/overtemp
plant1/machining/line3/cnc1/telemetry/spindle
plant1/machining/line3/cnc1/cmd/stop

Bedarf des Consumers	Subscription
OEE-Dienst für eine Linie	`plant1/machining/line3/+/state`
Instandhaltungsansicht aller Alarme	`plant1/+/+/+/alarms/#`
Historian für den gesamten Standort	`plant1/#`

Halten Sie das Vokabular der Namespaces klein und fest: telemetry, state, alarms, events, cmd. Erfindet ein Integrator für dasselbe data, values und measurements, muss jeder Consumer drei Muster lernen.

Die Ebenen <site>/<area>/<line>/<machine> entsprechen bereits der ISA-95-Ausrüstungshierarchie (Site → Area → Line → Cell). Ergänzen Sie das Unternehmen als oberste Ebene, wird daraus die Topic-Struktur eines Unified Namespace (UNS) auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. MES, SCADA, Historian und ERP-Anbindung abonnieren dann denselben Baum, statt über Punkt-zu-Punkt-Schnittstellen an jeder SPS einzeln zu hängen.

Beispiel für eine Energiemonitoring-Topic-Hierarchie

Energieprojekte mischen Zähler, Wechselrichter und Batterien über mehrere Gebäude. Der Baum trennt den physischen Standort von der gemessenen Energiegröße.

energy/<site>/<building>/<meterId>/<quantity>

energy/campus-a/building-3/main-meter/power       -> 42.7   (kW)
energy/campus-a/building-3/main-meter/energy      -> 18233.4 (kWh)
energy/campus-a/building-3/pv-inverter-1/power    -> 12.1
energy/campus-a/building-3/battery-1/soc          -> 76
energy/campus-a/building-3/battery-1/cmd/mode     -> "discharge"

Halten Sie Einheiten in der Dokumentation oder der Payload fest, niemals im Topic selbst. Ein Topic wie .../power_kw wird an dem Tag falsch, an dem jemand Watt veröffentlicht. Eine JSON-Payload wie {"v": 42.7, "unit": "kW", "ts": 1792130400} hält das Topic stabil und den Messwert selbstbeschreibend.

Zum Schluss: ein Unified Namespace im ISA-95-Stil

Wächst ein Industrie-4.0-Projekt über einen Standort hinaus, läuft es meist auf einen UNS hinaus, dessen Baum der ISA-95-Hierarchie (IEC 62264) folgt: Unternehmen, Standort, Bereich, Linie, Zelle oder Maschine, dann ein Daten-Namespace. Der Broker wird so zur zentralen Datendrehscheibe zwischen OT und IT, und jedes neue System findet die Daten an einer vorhersagbaren Adresse. Diese Form verwendet auch ConnectMQ, wenn es Sparkplug-B-Daten in lesbare Topics umveröffentlicht. Eine Sparkplug-Nachricht auf

spBv1.0/factory1/DDATA/line1/cnc1

wird dekodiert und erneut veröffentlicht auf

connectmq/factory1/production/line1/cnc1/telemetry

Das ergibt ein vollständiges Beispiel der Zielstruktur:

<enterprise>/<site>/<area>/<line>/<machine>/<namespace>

connectmq/factory1/production/line1/cnc1/telemetry
connectmq/factory1/production/line1/cnc1/state
connectmq/factory1/production/line2/press4/telemetry
connectmq/factory1/quality/lab/cmm1/events

Das ConnectMQ-Portal erkennt ISA-95- und UNS-Topics und zeigt Geräte nach diesen Ebenen gruppiert an, sodass sich ein disziplinierter Baum direkt in der Geräteansicht auszahlt. Der Artikel zu ISA-95-MQTT-Topics erklärt jede Ebene und ihre Fallstricke, und der Leitfaden zu Sparkplug B und Unified Namespace zeigt, wie beides zusammenpasst.

Die vier Bäume im Vergleich

Projekt	Oberste Ebene	Identitätsebene	Daten aufgeteilt nach	Typische Tiefe
Smart Home	`home`	Gerät in einem Raum	state / set / Messwert	4
Flotte	`fleet`	Fahrzeug in einer Region	telemetry / events / cmd	4–5
Fabrik	Standort	Maschine an einer Linie	Namespace	5–6
Energie	`energy`	Zähler in einem Gebäude	Messgröße	5

Die Tiefe spielt auf echten Brokern eine Rolle. Manche Broker begrenzen die Topic-Ebenen, und jede zusätzliche Ebene kostet in jeder Nachricht Bytes. Der öffentliche MQTT-Broker unter broker.connectmq.com erlaubt zum Beispiel bis zu 8 Topic-Ebenen, sodass ein Demo-Präfix wie connectmq/demo/<id> fünf Ebenen für Ihren eigenen Baum übrig lässt.

Einen Baum auf dem öffentlichen MQTT-Broker ausprobieren

Sie können jede dieser Hierarchien auf dem kostenlosen öffentlichen MQTT-Broker prototypisch testen, bevor Sie sich festlegen. Verwenden Sie ein eindeutiges Präfix, da der öffentliche MQTT-Broker für alle lesbar und nur für Tests und Prototypen gedacht ist, und halten Sie die Daten unkritisch.

# Subscriber: alle Gerätezustände in Ihrem Demo-Zuhause
mosquitto_sub -h broker.connectmq.com -p 1883 -i tree-sub-a91c \
  -t 'connectmq/demo/a91c/home/+/+/state' -v

# Publisher: ein retained Lampenzustand
mosquitto_pub -h broker.connectmq.com -p 1883 -i tree-pub-a91c -r \
  -t 'connectmq/demo/a91c/home/livingroom/lamp/state' \
  -m '{"on": true, "brightness": 70}'

Dieses Beispiel verwendet sieben Ebenen und bleibt damit innerhalb des Limits des öffentlichen Brokers. Sieht der Subscriber den Lampenzustand, funktioniert Ihr Wildcard-Plan. Probieren Sie dann connectmq/demo/a91c/home/livingroom/# und prüfen Sie, ob nur das Wohnzimmer zurückkommt. Ist der Baum neu für Sie, erklärt der Leitfaden zu MQTT-Wildcards genau, wie + und # jede Ebene matchen, und das MQTT-Tutorial behandelt die Grundlagen von Publish und Subscribe.

Häufige Fehler in Topic-Hierarchien

Den Datentyp an den Anfang setzen. temperature/kitchen verstreut jedes Gerät über viele Zweige und macht Subscriptions pro Gerät umständlich.
Werte in Topics kodieren. home/lamp/on und home/lamp/off als Topics bedeuten, dass Consumer beide abonnieren müssen; veröffentlichen Sie den Wert als Payload.
Ein Topic pro Nachrichten-ID oder Zeitstempel. Topics sind Adressen, keine Datensätze. Eindeutige Topics pro Nachricht blähen den Retained-Speicher und Topic-Listen auf.
Gemischte Trennzeichen. line-1, line_1 und Line1 im selben Baum lassen irgendwann jemandes Wildcard scheitern. Wählen Sie einen Stil.
Kein Befehlszweig. Teilen sich Befehle ein Topic mit Telemetrie, erhalten Geräte ihre eigenen Daten zurück und brauchen zusätzliche Filterung.

Mit ConnectMQ starten

Wenn Ihr Baum bereit für echte Geräte ist, betreiben Sie ihn auf einem Cloud-MQTT-Broker mit TLS und privaten Zugangsdaten. Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte, und sehen Sie zu, wie sich Ihre Hierarchie im Live-Topic-Explorer und in der ISA-95-Geräteansicht füllt.

Häufig gestellte Fragen

Wie tief sollte eine MQTT-Topic-Hierarchie sein?

Tief genug, um die Quelle und die Art der Daten zu identifizieren, meist vier bis sechs Ebenen. Mehr Ebenen fügen jeder Nachricht Bytes hinzu und können Broker-Limits erreichen, ohne nützliche Struktur zu ergänzen.

Sollte die Geräte-ID oder der Datentyp zuerst kommen?

Setzen Sie Standort und Geräteidentität an den Anfang, dann den Datentyp. So bleiben alle Daten eines Geräts in einem Zweig, und +-Wildcards können trotzdem einen Datentyp über alle Geräte auswählen.

Kann ich meine Topic-Hierarchie später ändern?

Ja, aber jeder Publisher und Subscriber muss mitziehen. Ein gängiger Migrationsweg ist, während einer Übergangsphase in den alten und den neuen Baum zu veröffentlichen und den alten erst abzuschalten, wenn alle Consumer umgezogen sind.

Brauche ich ISA-95 für ein kleines Projekt?

Nein. Ein einfacher Baum wie im Smart-Home-Beispiel reicht für kleine Projekte. Bäume im ISA-95-Stil lohnen sich, sobald sich mehrere Standorte, Teams oder Systeme einen Namespace teilen, also sobald Sie einen Unified Namespace aufbauen.