MQTT – Die Sprache im Internet der Dinge

Spricht man über das Internet der Dinge (IoT) oder Machine-to-Machine (M2M) Kommunikation, fällt meist erst im weiteren Gespräch der Begriff MQTT (Message Queue Telemetry Transport). Dabei wären ohne dieses Kommunikationsprotokoll viele der aktuellen diskutierten IoT Anwenderszenarien schwer vorstellbar bzw. gar nicht realisierbar. Wie das Protokoll funktioniert und warum es so hilfreich ist, werde ich in diesem Blogbeitrag tiefer gehend beleuchten.

Dr. Andy Stanford-Cark von IBM und Arlen Nipper von Arcom waren 1999 mit dem Problem konfrontiert, verschiedene Messstellen an einer Öl-Pipeline durch die Wüste an ein Leitsystem anzubinden. Das Hypertext Transfer Protocol (http) konnte einige der Herausforderungen dieses Projekts nicht abdecken. Unter anderem sollte die vorhandene Bandbreite sehr effizient genutzt werden und wenig Energie verbrauchen. Nach Wiederaufnahme der Verbindung sollten außerdem der letzte Zustand gemeldet und unterschiedliche Servicequalitäten für besonders kritische Metainformationen gewählt werden können.

Das MQTT Protokoll arbeitet nach dem subscribe/publish Konzept und löst sich damit im Prinzip vom klassischen Request/Response wie es z.B. bei http genutzt wird. Die Verbindung existiert also nicht Punkt zu Punkt zwischen einem Client und einem Server, sondern in einem Netzwerk mit zentralem Knoten, dem so genannten Broker. Am MQTT Broker melden sich alle Devices direkt an, da dieser u.a. die Aufgabe der Nachrichtenverteilung übernimmt. Jedes Device teilt dem Broker mit, welche Informationen es erhalten und welche Informationen es teilen möchte. Die Feinauflösung findet hierbei über Topics und deren Payloads statt. Die Payload ist dabei die Nachricht, das Topic der dazugehörige Betreff hierzu. Der Broker verteilt dann die Nachricht an alle, die sich genau für diesen Betreff angemeldet haben.

Use Case 1.0 – Lüftungsautomation

Ein Klimasensor published seine aktuelle Temperatur und Feuchtigkeit auf dem Topic „Erdgeschoss/Badezimmer“. Abhängig von der absoluten Feuchtigkeit soll nun das Fenster geöffnet werden, um Schimmelbefahl zu vermeiden. Hierzu subscriped sich die Fenstersteuerung am Broker unter genau diesem Topic und bekommt automatisch alle neuen Werte des Sensors im Badezimmer zugesendet, damit im Bedarfsfall der Öffnungsvorgang anstoßen werden kann. Die Kommunikation der Werte findet nicht direkt zwischen Fenstersteuerung und dem Sensor statt, sondern über den Broker. Dies hat den Vorteil, dass nun auch alle andern auf das selben Topic zugreifen können. Jede befugte Person kann sich also gleichzeitig die aktuellen Werte an ein Laptop schicken lassen oder per Smartphone abrufen, ohne diese beim Sensor direkt abzufragen. Dies verringert also die Datenrate zwischen dem Sensor und dem MQTT Broker extrem, weil die Payload nur einmal übertragen werden muss und die restliche Nachrichtenverwaltung zentral gesteuert wird. Der Broker kann aber noch mehr. Devices können ihre Verbindung auch mal verlieren und würden im klassischen Request/Response Prinzip dann keine Informationen erhalten. Der MQTT Broker kann die letzte Nachricht speichern, die so genannte retained message. Dies wird dann an das Device automatisch gesendet, sobald er sich neu verbindet und dann an dem Topic subscriped. Auf diese Weise hat jeder immer den letzten übertragen Wert, unabhängig vom Verbindungszustand bei Werterhebung. Etwas Vergleichbares existiert auch in die andere Richtung. Bricht also die Verbindung zwischen Sensor und Broker ab, kann vorab eine last will Nachricht festgelegt werden. Der Broker verteilt dann automatisch diese Nachricht an alle.

