MQTT-Topics, Wildcards und bewährte Vorgehensweisen – MQTT Essentials: Teil 5

MQTT-Topics sind ein grundlegender Bestandteil des MQTT-Protokolls, wenn es darum geht, Nachrichten zwischen Publishern und Subscribern zu übermitteln. Sie fungieren als „Adressen“, die festlegen, wohin jede Nachricht gesendet werden soll. Im Gegensatz zu herkömmlichen Messaging-Queues sind MQTT-Themen hierarchisch aufgebaut und ermöglichen ein sehr flexibles Publish/Subscribe-Kommunikationsmodell. Dies ist Teil 5 der MQTT Essentials, in dem wir uns auf MQTT-Themen, MQTT-Wildcards und bewährte Vorgehensweisen für deren Einsatz konzentrieren. In diesem Artikel betrachten wir auch SYS-Themen, die Einblicke in den Broker selbst bieten.

Was sind MQTT-Themen und welche Rolle spielen sie bei der Nachrichtenfilterung in MQTT?

In der Welt von MQTT bezeichnet ein Topic eine UTF-8-Zeichenkette, die Nachrichten für einen verbundenen Client filtert. Ein Topic besteht aus einer oder mehreren Ebenen, die durch einen Schrägstrich (Topic-Level-Trennzeichen) getrennt sind. Die UTF-8-Zeichenketten dienen als Identifikatoren für Nachrichten und ermöglichen ein Publish/Subscribe-System, bei dem Publisher Nachrichten an bestimmte Topics senden und Subscriber diese Topics abonnieren können, um relevante Nachrichten zu empfangen. Sie sind entscheidend für die Weiterleitung von Nachrichten zwischen Clients, da der Broker die Topic-Abonnements nutzt, um Nachrichten zu filtern und an die entsprechenden Subscriber zuzustellen.

Topics sind oft hierarchisch aufgebaut, mit Ebenen, die durch Schrägstriche (/) getrennt sind. Ein Beispiel: Das Topic „sensors/temperature/livingroom“ steht für eine Temperaturmessung von einem Sensor im Wohnzimmer.

The Basics of MQTT Topics

Im Vergleich zu einer Message Queue sind MQTT-Themen sehr leichtgewichtig. Der Client muss das gewünschte Topic nicht vorher erstellen, bevor er es veröffentlicht oder abonniert. Der Broker akzeptiert jedes gültige Topic ohne vorherige Initialisierung.

MQTT-Topic-Namen vs. Topic-Filter:

