ESP8266 / ESP-01 mit Deep-Sleep an Batterie

Ich habs jetzt nach zwei Tagen mühsamer Fummelei endlich geschafft nen ESP-01 mit DeepSleep-Modus zu betreiben, was bedeutet dass ich ihn nunmehr endlich auch mit Batterie betreiben kann.

Elke brauchte das dringend das für ihr Anzuchtgewächshaus, weil das alte System im Winter seinen Geist aufgegeben hatte. Das ist schon uralt (stammt noch aus der Prae-Arduino-Zeit) und basierte auf nem alten Atmel AVR-Netio board, mit Datenübertragung per Ethernet-Kabel.

Ich habe dazu bereits vor ein paar Jahren *DIESEN* Blog-Artikel gemacht, zu dem ich auch bis heute immer mal wieder Anfragen erhalte.

Eine schnelle Lösung wäre gewesen, den ESP8266 mit nem Arduino Nano zusammenzustöpseln, aber ich träume schon seit langem davon, den ESP8266 standalone und mit Batterie zu betreiben.

Das hab ich aber bisher nicht ans laufen gekriegt, weil es weniger trivial ist als man äusserlich vermuten würde. Der Punkt ist, dass eine normale NiMH Batterie bereits nach 24h leer ist, weil der ESP ziemlich viel Strom zieht, das können so 250 bis zu 400 mA sein.

Es gibt aber einen Weg, das zu umgehen, indem man ihn zwischendurch in den DeepSleep-Modus versetzt und alle 10 min wacht er kurz auf, misst und versendet seine Daten und inaktiviert sich wieder.

Vom Prinzip her eigentlich nicht so schwer, aber das Problem besteht darin, dass er zum Aufwachen ein Reset-Signal benötigt, welches aber beim ESP-01-Board nicht auf einen Anschlusspin rausgeführt ist, man muss diese Verbindung also nachträglich anlöten … was bei dem kleinen SMD-chip eine feinmotorische challenge ist

Ich hatte den ESP früher mit einer speziellen Toolchain (Esplorer + NodeMCU-Firmware/LUA) programmiert, aber mittlerweile gibt es ja volle Unterstützung vom Arduino IDE, worauf ich eh gerne umsteigen wollte. Also, das klappt jetzt auch ganz gut, allerdings hat der ESP zum Programmupload keinen seriellen Bootloader wie der Arduino, sondern es wird direkt geflasht (was immer ein paar Sekunden länger dauert.)

Dazu ist es notwendig G0 auf GND zu setzen um ihn zu programmieren und anschliessend Reset kurz gegen GND zu ziehen um ihn zu resetten und normal zu betreiben.

Wenn man ihn aber gleichzeitig noch über den serial-monitor debuggen möchte, dann gibts ein Problem, nämlich dass der Saft nicht reicht.

Man muss also die Stromversorgung (vcc) aus dem FTDI-Adapter unterbrechen und gleichzeitig dem ESP-01 eine eigene 3V-Stromversrgung verpassen, das kann entweder aus einer Batterie sein, oder wie in meinem Fall mit einem AMS1117 Spannungsregler, der aus 5V die benötigten 3.3V macht. Den wiederum versorge ich über einen separaten USB-Anschluss.

Damit gings dann schliesslich. Man muss sich halt daran gewöhnen beim testen dauernd zwischen Programming- und Betriebs-Modus hin und her zu switchen und bei jedem Switch einen Reset mit auf den Weg zu geben.
Aber damit kann man den ESP8266 direkt und standalone mit der Arduino-IDE programmieren UND betreiben (was ja während der Entwicklung zum testen öfters mal nötig ist.)

Ich bin mit dem ESP-01 Modul schon ganz zufrieden. Eine spannende Frage war noch, ob es auch die Reichweite bis nach draussen ins Gewächshaus (ca. 20m) und durch ein paar Wände hindurch schafft, aber das klappt gut. Andernfalls hätte man durch anlöten eines 12cm Drahtes die Platinenantenne ersetzen und die Reichweite noch verbessern können. Der hat aber jetzt auch so schon eine bessere Reichweite zum WLAN (bzw. zur Position des WLAN-Routers) hin als manche Handys.

Eine inhaltliche Erkenntniss bei der Sache war für mich noch, dass der Batteriebetrieb nicht mit jeder Art von Anwendung möglich ist, namentlich nicht mit solchen, die einen kleinen Webserver auf dem ESP8266 benötigen.

Dieser setzt nämlich voraus, dass der ESP ständig im WLAN lauscht, ob sich ein client connecten möchte, etwa um sich die DataSamples abzuholen. Wenn er aber ständig lauschen muss, dann kann ich ihn nicht gleichzeitig in Tiefschlaf vesetzen.

Sinnvoll ist der Batteriebetrieb also nur mit Anwendungen, die von sich aus die Datas pushen, wie hier zum ThingSpeak Server oder das könnte auch ein lokaler Server sein, zB. ein Raspi. Weil er dafür halt gezielt aufgeweckt werden kann, das dann eben erledigt und sich anschliessend wieder schlafen legt.

Leider ist der fliegende Aufbau mit Breadboard und DuPont-Steckern eine ziemlich fragile Sache und ich hab mich mal allgemein nach Development-Boards umgesehen.

An bereits fertigen Boards hab ich nix passendes gefunden, aber es gibt auf der Blog-Seite von Martyn Currey eine schöne Bauanleitung für Lochrasterplatine, die für meine Ansprüche perfekt ist und keine Wünsche offen lässt und die ich demnächst mal nachbauen möchte.

