Allererste Gehversuche mit dem ESP8266- / NodeMCU-Modul

Ein wenig Abwechslung kann ja manchmal nicht schaden, eigentlich wollte ich hier eher über die nächste Version des WordPress-Themes und dessen Neuerungen schreiben, aber ein Feature hält mich nun doch länger auf als erwartet. Am vergangenen Wochenende fand die diesjährige FrOSCon (Free and Open Source Conference) statt – trotz der örtlichen Nähe war ich zwar nicht vor Ort, aber glücklicherweise wurden die Vorträge aufgezeichnet und sind online verfügbar, u.a. auch im YouTube-Channel der FrOSCon. Wie üblich sind einfach zu viele Themen interessant, aber eine der ersten Aufzeichnungen, die ich mir angesehen habe, war „Wi-Fi mit Lua“ – NodeMCU für ESP8266-Module von Uwe Berger. 

Zur Einführung kann ich den Vortrag sehr empfehlen, andererseits gibt es im Netz inzwischen auch Dutzende von wirklich guten Tutorials und Hilfestellungen. Daher will ich mich auch gar nicht wiederholen, sondern verweise stellvertretend auf den Blog-Artikel „NodeMCU-Board mit NodeMCU-Firmware – eine Einführung„. Kurz gesagt ist der ESP8266 ein Mikrocontroller mit WLAN-Schnittstelle und bietet einen TCP/IP-Stack sowie etliche Schnittstellen wie SPI, I2C sowie I/O-Ports. Dabei sind Flash-Speicher von 512 kB bis hin zu 4 MB enthalten, je nach Ausführung. Davon gibt es einige Module, die bekanntesten dürften unter den Bezeichnungen ESP-01 und ESP-12E zu finden sein. Für weitere technische Daten hilft wie immer die Suchmaschine der Wahl. Nicht minder interessant ist jedoch der Preis – je nach Ausführung kostet ein komplettes Modul gerade mal zwei bis drei Euro. Somit ist es perfekt geeignet für die immer weiter verbreitete Anwendung im Bereich „Smart Home“ bzw. weiter gefasst als „Internet of things“ (IoT). Programmieren lässt sich der Mikrocontroller in Lua, aber z.B. auch mit (Micro)Python, AT-Befehlen (man erinnere sich an Modems!), C, Arduino Core, ESP8266Basic oder ESP8266Forth.

Die Anfänge

Nun liegt meine erste und bis dahin auch letzte, eher suboptimale Erfahrung mit dem ESP8266 eine ganze Weile zurück. Ich hatte vor etwas mehr als einem Jahr davon gehört und mir zunächst einmal ein paar der extrem günstigen ESP-01-Module beschafft. Diese bieten immerhin zwei I/O-Pins, was beispielsweise für den Einsatz zur Temperaturmessung locker ausreicht. Nun ist die Programmierung jedoch etwas umständlich – entweder per USB-zu-Seriell-Adapter oder mit Hilfe eines Arduino. Zwar hatte ich die benötigten Adapter im Einsatz, und anfangs schien das Flashen der Firmware auch zu funktionieren, aber kurz vor einem erfolgreichen Ende brach die Verbindung immer wieder ab. Nach zahlreichen Versuchen hatte ich erstmal genug davon und orderte die insbesondere für den Einstieg einfacher zu benutzenden NodeMCU-Boards.

 

Ein solches Entwicklungsboard ist nicht viel teurer, hat aber handfeste Vorteile in Form einer USB-Schnittstelle und für Breadboards passenden Steckverbindungen. Zudem sind mehr I/O-Ports nach außen geführt und als ESP-Modul kommt das ESP-12E zum Einsatz. Daneben ist bereits die NodeMCU-Firmware vorinstalliert – oder sollte es zumindest sein. Derartige Boards lassen sich aktuell ab ca. 2,50 EUR z.B. bei Aliexpress bestellen, sofern man die Geduld für den Versand aus China mitbringt. Ansonsten werden die Boards auch hierzulande von den üblichen Händlern vertrieben und bewegen sich noch immer im Bereich von wenigen Euro. Damals hatte ich zwar die Geduld, aber nach der Ankunft habe ich die beiden Exemplare erstmal in den Schrank gepackt, in dem sie bis gestern geblieben waren.

Der Wiedereinstieg