Publisher verwenden „Topic-Namen“, um Nachrichten zu senden, während Subscriber „Topic-Filter“ verwenden, um anzugeben, von welchen Topics sie Nachrichten empfangen möchten. Topic-Filter können auch Wildcards enthalten (z. B. „+“ oder „#“), um mehrere Topics abzudecken.

Im Vergleich zu einer Message Queue sind MQTT-Themen sehr leichtgewichtig. Der Client muss das gewünschte Topic nicht vorher erstellen, bevor er es veröffentlicht oder abonniert. Der Broker akzeptiert jedes gültige Topic ohne vorherige Initialisierung.

Beispiele für MQTT-Themen

Hier sind einige Beispiele für MQTT-Themen:

myhome/groundfloor/livingroom/temperature: Dieses Topic steht für die Temperatur im Wohnzimmer eines Hauses im Erdgeschoss.

USA/California/San Francisco/Silicon Valley: Diese Topic-Hierarchie kann verwendet werden, um Informationen oder Ereignisdaten im Zusammenhang mit dem Silicon Valley in San Francisco, Kalifornien, USA auszutauschen oder zu verfolgen.

5ff4a2ce-e485-40f4-826c-b1a5d81be9b6/status: Dieses Topic könnte genutzt werden, um den Status eines bestimmten Geräts oder Systems zu überwachen, das durch eine eindeutige Kennung identifiziert wird.

Germany/Bavaria/car/2382340923453/latitude: Diese Topic-Struktur könnte verwendet werden, um die Breitenkoordinaten eines bestimmten Fahrzeugs in der Region Bayern, Deutschland, zu übermitteln.

Was sind MQTT-Wildcards und wie verwendet man sie bei Topic-Abonnements?

In MQTT bieten Wildcards eine leistungsstarke Möglichkeit, mehrere Topics gleichzeitig zu abonnieren. Wenn ein Client ein Topic abonniert, kann er entweder das exakte Topic einer veröffentlichten Nachricht abonnieren oder Wildcards verwenden, um seine Subscription auszuweiten. Es ist wichtig zu beachten, dass Wildcards nur für Abonnements und nicht für das Veröffentlichen von Nachrichten verwendet werden können. Es gibt zwei Arten von Wildcards: single-level und multi-level.

MQTT Wildcard – Single Level: +

Die single-level wildcard wird durch das Pluszeichen (+) dargestellt und ermöglicht das Ersetzen einer einzelnen Topic-Ebene. Wenn man ein Topic mit einer single-level wildcard abonniert, wird jedes Topic berücksichtigt, das an der Stelle der Wildcard eine beliebige Zeichenfolge enthält.

Beispiel zur Verwendung der MQTT-Wildcard für eine einzelne Ebene (+)

Ein Abonnement auf myhome/groundfloor/+/temperature kann zum Beispiel folgende Ergebnisse liefern:

MQTT Wildcard – Multi Level:

Die Multi-Level Wildcard deckt mehrere Topic-Ebenen ab. Sie wird durch das Rautezeichen (#) dargestellt und muss als letztes Zeichen im Topic stehen, wobei ihr ein Schrägstrich vorausgehen muss.

Wenn ein Client ein Topic mit einer Multi-Level Wildcard abonniert, empfängt er alle Nachrichten von Topics, die mit dem Muster vor dem Wildcard-Zeichen beginnen – unabhängig von der Länge oder Tiefe des Topics. Wenn das Topic lediglich als „#“ angegeben ist, empfängt der Client alle Nachrichten, die an den MQTT-Broker gesendet werden.

MQTT Topic wildcard hash example

Es ist jedoch wichtig zu beachten, dass das Abonnieren mit einer alleinstehenden Multi-Level Wildcard ein Anti-Pattern sein kann, wenn ein hoher Datendurchsatz erwartet wird. Das Abonnieren eines sehr allgemeinen Topics kann dazu führen, dass eine große Menge an Nachrichten an den Client gesendet wird, was sich negativ auf die Systemleistung und die Bandbreitennutzung auswirken kann. Befolgen Sie bewährte Vorgehensweisen, um Topic-Abonnements zu optimieren und eine unnötige Nachrichtenflut zu vermeiden.

Warum und wann man MQTT-Themen verwenden sollte, die mit $ beginnen

Im MQTT-Protokoll ist die Themenbenennung sehr flexibel, sodass Sie Namen wählen können, die Ihren Anforderungen entsprechen. Es gibt jedoch eine wichtige Ausnahme: Themen, die mit dem Dollarzeichen ($) beginnen, haben einen besonderen Zweck. Diese Themen werden bei der Verwendung der Mehrfach-Wildcard (#) nicht in das Abonnement einbezogen. Stattdessen sind sie für interne Statistiken des MQTT-Brokers reserviert und bieten wertvolle Einblicke in dessen Betrieb.

Das Veröffentlichen von Nachrichten auf Themen, die mit $ beginnen, ist nicht erlaubt, da diese Themen dem Broker dazu dienen, interne Informationen und Statistiken für Clients bereitzustellen. Obwohl es derzeit keine offizielle Standardisierung für diese Themen gibt, ist es üblich, das Präfix $SYS/ zu verwenden, um solche Informationen zu kennzeichnen. Die konkrete Umsetzung kann sich je nach Broker unterscheiden.

Eine empfohlene Quelle zum Verständnis von $SYS-Themen ist die MQTT GitHub Wiki-Seite.

Beispiele für $SYS-Themen und deren Informationen

• $SYS/broker/clients/connected: Zeigt die Anzahl der derzeit mit dem Broker verbundenen Clients.

• $SYS/broker/clients/disconnected: Zeigt die Anzahl der Clients, die sich vom Broker getrennt haben.

• $SYS/broker/clients/total: Gibt die Gesamtzahl aller Clients an (verbunden und getrennt), die jemals mit dem Broker kommuniziert haben.

• $SYS/broker/messages/sent: Zeigt die Gesamtanzahl der vom Broker gesendeten Nachrichten.

• $SYS/broker/uptime: Zeigt an, wie lange der Broker bereits läuft.

Diese $SYS-Themen bieten wichtige Einblicke in die interne Funktionsweise und Leistung des MQTT-Brokers. Administratoren und Entwickler können damit wichtige Metriken überwachen und analysieren.

Verständnis der dynamischen Natur von MQTT-Themen

Das sind die Grundlagen von MQTT-Topics. Wie Sie sehen, sind MQTT-Themen dynamisch und bieten große Flexibilität. Beim Einsatz von Wildcards in der Praxis gibt es Herausforderungen, die Sie kennen sollten. Wir haben aus vielen Projekten die bewährtesten Methoden zusammen getragen und sind offen für Ihre Erfahrungen. Schreiben Sie gerne Ihre Ansichten in die Kommentare oder teilen Sie Ihre Best Practices!

Bewährte Methoden für MQTT-Themen

• Mindestens ein Zeichen: Jedes Topic muss mindestens ein Zeichen enthalten.

• Groß- und Kleinschreibung beachten: Topics sind case-sensitive – myhome/temperature ≠ MyHome/Temperature.

• Kein anführender Schrägstrich (/): Er fügt eine zusätzliche leere Ebene hinzu und kann zu Verwirrung führen.

• Keine Leerzeichen verwenden: Sie erschweren das Debugging und können unterschiedlich codiert sein.

• Kurz und prägnant halten: Da jedes Topic in jeder Nachricht enthalten ist, spart eine kurze Benennung Bandbreite.

• Nur ASCII-Zeichen verwenden: Vermeiden Sie nicht druckbare oder Nicht-ASCII-Zeichen zur besseren Lesbarkeit.

• Client-ID oder eindeutige Kennung einbetten: Z. B. client1/status erlaubt einfache Identifikation und Zugriffskontrolle.

• Vermeiden Sie Wildcard-Abos (#): Abonnieren Sie nicht blind alles – das kann Clients überlasten. Nutzen Sie Broker-Erweiterungen, z. B. mit HiveMQ Extensions.

• Für zukünftiges Wachstum planen: Strukturieren Sie Topics so, dass neue Geräte oder Sensoren leicht hinzugefügt werden können.

• Spezifische statt allgemeine Topics: Z. B. myhome/livingroom/temperature statt nur myhome/livingroom.

• Dokumentation pflegen: Halten Sie fest, welche Topics was tun, wie Payloads aussehen und welche Konventionen gelten.

• Regelmäßige Optimierung: Überprüfen Sie Ihre Struktur regelmäßig auf Effizienz und Skalierbarkeit.

• Sicherheitsaspekte beachten: Achten Sie darauf, keine sensiblen Infos über die Topics preiszugeben. Nutzen Sie Authentifizierung und Zugriffskontrollen.

MQTT-Designmuster für Industrielle Anwendungen

In industriellen Umgebungen ist eine durchdachte Topic-Struktur besonders entscheidend – aufgrund der Vielzahl an Geräten, Datenpunkten und Prozessen. Die Erfahrung von HiveMQ zeigt: Gute Topic-Designs verbessern die Leistung, Skalierbarkeit und Wartbarkeit von Systemen erheblich.

Hierarchisches Topic-Design für Industrial IoT

Industrielle Anwendungen profitieren von einem Topic-Design, das einer hierarchischen Struktur folgt – vom Allgemeinen zum Spezifischen. Dieser Ansatz passt gut zur typischen Organisation industrieller Systeme.

Ein Fertigungsunternehmen könnte beispielsweise folgende Struktur verwenden:

Dieser hierarchische Ansatz erleichtert es:

• Daten logisch im gesamten Unternehmen zu organisieren

• Bestimmte Informationsebenen gezielt zu abonnieren

• Das System mit dem Unternehmenswachstum zu skalieren

• Zugriffsrichtlinien umzusetzen

ISA-95-Modell für Topic-Design

Viele Fertigungsunternehmen strukturieren ihre MQTT-Themen nach dem ISA-95-Modell für Geräteeinrichtungen – ein gängiger Standard in industriellen Umgebungen. Dieser Ansatz ermöglicht eine natürliche Zuordnung zwischen physischen Anlagen und ihren digitalen Repräsentationen.

Eine typische, auf ISA-95 basierende Topic-Struktur könnte wie folgt aussehen:

Dieser strukturierte Ansatz sorgt für Konsistenz im gesamten Unternehmen und erleichtert Systemen die Erkennung und Interpretation von Daten.

Die Rolle von MQTT-Themen beim Aufbau eines Unified Namespace (UNS)

Der Unified Namespace (UNS) hat sich als leistungsstarkes Architekturmodell für Industrial IoT etabliert und basiert stark auf gut gestalteten MQTT-Themen. Ein UNS schafft eine zentrale, hierarchische Datenstruktur, die als „Single Source of Truth“ für ein Unternehmen dient.

Ein intelligentes Fertigungssystem kann auf einer UNS-Architektur basieren und die ISA-95-Norm nutzen, um die Datenobjekte zu modellieren, die in den Namespace eingespeist werden.

In einer UNS-Architektur bilden MQTT-Themen das Rückgrat der Datenhierarchie. Der MQTT-Broker organisiert die Daten mithilfe einer Themenhierarchie, die als strukturiertes Rahmenwerk für den Datenzugriff innerhalb des UNS dient. Dies ermöglicht:

• Echtzeit-Datenaustausch zwischen Systemen

• Effizientes Routing und Filtern von Daten

• Einheitliche Datenrepräsentation

• Leichte Auffindbarkeit verfügbarer Daten

• Vereinfachte Integration unterschiedlicher Systeme

Beispiel für ein UNS-Topic-Design

Hier ist ein Beispiel dafür, wie ein Unified Namespace (UNS) Themen in einer Fertigungsumgebung organisieren könnte:

Diese Struktur ermöglicht es Teilnehmern im MQTT-Netzwerk, gezielt auf bestimmte Datenebenen zuzugreifen.

Ein Supervisor könnte beispielsweise manufacturing/plantA/machines/+/# abonnieren, um alle Nachrichten zu Maschinen in Werk A zu erhalten. Ein Qualitätsanalyst könnte hingegen manufacturing/plantB/quality_control/testing/# abonnieren, um alle Daten zu Tests im Werk B zu empfangen.

Fazit

Damit sind wir am Ende von Teil 5 unserer MQTT Essentials-Reihe angekommen. Zusammenfassend lässt sich sagen, dass MQTT-Themen das Rückgrat der flexiblen und effizienten Nachrichtenkommunikation im MQTT-Protokoll bilden. Durch ein genaues Verständnis der Funktionsweise und die Anwendung bewährter Praktiken können Sie Ihre MQTT-Implementierungen für maximale Leistung und Skalierbarkeit optimieren.

In diesem Artikel haben wir die dynamische Natur von MQTT-Themen untersucht, insbesondere die Verwendung von Wildcards, technische Aspekte und empfohlene Strategien. Wir haben erklärt, warum führende Schrägstriche und Leerzeichen in Topics vermieden werden sollten, warum Themen kurz gehalten und ASCII-Zeichen verwendet werden sollten und warum es sinnvoll ist, eindeutige Bezeichner oder Client-IDs in Topics einzubetten. Ebenso wurde betont, warum es problematisch sein kann, alle Nachrichten mittels Wildcard zu abonnieren, und welche Rolle Erweiterbarkeit im Topic-Design spielt.

Wenn Sie diese Best Practices befolgen, verbessern Sie die Lesbarkeit, Wartbarkeit und Sicherheit Ihrer MQTT-Infrastruktur. Wir hoffen, dieser Artikel hat Ihnen wertvolle Einblicke und praktische Informationen geliefert, um Ihre MQTT-Projekte auf das nächste Level zu bringen. Vielen Dank, dass Sie uns auf dieser Reise durch die Feinheiten von MQTT-Themen begleitet haben. Wir hoffen, Sie fanden den Artikel nützlich und informativ.

Was erwartet Sie in Teil 6? In Teil 6 dieser Serie beschäftigen wir uns mit den Quality of Service (QoS)-Stufen in MQTT. Wir erklären, warum dieses Feature so wichtig ist und wie Sie es gezielt einsetzen können.

Möchten Sie verstehen, wie MQTT-Control-Pakete aufgebaut sind und wie man damit MQTT-basierte Systeme entwirft und testet? Dann lesen Sie unseren Blog: MQTT Packets: A Comprehensive Guide.