Version vom 30. August 2017, 12:21 Uhr

MQTT und FHEM

Wozu MQTT?

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.^[1]

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.

EineA Anleitung zur Installation findet sich beispielsweise in diesem Blogeintrag.

Für Arduinos böte sich der PubSubClient an, gegebenfalls ein Analyse-Tool wie MQTT.fx.

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 Mosquito zu installieren.

MQTT Server auf dem RPi einrichten

Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte und ist wie folgt beschrieben durchzuführen.

# aus dem mosquitto Repo installieren:
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-wheezy.list
# oder für jessie
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
# mosquitto installieren, sowie client Befehl mosquito_sub (gehört nicht zum Server, wird aber weiter unten benötigt)
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

MQTT und Sonoff

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"

FHEM-Anbindung

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/set
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

↑ {{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.}}

[1] {{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.}}

[1]

@@ Zeile 1: / Zeile 1: @@
-= MQTT =
+= MQTT und FHEM =
-Message Queue Telemetry Transport
+== Wozu MQTT? ==
+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.
-== Was ist das? ==
+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.
-Es handelt sich um ein Protokoll, um Daten unter verschiedenen Geräten zu übermitteln. MQTT funktioniert z.B. über eine TCP/IP Verbindung.
+== Eine sehr kurze Einführung in MQTT ==
-(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.)
+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 [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.
-== Grundlegender Aufbau ==
+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.<ref>{{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.}}</ref>
-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)
+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:
-== 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'''
+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.
-Dieses Topic böte sich geradezu an, den Zustand des Küchenlichts im 1. Stock reinzuschreiben.
+Ein Payload kann beliebige Inhalte aufnehmen. Oft enthalten Topics Befehle oder Daten.
-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? ==
+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.
-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.
+== Installation in FHEM ==
-Unser Display abonniert also die Temperatur. Zukünftig wird der Broker immer versuchen, unserem Display die Temperatur zu übermitteln.
+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.
+EineA Anleitung zur Installation findet sich beispielsweise in diesem [http://blog.wenzlaff.de/?p=6487 Blogeintrag].
+Für Arduinos böte sich der PubSubClient an, gegebenfalls ein Analyse-Tool wie MQTT.fx.
-== Ah ja. Und was ist daran toll? ==
+== MQTT und Sonoff-Tasmota ==
-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.
+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 Mosquito zu installieren.
-Wenn wir nun ein weiteres Display haben wollen, bauen wir uns eben ein zweites Display und subscriben das Topic ebenfalls beim Broker.
+===MQTT Server auf dem RPi einrichten===
-Zukünftig wird er an beide Displays die Information schicken.
+Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte und ist wie folgt beschrieben durchzuführen.
-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.
+ # aus dem mosquitto Repo installieren:
+ 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-wheezy.list
+ # oder für jessie
+ sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
+ sudo apt-get update
+ # mosquitto installieren, sowie client Befehl mosquito_sub (gehört nicht zum Server, wird aber weiter unten benötigt)
+ 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
-== 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.
+===MQTT und Sonoff===
-Für den "ambitionierten Bastler" bedeutet dies:
+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"
-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? ==
+===FHEM-Anbindung===
-Einen MQTT Broker; z.B. Mosquitto.
+Die Einrichtung in FHEM wird von den Modulen 00_MQTT.pm, 10_MQTT_BRIDGE und 10_MQTT_DEVICE.pm unterstützt.
-Für den Mikrocontroller der eigenen Wahl eine passende Library. Für Arduinos böte sich der PubSubClient an
+Ebenso wird das Modul 98_expandJSON.pm benötigt, um den {{Link2Forum|Topic=66761|LinkText=JSON String zu filtern}}.
-Ggfs. ein Analyse-Tool wie MQTT.fx
+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.
-== Nachteile ==
+[https://forum.fhem.de/index.php?topic=27532.0 Link zum Forum: MQTT FHEM Einrichtung]
-=== Single Point of Failure ===
+ ### 1. Broker anlegen ###
+ define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
-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.
+ ### 2. FHEM Device mit MQTT verbinden ###
-Möglicher Grund:
+ define Sonoff_Switch MQTT_DEVICE
-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.
+ 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/set
+ 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!
+<div style="clear:both;"></div>
-=== Sicherheit ===
+== 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 ====
@@ Zeile 100: / Zeile 110: @@
 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 ==