Motiviert durch den Vortrag habe ich die Boards aus dem Schrank gekramt und wollte als einfachstes Beispiel die Netzwerkverbindung aufbauen und irgend etwas vom „Webserver-in-drei-Zeilen-Lua“ ausliefern lassen. Also noch ohne jegliche andere Hardware, erst sollte die Funktionsfähigkeit des Boards an sich bewiesen werden.

Dabei gab es trotz der Einfachheit einige Fallstricke, die ich im Folgenden skizzieren möchte. Wie erwähnt, es gibt eine Vielzahl von Anleitungen, Tutorials, Bauanleitungen, Hardware-Hinweisen usw., doch darum soll es mir hier zunächst nicht gehen. Das Ziel war, die Hardware grundsätzlich zum Laufen zu bringen.

Die Software: ESPlorer-IDE

Als Software für die ersten Schritte gibt es eine Art IDE namens ESPlorer. Dank Java ist das Programm unter nahezu allen Plattformen verwendbar, sieht jedoch auch dementsprechend aus. Voraussetzung ist natürlich ein installiertes JRE (Java Runtime Environment). Nach dem Download des zip-Files und nachfolgendem Entpacken habe ich auf die ESPlorer-Batch-Datei (ESPlorer.bat) geklickt. Das Programm wurde gestartet, allerdings habe ich nahezu nichts erkennen können, weil alles viel zu klein dargestellt war. Grund – ein benutzerdefinierter Skalierungsfaktor, ohne den ich am 4K-Display eine Lupe benötigen würde. Die Umstellung der Darstellung auf „Windows“ (Menüpunkt View -> Windows) hat zumindest beim Menü und einigen Elementen geholfen, Schriften im Terminal- und Editorfenster lassen sich ebenfalls unter „View“ vergrößern. Mit dem ESPlorer lässt sich eine Verbindung über die serielle (USB) Schnittstelle zum Mikrocontroller öffnen, so dass man direkten Zugriff darauf hat. Per Terminal kann man Kommandos eingeben, oder aber über den Editor Skripte erstellen, speichern, laden etc., die wiederum auf dem ESP-Modul gespeichert und ausgeführt werden. Weitere Features wie Logging oder Debugging (?) sind dann eher etwas für die fortgeschrittenere Nutzung.

Somit besteht der erste Schritt darin, das NodeMCU-Board anzuschließen und per ESPlorer anzusprechen, um darin z.B. die verwendete Firmware-Version anzeigen zu können.

Erste Verbindung und der Windows-Treiber

Zunächst also die grundsätzliche Verbindung herstellen – ein passendes USB-Kabel lag bereit, also schnell mal angeschlossen.

Das sah anfangs gut aus, denn Windows 10 erkannte den verwendeten Chipsatz und installierte die benötigten Treiber. Danach war ein neuer Eintrag „USB-Serial CH340“ in der Systemsteuerung unter „Bluetooth- und andere Geräte“ vorhanden. Wobei der Port zunächst als COM3 angegeben war – nicht wie im Screenshot als COM5. Dazu gleich mehr. Ich hatte aus praktischen Gründen die USB-Buchse vorne am Rechner genutzt.

Zumindest unter Windows 10 ist somit keine manuelle Treiber-Installation notwendig, wie auf der Rückseite des Boards angegeben. Die weiteren Schritte dieser Mini-Anleitung kann man ebenso ignorieren, denn als Verbindungsgeschwindigkeit können 115200 bps genutzt werden, nicht nur 9600 bps.

Daraufhin habe ich den ESPlorer gestartet, der in der Auswahlbox rechts COM3 gefunden hatte. Somit angewählt, die Übertragungsrate auf 115200 bps eingestellt und die Verbindung geöffnet (Button „Open“). Jedoch folgten daraufhin erstmal einige wirre Zeichen im darunter liegenden Terminalfenster. Laut diversen Hinweisen sollte man daraufhin den Reset-Knopf auf dem Board drücken (neben der USB-Buchse, bezeichnet mit RST). Aber auch das führte nicht zum Erfolg, denn die letzte Meldung waren wiederum wirre Zeichen und danach „AI-Thinker“. Gut, es handelte sich um ein Billig-Produkt aus China, anscheinend fehlte doch noch die richtige Firmware.

Probleme mit USB, Treiber, Hardware?

