MQTT Einführung

MQTT

Message Queue Telemetry Transport

Was ist das?

Es handelt sich um ein Protokoll um Daten unter verschiedenen Geräten zu übermitteln. MQTT funktioniert z.B. über eine TCP/IP Verbindung. (Für die, die etwas verbal posen wollen: Man nennt das M2M, Machine to Machine; im Übrigen handelt es sich bei MQTT um ein Transportprotokoll.)

Grundlegender Aufbau

Herzstück des eigenen MQTT Netzes ist ein Broker. Die mit dem Broker verbundenen Geräte nennen wir der Einfachheit halber mal Clients. (stimmt nicht ganz, aber später lernen wir das genauer kennen)

So tickt MQTT

Wir schreiben/schicken einfach eine Nachricht an den Broker. Wer wann die Nachricht abholt und liest, interessiert an dieser Stelle überhaupt nicht. Das ist einer der großen Vorteile.

Ordnung in das Chaos

Worin liegt nun der Vorteil? Und wie kann nun jemand eine Nachricht lesen? Hier beginnt das raffinierte Konzept von MQTT: Wir stellen nicht einfach nur Daten dem Broker zur Verfügung. Wir organisieren sie auch selbst. Das Zauberwort hierfür nennt sich "Topic". Kann man sich so ähnlich vorstellen wie einen Verzeichnisbaum unter Windows, oder wie eine Datei auf einem Webserver. Ein anderes Bild für einen "Topic" wäre eine Art schwarzes Brett.

Ein Topic könnte so lauten: zuHause/1OG/Kueche/Licht/state

Dieses Topic böte sich geradezu an, den Zustand des Küchenlichts im 1. Stock reinzuschreiben.

Unser kleiner schlauer Lichtschalter könnte in diesem Topic immer den aktuellen Zustand des Lichts notieren. In "MQTT-Sprechweise" würde man sagen, unser Client ist ein Publisher. Er veröffentlicht Informationen.

Nehmen wir im folgenden einen Sensor: zuHause/1OG/Kueche/Kuehlschrank/Temperatur/state

Das ergäbe ein hübsches Topic für einen im Kühlschrank befindlichen Temperatursensor. Auch hier hätten wir es mit einem Publisher zu tun.

Wichtig ist hierbei, dass wir uns nicht um die Technik kümmern müssen. Auch bei der Organisation der Topics haben wir ziemlich freie Hand.

Was kann man jetzt damit anfangen?

Nun wollen wir die Kühlschranktemperatur auf einem Display sehen. Vielleicht lagern wir ja empfindliche Medikamente im Kühlschrank und haben Kinder, die gerne die Kühlschranktür offen lassen?

Wir nehmen also ein Display und klemmen das auch an unseren Broker. Jetzt möchten wir aber nicht die Temperatur publishen, das macht ja der Sensor. Wir wollen sie lesen. Also melden wir uns mit dem Display beim Broker an und "subscriben" das Topic. Wir teilen dem Broker mit, dass uns diese Information interessiert.

Unser Display abonniert also die Temperatur. Zukünftig wird der Broker immer versuchen, unserem Display die Temperatur zu übermitteln.

Ah ja. Und was ist daran toll?

Nun, wie wir das Thermometer programmiert haben, wussten wir nichts von dem Display. Wir müssen auch am Thermometer gar nichts mehr verändern. Das bleibt so wie es ist.

Wenn wir nun ein weiteres Display haben wollen, bauen wir uns eben ein zweites Display und subscriben das Topic ebenfalls beim Broker. Zukünftig wird er an beide Displays die Information schicken.

Wenn wir eine grafische Auswertung des Temperaturverlaufs wollen, dann könnten wir das Topic beim Broker zusätzlich mit FHEM subscriben. Temperatur bekommen, in Logfile schreiben, Plot, fertig.

Immer noch: warum ist das so toll?

Nun, bei der Konzeption von MQTT hat man Wert darauf gelegt, dass es ohne große Ressourcen auskommt. Das bedeutet für uns, dass es für viele "Bastelhardware" (Arduino etc.) fertige Libraries gibt. Ich zeige das später. Auch wer gerne mit Javascript, Java, Perl, Python programmiert, findet gut funktionierende Bibliotheken. Für den "ambitionierten Bastler" bedeutet dies: Wir können Geräte bauen und programmieren, die sich selbstständig miteinander unterhalten. Ein Taster der Licht an einem entfernten Aktor einschaltet, ist kein Problem. Und zwar ohne FHEM hiermit zu belasten oder es auch nur zu brauchen. Wir können also sehr schnell unsere Kühlschranktemperatur mit diversen Programmiersprachen auf einer Unzahl von Geräten lesen und auswerten.

