Albatros

Albatros

Infos für Modellflug und Technik!

Nutzung von LWT/MQTT in ESP8266 basierten Systemen

Einleitung

Um in IOT (internet of things) kleinere Projekte zu realisieren, ohne aufwendige GUI Implementierungen zu machen, empfiehlt es sich diese ESP8266 basierten Systeme mittels MQTT an einen entsprechenden Broker zu verbinden. In unserem Fall wäre dies der MQTT2-Broker des HomeAutomation-Service [FHEM]. Andere MQTT Server sollte prinzipell gleiche Ergebnisse liefern.

Um MQTT auf einem ESPP8266 zu nutzen, habe wir die [PubSubClient-Library] (Arduino Client for MQTT) im Einsatz, die problemlos funktioniert. Alles folgendes setzt voraus, dass wir als einen laufenden MQTT Server haben, zu dem ein Client eine Verbindung aufbauen kann und an den dieser auch MQTT-Topics publishen kann.

Im Weiteren dieses kleinen Artikels soll, es nur noch um LWT / Last Will and Testament gehen.

LWT / Last Will and Testament

Statusmeldungen bei Verbindungsabbrüchen oder Sensor-Offline-Situationen

Ohne die Nutzung dieses LWT Features, das in MQTT konzeptionell vorhanden ist, werden MQTT-Topics auch bei Verbindungsabbrüchen (Netzwerk fällt aus oder auch Sensor-MC (ESP8266) wird einfach stromlos geschaltet) einfach in ihrem bisherigen Zustand weiter angezeigt. Man sieht zwar am Datum des Werts, dass dieser nicht aktuell ist, aber man sieht nicht so einfach, dass kein anderer Wert gesendet werden kann.

Für solche Situationen hat MQTT den LWT / Last Will and Testament. Ein Client, also in unserem Fall der MicroController ESP8266, verbindet sich per connect() mit der Broker. Hierbei können, gesteuert durch mehrere Parameter, dem Broker ein LWT-Topic, ein LWT-Value und das Retained-Flag mitgegeben werden.

 const char* MQTT_LWT_TOPIC = "/stat/meinBeispielClient/LWT";
 ourMqttClient.connect(mqtt_id.c_str(), MQTT_USER, MQTT_PASSWD, MQTT_LWT_TOPIC, 0, 0, "offline", true)

Hiermit teil man dem Broker mit, welchen LWT-Topic, er bei Verbindungsverlust zum Client er aus welchen Value (hier "offline") setzen soll. Damit bei bestehender Verbindung der Wert z.B. auf "online" gesetzt wird, muss der Client natürlich selber dafür sorgen, dass der LWT Topic auf den entsprechenden Wert gesetzt wird.

 ourMqttClient.publish(MQTT_LWT_TOPIC, "online");

Pro Client kann es nur ein LWT Topic geben, da pro Client nur ein connect() gemacht werden kann. Der Name des Topic und der Value ist frei wählbar. Es ist natürlich sinnvoll dem Broker einen anderen LWT-Value zu senden (z.B. "offline"), als das LWT-Topic-Value das man nach dem erfolgreichen Verbinden mit dem Broker sendet (z.B. "online")

Das war es dann auch schon. Verbindet sich nun der Client / ESP8266 mit dem Broker sendet er das gewählte LWT-Topic mit dem entsprechenden Value "online". Wird die Verbindung unterbrochen (z.B. durch ein Ausschalten des ESP8266), dann wird der Broker den beim connect() mitgegeben Value "offline" an die Subscriber versenden.

Das retained Flag

In MQTT können Nachrichten und auch das LWT mit oder ohne retained-Flag versendet werden. Nachrichten die ein Client an den Broker mit gesetztem retained-Flag sendet, werden auf dem Broker gespeichert und bei der Neuregistrierung eines neuen Subscribers auf das entsprechende Topic, werden diese gespeicherte Werte an den neue Subscriber gesendet. Ohne gesetztes retained-Flag, muss ein neuer Subscriber darauf warten, bis ein Client (Topic-Publisher) bei einer Änderung das Topic wieder sendet.

Als Beispiel für die Verwendung des retained-Flags wird hier das Interface der publish()-Methode der von unser verwendeten Klasse PubSubClient gezeigt:

  boolean PubSubClient::publish(const char* topic, const char* payload, boolean retained);