Aber weitaus schlimmer, zwischendurch brach die Verbindung ab, d.h. die COM3-Schnittstelle wurde nicht mehr gefunden. Windows kündigte dies durch den bekannten „USB-Gerät abgezogen“-Klang an. Wenig später wieder „USB-Gerät erkannt“. Und so weiter. Ein Neustart des Rechners half dabei nicht, absichtliches Abziehen und Einstecken des Boards ebenso wenig. Es wirkte wie ein Wackelkontakt, Windows erkannte in einer Sekunde das Modul, nach wenigen Sekunden war es wieder weg und das Spiel wiederholte sich, begleitet von sich überschlagenden Systemsounds.

Daraufhin testete ich das Szenario mit dem zweiten NodeMCU-Modul, jedoch ohne Erfolg, wechselte anschließend das verwendete USB-Kabel, doch auch das erbrachte keine Besserung. Ebenso wenig wie der Versuch, eine Buchse am USB-Hub zu verwenden. Somit habe ich erstmal nachgeforscht und tatsächlich mehrere Hinweise gefunden, dass es Probleme mit diversen Boards des Typs „LoLin“ mit dem CH340-USB-to-Serial-Chipsatz geben kann. In einem Forum wurde sogar empfohlen, zwei Dioden auf dem Board zu überbrücken, danach wäre der Betrieb stabil. Ein anderer Hinweis bezog sich darauf, einen USB-2.0- anstatt eines USB-3.0-Ports zu verwenden. Das wollte ich zunächst ausprobieren, somit schnappte ich mir einen anderen USB-Port von der Rückseite des Rechners. Und siehe da – der Chipsatz wurde erkannt, nun mit COM5 bezeichnet. Zumindest zeigten sich nach wenigen Minuten keine Ausfälle, insofern schien das erstmal halbwegs stabil zu laufen.

Es soll nicht unerwähnt bleiben, dass es weitere Versionen des NodeMCU-Moduls gibt, eine davon mit dem CP2102 bezeichneten USB-to-Serial-Chipsatz. Dieser soll angeblich stabiler laufen.

Nun zurück zum ESPlorer, COM5 für die Verbindung eingestellt, Verbindung geöffnet, auf dem NodeMCU-Board Reset gedrückt. Daraufhin zeigten sich wieder die wirren Zeichen, gefolgt von der Meldung „AI-Thinker“. Immerhin ließ sich dies jedoch wiederholen und die Verbindung war permanent vorhanden. Somit hieß es im nächsten Schritt, eine aktuelle Firmware darauf zu laden.

Flashen der NodeMCU-Firmware

Das Flashen der Firmware setzt zunächst einen Download derselben voraus. Die einfachste Möglichkeit ist die Nutzung des Cloud Build Service. Zugegebenermaßen ist es vielleicht ein wenig merkwürdig, dass man dort zwingendermaßen seine Mailadresse hinterlegen muss, an die dann Status-Updates bzw. eine Nachricht über die Fertigstellung gesendet wird, aber zur Not nimmt man eben eine der üblichen Wegwerf-Adressen, die ansonsten zur Verhinderung von Newsletter-Empfang verwendet wird. Als Neuling auf dem Gebiet weiß man möglicherweise auch noch nicht, welche der auf der Seite aufgeführten Module überhaupt sinnvoll bzw. notwendig sind. In dem Fall empfiehlt es sich, einfach bei der standardmäßig gesetzten Auswahl zu bleiben und später den Build-Schritt mit weiteren Modulen zu wiederholen.

Nach Start des Build hatte ich nach wenigen Minuten eine Nachricht über den erfolgreichen Bau der Firmware in meinen Mails. Darin befand sich der Download-Link auf zwei Varianten, einmal als „float“-, und einmal als „integer“-Version. Da die „float“-Fassung nicht signifikant größer ist als die „integer“-Version und ich davon ausgehe, dass man mit der „float“-Fassung auch integer-Werte berechnen kann, habe ich erstere benutzt.

Für den Vorgang des Flashens gibt es wie immer mehrere Tools, der Einfachheit halber habe ich den NodeMCU Flasher unter Windows verwendet. Der COM-Port war bereits ausgewählt und fiel korrekt auf COM5.

Anschließend wird im Tab „Config“ die Firmware-Datei ausgewählt, d.h. die Datei, die im vorherigen Schritt nach dem „Build“ heruntergeladen wurde.

