Mit MQTT einen Roboter steuern - [Teil 1]

In den meisten Blogbeiträgen geht es um einfachere Steuerungen oder Regelungen, die ein Microkontroller übernimmt. Doch die IoT-Geräte, Kurzform für Internet of Things, können weitaus mehr. Grundlage dafür bieten Protokolle, welche die Kommunikation zu den einzelnen Geräten sicherstellen, wie das hier genutzte MQTT. Dieser erste Beitrag der Blogserie über MQTT vermittelt die Grundlagen. Am Ende der Blogserie wird mittels MQTT ein kleiner Roboter gesteuert, ähnlich wie mit einer Fernsteuerung.

Voraussetzung

Für diesen Blogbeitrag brauchen Sie nur wenige Bauteile, siehe Tabelle 1.

Anzahl Bauteil
1 Raspberry Pi
1 Passendes Netzteil

Tabelle 1: Benötigte Hardware

Denken Sie bei dem Pi daran, dass Sie neben der oben genannten Hardware auch eine MicroSD-Karte brauchen. Hierzu sollten Sie Raspberry Pi OS (ehemals Raspbian) als Image auf die Karte installieren.

Hinweis an dieser Stelle

Dieses Tutorial behandelt MQTT und wie man sich selbst einen MQTT-Broker und Clients einrichten kann. Daher benötigen Sie ausschließlich für diesen Teil einen Raspberry Pi, um alle hier gezeigten Schritte nachzuvollziehen und nachmachen zu können. In den weiteren Teilen der Blogserie werden weitere Clients, wie das Mikrocontroller Board kompatibel mit Arduino Uno R3 und NodeMCU’s, integriert.

Was ist MQTT?

MQTT ist die Abkürzung für Message Queuing Telemetry Transport und ist auch noch unter dem älteren Namen WebSphere MQTT, kurz WSMQTT, bekannt. Es handelt sich dabei um ein offenes Netzwerkprotokoll für eine Machine-to-Machine-Kommunikation, um z.B. Sensordaten zu übermitteln und/oder Aktoren zu steuern. Hintergrund dieses Protokolls ist, dass auch in sogenannten instabilen Netzen eine Übertragung von Informationen gewährleistet werden kann. Der Begriff „instabile Netze“ stammt aus der Zeit, als Netzwerke noch sehr störanfällig waren.

MQTT ist, sofern es standardmäßig installiert wird, über den Netzwerkport 1883 erreichbar. Der zweite Port 8883 ist der gesicherte Netzwerkport, muss aber mittels TLS-Protokoll verschlüsselt werden. Damit Sie MQTT benutzen können, braucht es einen MQTT-Server, den sogenannten Broker, sowie die entsprechenden Endgeräte, welche die Daten senden oder empfangen, auch Clients genannt. Meist findet sich der Broker auf einem Linux-basierten Betriebssystem. Windows-Betriebssysteme sind jedoch ebenfalls möglich. Mittlerweile findet man MQTT in der Automatisierungstechnik und bei IoT-Projekten, da es relativ einfach ist, ein MQTT-Netzwerk mit geringen Ressourcen aufzubauen.

Die hier genutzte Protokollversion 3.1.1, sowie die vorherige Version 3.1, wurden 2010 unter einer freien Lizenz veröffentlicht, welche durch das Standardisierungsgremium OASIS spezifiziert wurde. Diese Protokollversion ist damit zum Zeitpunkt der Blogveröffentlichung schon über 10 Jahre alt. Die aktuellste Protokollversion 5.0 ist im Jahre 2019 veröffentlicht und zugleich durch das Standardisierungsgremium OASIS spezifiziert worden.

Wie funktioniert MQTT

MQTT nutzt die ereignisgesteuerte Publish/Subscribe-Architektur, zu Deutsch Bereitstellen / Abonnieren Architektur. Dabei gibt es keine Ende-zu-Ende-Verbindung, wie zum Beispiel bei einer Website, sondern einen Server, den sogenannten Broker, zu welchem sich Sender und Empfänger, die sogenannten Clients, verbinden. Um diese Verbindungen besser zu verstehen, soll Abbildung 1 dies in vereinfachter Form darstellen.

Abbildung 1: Veranschaulichung der MQTT-Architektur

Ein Client, hier im Bild der Sensor, das mobile Endgerät oder das IoT-Gerät, kann Daten immer senden und/oder empfangen, der Broker dient lediglich als Informationspuffer, der die Daten an andere Clients weiterleitet. Damit der Client eine entsprechende Nachricht vom Broker empfangen kann, muss dieser beim Verbindungsaufbau oder aber während des Betriebs beim Broker die sogenannten Topics abonnieren.

