MQTT Einführung

Aus FHEMWiki
Version vom 20. März 2018, 10:04 Uhr von Beta-User (Diskussion | Beiträge) (Installation auf stretch geändert, ältere Versionen in Infobox ausgelagert)

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen Broker, den so genannten MQTT-Broker.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist ergebnisorientiert und daher muss ein Client nicht beständig beim Server anfragen, ob neue Daten vorliegen. Heute findet sich MQTT vor allem im Bereich des Internet-of-Things (IoT). Insbesondere dort, wo viele Sensoren ausgelesen werden müssen, wird MQTT eingesetzt.

Es ist daher nicht verwunderlich, dass mehr und mehr Geräte MQTT einsetzen. MQTT kann leicht mit FHEM verbunden werden, ohne dass dabei größerer CPU- oder Datenverbrauch entsteht.

Eine sehr kurze Einführung in MQTT

Die folgende Einführung soll denjenigen helfen, die noch nie von MQTT gehört haben und überlegen, ob sie es in FHEM einsetzen. Sie kann eine vollwertige Einleitung wie beispielsweise diese Wikieinträge nicht ersetzen.

Bei MQTT findet die Kommunikation nur zwischen den Geräten (seien es Empfänger oder Sender) auf der einen Seite und dem Broker auf der anderen Seite statt. Die Geräte kommunizieren nicht untereinander. Eine Nachricht besteht im Wesentlichen aus zwei Dingen: Einem Topic und einem Payload. Dies ist nicht ganz korrekt. Es gibt zwei weitere Elemente, die zu einer Nachricht gehören: Den Quality of Service (soll geprüft werden, ob die Nachricht zugestellt wurde und mit welcher "Tiefe"?) und Retained Message. Details bitte in der oben genannten Einführung nachlesen.

Eine anschauliche Beschreibung würde beide Begriffe mit einem Brief vergleichen. Der Topic entspricht der Adresse, an die der Brief geschickt wird. Der Payload ist der Inhalt, der sich im Briefumschlag befindet.

Ein Topic schafft damit eine Hierarchie der Nachrichten und sortiert für die Clienten, um was für Nachrichten es sich handelt. Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen erlaubt, das gilt auch für gewisse Sonderzeichen). Ein Topic könnte beispielhaft so lauten:

zuHause/1OG/Kueche/Licht/state

Offensichtlich sind hier Objekte zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.

Ein Payload kann beliebige Inhalte aufnehmen. Oft enthalten Topics Befehle oder Daten.

Eine Besonderheit von MQTT besteht darin, dass die Geräte nur mit dem Broker kommunizieren. Sendet ein Gerät also Daten, werden diese an den Broker geschickt und der Broker nimmt sie entgegen. Wollen die Clienten wissen, welche Daten vorliegen, müssen sie dem Broker mitteilen, dass sie über diese Daten informiert werden wollen. Diesen Vorgang nennt man "subscribe". Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den Broker vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt.

Installation in FHEM

Um MQTT in FHEM zu nutzen, benötigt man einen MQTT-Broker. Ein gern verwendeter Broker ist beispielsweise [Mosquitto]. Er kann ohne weiteres auf dem Raspberry Pi, der bereits eine FHEM-Installation besitzt, installiert werden und wird keine größere CPU- oder Netzwerklast verursachen. MQTT kommuniziert über Port 1883.

Eine Anleitung zur Installation findet sich beispielsweise in diesem Blogeintrag. Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte. Bei stretch ist Mosquitto bereits in der Distribution enthalten und kann - zusammen mit dem client Befehl mosquito_sub, der weiter unten benötigt wird wie folgt installiert und getestet werden:

Info green.pngFür ältere Distributionen (hier am Beispiel von jessie) muß ggf. aus einer zusätzlichen Paketquelle installiert werden:
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
Danach kann die eigentliche Installation durchgeführt werden wie links für stretch beschrieben.
  sudo apt-get install mosquitto mosquitto-clients
 
 # MQTT Server Test
 sudo service mosquitto status

 # Start / Stop des Servers
 sudo service mosquitto stop
 sudo service mosquitto start
 
 # Perl Version ausgeben
 perl -v
 # Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
 sudo cpan install Net::MQTT:Simple
 sudo cpan install Net::MQTT:Constants

Danach ist FHEM mit shutdown restart neu zu starten.

Zur Kommunikation mit dem Broker von seiten eines Arduinos böte sich der PubSubClient an. Um die Funktionalität des Brokers zu testen kann z.B. ein Analyse-Tool wie MQTT.fx verwendet werden.

MQTT und Sonoff-Tasmota

Eine derzeit oft genutzte Möglichkeit für MQTT bilden die Sonoff-Geräte. Werden diese mit einer offenen Firmware von arendst geflasht, so kommunizieren sie über MQTT. Um diese Geräte einzubinden, ist wie folgt vorzugehen. Zuerst ist Mosquitto zu installieren.

Unter Sonoff sind einige Topics voreingestellt. arendst stellt insbesondere drei Topic-Präfixe bereit, die seiner Meinung jedes Topic einleiten sollen (in den Eingabemasken als "%prefix%" notiert). Das sind einmal Kommandos (abgekürzt als cmnd), die dazu dienen, Befehle auszuführen. Daten werden mit tele und stat übertragen. Ein Topic besteht dann zuerst aus diesem Präfix und danach dem eigentlichen Topic. Wer also beispielsweise einem Sonoff_Switch einen Befehl senden will, sollte als Topic cmnd/Sonoff_Switch wählen. Wenn der Switch ein- und ausgeschaltet werden kann, muss der Topic noch das Wort POWER enthalten (in MQTT werden viele Kennworte komplett groß geschrieben). Der Topic lautet damit vollständig "cmnd/Sonoff_Switch/POWER/set"

Die Einrichtung in FHEM wird von den Modulen 00_MQTT.pm, 10_MQTT_BRIDGE und 10_MQTT_DEVICE.pm unterstützt. Ebenso wird das Modul 98_expandJSON.pm benötigt, um den JSON String zu filtern.

Briges und Devices unterscheiden sich wie folgt. Eine Bridge ist ein Gerät, das bereits in FHEM angelegt wurde und nur mit MQTT verbunden werden soll. Ein Device existiert noch nicht in FHEM und soll erst angelegt werden.

Link zum Forum: MQTT FHEM Einrichtung

### 1. Broker anlegen ###
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
### 2. FHEM Device mit MQTT verbinden ###
define Sonoff_Switch MQTT_DEVICE
attr Sonoff_Switch IODev myBroker
attr Sonoff_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Sonoff_Switch icon hue_filled_br30
attr Sonoff_Switch publishSet ON OFF cmnd/TestSwitch/POWER
attr Sonoff_Switch room MQTT
attr Sonoff_Switch subscribeReading_Licht stat/Sonoff_Switch/POWER
attr Sonoff_Switch subscribeReading_Sensor tele/Sonoff_Switch/SENSOR
attr Sonoff_Switch subscribeReading_Status stat/Sonoff_Switch/STATUS
attr Sonoff_Switch webCmd ON:OFF

Der hier dargestellte Beispielcode realisiert die Kommunikation zwischen FHEM und dem sonoff Modul via MQTT Broker. Zu beachten ist hier, dass subscribeReading_Licht und subscribeReading_state unterschiedliche Syntax des Topic Strings haben!

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.

Links