Im Tab „Advanced“ habe ich zur Sicherheit noch die „Baudrate“ geprüft (eigentlich bps, bit/s), diese war ebenfalls korrekt bei 115200.

Danach kann wieder in den ersten Tab gewechselt und „Flash“ gedrückt werden.

Die blaue LED auf dem ESP8266 blinkt während des Flashens, der eigentliche Vorgang dauert nur wenige Minuten. Nach Beendigung wird im besten Fall der Erfolg im NodeMCU Flasher Tool angezeigt, wenngleich auch nur durch einen grünen Punkt mit einem Haken darin.

Danach kann das Tool wieder geschlossen werden, es geht zurück zum ESPlorer bzw. sollte dieser neu gestartet werden.

Erste Schritte mit dem ESPlorer

Nach dem Klick auf „Open“ ist die Ausgabe im Terminalfenster zu sehen, der Druck auf den Reset-Button auf dem NodeMCU-Board ließ mich zunächst einmal erstaunen, denn zunächst wurde die Meldung ausgegeben, dass das Filesystem formatiert würde. Wenig später meldete sich NodeMCU jedoch wie erwartet, und das Formatieren wird auch nur beim ersten Reset nach dem Flashen durchgeführt. Insgesamt sollte sich der ESPlorer zeigen wie im folgenden Screenshot:

Mit den Buttons „Heap“, „Chip Info“ etc. lassen sich zumindest grundlegende Statusabfragen durchführen. Wenn dies ohne Probleme und stabil funktioniert, waren die bisherigen Schritte immerhin bereits erfolgreich.

In der Eingabezeile unten lassen sich Kommandos direkt eingeben, hier könnte somit auch ein erstes Lua-Skript Zeile für Zeile geschrieben werden. Da dies etwas unkomfortabel ist, gibt es das Editorfenster links. In einigen Beispielen finden sich nun als erste Zeilen die Kommandos zur Initialisierung und Konfiguration der WLAN-Verbindung.

In den von mir besuchten Tutorials hießen die ersten Zeilen wie folgt:

wifi.setmode(wifi.STATION)
wifi.sta.config("SSID","Passwort")

Diese Zeilen lassen sich auch in der Kommandozeile eingeben, d.h. rechts unterhalb des Terminalfensters. Danach sollte die WLAN-Verbindung bereits vorhanden sein. Natürlich lässt sich diese im Anschluss daran noch prüfen, im Realbetrieb sollte dies auch durchgeführt werden, der eingangs erwähnte Vortrag gibt dazu ein Beispiel.

Während ich die erste Zeile problemlos eingeben konnte, wurde mir jedoch bei der zweiten eine Fehlermeldung ausgegeben:

Interessant, „config table not found“. Was für eine config-Table? Nachdem auch Google und der Blick in den Quellcode nicht viel geholfen hat (sinngemäß steht da drin „Wenn config-Tabelle vorhanden, dann initialisiere, ansonsten gib jene Fehlermeldung aus!“), dachte ich mir, dass ein Blick in die wirklich umfangreiche und gute Dokumentation von NodeMCU nicht schaden kann.

Das Rätsel war somit schnell gelöst, die Lösung befand sich in der Doku zum Modul „wifi“. Der wifi.sta.config()-Funktion muss eine Tabelle übergeben werden, die die Konfigurationsparameter beinhaltet. Aus einem der Beispiele kopiert:

station_cfg={}
station_cfg.ssid="NODE-AABBCC"
station_cfg.pwd="password"
wifi.sta.config(station_cfg)

Mitunter hilft tatsächlich das Lesen des Manuals… Ich vermute, dass sich die Parameter in den neueren Versionen einfach geändert haben, so dass die Konfiguration früher tatsächlich ohne diese Datenstruktur erfolgen konnte.

Der Rest lief dann wie im Beispiel beschrieben. Links im Editorfenster ist der Quelltext einzutragen, der danach auf das Modul übertragen wird (per „Save to ESP“). Nennt man die Datei „init.lua“, wird sie beim Start bzw. Reset des Moduls automatisch ausgeführt. Der gesamte Quelltext besteht nur aus wenigen Zeilen und ist bis auf die Initialisierung eine Kopie aus der o.g. Einführung:

