MQTT Einführung: Unterschied zwischen den Versionen
Andies (Diskussion | Beiträge) (→FHEM-externer Broker: mosquitto von unten nach oben verschoben) |
Andies (Diskussion | Beiträge) |
||
Zeile 60: | Zeile 60: | ||
=== FHEM als Broker === | === FHEM als Broker === | ||
Seit 2018 kann auch FHEM selbst fungieren. Zu diesem Zweck legt man in FHEM das folgende Gerät an | Seit 2018 kann auch FHEM selbst fungieren. Zu diesem Zweck legt man in FHEM das folgende Gerät an | ||
defmod | defmod myBroker MQTT2_SERVER 1883 global | ||
Dieses Gerät fungiert dann als IO-Device für alle diejenigen devices, die in FHEM einem MQTT-fähigem Objekt zugeordnet werden. | Dieses Gerät fungiert dann als IO-Device für alle diejenigen devices, die in FHEM einem MQTT-fähigem Objekt zugeordnet werden. | ||
Version vom 23. Juni 2019, 09:48 Uhr
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 zentrale MQTT-Server, in alter Nomenklatur auch Broker genannt.
MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist nachrichtenorientiert, 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). 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 kann eine vollwertige Einleitung wie beispielsweise diese Wikieinträge nicht ersetzen.
Bei MQTT findet die nachrichtenbasierte Kommunikation nur zwischen den Geräten (Devices) auf der einen Seite und dem MQTT-Server (Broker) auf der anderen Seite statt. Die Geräte kommunizieren nicht direkt untereinander. Wenn also ein Klient (Client) Daten von einem bestimmten Gerät (Device) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass es die Nachrichten dieses Gerätes (Devices) abonniert (deshalb wird dieser Vorgang als subscribe bezeichnet). 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.
Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
- Topic - das ist die Adresse des endgültigen Empfängers. Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten:
zuHause/1OG/Kueche/Licht/state
. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie 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. - Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.
- Quality of Service - soll geprüft werden, ob die Nachricht zugestellt wurde und wenn ja, mit welcher "Tiefe"?
- Retained Message.
Details bitte in der oben genannten Einführung nachlesen.
Installation in FHEM
Um MQTT in FHEM zu nutzen, benötigt man einen MQTT-Broker. Es gibt zwei Möglichkeiten: Man kann einen FHEM-externen Broker verwenden oder man kann FHEM als Broker nutzen. Seit Ende 2018 wird empfohlen, bei einer Neuinstallation FHEM als Broker zu verwenden. Wir werden jetzt beide Installationswege erläutern.
FHEM-externer Broker
Ein gern verwendeter Broker ist 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[1]:
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 updateDanach 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 der RPi mit shutdown restart neu zu starten. Damit FHEM mit dem Broker kommuniziert, muss noch folgendes device angelegt werden
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
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.
FHEM als Broker
Seit 2018 kann auch FHEM selbst fungieren. Zu diesem Zweck legt man in FHEM das folgende Gerät an
defmod myBroker MQTT2_SERVER 1883 global
Dieses Gerät fungiert dann als IO-Device für alle diejenigen devices, die in FHEM einem MQTT-fähigem Objekt zugeordnet werden.
MQTT und Sonoff-Tasmota
Eine derzeit oft genutzte Möglichkeit für MQTT bilden die Sonoff-Geräte. Werden diese mit Tasmota (Theo Arends Sonoff MQTT Over The Air - 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
### 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_Status 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
- Offizielle Homepage von MQTT, englisch
- Sehr gute Einführung, englisch, sind 5 lesenswerte Teile
- Ein Exkurs von Heise mit Beispielen, deutsch, sehr lesenswert
- MQTT FX - ein sehr praktisches Analysetool
- Diskussionsthread im Forum
- Teil 2 der MQTT Einführung; schwerere Kost
- Teil 3 der MQTT Einführung: Hände schmutzig machen
Hinweise
- ↑ Die für den Betrieb mit FHEM erforderlichen Perl-Module sind teilweise (noch) nicht in den Paketquellen verfügbar. Sie können dennoch statt mit cpan auch als Debian-Paket mit Hilfe von dh-make-perl installiert werden, wobei vorab das in den Paketquellen bereits vorhandene libmodule-pluggable-perl installiert werden sollte:
dh-make-perl --install --cpan Net::MQTT::simple
dh-make-perl --install --cpan Net::MQTT::Constants
sudo dpkg -i libnet-mqtt-simple-perl*.deb
sudo dpkg -i libnet-mqtt-perl*.deb