Ein Topic können Sie sich wie eine Art URL (Uniform Resource Locator) vorstellen, der den gewünschten Inhalt wiedergibt. Ein Topic für einen Temperatursensor im Wohnzimmer könnte die Messwerte auf Daheim/Erdgeschoss/Wohnzimmer/Temperatur veröffentlichen. Um gleich eins klarzustellen, es handelt sich nicht um eine Adresse zu dem Sensor, sondern ermöglicht den Zugriff auf die zuletzt übermittelten Sensordaten. Wird der Messwert aktualisiert, prüft der Broker, welcher Client diese Information zum Empfang abonniert hat, und leitet diese weiter.

Datenaustausch mit dem Broker

Wie Anfangs erwähnt, war MQTT für instabile Verbindungen gedacht, weswegen es drei unterschiedliche Servicequalitäten, im Englischen Quality of Service bzw. QoS, gibt. Bei Stufe 1 oder auch QoS = 0 wird die Nachricht genau einmal gesendet. Eine Bestätigung, wie es bei den anderen QoS der Fall ist, wird dabei komplett ignoriert. Einzig das Veröffentlichen, der sogenannte PUBLISH, ist wichtig.

Bei QoS = 1 spricht man auch von „mindestens einmal geliefert“, was so viel heißt, dass der Sender auf eine Bestätigung vom Empfänger wartet. Diese Empfangsbestätigung nennt sich PUBACK und ist verpflichtend für die Gegenstelle, andernfalls übersendet der Sender solange, bis eine Empfangsbestätigung kommt. Dies führt im Umkehrschluss dazu, dass eine Nachricht mehrfach an den Empfänger übermittelt wird.

QoS = 2 ist quasi die Kombination aus QoS = 0 und QoS = 1, wobei Sie auch die langsamste Übertragung darstellt. Hier wird die Nachricht exakt nur ein einziges Mal gesendet. Um dies zu erreichen, ist eine zweistufige Empfangsbestätigung nötig.

Zunächst sendet (PUBLISH) der Sender seine Nachricht an den Empfänger, welche die Nachricht annimmt und eine Bestätigungsnachricht (PUBREC) sendet, wobei der Inhalt vom Sender als eine Kopie mit angehängt ist. Wird diese Bestätigungsnachricht (PUBREC) vom Sender empfangen, speichert dieser die Information und antwortet ebenfalls mit einer Bestätigungsnachricht (PUBREL).

Zuletzt, wenn der Empfänger die PUBREL erhalten hat, schickt dieser die letzte Bestätigungsnachricht (PUBCOMP). Am Ende einer solchen Übertragung von Daten ist sichergestellt, dass die Nachricht auch tatsächlich angekommen ist. Um es verständlicher zu halten, zeigt
Abbildung 2 noch einmal schematisch, wie der Nachrichtenverlauf bei allen drei QoS-Varianten aussieht.

Abbildung 2: MQTT QoS-Übersicht

Daten vom Broker abonnieren

Nun stellt sich die Frage, wie ein Client nun Sensordaten abfragen kann? Dazu gibt es auch wieder mehrere Varianten, die zum Ziel führen können. In der ersten Variante können Sie, wie schon oben bei der einfachen Sensordatenübertragen gezeigt, den Topic komplett vorgeben. Dazu geben Sie dann einfach den Topic Daheim/Erdgeschoss/Wohnzimmer/Temperatur an. Sie erhalten an der Stelle dann aber auch tatsächlich nur genau diesen einen Wert.

Bei der Nutzung von Variante zwei kommt der +-Operator ins Spiel. Durch Daheim/+/+/Temperatur erhalten Sie für alle Zimmer auf jeder Etage die Temperaturdaten. Nützlich ich dies, wenn Sie eine solche Struktur für alle Sensoren in ihrem Haus so vorgeben und z.B. gebündelt anzeigen lassen wollen.

Variante drei geht mit dem #-Operator noch einen Schritt weiter. Durch Daheim/Erdgeschoss/# erhalten Sie alle verfügbaren Informationen für jedes Zimmer auf der Etage Erdgeschoss. Je nach Informationsquantität kann schon an dieser Stelle einiges zusammenkommen.

