Wie schon in meinem vorherigen Eintrag versprochen, möchte ich zwei meiner aktuellen ESP Projekte im Detail vorstellen. Anfangen möchte ich mit meinem akkubetriebenen Sensor.
Eigentlich wollte ich mir eine hübsche Platine ätzen. Aber die Zeit lies das bisher nicht zu. Daher habe ich mit lauter Teilen von der Bucht die im Bild gezeigte Schaltung zusammen gebaut. Genauer handelt es sich dabei um
- ESP8266 WIFI Serial Development Kit Board (ESP-12E)
- Vander 3.7 Vol Li-Ion Akku
- DHT22 Temperature/Humidity Sensor
- 5V Micro USB 1A 18650 Lithium Battery Charging Board Charger Module
- Ein Schalter 🙂
Alles zusammen kostet ca. 10 Eur. Wobei ich nicht empfehlen kann, die o.g. Akkus zu kaufen. Ich habe, verführt durch den Preis, direkt zugeschlagen und erst im Nachhinein ein wenig recherchiert. Das hätte ich mal lieber vorher getan, dann hätte ich diese Akkus nicht gekauft. Demnächst ersetze ich den Vander durch einen Samsung oder Panasonic. Leider kostet da einer so viel, wie die 8 Vander. Aber wer will schon gerne abbrennen 😉
Hardware
Auf dem ESP8266 Development Board habe ich die Fotozelle entfernt. Wenn der ADC-Port des ESP12-E nicht beschaltet ist, dann kann man mit dem SDK die interne Versorgungsspannung des Moduls messen. Da ich in meinem Sensor-Projekt keine Verwendung für den ADC hatte, aber die Versorgungsspannung wegen dem Akkubetrieb eine relevante Kennzahl ist, habe ich mich dazu entschieden. Des weiteren habe ich auf der Platine die RGB-Led, sowie die SMD-LED für “Power-On” (Blaue LED) und die SMD-LEDs für die von mir anderweitig verwendeten GPIOs (Rote LEDs) entfernt. Damit können die GPIOs über die Stiftleisten abgegriffen und zum Beispiel der DHT22 angeschlossen werden. Auch spart das entfernen der LEDs Strom, da zumindestens die Power-LED ansonsten die gesamte Zeit leuchtet.
Geladen wird der Sensor also am USB-Port des Rechners, oder noch besser mit einem entsprechenden Handy-Netzteil. Das Charger Modul bietet einen Tiefentlade- und Überladeschutz. Einen Test des Moduls könnt Ihr im folgenden Video sehen.
Der DHT22 liefert Luftfeuchtigkeit und Temperatur zu. Den Sensor habe ich auf eine kleine Platine gelötet und ihm eine Pfostenleiste spendiert, da die Pins des Sensors selber zu dünn sind, um sie verlässlich in den Pfostensteckern der Kabel zu verankern. Um weiter Energie zu sparen, wird der Sensor nur dann vom Modul aktiviert, wenn auch Daten bezogen werden sollen. Dazu hängt die Versorgungsspannung des DHT22 auf einem GPIO des ESP12-E. Der Sensor verbraucht so wenig Strom, dass eine Versorgung via GPIO Pin kein Problem darstellt.
Software
Als weitere Sensordaten erfasse ich zur Zeit noch die interne Betriebsspannung (VDD) des ESP, den RSSI der WLAN-Verbindung sowie die free Heap-Size des Moduls. Diese Sensordaten übertrage ich per HTTPS an ein EMONCMS, um dort entsprechende Grafiken und Dashboards zu erstellen. Wirklich cool finde ich, dass die Übertragung der Daten seit Espressif SDK 1.3 per TLS möglich ist. In den Apache-Logs des Emon-Servers sieht das dann so aus:
[12/Oct/2015:20:58:41 +0200] 11.22.33.44 TLSv1.1 AES256-SHA "GET /emoncms/input/post.json?node=esp02&json={temp:21.89,humid:39.70,rssi:-57,vdd:3562,heap:45272}&apikey=myniceandsecretapikey HTTP/1.1" 2
Die Software auf dem Modul ist mit esp-open-sdk, esphttpclient und auf der Basis von esp_mqtt als eigenständige Firmware realisiert. D.h. ich habe mir esp_mqtt als Skeleton genommen, alle MQTT-Features entfernt, aber das Wifi- und Configuration-Handling, sowie die Verzeichnisstruktur und das Makefile als Basis verwendet.
Die Idee ist folgende: Das Modul startet, es verbindet sich zum WLAN (ich verwende das Guest-WLAN meiner Fritzbox um den IOT Krempel vom Rest getrennt zu halten). Parallel zum Verbindungsaufbau zum WLAN wird der DHT22 mit Strom versorgt. Da der Sensor auch “booten” muss und eine gewisse Zeit braucht, bis die Messwerte stabil sind, lässt sich das prima parallelisieren. Wenn die Verbindung zum WLAN erfolgreich war und per DHCP eine IP bezogen wurde, dann wird ein Timer gestartet, der nach 65 Sekunden einen REST Call per HTTPS an das EMONCMS absetzt. In der Zwischenzeit werden alle 30 Sekunden die Daten vom DHT22 gepollt. Manchmal geht der Poll in die Hose, da das Protokoll relativ Zeitkritisch ist, aber das ESP-SDK konzeptbedingt nicht immer eine genaue Zeitbasis liefern kann (WLAN und IP-Stack können Interrupts auslösen, die sich nicht unterbinden lassen und somit das Timing der DHT22 Kommunikation stören können). Bisher ist es aber noch nicht vorgekommen, dass 2 Polls hintereinander nicht funktioniert haben. D.h. nach 60 Sekunden liegen also in jedem Fall gültige Messwerte vo DHT22 vor. In der Callback-Funktion des REST-Timers (nach 65 Sekunden) werden dann noch die interne Betriebsspannung des Moduls, der RSSI und der Free-Heap ermittelt und dann zusammen mit den DHT22 Messwerte per HTTP übertragen. In der Callback-Funktion des HTTP-Client wird das Modul dann für 15 Minuten in den Deepsleep geschickt. Dabei wird auch der DHT22 wieder stromlos gemacht und der Energieverbrauch sinkt auf ein Minumum ab. Auf dem Bild zu Beginn des Berichts sieht man ein schwarzes Kabel, dass zwei Pins der oberen Pfostenleiste verbindet. Das sind GPIO16 und der Reset PIN. Ist diese Verbindung hergestellt, dann kann sich das Modul nach Ablauf des Deepsleep Timers selber wecken. Technisch wird hierzu in der RTC Einheit des Moduls ein Alarm gesetzt, der nach Ablauf den Reset-PIN triggert. Wenn das Modul aufwacht, dann beginnt der in diesem Abschnitt beschriebene Ablauf von vorne.
Es stellt sich jetzt also die Frage, wie lange der Akku halten wird. Und natürlich auch, wie lange ein qualitativ hochwertiger Akku halten würde 🙂 Prinzipiell kann man auch noch weitere Sensoren anbringen, wie z.B. OneWire Temperatur-Sensoren. Gerne würde ich meinen günstigen Mischgassensor verwenden. Aber das wird im Akku-Betrieb nichts, da der Strom zum Heizen des Sensors viel zu groß ist. Auch braucht der Sensor zwingend 5 Volt und kann daher nicht direkt am ESP betrieben werden. Das ist jetzt ein nette Überleitung zu meinem zweiten ESP-Projekt. Hier verwende ich das ESP-Modul zum senden und empfangen von Daten via WIFI. Die Sensoren aber sind an einem Atmega angebunden, der komplett Echtzeitfähig ist und auch 5 Volt Sensoren bedienen kann. Die Kommunikation zwischen dem Atmega und dem ESP erfolgt via I2C mit CRC prüfsummen (Timing nicht vergessen, das ESP kann auch die I2C Kommunukation zerhackstückeln). Nett ist auch, dass der Atmega das Modul aus dem Deepsleep holen kann, wenn Daten zur Übertragung bereit stehen. Da der Atmega deutlich energieeffizienter ist als das ESP ist das ein spannender Ansatz. Dazu mehr, wenn ich mal wieder Zeit finde.