Wiesemann & Theis GmbH

Netzwerk-, Sensor- & Schnittstellentechnik für Industrie, Office & IT

Hintergrundwissen:

MQTT - Message Queue Telemetry Protocol

Datenaustausch ohne direkte Verbindung


Die Besonderheit von MQTT besteht darin, dass zwei Kommunikationspartner, die miteinander Daten austauschen, dies niemals über eine direkte Verbindung tun.


Stattdessen gibt es einen zentralen Datenvermittler, den Broker. Der Broker nimmt Daten von einem MQTT-Nutzer entgegen und verteilt sie an andere weiter.

MQTT - Übertragung auf Netzwerkebene

MQTT nutzt als Basisprotokoll TCP und arbeitet somit nach dem Client/Server-Prinzip.

MQTT - Netzwrkpaketaufbau


Der Broker ist dabei der Server, der standardmäßig auf TCP-Port 1883 Verbindungen annehmen kann. Die MQTT-Nutzer agieren als TCP-Clients und verbinden sich bei Bedarf mit dem Broker.

MQTT - Verbindungen mit dem Broker


MQTT - Datenaustausch auf Protokollebene

Bei MQTT gibt es zwei Rollen, die ein Client annehmen kann.

Publisher
Als Publisher sendet der Client Daten an den Broker. Das können Messwerte, Schaltzustände oder andere beliebige Prozessdaten sein. Neben lesbaren Textinhalten lässt MQTT auch binäre Daten zu. Ob der Publisher seine Daten dem Broker bei Veränderung oder zyklisch übermittelt, hängt von der Anwendung ab.

Subscriber
Der Subscriber nimmt Daten vom Broker entgegen. In der Rolle des Subscribers teilt der Client dem Broker nach Verbindungsaufbau mit, welche Daten er erhalten bzw. abonnieren möchte.

Jeder MQTT-Client kann Publisher, Subscriber oder auch beides sein. Es gibt also kein zwingendes Master/Slave-Prinzip wie bei anderen Industrieprotokollen. Alle MQTT-Endgeräte bzw. Clients sind auf MQTT-Ebene zunächst gleichberechtigt. Wer Daten liefert und wer sie bekommt bestimmt also ausschließlich die Anwendung durch die Publisher/Subscriber-Zuordnung.

Topic
Der MQTT-Broker verwaltet die auszutauschenden Daten nach Datenendpunkten. Die Benennung der Datenendpunkte erfolgt über Topics. Das sind Strings, also Zeichenketten, die ähnlich der URL beim Webseitenaufruf strukturiert aufgebaut sein können.

Beispiel:

Ein W&T Web-Thermo-Hygrobarometer misst Temperatur, Luftfeuchte und Luftdruck im Serverraum des W&T Firmengebäudes. Jeder der drei Werte stellt einen Datenendpunkt dar.

Die Topics dazu könnten so aussehen:

wut/serverraum/temperatur
wut/serverraum/luftfeuchte
wut/serverraum/luftdruck

Per MQTT-Publish übergibt das Web-Thermo-Hygrobarometer die gemessenen Werte als Payload, also als Dateninhalt, unter diesen Topics an den MQTT-Broker.

Ein beliebiger MQTT-Client kann nun ein Subscribe unter Angabe des gewünschten Topics an den MQTT-Broker senden. Hier sendet der MQTT-Client ein Subscribe auf wut/serverraum/temperatur und abonniert damit den Temperaturwert des Web-Thermo-Hygrobarometers.

MQTT - Publish/Subscribe


Solange der PC als MQTT-Client mit dem Broker verbunden ist, bekommt er automatisch den vom Web-Thermo-Hygrobarometer per Publish gesendeten Wert.

Der Subscriber kann bei der Angabe der Topics mit Wildcards "#" arbeiten.

Beispiel: wut/serverraum/# abonniert Temperatur, Luftfeuchte und Luftdruck für den Serverraum.