In einem anderen Artikel beschreibt Martyn sein Toolchain-Setup für Entwicklung mit der Arduino-IDE und erwähnt dabei, dass er den Grossteil der Entwicklung auf dem etwas größeren NodeMCU-Board macht und erst am Schluss, wenn alles läuft, die Firmware dann auf ein ESP-01-board flasht.

Für diverse Alltagsanwendungen war mir das NodeMCU-Board bislang zu teuer, aber man braucht ja nur ein einziges davon als Entwicklungsboard und lässt die Anwendungen dann später auf den ESP-01-boards laufen, die nur einen Bruchteil davon kosten.

Für die Entwicklung ist das NodeMCU auch gut ausgestattet, indem es z.B. die zwei Buttons für das flashen und den Reset hat, sowie einen FTDI-Chip, so dass die Stromversorgung und SerialMonitoring über den USB-Anschluss erfolgen kann, also genau wie beim Arduino.

Ich hab mir denn auch gleich ein NodeMCU bestellt, halte das selbstgelötete Entwicklungsboard für den ESP-01 aber trotzdem noch für sinnvoll, nämlich um am Ende die fertigen Programme auf den ESP-01 übertragen zu können. Ausserdem ist dabei der Flash-Taster durch einen Schiebeschalter ersetzt worden, was mir deutlich ergonomischer erscheint. Der entsprechende Taster auf der NodeMCU ist nämlich sehr klein und es ist mühsam den während des ziemlich langen Flashvorgangs die ganze Zeit sauber runtergedrückt zu halten. Aber bis ich das andere Board selbst gelötet habe ist das erst mal ok und kann später noch als Referenz- und Ersatz-Entwicklungsboard dienen. Und mittlerweile sind die Preise auch etwas gesunken, ich hab grad mal 7,70 EUR dafür bezahlt.

Wenn man nun mehrere solcher autonomen Sensoren an unterschiedlichen Orten haben möchte, dann ist der Aufbau mit dem ESP-01 aber nicht nur deutlich preisgünstiger, sondern auch noch smarter, weil hierbei ja das ganze Geraffel mit dem Flash- und Reset-Button entfallen kann, lediglich um den GPIO16-Anschluss kommt man nicht drumrum. Eine gute Beschreibung dieser Schaltung kann man *HIER* finden.

Verbleibt noch die Frage, wie lange denn nun die Batterie tatsächlich reicht. Die Tests dazu laufen im Moment noch, wobei ich zum einen eine Lithium-Zelle mit 3000 mAh verwende und zum anderen zwei NiMH AA-Batterien mit schätzungsweise 400 bis 800 mAh. Genau kann ich das bei letzterer (noch) nicht sagen, denn selbst wenn da z.B. insgesamt 800 mAh drin stecken, kann man die u.U. nicht voll ausnutzen, denn beide Zellen zusammen haben gerade mal 3.2V (statt der eigentlich verlangten 3.3V) und es ist die Frage, wie weit die Spannung runtergehen darf, ehe der ESP8266 nicht mehr mitspielt. Der ist sowiso ziemlich zickig, was unzureichende Stromversorgung angeht (und letztere ist das was man bei Problemen als erstes checken sollte).

Aber vorsichtig geschätzt erwarte ich bei den NiMH Zellen eine Dauer von 5 bis 8 Tagen, wobei die im aktuellen Test bereits 3 Tage rum haben und das ist – dank dem DeepSleep-Modus schon deutlich mehr als vorher, wo sie gerade mal knapp 24h gehalten haben. Das ist aber letztlich ohnehin keine Option, weil es sich um Einweg-Batterien handelt (zwei NiMH-Akkus würden zusammen nur 2.4V Spannung ergeben, was nicht ausreichend wäre).

Der Li-Akku könnte rein rechnerisch durchaus bis zu 40 Tagen halten, was u.a. auch von der Dauer der DeepSleep-Phase abhängt, ich würde den später gerne mit 5 Minuten Intervallen betreiben aber teste momentan konservativ mit nur einer Minute.

Der Stromverbrauch während der DeepSleep Phase ist im Datenblatt mit 20 uA angegeben, allerdings kommt da ja auch noch der Verbrauch des Temperatursensors und seines 4.7K-Widerstands hinzu. Eine Messung ergab in diesem Setup 28 uA, was mir immer noch als sensationell günstig erscheint. Aber mal abwarten was der Langzeit-Test in der Praxis letztendlich ergibt, ich werde den Wert dann hier noch nachreichen.

Achja, und was ich bei dieser Gelegenheit jetzt auch mal ans laufen bekam, das war die Datenübertragung nach ThingSpeak, also einem externen IOT-Server im Internet.

Ich halte davon aber nicht wirklich viel, weil ich lieber einen eigenen Raspi-basierten Server hier im lokalen WLAN verwende und ausserdem finde ich die Darstellung der Visualisierung bei denen ziemlich grottig und es gibt zumindest vordergründig wenig Einstellungsmöglichkeiten. Ich bleibe da lieber bei meiner alt-erprobten Variante mit rrdtool, allerdings war es dabei bislang so, dass der Server immer vom Sensor gepollt hat, während ich die Daten aber nun vom Sensor aus auf den Server pushen muss, wie oben bereits angedeutet.

Das habe ich aber auf denkbar einfachste Weise realisiert mittels eines kleinen CGI-shellscripts, welches im WLAN lauscht und ankommende Daten dann sofort in der rrdtool-Datenbank ablegt. Das gefällt mir eigentlich ganz gut im Vergleich mit der alten Version, bei der ein mittels Crontab getriggertes Shellscript die Abfrage des Sensors periodisch angestossen hat, was aber mitunter insbesondere bei größeren Anwendungen mit vielen Sensoren schon mal zu timing-Problemen führen kann. Aber ab jetzt ist ja beides möglich