Use Case 2.0 – Ausfallsicherheit

In unserem Beispiel nutzt der Klimasensor als Energiequelle eine Batterie, überträgt also den Batteriezustand nicht. Damit die Regelung trotzdem zuverlässig funktioniert, sendet der Broker automatisch die last will Nachricht an die Fenstersteuerung, sobald der Klimasensor abgemeldet ist und kann reagieren. Des Weiteren hat das Protokoll ein Service Level eingefügt, kann also priorisieren wie wichtig manche Verbindungen und deren Informationen dazwischen sind. Level 0, also at most once bedeutet hierbei, dass der Wert vom Broker einmalig an das Device übertragen wird. Ob das Device den Wert erhalten hat, weiß er nicht. Im Prinzip wie ein fire and forget. Level 1, also at least once sieht hierbei vor, dass das Device Rückmeldung gibt. Der Broker sendet also die Payload so lange, bis das Device den Empfang bestätigt hat. Das kann allerdings auch bedeuten, dass die Payload eben mehrfach angekommen ist, weil z.B. die Rückmeldung nicht beim Broker ankam. Für diese Prämisse existiert dann Level 2, also exactly once. Hierbei wird auf jede Übertragung in beide Richtungen nachgefragt und der Empfang muss bestätigt werden. Das Device sendet also die Rückmeldung so lange, bis der Broker diese bestätigt hat. Mit jedem Level steigt logischerweise der Overhead, also die Informationen die erstmal nichts mit der eigentlichen Nachricht zu tun haben. In manchen kritischen Anwendungen lässt sich dies allerdings nicht vermeiden.

Da der MQTT Broker als zentrales Nachrichtenhub dient und sich alle Devices und Clients an ihm anmelden müssen, kann er sehr gut für Statistikzwecke genutzt werden. Neben Informationen über die Clients und Devices, kennt er auch die Publishingrate auf allen Topics.

Damit lassen sich im obigen Fall also sehr gut Rückschlüsse auf die Häufigkeit und Dauer von Lüftungsvorgängen machen.

Use Case 3.0 – Real world Application

Das obige Beispiel ließe sich sicherlich auch über andere Protokolle oder ggf. sogar eine feste Verdrahtung lösen. Im industriellen Umfeld ist allerdings oftmals die Netzwerkabdeckung im kompletten Werk an allen Orten nicht ausreichend flächendeckend genug bzw. der Aufwand für eine Verdrahtung steht kaum im Verhältnis. In einem von uns umgesetzten Projekt wurden Beispielsweise der Zustand von Brandmeldeanlagen werksweit angebunden. Gerade die Funktionen last will und retained message waren neben der effizienten Ausnutzung der teilweise sehr geringen Netzabdeckung an den Verbauungsorten äußerst hilfreich.

Die beschriebenen Funktionalitäten des Protokolls finden im Internet der Dinge gerade im industriellen Bereich großen Anklang. Das Konzept des Brokers als Mittelsmann eröffnet viele Möglichkeiten, die mit http so nicht realisierbar wären. Es hat dabei noch den Vorteil, dass es sich extrem einfach implementieren lässt und quelloffen ist. Völlig zu Recht ist es daher die Sprache im Internet der Dinge.

MQTT - Sprache für das Internet of Things
MQTT – Sprache für das Internet of Things

Kommentare

  1. Sehr ansprechend und nachvollziehbar beschrieben – toller Beitrag, der mir das Thema verständlich gemacht hat und EInsatzszenarien aufzeigt.

    1. Danke für dein Feedback, ich freue mich wenn der Beitrag gut ankommt und aufklärt.

  2. Toller Artikel, vielen Dank hierfür.

Diesen Beitrag kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.