Neben "#" gibt es noch "+" als Wildcard. Mit der Angabe von "+" werden nur End-Topics der entsprechenden Ebene abonniert – Topics aus dahinterliegenden Ebenen werden ignoriert.

Für jeden abonnierten Wert gibt es eine eigene Datensendung.

Die Übertragung der Daten erfolgt byte-orientiert und damit binärtransparent – es können also beliebige Inhalte übertragen werden. Für alle Textinhalte ist zur Vereinheitlichung UTF8 als Format vorgegeben.

MQTT - Besondere Features

MQTT bietet für den Transport und Austausch der Daten einige Sonderoptionen, die über Flags für jede Verbindung bzw. jedes Abonnement gesetzt werden können.

Quality of Service – QoS
Mit Werten zwischen 0 - 2 wird festgelegt, mit welcher Zuverlässigkeit eine Publish-Nachricht an den Broker versendet wird.

  1. raus und vergessen
    Der MQTT-Client erwartet für gesendete Daten keine Bestätigung.
    Dieses Verfahren ist unsicher, dafür aber sehr schnell.

  2. mindestens einmal
    Der MQTT-Client sendet die Daten ggf. auch mehrfach,
    bis er vom MQTT-Broker eine Empfangsbestätigung bekommt.
    Dieses Verfahren stellt sicher, dass die Daten beim Broker ankommen,
    ggf. aber mehrfach.

  3. genau einmal
    Jede Datensendung muss explizit vom MQTT-Broker quittiert werden.
    Dadurch wird sichergestellt, dass nichts doppelt versendet wird.
    Dieses Verfahren ist das sicherste, aber auch das langsamste.

Bei QoS1 und 2 stellt sich auf den ersten Blick die Frage, warum eine einfache Datensendung sicherer ist als eine mehrfache. Anhand von zwei Beispielen wird der Hintergrund aber schnell klar.

Geht es darum, einen Messwert zu übertragen - z. B. eine Temperatur - spielt es keine Rolle, ob der Wert mehrfach bei einem Subscriber ankommt. Wird aber der Winkel übertragen, um den sich ein Roboterarm bewegen soll - z. B. 5° - und die Datensendung kommt drei mal beim Subscriber an, würde sich der Roboterarm um 15° bewegen, was fatale Folgen haben könnte.

Last Will and Testament
Ein Publisher kann festlegen, dass der Broker für den Fall, dass die MQTT-Verbindung verloren geht, statt der abonnierten Werte/Daten eine bestimmte Nachricht an den/die Subscriber sendet.

Retained Message
Mit Setzen dieses Flags weist der Publisher den Broker an, den letzten gesendeten Wert / die letzten Daten zwischenzuspeichern und einem Subscriber, der sich neu verbindet, sofort zu übermitteln.

Alle drei Features sind insbesondere dann sehr nützlich, wenn über nicht immer zuverlässige Übertragungswege (z. B. mobile Netze) übertragen wird.

Eigenschaften und Vorteile von MQTT

MQTT gilt als das Übertragungsprotokoll für das „Internet der Dinge“ und bietet insbesondere für den Datenaustausch über das Internet diverse Vorteile:

  • Da alle MQTT nutzenden Endgeräte als Client arbeiten, ist die Überwindung von Firewalls und Security-Maßnahmen meist ohne oder mit überschaubarem Aufwand möglich (es müssen in den Firewalls keine Port-Freigaben und kein NAT-Routing / Port-Forwarding eingerichtet werden).
  • Der Publisher muss sich nicht darum kümmern, welche Empfänger die bereitgestellten Daten tatsächlich bekommen.
  • Anders als bei anderen Internet-basierten Protokollen können Binärdaten ohne Base64- oder andere Kodierung übertragen werden.

Eigenheiten und Nachteile

  • Der Datenlieferant bekommt keine Kenntnis darüber, wer seine Daten tatsächlich empfängt (keine Ende-zu-Ende-Quittierung).
  • Keine Echtzeitfähigkeit

Grundlagen zu gängigen Industrieprotokollen

Produkte für industrielle Anwendungen mit Standardprotokollen

^