Der vierte und letzte Fall ist, sofern Sie Unmengen an Daten übermitteln, die wohl Daten-intensivste Topicabonnierung. Mittels /# abonnieren Sie das Wurzelverzeichnis und ihnen wird jede Änderung übermittelt. Gerade diese Variante empfehle ich an dieser Stelle ausdrücklich nicht! Sie sollten sich schon im Vorfeld Gedanken machen, wie Ihre Struktur bzw. die Messdaten, die Sie aufnehmen wollen, aussehen und vorher festlegen.

Zuletzt kommt wahrscheinlich noch die Frage auf, was passiert denn, wenn ein Sender plötzlich nicht mehr sendet? Dazu gibt es in MQTT die sogenannte Retained Message, die den letzten Willen und das Testament beinhaltet. Damit dies genutzt werden kann, muss der Sender, in unserem Fall ein Sensor, bei der Verbindung zum Broker eben diese Retained Message mitliefern. Darin ist gespeichert, was gesendet werden soll, wenn der Sender nicht mehr erreichbar ist. Pro Topic kann dann ein individueller Inhalt durch den Broker geschrieben werden. Da MQTT schon von Haus aus eine Überwachung mitliefert, brauchen Sie sich um diesen Punkt nicht zu kümmern. Da es zu tief in die Materie geht, kann ich an dieser Stelle aber gerne das Stichwort LWT message mitgeben, womit Sie im Internet genügend Lesestoff finden werden.

Der Raspberry Pi wird zum Broker

Wie in dem Abschnitt „Was ist MQTT?“ erwähnt, erfreut sich dieses Protokoll größter Beliebtheit in der IoT-Szene. Viele scheuen sich, ihre persönlichen Daten oder Daten zur Steuerung ihres Heimes im Internet, z.B. bei mqtt-dashboard.com/ zu speichern. Daher bietet es sich an,  einen kleinen, lokalen Broker mit dem Raspberry Pi aufbauen. Dazu ist es erst einmal egal, welche Raspberry Pi - Version Sie nehmen und ob dieser schon irgendwelche Aufgaben übernimmt.

Öffnen Sie zunächst einmal das Terminal Ihres Raspberry Pis, siehe Abbildung 3 und geben Sie danach die Befehle aus Code 1 ein.

Abbildung 3: Öffne Terminal im Pi

sudo apt upgrade

sudo apt dist-upgrade

Code 1: Raspbian updaten

Damit aktualisieren Sie erst einmal den Raspberry Pi und alle installierten Pakete. Danach geben Sie den Befehl aus Code 2 ein. Damit laden Sie sich den beliebten mosquitto-broker und die Clientanwendung auf Ihren Raspberry Pi. Bestätigen Sie an der entsprechenden Stelle die Installation im Terminal.

sudo apt install mosquitto mosquitto-clients

Code 2: Mosquitto-Server und -Client installieren

Damit der Broker auch nach einem Neustart direkt mitstartet, nutzen Sie den Befehl aus Code 3.

sudo systemctl enable mosquitto.service

Code 3: Service von mosquitto bei Neustart vom Pi mit starten

Da der daemon auf dem Pi bisher ggf. noch nicht läuft, starten Sie diesen mit dem Befehl aus Code 4.

sudo mosquitto -d

Code 4: mosquitto starten

Ab diesem Punkt haben Sie einen lokalen, unverschlüsselten MQTT-Broker in ihrem Heimnetzwerk eingerichtet. Dieser ist, sofern Sie keine Weiterleitung von Ports auf den Raspberry Pi über ihren Router eingerichtet haben, im Internet nicht erreichbar. Für den privaten Zweck soll es aber erst einmal reichen. Damit auch der Broker vom Pi nach einem Neustart erreichbar bleibt, sollten Sie dem Raspberry Pi eine feste IP-Adresse über den Router vergeben.

Daten an den Broker senden und empfangen

Nun wird es Zeit, die Theorie in die Praxis umzusetzen und Nachrichten an den Broker zu senden und auch Nachrichten vom Broker zu empfangen. Dazu werden die Terminalbefehle „mosquitto_sub“ für die Funktion subscribe und „mosquitto_pub“ für die Funktion publish von Nachrichten benötigt.

Den Anfang wird der Terminalbefehl „mosquitto_sub“ machen, und die wichtigsten Befehle werden nachfolgend erläutert. Wollen Sie über die hier gezeigten Befehle hinausgehen, empfehle ich an dieser Stelle das intern mitgelieferte Linux-Handbuch, das Sie im Terminal mit dem Kommando „man mosquitto_sub“, „man mosquitto_pub“ oder „man mosquitto“ aufrufen können. Der Linux-Befehl man steht dabei für Manual, auf Deutsch Anleitung oder Handbuch.

