In der letzten Folge hatte ich meine Mini-Bibliothek zum Veröffentlichen von MQTT-Nachrichten auf das „Pretzel-Board“ portiert, das mit einem ATmega328 und einem WLAN-Chip ESP8266 ausgestattet ist. Wir erinnern uns, dass der ATmega bequem über die Arduino-IDE programmierbar ist und den ESP8266 über einfache ASCII-Kommandos ansteuert, zum Beispiel zum Einloggen in ein WLAN-Netz, zum Verbinden mit einem TCP-Server und zum Senden von Zeichen dorthin. In den Funktionen meiner Mini-Arduino-TCP-Library (TCPClient_Connect, TCPClient_Close, TCPClient_Send) werden die entsprechenden ASCII-Befehle zusammengestellt und an den ESP8266 geschickt. Die Funktionen meiner rudimentären MQTT-Library konnte ich fast unverändert von der PC-Version übernehmen, denn sie setzen auf die TCP-Library auf.

Zum Test hatte ich mir eine ganz einfache Applikation überlegt. Beim Anlegen der Betriebsspannung loggte sich der ESP8266 in mein heimisches WLAN-Netzwerk ein, danach leuchtete eine ans Board angeschlossene LED auf. Nach Betätigen eines Tasters, den ich ebenfalls auf einem Steckbrett unterbrachte, verband sich der ESP8266 über TCP mit dem HiveMQ-Testserver in der Cloud. Danach wurde das MQTT-Connect-Kommando über TCP verschickt, gefolgt von dem MQTT-Publish-Kommando. Als MQTT-Nachricht hatte ich schlicht den Text „Button“ (plus eine Zahl) benutzt, und als Topic „/ElektorMyJourneyIoT/TestTopic/test“. Den Erfolg konnte man mit einem MQTT-Client nach Wahl überprüfen.

Als ich vor zwei Wochen mit der Arbeit an dieser Folge begann, blieb der Erfolg erst einmal aus. Ich fand schnell heraus, dass sich wohl die IP-Adresse des Testservers geändert haben musste. Jedenfalls funktionierte alles wieder, nachdem ich im Arduino-Sketch (und meinem Test-Client für den PC) statt der IP-Adresse „52.29.193.216“ den URL-String „broker.hivemq.com“ angab.

Was ich noch gar nicht implementiert hatte, war eine Fehlerbehandlung – die LED leuchtete auch brav auf, wenn die SSID und das Passwort (hardcodiert im Arduino-Sketch anzugeben) gar nicht stimmte, sich das Board also gar nicht in mein WLAN-Netzwerk einloggen konnte. Ich ersetzte die einfarbige LED durch die RGB-LED des Maker-Kits, so konnte ich mit Rot einen Misserfolg und mit Grün einen Erfolg anzeigen lassen. Im Handbuch zum Pretzel-Board ist eine praktische Funktion der mitgelieferten SoftwareSerial-Library beschrieben, mit der man die ASCII-Rückmeldungen des ESP8266 auswerten kann. Neben einigen anderen Zeichen sendet dieser nämlich „ERROR“, wenn der vom ATmega kommende Befehl nicht korrekt ausgeführt werden konnte, sowie „OK“ im Erfolgsfall. Mit der Zeile

Boolean success = esp8266.findUntil(“OK“, “ERROR“);

weist man den ATmega an, so lange zu warten, bis entweder ein „OK“ oder ein „ERROR“ vom ESP8266 zurückkommt (oder bis eine einstellbare TimeOut-Zeit abläuft). Eine saubere Sache, die auch gleich meine Quick-and-Dirty-Delay-Befehle aus der ersten Programm-Version überflüssig machte.

So dachte ich zumindest. Denn als ich die Funktion in die Setup-Routine meines Sketches einbaute, um Fehler beim Einloggen in das WLAN-Netzwerk zu detektieren, folgte ein starkes Stündchen Probiererei. Es leuchtete immer die grüne LED auf, egal was ich als Passwort einstellte. Irgendwie musste nach dem Kommando zum Einloggen immer ein „OK“ vom ESP8266 zurückkommen. Ich fand schließlich heraus, dass die Bearbeitung der Rückmeldung des Kommandos, das ich davor gab, wohl noch nicht abgeschlossen war, als ich das neue Kommando verschickte. Ein kleiner Delay-Befehl löste das Problem.

Nun ging es weiter auf dem Weg zu einem autark arbeitenden Sensor-Board. Im Maker-Kit ist auch ein Phototransistor enthalten, die Mess-Spannung ließ ich am Pin A6 des Pretzel-Boards digitalisieren. Den Taster funktionierte ich um. Hiermit kann man nun zwischen den Modi „Test“ und „Sensor“ wechseln, was durch die auf dem Board integrierte, blaue LED D3 angezeigt wird. Nach Anlegen der Betriebsspannung loggt sich der ESP8266 in das WLAN ein, dessen Zugangsdaten man (noch) hardcodiert in den Sketch schreiben muss. Bei Erfolg leuchtet die RGB-LED grün auf. Mit einem Druck auf den Taster kann man nun in den Modus „Sensor“ wechseln. Das Board erfasst dann fortlaufend die Helligkeit, wandelt den 10-bit-Wert des ADCs in einen String aus Hex-Ziffern um und schickt diesen per MQTT unter dem obengenannten Topic zum Testserver. Meine Funktion

void SendValueOverMQTT(int TenBitValue)

arbeitet weiterhin etwas brutal: Erst wird die TCP-Verbindung geschlossen, dann wieder geöffnet. Hier habe ich ebenfalls eine Fehlerbehandlung mit Anzeige implementiert. Wenn das Verbinden mit dem TCP-Server nicht klappt, leuchtet die RGB-LED rot auf. Im Erfolgsfall leuchtet die RGB-LED gelb (rot+grün), dann werden die MQTT-Kommandos verschickt. Daraufhin zeigt die RGB-LED wieder grün (noch nicht implementiert ist eine MQTT-Fehlerbehandlung, aber wir wollen ja auch noch etwas in den nächsten Folgen zu tun haben ;-) ). Danach beginnt das Spiel mit einem neuen Messwert. In den Testmodus kommt man mit einer erneuten Betätigung des Tasters (gedrückt halten bis die LED D3 auf dem Board verlischt). In diesem Modus kann man den ESP8266 von einem Terminalprogramm aus „händisch“ steuern.

Den Code finden Sie wie immer im Download – zusammen mit einer angepassten Version meines MQTT-Test-Clients für den PC zum Empfang der Messwerte (in die Textbox „Topic to subscribe“ ist nur „TestTopic“ einzugeben). Ich habe im Arduino-Sketch erst einmal mit Absicht darauf verzichtet, alles zu modularisieren und zu abstrahieren, damit man den Code besser mit dem der vorhergehenden Folge vergleichen kann. Aber das wird noch nachgeholt – dann kann man die kleine Referenzanwendung auch leicht an andere Boards anpassen.
In der nächsten Folge geht es weiter!