Das Protokoll MQTT erklärt und vorgestellt #Part1
Heute möchte ich euch ein wenig über das MQTT Protokoll erzählen. Wir klären ab was das ist und wofür das vorgesehen ist, wer benutzt es schon und wie könnte dein Zukünftiger Use-Case aussehen? Zunächst sollt man sich das Titelbild mal genau anschauen, denn dort ist eigentlich der gesamte vereinfachte Kommunikationsprozess anzusehen.
Als Mittelspunkt der Kommunikation ist ein Broker vorgesehen. Hierfür gibt es bereits die verschiedensten Softwareprodukte wie z.B. Mosquitto [Mosquitto Website]. Mosquitto ist für jegliche Plattformen bereits verfügbar und ist meiner Meinung nach die am besten dokumentierte Lösung.
Aber nun erstmal zum Message Queuing Telemetry Transport Protokoll (MQTT). MQTT ist ein Nachrichtenprotokoll für unteranderem eine Machine-to-Machine-Kommunikation (M2M), wobei die Übertragung von Telemetriedaten dabei im Mittelpunkt stehen. Hierbei können die unterschiedlichsten Endgeräte als Machine herangezogen werden. Z.b. Sensoren und Aktoren, aber auch ganz normale Smarthome Geräte oder gar ein ganz normaler Server oder sogar das eigene Smartphone. Eigentlich spielt es keine Rolle worauf MQTT gesprochen wird, solange das System das Netzwerkprotokoll TCP sprechen kann. Aber ich will garnicht erst so in die Tiefe gehen, da das doch aus meinen Augen ein wenig langweilig wirkt. Wichtig ist das wir verstanden haben, dass wir hier von kurzen Nachrichten sprechen oder einfache Telemetriedaten wie z.B. die Temperatur von einem Temperaturfühler. Möglich wäre auch ein Türkontakt, der nur eine 0 oder 1 sendet. Aber wieder rum wäre es auch Ok wenn eine Wetterstation Ihre kompletten Daten in einem json String im Minutentakt published.
Jetzt zum Titelbild. Wie man schon erkennen kann gibt es hier zwei wichtige Schlagworte und das sind "Publish" und "Subscribe". Die Kommunikation bei MQTT ist wie im Social Media Bereich, ein Client bekommt nur Nachrichten von den Topics welche er selbstständig Abboniert hat. Abbonieren ist hier das Subscriben. Wie im Bild zu sehen, gibt es einen Temperaturfühler, welche gerne seine gemessene Temperatur weitergeben möchte. Dies tut er in dem er seine Messung in ein Topic packt z.B. "/temperatur". Dies sendet er zum Broker und der Broker verteilt diese Nachricht an alle Abbonenten / Subscriber, welche das Topic "/temperatur" Abboniert haben. Das kann ein Abbonent sein oder auch zwanzig, dies spielt hier keine Rolle.
Natürlich kann ein Publisher auch gleichzeitig ein Subscriber sein. Bekommt dieser beispielsweise die Temperatur über ein Abbonent mitgeteilt, kann er diese dazu verarbeiten um anderen mitzuteilen das Fenster zu schließen oder die Heizung einzuschalten. Oder es wird die Lichtintensität gemessen, wobei festgestellt wird, dass es besser wäre das Licht einzuschalten.
Bevor wir mit dem ersten Part von der MQTT Tour zum Ende kommen, muss ich euch aber noch erklären wie sich die Topics aufbauen. In unserem Beispiel weiter oben, haben wir ein Abbonent auf /temperatur gesetzt. Dies wäre natürlich völlig OK, aber sinnvoller wäre es wenn man dies ein wenig weiter verschachtelt.
Beispiel:
haus/garten/luftfeuchtigkeit
haus/wohnzimmer/temperatur
Als Empfänger könnte man nun hingehen und alle drei Topics abbonieren und würde natürlich auch alle darüber publizierten Meldungen erhalten. Aber was ist wenn wir uns wirklich nur für die Temperaturen interessieren. Hierzu gibt es dann zwei verschiedene Filter, welche zum Einsatz kommen können. Zunächst gibt es die Single-Level Wildcard [ + ] und die Multi-Level Wildcard [ # ].
Beispiel:
haus/# -- Hier erhalten alles was sich hinter haus/ verstecken würden wie zum Beispiel auch haus/garten/temperatur/sensor1
Vermutlich klärt sich das Thema aber viel besser auf wenn man sieht wie es in der Realität wirklich verhält. Im nächsten Part von der Vorstellung von MQTT gehen wir mehr in die Praxis über und üben ein wenig am lebenden Objekt.
Link to #Part 2.
Wer schon mal ein wenig testen möchte, kann gerne den rpicloud.de MQTT-Broker auf Mosquitto ausprobieren.
MQTT-Broker: rpicloud.de
Port: 1883