Um umfangreich zu sehen, was der mosquitto-Subscriber im Hintergrund abarbeitet, und auch um alle Nachrichten zu empfangen, nutzen Sie den Befehl aus Code 5.

mosquitto_sub -d -q 2 -t /#

Code 5: Mosquitto-Subscriber auf Wurzelknoten lauschen lassen

Der hier gezeigte Code 5 nutzt dabei die Optionen aus Tabelle 2.

Option Erläuterung
-d Aktiviert den Debug-Modus und zeigt alle nützlichen Informationen an.
-q Spezifiziert welche QoS der Subscriber mit dem Broker kommunizieren soll. In Code 5 wird QoS 2 genutzt.
-t Gibt an, welches Topic vom Subscriber abonniert werden soll. In Code 5 abonnieren der Subscriber alle Topics.

Tabelle 2: Optionen des mosquitto-Subscriber

Haben Sie den Befehl aus Code 5 eingegeben, wird die Ausgabe zunächst die erfolgreiche Verbindung zu dem Broker anzeigen, siehe Abbildung 4 Markierung 1.

Abbildung 4: Terminalausgabe von moquitto_sub

In Markierung 1 von Abbildung 4 sieht man, dass eine Verbindung aufgebaut wird und die Gegenstelle, der Broker, die Verbindung akzeptiert hat. Direkt danach übermittelt der Subscriber, welches Topic abonniert werden soll, hier „/#“, und welcher QoS angefordert wurde, hier „QoS: 2“. Zuletzt wird die Subscribe-Anfrage mittels SUBACK, der Subscription Acknowledged, akzeptiert. Die Verbindung zum Broker ist hergestellt und das gewünschte Topic ist abonniert. 

Markierung 2 von Abbildung 4 wird nach einer Zeit bei Ihnen im Terminal erscheinen. Dies ist, wie in „Wie funktioniert MQTT“ beschrieben, die Abfrage, ob der Subscriber noch online ist. Der Broker fragt nach, ob der Subscriber noch online ist, den sogenannte Ping Request. Im Normalfall sendet der Client die entsprechende Antwort, den sogenannten Ping Response, an den Broke.

Der nächste Schritt, nachdem wir nun einen Subscriber haben, besteht darin, einen Publisher zu nutzen, um Daten an den Broker zu senden. Die erste Nachricht soll natürlich „Hello world“ sein. Diesen kleinen Satz sendet der Publisher an das Topic /test/testpub.

Öffnen Sie dazu ein zweites Terminal-Fenster und geben den Befehl gemäß Code 6 ein . 

mosquitto_pub -d -q 2 -t /test/testpub -m “Hello world“

Code 6: mosquitto_pub "Hello world"

Die genutzten Optionen für Code 6 sind in Tabelle 3 aufgelistet.

Option Erläuterung
-d Aktiviert den Debug-Modus und zeigt alle nützlichen Informationen an.
-q Spezifiziert, welche QoS der Publisher mit dem Broker kommunizieren soll. In Code 6 wird QoS 2 genutzt.
-t Gibt an, an welches Topic die Daten gesendet werden sollen, hier /test/testpub
-m Sende nachfolgende Nachricht, hier „Hello world“

Tabelle 3: Optionen des mosquitto-Publisher

Schauen wir uns einmal an, welche Daten bei der Übermittlung, siehe Abbildung 5 Markierung 1, an den Broker gesendet werden. Wie schon zuvor wurde QoS 2 in den Optionen gewählt, weswegen Sie auch den entsprechenden Kommunikationsverlauf sehen.

Abbildung 5: Terminalausgabe von moquitto_pub und mosquitto_sub

Direkt danach schickt der Broker die neue Nachricht an den Subscriber, siehe Abbildung 5 Markierung 2, da dieser alle Topics abonniert hat. An der oberen Umrandung von Markierung 2 von Abbildung 5 sehen Sie, dass neue Daten im Topic /test/testpub empfangen wurden. Der QoS 2 – Handshake wird direkt dahinter angezeigt, wobei die Nachricht „Hello world“ empfangen wurde.

Damit haben Sie die Grundlagen von MQTT und die technischen Hintergründe zu MQTT gelernt. Spielen Sie ruhig einmal mit den Befehlen und senden Sie Daten an den Broker und öffnen Sie ggf. weitere Terminals, die andere Topics abonnieren.

