Funktionsweise, Vorteile & Anwendungsbeispiele
Was ist MQTT?
MQTT ist ein robustes Netzwerkprotokoll für den Datenaustausch zwischen Maschinen, Geräten und anderen Anwendungen. Es basiert auf einem Publish-Subscribe-Modell und hat sich als eines der wichtigsten Protokolle für das Internet of Things (IoT) etabliert. MQTT wird sowohl in der Industrie als auch in der Heimautomatisierung vielfach eingesetzt.
Definition
Was bedeutet MQTT?
MQTT (Message Queuing Telemetry Transport) ist ein offenes, leichtgewichtiges Netzwerkprotokoll, über das Maschinen, Sensoren und Anwendungen Nachrichten nach dem Publish/Subscribe-Prinzip über einen zentralen Broker austauschen. Sender (Publisher) und Empfänger (Subscriber) kennen sich dabei nicht: Sie verbinden sich nur mit dem Broker, der die Nachrichten anhand ihres Themas (Topic) verteilt.
Entwickelt wurde MQTT 1999 von Andy Stanford-Clark (IBM) und Arlen Nipper (Arcom), um Ölpipelines über Satellitenverbindungen mit geringer Bandbreite zu überwachen. Seit 2014 ist das MQTT-Protokoll ein offener Standard der OASIS (Version 3.1.1), seit 2016 auch als ISO/IEC 20922 genormt. 2019 folgte MQTT 5.0. Die Bezeichnung MQTT gilt heute als Eigenname, die frühere Langform „Message Queuing Telemetry Transport“ ist aber weiterhin geläufig.
MQTT setzt auf TCP/IP auf und nutzt standardmäßig den Port 1883, verschlüsselt mit TLS den Port 8883. In der Industrie sind beide Versionen verbreitet: MQTT 5 ergänzt unter anderem Rückmeldecodes (Reason Codes), geteilte Abonnements (Shared Subscriptions), ein Ablaufdatum für Nachrichten und frei definierbare Eigenschaften (User Properties). Damit ist MQTT neben OPC UA eines der wichtigsten Protokolle für die Machine-to-Machine-Kommunikation (M2M) im Industrial Internet of Things (IIoT). Die wichtigsten Funktionen des MQTT-Protokolls – Publish/Subscribe, Topics, Zustellgarantien, Retained Messages und Last Will – erklären die folgenden Abschnitte.
Erklärung
Wie funktioniert MQTT?
MQTT (ehemals eine Abkürzung für Message Queuing Telemetry Transport) ist ein offenes und ressourcensparendes Netzwerkprotokoll für den Austausch von Nachrichten zwischen Geräten, Maschinen und anderen Systemen. Aufgrund seiner Verlässlichkeit hat es sich als eines der wichtigsten Protokolle für das Internet of Things (IoT) etabliert. Im OSI-Modell ist MQTT auf der Anwendungsschicht angesiedelt.
Im Mittelpunkt der Kommunikation steht bei MQTT der sogenannte MQTT-Broker.
MQTT-Clients schicken Messages (Nachrichten) zu einem Topic (Thema) an den Broker. Der Broker wiederum leitet diese Nachrichten automatisch an alle Clients weiter, die das jeweilige Topic abonniert haben. Damit agiert der MQTT-Broker als zentraler Vermittler zwischen den MQTT-Clients.
Diese Kommunikationsstruktur hat einen wichtigen Vorteil: Der leistungsfähige, oft in der Cloud oder lokal im Werksnetz betriebene Broker verwaltet Sitzungen und Daten, während die beteiligten Client-Geräte lediglich ausgewählte Nachrichten schicken und erhalten. Dadurch sind auch kleinere, weniger leistungsfähige Geräte wie Sensoren, eingebettete Geräte und industrielle Steuerungen in der Lage, an der MQTT-Kommunikation teilzunehmen. Außerdem wird die Netzwerkbandbreite weniger stark ausgelastet.
Zudem definiert MQTT bestimmte Mechanismen zum Umgang mit Verbindungsunterbrechungen (siehe „Wie geht MQTT mit Verbindungsabbrüchen um?“).
MQTT-Kommunikation einfach erklärt
Im Regelfall läuft der Datenaustausch über MQTT folgendermaßen ab:
- Geräte oder andere Anwendungen übermitteln Nachrichten an einen MQTT-Broker (manchmal auch als MQTT-Server bezeichnet). Diese Nachrichten sind jeweils mit einem Topic versehen. MQTT-Clients, die auf diese Weise Nachrichten über den MQTT-Broker veröffentlichen, nennt man Publisher.
- Geräte oder andere Anwendungen abonnieren ausgewählte Topics bei dem MQTT-Broker. Der Broker sendet neue Nachrichten zu einem Topic automatisch an Clients, welche dieses Topic abonniert haben (Subscriber).
Verschiedene MQTT-Clients kommunizieren demnach nie direkt miteinander, sondern immer über einen zentralen Broker.
Ein MQTT-Broker ist keine Datenbank und speichert im Normalfall keine früheren Nachrichten zu einem Topic. Mithilfe sogenannter „Retained Messages“ können jedoch ausgewählte Nachrichten dauerhaft gespeichert und automatisch an neue Abonnenten eines Topics übermittelt werden.
Was ist ein MQTT-Broker?
Ein MQTT-Broker ist ein Server, der oft in der Cloud betrieben wird. Er übernimmt die Verteilung von Nachrichten an die MQTT-Clients. Dazu muss er die Sitzungen der Clients speichern, d. h. welche Clients welche Topics abonniert haben.
In der Produktion läuft der Broker häufig auf einem Server oder Edge-Gerät im Werksnetz, damit Maschinendaten das lokale Netz nicht ungeschützt verlassen. Welche Broker sich für industrielle Anforderungen eignen, zeigt unser Vergleich kommerzieller MQTT-Broker.
Was ist ein MQTT-Client?
Ein MQTT-Client kann sowohl als Publisher als auch Subscriber auftreten. Ein Subscriber-Client empfängt neue Nachrichten zu einem oder mehreren Topics, die er abonniert hat. Ein Publisher-Client veröffentlicht Nachrichten zu einem Topic, die dann durch den Broker an die Subscriber weitergeleitet werden. Genau genommen ist der MQTT-Client ein kleines Programm, welches auf einem Sensor, Rechner oder einem anderen Gerät installiert ist und die MQTT-Funktionalität ermöglicht.
Was sind MQTT-Topics?
Jede MQTT-Nachricht ist einem bestimmten Topic zugeordnet. Der MQTT-Broker verwaltet Topics und die dazugehörigen Nachrichten in einer hierarchischen Struktur, die einem Dateisystem auf einem PC ähnelt.
Ein Topic könnte z. B. nach dem folgenden Muster aufgebaut sein:
Produktionsstandort/Produktionslinie/Anlage/Messwert
Clients können beliebige Hierarchieebenen eines Topics abonnieren. Dafür gibt es zwei Platzhalter (Wildcards): + steht für genau eine Ebene, # für alle folgenden Ebenen. Das Abonnement Werk1/Linie3/+/Temperatur liefert die Temperatur aller Anlagen der Linie 3, Werk1/Linie3/# sämtliche Werte dieser Linie.
Für die Produktion hat sich eine Topic-Struktur bewährt, die dem Aufbau des Unternehmens folgt – etwa Unternehmen, Werk, Bereich, Linie und Anlage nach dem Ebenenmodell ISA-95. Sprechende, einheitliche Namen ohne Leerzeichen und Sonderzeichen erleichtern Abonnements und Auswertungen. Auf dieser Idee baut der Unified Namespace auf.
Was ist die MQTT-Payload?
Die MQTT-Payload ist der eigentliche Inhalt einer MQTT-Nachricht. Zusätzlich zu diesem Inhalt muss für jede Nachricht ein Topic und ein Quality of Service (QoS)-Level spezifiziert werden. Das Format der Payload legt MQTT nicht fest: Üblich sind einfache Werte, JSON-Objekte oder Binärformate.
Was ist die Quality of Service (QoS)?
Die Quality of Service (QoS) einer MQTT-Nachricht definiert, wie oft die Nachricht an die Subscriber eines Topics verschickt wird.
Folgende QoS sind möglich:
- At most once (0): Die Nachricht wird nur einmal verschickt und es erfolgt keine Bestätigung über die erfolgreiche Zustellung.
- At least once (1): Die Nachricht wird wiederholt versendet, bis eine Empfangsbestätigung vorliegt.
- Exactly once (2): Durch einen Austausch zwischen Client und Broker wird sichergestellt, dass die Nachricht genau einmal zugestellt wird. Dies ist die zuverlässigste QoS, erfordert aber eine mehrfache Datenübertragung zwischen Client und Broker und ist daher auch am ressourcenintensivsten.
QoS
QoS-Stufen von MQTT im Vergleich
Die QoS-Stufe legt fest, welche Zustellgarantie MQTT für eine Nachricht gibt. Je höher die Stufe, desto höher die Zuverlässigkeit der Zustellung – und desto mehr Pakete gehen zwischen Client und Broker hin und her. In der Produktion wählt man die Stufe deshalb je Datenart.
| Kriterium | QoS 0 – At most once | QoS 1 – At least once | QoS 2 – Exactly once |
|---|---|---|---|
| Zustellung | Höchstens einmal, Verlust möglich | Mindestens einmal | Genau einmal |
| Bestätigung | Keine | PUBACK vom Empfänger | Vierstufig: PUBLISH, PUBREC, PUBREL, PUBCOMP |
| Doppelte Nachrichten | Nein | Möglich, der Empfänger muss sie erkennen | Nein |
| Netz- und Gerätelast | Gering | Mittel | Hoch |
| Typischer Einsatz in der Produktion | Zyklische Messwerte wie Temperatur oder Druck im Sekundentakt – der nächste Wert folgt ohnehin | Zustands- und Störmeldungen einer Anlage | Zählerstände, Auftragsquittungen und Buchungen, die nicht doppelt ankommen dürfen |
Die Stufe gilt je Strecke: Publisher und Broker sowie Broker und Subscriber handeln sie getrennt aus. Abonniert ein Subscriber mit Stufe 0, erhält er eine Nachricht auch dann ohne Bestätigung, wenn sie mit Stufe 2 veröffentlicht wurde. Für Subscriber, die gerade nicht verbunden sind, hält der Broker Daten nur bei einer persistenten Sitzung und Stufe 1 oder 2 vor.
Wie geht MQTT mit Verbindungsabbrüchen um?
Wenn die Verbindung eines Publisher-Clients zum Broker unerwartet abbricht, kann eine sogenannte „Last Will“-Nachricht zu einem bestimmten Topic veröffentlicht werden. Diese Nachricht hinterlegt der Client bereits beim Verbindungsaufbau; der Broker verschickt sie selbst, sobald er den Abbruch bemerkt – etwa weil das vereinbarte Keep-Alive-Signal ausbleibt. Mithilfe dieser können Abonnenten des Topics benachrichtigt werden, dass der Client nicht mehr erreichbar ist. In der Produktion meldet so zum Beispiel eine Steuerung automatisch „offline“, wenn ihre Netzverbindung ausfällt.
Ist der Abonnent eines Topics nicht erreichbar, können Nachrichten durch den Broker zwischengespeichert und zu einem späteren Zeitpunkt gesendet werden. Voraussetzung ist eine persistente Sitzung (Persistent Session) und QoS 1 oder 2.
Welche Sicherheitsmaßnahmen gibt es bei MQTT?
Die Berechtigungen von MQTT-Clients werden durch den Broker verwaltet. Hier kann festgelegt werden, welche Clients auf welche Topics zugreifen können. Außerdem ist es üblich, dass Clients sich gegenüber dem Broker mit Benutzernamen und Passwort authentifizieren müssen.
Die übermittelten Daten werden in der Regel mittels TLS verschlüsselt.
Sicherheit bei MQTT: 4 Risiken und was dagegen hilft
MQTT selbst ist so sicher wie seine Konfiguration. Das Protokoll bringt Funktionen für Anmeldung, Verschlüsselung und Berechtigungen mit, schaltet sie aber nicht von selbst ein. In der Produktion transportiert das Protokoll Maschinendaten und manchmal auch Befehle – deshalb gehören die folgenden vier Maßnahmen zu jeder Installation.
Broker offen erreichbar
Ein Broker, der auf Port 1883 ohne Anmeldung aus dem Internet erreichbar ist, liefert jedem seine Daten. Den Broker deshalb im Werksnetz betreiben oder nur über verschlüsselte, angemeldete Verbindungen freigeben.
Daten im Klartext
Ohne Verschlüsselung lassen sich Nachrichten mitlesen und verändern. TLS verschlüsselt die Verbindung zwischen Client und Broker, üblicherweise über Port 8883.
Fremde Clients
Jeder Client sollte sich am Broker anmelden – mit Benutzername und Passwort oder, sicherer, mit einem Client-Zertifikat.
Zu weite Rechte
Topic-Berechtigungen (Access Control Lists) legen je Client fest, was er lesen und schreiben darf. Ein Energiezähler braucht zum Beispiel nur Schreibrechte auf sein eigenes Topic.
Was sind die Vorteile von MQTT?
Der Datenaustausch per MQTT bietet zentrale Vorteile für die IoT-Kommunikation – vor allem dann, wenn kleinere Geräte oder begrenzte Netzwerkressourcen vorhanden sind.
Geringe Netzwerkauslastung
MQTT ist ein leichtgewichtiges und effizientes Protokoll. Datenpakete (Header) sind schlank, da MQTT ein binäres Nachrichtenformat verwendet (HTTP beispielsweise nutzt ein textbasiertes Nachrichtenformat).
Kommunikation über instabile Netzwerke
Aufgrund der geringen Netzwerkauslastung (siehe oben) und den Mechanismen zum Umgang mit Verbindungsabbrüchen eignet sich MQTT auch für den Datenaustausch in unzuverlässigen Netzwerken.
Geringe Anforderungen an Geräteressourcen
Die schlanken Datenpakete, die verteilte Client-Server-Struktur und die Möglichkeiten zum Umgang mit Verbindungsabbrüchen ermöglichen einen zuverlässigen Datenaustausch mit ressourcenärmeren Geräten wie z. B. Sensoren.
Skalierbarkeit
Da der Nachrichtenaustausch per MQTT dem Publish-Subscribe-Modell folgt und über einen zentralen Broker stattfindet, können prinzipiell jederzeit weitere Geräte als Clients integriert werden. MQTT-Broker selbst sind oft in der Cloud angesiedelt und sehr leistungsstark.
Sicherheit
MQTT unterstützt sowohl die Authentifizierung von Kommunikationsteilnehmern als auch Verschlüsselungsmechanismen wie TLS.
Einfachheit
Vor allem auf Client-Seite ist MQTT sehr einfach zu implementieren und zu benutzen.
Grenzen
Grenzen von MQTT – und wie man sie in der Praxis löst
MQTT transportiert Nachrichten zuverlässig, legt aber nicht fest, was in ihnen steht. Diese und weitere Grenzen sind kein Grund gegen MQTT, sie bestimmen aber, welche Bausteine in einer industriellen IoT-Architektur dazukommen.
| Thema | Grenze | Lösung in der Praxis |
|---|---|---|
| Datenmodell | Die Payload hat kein festes Format und keine Semantik – was „72,4“ bedeutet, steht nicht in der Nachricht. | Einheitliche Topic-Struktur und Payload-Konventionen, Spezifikationen wie Sparkplug B oder ein Datenmodell in der Plattform, die die Daten auswertet. |
| Zentraler Broker | Fällt der Broker aus, steht die gesamte Kommunikation. | Broker-Cluster bzw. redundante Broker, Pufferung in den Clients. |
| Abfragen und Befehle | MQTT 3.1.1 kennt kein Anfrage-Antwort-Muster, Befehle brauchen eigene Rückmelde-Topics. | MQTT 5 mit Request/Response, für Abfragen und Schreibzugriffe auch REST oder OPC UA. |
| Historie | Der Broker speichert keinen Verlauf, Retained Messages halten nur den letzten Wert. | Eine Datenbank oder Software-Plattform abonniert die Daten und speichert die Werte als Zeitreihe. |
| Konfiguration | Ohne Anmeldung, TLS und Topic-Rechte ist der Broker offen. | Die vier Maßnahmen aus dem Abschnitt Sicherheit von Anfang an einrichten. |
Für Abfragen, Schreibzugriffe und Maschinen mit standardisiertem Informationsmodell ist OPC UA oft die bessere Wahl. Wann sich welches Protokoll eignet, steht im Abschnitt „Wo wird MQTT eingesetzt?“.
Anwendungsbeispiele
Wo wird MQTT eingesetzt?
Die Einsatzgebiete von MQTT sind äußerst vielfältig. Die Datenübertragung per MQTT zeichnet sich durch ihre geringe Netzwerkauslastung sowie die geringen Anforderungen an Systemressourcen beteiligter Geräte aus (siehe auch „Was sind die Vorteile von MQTT?“).
Deshalb wird das Protokoll vor allem dort eingesetzt, wo kleinere Geräte zuverlässig Daten austauschen sollen. Für das Internet of Things (IoT), Industrial Internet of Things (IIoT) und Edge Computing ist MQTT daher eines der wichtigsten Protokolle.
Auch das Konzept des Unified Namespace, bei dem sämtliche Unternehmensdaten in eine hierarchische Struktur integriert und über einen zentralen Broker verteilt werden, wird in der Praxis so gut wie immer mit dem MQTT-Protokoll umgesetzt.
In vielen Fällen werden mithilfe von MQTT Daten zwischen Geräten und Cloud-Umgebungen übermittelt. So integrieren z. B. Cloud-Umgebungen wie Microsoft Azure und Amazon Web Services eigene MQTT-Broker, um MQTT-Daten von IoT-Geräten zu verarbeiten.
Zu den wichtigsten Anwendungsbereichen von MQTT gehören die folgenden:
- Industrielle Produktion: Datenaustausch mit Produktionsanlagen (siehe „MQTT in der Produktion“)
- Logistik: Tracking von Gütern und Lagerbeständen
- Gesundheitswesen: Kommunikation mit medizinischen Geräten
- Energieversorgung: Überwachung von Energieverbräuchen und Stromnetzkomponenten
- Fahrzeugvernetzung: Überwachung von Fahrzeugen und Kommunikation mit Verkehrssystemen
- Landwirtschaft: Überwachung von Geräten, Bewässerungssystemen und Umweltbedingungen
- Sicherheitssysteme: Einsatz in Überwachungskameras und Alarmsystemen
MQTT eignet sich insbesondere für Umgebungen, in denen Edge Computing und Cloud Computing miteinander kombiniert werden sollen. Daten von Edge-Geräten können unter Verwendung von MQTT an zentrale Cloud-Plattformen übermittelt werden.
In vielen Industrieumgebungen kommt MQTT neben anderen Kommunikationsstandards wie OPC UA und REST zum Einsatz. In unserem Blogbeitrag MQTT vs. REST vs. OPC UA – Unterschiede und Einsatzgebiete haben wir die drei Technologien miteinander verglichen. Die Welten lassen sich auch verbinden: Mit OPC UA PubSub können OPC-UA-Daten über einen Broker verteilt werden.
MQTT in der Fertigung
MQTT in der Produktion: Topic-Struktur, Unified Namespace und Sparkplug B
Im industriellen IoT verbindet MQTT Steuerungen, Sensoren und Zähler mit den Systemen, die ihre Daten nutzen – vom Dashboard am Hallenmonitor bis zum MES. Diese Architektur hat einen Vorteil: Weil Publisher und Subscriber entkoppelt sind, kann jede neue Anwendung vorhandene Topics abonnieren, ohne dass an der Maschine etwas geändert werden muss.
Wie Maschinendaten zu MQTT kommen: Viele aktuelle Steuerungen, Industrie-PCs und IoT-Sensoren bringen einen MQTT-Client mit und veröffentlichen ihre Werte direkt beim Broker (Publish). Ältere Steuerungen ohne MQTT bindet ein IoT-Gateway oder Edge-Gerät an: Es liest die Daten per OPC UA, Modbus oder herstellerspezifischem Protokoll und veröffentlicht sie per MQTT. Ein Beispiel dafür ist der OPC Router von inray, der Maschinen und IT-Systeme unter anderem per OPC UA und MQTT verbindet.
Unified Namespace: Statt jede Anwendung einzeln mit jeder Maschine zu verbinden, veröffentlichen alle Systeme ihre aktuellen Daten in einer gemeinsamen Topic-Struktur auf dem Broker. ERP, MES, Dashboards und Analysen lesen dort, was sie brauchen. MQTT ist dafür das übliche Transportprotokoll.
Sparkplug B: Die Spezifikation der Eclipse Foundation ergänzt MQTT um einen festen Topic-Namensraum, ein binäres Payload-Format (Protocol Buffers) und Statusmeldungen, mit denen Teilnehmer ihren Online-Zustand und ihre Datenpunkte bekannt geben (Birth- und Death-Zertifikate). Sie schließt damit die Lücke beim Datenmodell. Wer kein Sparkplug B einsetzt, erreicht Ähnliches mit einer festen Topic-Struktur und einem Datenmodell in der Plattform.
Typische Szenarien:
- Maschinenzustände und Stückzahlen mehrerer Linien in Echtzeit sammeln
- Strom-, Druckluft- und Kühlwasserzähler für das Energiemonitoring auslesen
- Messwerte von Prüfständen und Sensoren an die Qualitätssicherung weitergeben
- Störmeldungen einer Anlage direkt an die Instandhaltung verteilen
MQTT für die Produktion
MQTT-Kommunikation mit manubes
Auch manubes, unsere Cloud-Plattform für digitales Produktionsmanagement, nutzt MQTT zur Kommunikation mit industriellen Maschinen, Geräten und Cloud-Plattformen.
manubes kann als Subscriber an einen MQTT-Broker angebunden werden und dadurch Zugriff auf verschiedenste Datenquellen erhalten – darunter z. B. Sensoren, Steuerungen und andere Geräte. Diese Daten lassen sich mit manubes nicht nur in Form von Datenmodellen speichern und strukturieren, sondern auch interaktiv und in Echtzeit visualisieren.
Umgekehrt ist manubes als Publisher in der Lage, Daten an Cloud-Plattformen wie Microsoft Azure zu senden, welche einen MQTT-Broker integrieren.
Die oben genannten Anwendungsfälle und viele weitere Szenarien lassen sich mit manubes im Rahmen automatisierter Workflows umsetzen. Im Zusammenspiel ermöglichen die manubes-Features eine Entwicklung und Verwaltung vollumfänglicher Industrie-Anwendungen auf No-Code-Basis (siehe auch Citizen Development).
So funktioniert die Anbindung: Ein Edge Node im Produktionsnetz verbindet sich über einen Connector als MQTT-Client mit einem vorhandenen Broker – manubes bringt keinen eigenen Broker mit. Die Verbindung zum Broker lässt sich mit TLS verschlüsseln, Abonnements dürfen Wildcards enthalten, und manubes wertet unterschiedliche Payload-Formate aus. Zur manubes Cloud baut der Edge Node nur ausgehende, verschlüsselte Verbindungen auf (Sicherheitskonzept); bricht die Verbindung ab, puffert er die Daten. Im Workflow Designer kann eine eingehende MQTT-Nachricht einen Workflow auslösen, umgekehrt kann ein Workflow selbst Werte an einen Broker senden (Publish).
MQTT-Daten aus der Produktion in Echtzeit nutzen
manubes an Ihren MQTT-Broker anbinden, Topics per Wildcard abonnieren und Maschinendaten in Dashboards, Datenmodellen und Workflows nutzen – ohne Programmierung.
Jetzt testenHäufige Fragen zu MQTT
Was bedeutet MQTT?
MQTT stand ursprünglich für Message Queuing Telemetry Transport und bezeichnet ein offenes, leichtgewichtiges Nachrichtenprotokoll für das Internet of Things. Geräte und Anwendungen tauschen darüber Nachrichten nach dem Publish-Subscribe-Prinzip über einen zentralen Broker aus. Heute gilt MQTT als Eigenname; das Protokoll ist als OASIS-Standard und als ISO/IEC 20922 genormt.
Basiert MQTT auf TCP oder UDP?
MQTT basiert auf TCP/IP. TCP sorgt für eine geordnete, verlustfreie Verbindung zwischen Client und Broker, auf der MQTT seine Sitzungen und QoS-Stufen aufbaut. Für Netze und Kleinstgeräte, die nur UDP oder Funkprotokolle wie Zigbee nutzen, gibt es die Variante MQTT-SN (MQTT for Sensor Networks).
Welchen Port nutzt MQTT?
MQTT nutzt standardmäßig den TCP-Port 1883 für unverschlüsselte Verbindungen und den Port 8883 für Verbindungen mit TLS-Verschlüsselung. Beide Ports sind bei der IANA für MQTT registriert. Über WebSockets lässt sich MQTT auch über die üblichen Web-Ports betreiben, etwa für Browser-Anwendungen. In der Produktion sollte nur Port 8883 mit Anmeldung genutzt werden, sobald Daten das lokale Netz verlassen.
Was ist der Unterschied zwischen MQTT-Broker und MQTT-Client?
Der MQTT-Broker ist der zentrale Server, der eingehende Daten annimmt, Abonnements verwaltet und sie an die passenden Empfänger verteilt. MQTT-Clients sind die Teilnehmer – Steuerungen, Sensoren oder Anwendungen –, die Nachrichten veröffentlichen (Publisher) oder Topics abonnieren (Subscriber). Ein Überblick über industrietaugliche Broker steht im MQTT-Broker-Vergleich.
Was bedeuten QoS 0, 1 und 2 bei MQTT?
Die Quality of Service legt die Zustellgarantie fest: QoS 0 stellt eine Nachricht höchstens einmal ohne Bestätigung zu, QoS 1 mindestens einmal mit Bestätigung, wobei Duplikate möglich sind, und QoS 2 genau einmal über einen vierstufigen Austausch. Für zyklische Messwerte reicht meist QoS 0, für Meldungen und Zählerstände sind QoS 1 oder 2 üblich (Vergleich der QoS-Stufen).
Welche Geräte können MQTT?
MQTT beherrschen viele IoT-Sensoren, Energiezähler, IoT-Gateways, Edge-Geräte, Industrie-PCs und zunehmend auch Steuerungen (SPS) mit eingebautem MQTT-Client. Ältere Steuerungen ohne MQTT werden über ein Gateway oder Edge-Gerät angebunden, das ihre Daten zum Beispiel per OPC UA oder Modbus liest und per MQTT veröffentlicht.
Was ist Sparkplug B?
Sparkplug B ist eine Spezifikation der Eclipse Foundation, die MQTT für die Industrie um einen festen Topic-Namensraum, ein einheitliches Payload-Format und Statusmeldungen der Geräte ergänzt. Sie löst damit das fehlende Datenmodell von MQTT. manubes unterstützt Sparkplug B nicht; dort ordnen eine feste Topic-Struktur, Wildcard-Abonnements und das Datenmodell die Werte zu.
Was ist der Unterschied zwischen MQTT und OPC UA?
MQTT ist ein schlankes Transportprotokoll, das Nachrichten über einen Broker verteilt, aber ihren Inhalt nicht beschreibt. OPC UA bringt zusätzlich Funktionen wie ein standardisiertes Informationsmodell, Lese- und Schreibzugriffe sowie integrierte Sicherheitsmechanismen mit. In der Praxis werden beide oft kombiniert. Details zeigt der Vergleich MQTT vs. REST vs. OPC UA.
Produktvideo: Lernen Sie manubes kennen
Weitere Informationen
Optimieren Sie Ihre Produktion mit manubes
manubes bietet eine zentrale Plattform für Datenmanagement, Visualisierung und workflow-basierte Prozessautomatisierung.
Produzierende Unternehmen erhalten Zugriff auf innovative Werkzeuge zur Entwicklung eigener Lösungen – zugeschnitten auf die Anforderungen der Produktionsumgebung.
Testen Sie manubes – kostenlos und unverbindlich
Testen Sie sämtliche manubes-Features in Ihrer persönlichen Cloud-Umgebung.
Testzugang erhalten
'/%3E%3C/svg%3E){kind=small}