Cool, was braucht man?

Einen MQTT Broker; z.B. Mosquitto. Für den Mikrocontroller der eigenen Wahl eine passende Library. Für Arduinos böte sich der PubSubClient an Ggfs. ein Analyse-Tool wie MQTT.fx

Nachteile

Single Point of Failure

Wo Licht ist, ist bekanntermaßen auch Schatten. Für uns, da wir FHEM zur Haussteuerung einsetzen, stellt sich die erste Frage, warum man seine Geräte nicht einfach gleich an FHEM anbindet, sondern erst noch einen MQTT Broker (letztlich noch ein Stück Software) extra davor setzt. Möglicher Grund: MQTT ist besser ausgereift als jedes selbst gestricke Protokoll. Es ist sogar ISO Standard. Es gibt viele Tools und Hilfestellungen dafür; eigene Intelligenz den Geräten beizubringen ist auch recht einfach.

Sicherheit

Prinzipiell ist MQTT ebenso sicher wie eine Postkarte. Solange man es nicht extra absichert, kann jeder der im eigenen LAN ist (und die Adresse vom Broker kennt) alle Topics mitlesen. meinHaus/Flur/Haustuer:open / close Ist da nicht wirklich schlau! Abhilfe:

Username / Passwort

Zunächst kann man erst mal einen Username / Passwort vergeben. Da ist zwar auch noch lange nicht sicher, aber zumindest steigert es den Aufwand schon mal. Jetzt muss man zumindest schon mal Pakete sniffen und verstehen, um unbefugt zu lesen oder gar zu publishen.

TLS

Um wirklich sicher zu werden, führt kein Weg an TLS vorbei. Leider kann z.B. ein Arduino das schlicht nicht mehr. Irgendwo machen sich der Speicher und die Rechenleistung dann doch bemerkbar.

Änderung der Topic Hierarchie

Ja, das ist ein Problem. Wenn man die Hierarchie der Topics ändern will, wird man in den seltensten Fällen drum rum kommen, seinen Programmcode (Arduino..,) anzupassen, neu zu kompilieren und wieder hoch zu laden. Gleiches gilt, wenn sich z.B. die IP Adresse des Brokers ändert.

Netzwerktraffic

Eine weitere Frage, die man sich stellen kann ist eine grundsätzliche: Welchen Sinn hat es, sein Netzwerk (insbesondere WLAN) mit so Dingen wie Sensordaten zuzukleistern. Das ist nicht völlig unberechtigt. MySensors ist für viele kleine batteriebetriebenen Sensoren vermutlich eine deutlich bessere Wahl. Sensoren mit Akku in ein WLAN einzubinden, ist technisch eine echte Herausforderung. De große Vorteil ist aber, dass man sein WLAN im Fall des Reichweitenendes einfach erweitern kann. WLAN-Repeater, Sache gut.

Ausblick

Hier endet erst mal der kurze Überblick. Wer neugierig geworden ist, darf sich auf viele weitere spannenden Themen freuen:

QoS

Ein weiteres Feature sind die QoS Level von MQTT.

* QoS Level 0: ist eine Art fire and forget. Ob die Daten ankommen, wird nicht weiter geprüft
* QoS Level 1: garantiert die Zustellung der Nachricht; es kann aber auch passieren, dass eine Nachricht öfter zugestellt und empfangen wird
* QoS Level 3: Hier wird garantiert, dass jede Nachricht genau 1x bei den Empfängern ankommt

Retained Messages

Auch eine lustige Sache, lernen wir später kennen. Aber ein Beispiel möchte ich dennoch schon schildern: Wir basteln uns später den oben angesprochenen Temperatursensor und das zugehörige Display. Das erweitern wir um eine blinkende LED, wenn eine bestimmte Temperatur überschritten wird. Quizfrage: woher kennt das Display den gewünschten Schwellenwert? Freilich könnte man ihn im Programmcode hinterlegen. Aber dann ist er fest verdrahtet. Wenn wir ihn einfach nur normal publishen würden, würde das Display ihn erst kennen, wenn der Schwellwert gepublished würde nachdem das Display mit dem Broker verbunden war... Hier kommen retained Messages. Diese werden auch beim Verbinden eines Subscribers gesendet, obwohl es da keine Änderung gab.

Links

• Offizielle Homepage von MQTT, englisch
• Sehr gute Einführung, englisch, sind 5 lesenswerte Teile
• Ein Exkurs von Heise mit Beispielen, deusch, sehr lesenswert
• Diskussionsthread im Forum