Im nächsten Teil der Blogserie werden Sie einen Arduino Microkontroller bzw. ESP32 mit dem MQTT verbinden und Daten senden, und die Gegenstelle wird entsprechend darauf reagieren.

Dieses und weitere Projekte finden sich auf GitHub unter https://github.com/M3taKn1ght/Blog-Repo

Projekte für anfängerRaspberry pi

7 Kommentare

Ruediger

Ruediger

@Jörn: Ein paar Informationen gibt es hier: https://www.facebook.com/flyingthewinglets

Jörn Weise

Jörn Weise

Hallo Herr Kress,
sofern Sie fertige Bibliotheken benutzen, müssen Sie sich um das Quittieren kann Sorgen machen. Bauen Sie aber eine eigene Bibliothel oder Funktion die MQTT übernehmen soll, müssen Sie natürlich daran denken. Ich empfehle hier ganz klar die fertigen Bibliotheken, da spart man sich die Zeit und den Streß.

Hallo Lothar, Egon,
Danke für das Feedback, freut mich als Autor und als Blogger, wenn Beiträge gut ankommen.

Hi jm1704,
thanks for the feedback. Funny part is, that I will show people MQTT.fx in part two of this blog serie. I’m also using this tool for my normal buissnes to test and check signals.

Hallo Ruediger,
das hört sich nach einem sehr spannenden Projekt an. Das interessiert mich wahnsinnig, gibt es dazu ggf. eine Website, wo man diesen Status sehen kann? Zu der Thematik mit den Controllern muss ich gestehen, hatte ich bisher noch keine Aussetzer. Egal welchen ich verwendet habe, hatte ich eine zuverlässige Verbindung zum Wifi. Sicher das an irgendeiner Stelle nicht der verbaute Watchdog vom ESP32 oder ESP8266 zuschlägt? Ich hatte das bei ein paar Tests mal, da hatte ich eine Endlosschleife und habe erst später bemerkt, dass hier der Watchdog immer meinen MicroController neu gestartet hatte.

Gruß / Greetings
Weise

jm1704

jm1704

Good MQTT article with MOSQUITTO
For peoples who want to control or simulate MQTT transaction and check the critical or not and when problem was.
I am also using 2 tools MQTT.fx and MQTT Explorer

Ruediger

Ruediger

Ich betreibe privat einen B737 Flugsimulator und habe vor 1 Jahr damit begonnen Teile der Steuerung auf WiFi und MQTT umzustellen. Das funktioniert soweit recht gut, verwende es aber derzeit noch nicht für kritische Signale. Meine Erfahrung ist, das die WiFi Verbindung immer mal wieder zusammenbricht. Diese wird von dem betroffenen Client zwar wieder aufgebaut, dauert aber 3-5 sek. Während dieser Zeit kann viel passieren. Deshalb mein Hinweis mit MQTT bei kritischen Verbindungen vorsichtig zu sein. Woran es liegt, dass die Wifi Verbindung hin und wieder zusammenbricht, kann ich so noch nicht sagen. Nur soweit, dass ich mit dem ESP8266 ESP-01S noch keine Probleme hatte. Wohl aber mit dem ESP WROOM 32. Eigentlich hätte ich es eher anders herum erwartet. Ingesamt betreibe ich derzeit 4 ESP8266 ESP-01S Clienets und 3 ESP WROOM 32 Clients.

Egon

Egon

Kurz und knapp, sehr verständlich erklärt. Macht weiter so. Warte schon auf den nächsten Beitrag.

Lothar

Lothar

Vielen Dank für das tolle Tutorial zum Thema MQTT. Bin schon sehr gespannt, wie weiter geht.

E. Kress

E. Kress

Es wäre gut zu wissen, ob man als Progeammierer bei QoS 2 selbst für die Quittung-Tätigkeiten sorgen muss oder ob das im MQTT-System automatisch geschieht.

Einen Kommentar hinterlassen

Alle Kommentare werden vor der Veröffentlichung moderiert

Aanbevolen blog berichten

  1. Installeer ESP32 nu van de raad van bestuur
  2. Lüftersteuerung Raspberry Pi
  3. Arduino IDE - Programmieren für Einsteiger - Teil 1
  4. ESP32 - das Multitalent
  5. OTA - Over the Air - ESP Programmeren via Wi-Fi

Aanbevolen producten