station_cfg={}
station_cfg.ssid="SSID"
station_cfg.pwd="PASSWORT"
wifi.setmode(wifi.STATION)
wifi.sta.config(station_cfg)
srv=net.createServer(net.TCP)
srv:listen(80,function(conn)
    conn:on("receive",function(conn,payload)
    print(payload)
    conn:send("<h1> Hello, NodeMCU.</h1>")
    end)
    conn:on("sent",function(conn) conn:close() end)
end)

Wenn alles funktioniert hat, sollte nun der ESP8266 im WLAN erreichbar sein. Die IP-Adresse wurde per DHCP zugewiesen, natürlich lässt sich diese auch manuell konfigurieren. Per IP-Scanner oder auch Blick auf den DHCP-Server, z.B. im Router, lässt sich die vergebene IP-Adresse herausfinden. Dort hat sich das Modul bei mir als „NODE-XXXXX“ zu erkennen gegeben. Der Beispiel-Code stellt einen minimalen Web-Server dar, somit sollte sich unter der IP-Adresse die Meldung „Hello, NodeMCU“ zeigen, wenn man den Web-Browser darauf los lässt:

Tatsächlich hat dies genau so funktioniert, der Browser gab die Meldung aus, während im Terminalfenster von ESPlorer dank der Zeile „print(payload)“ die Requests vom Browser ausgegeben wurden:

Ausblick

Ein solcher Web-Server ist natürlich nicht als Ersatz für die Server-Software auf dem (virtuellen) Host gedacht, dazu ist die Bandbreite und die mögliche Anzahl paralleler Requests zu beschränkt. Vielmehr ist es eine einfache Möglichkeit, an Daten zu gelangen, die vom Mikrocontroller gesammelt werden, etwa von daran angeschlossenen Sensoren. Und genau das wären auch die nächsten Schritte, denn Möglichkeiten bietet der ESP8266 genug, und zusammen mit der einfachen Programmierung mit Lua dank NodeMCU und den vielen Anleitungen und Hinweisen da draußen sollte zumindest die Sammlung von Temperaturdaten keine größeren Probleme darstellen.

Nachtrag

Da die ersten Schritte hier auch eher suboptimal verlaufen waren, hatte ich mir ein weiteres NodeMCU-Modul bestellt, was mit dem CP2102-USB-to-Serial-Chipsatz bestückt sein sollte. Da dies heute angekommen war, bot sich die Chance, es zeitnah auszuprobieren. Es ist sogar noch ein bisschen kleiner als das LoLin NodeMCU v3 Modul und verwendet auch ein anderes ESP8266-Modul, was nach einem ESP-12F aussieht und eine verbesserte bzw. optimierte Version darstellen soll.

Eingesteckt in den USB-Port wurde auch für den USB-to-Serial-Konverter der Treiber nach wenigen Sekunden automatisch installiert:

Danach der obligatorische Test mit dem ESPlorer. COM6 wurde als Schnittstelle erkannt, insofern Verbindung öffnen und Reset gedrückt. Doch mit einer Verbindungsgeschwindigkeit von 115200 bps waren nur wirre Zeichen zu sehen. Daher habe ich die Geschwindigkeit auf 9600 bps verringert, erneut Reset gedrückt und siehe da, die Zeichen waren nicht nur lesbar, sondern im Terminalfenster erschien die Meldung, dass die NodeMCU-Firmware bereits installiert war.

Dennoch wollte ich die aktuelle Version der NodeMCU-Software einsetzen, schließlich war die installierte Fassung bereits über ein Jahr alt. Daher habe ich den NodeMCU-Flasher gestartet, die Parameter auf 9600 bps eingestellt und die weiteren Schritte ausgeführt wie weiter oben beschrieben. Jedoch tat sich – nichts. Die blaue LED blinkt zwar, aber darüber hinaus scheint nichts zu passieren. Kein Fortschrittsbalken, der sich bewegt, denn auch wenn das Flashen aufgrund der geringeren Übertragungsgeschwindigkeit länger dauert, müsste zumindest irgend etwas passieren. Nach einer Weile habe ich den Vorgang abgebrochen, ESPlorer erneut gestartet, auch dort fand sich der ursprüngliche Zustand wieder. Weitere Versuche führten ebenfalls nicht zum Erfolg, auch ein vorheriges Drücken des mit „Flash“ bezeichneten Tasters half nicht, insofern habe ich bislang noch keine Lösung dafür…