Motivation
Nachdem wir 2016 in unser Haus gezogen waren, wurde auch das Umfeld jedes Jahr erweitert und mit vielen Pflanzen – vorwiegend von der immergrünen Sorte – gestaltet.
Die 400m² Rasenfläche verlangten regelmäßig nach Pflege. Für diese Aufgabe hielt ziemlich schnell ein Rasenmähroboter (Husquarna 315 mit nachgerüstetem W-LAN-Modul) Einzug. Aber auch das Gießen der Pflanzen und das Bewässern des Rasens wurde schnell zu einer recht zeitaufwendigen fast täglichen Beschäftigung.
Also wurde kurzerhand die Außenanlage mit einer automatischen Bewässerung auf Basis von Gardena-Komponenten erweitert.
Nun kann man den verwendeten Gardena Bewässerungscomputer duo zwar auf verschiedene Zeiten programmieren und die beiden getrennten Kreise mit jeweils einem Feuchtesensor versehen. Aber eben nur mit einem Sensor pro Kreis.
Die Idee ist, dass eine weiter verteilte Ermittlung der Bodenfeuchtigkeit eine optimalere Abdeckung des Bewässerungsbedarfs sicherstellt. Außerdem sollte so ein Sensor ja nicht allzu schwer zu bauen sein.
Und nebenbei bekommt man für’s SmartHome noch den aktuellen Feuchte-Status des Bodens in verschiedenen Regionen der Außenanlage geliefert. Denn das Projekt ist aktuell für zehn Sensoren ausgelegt, die frei im Gelände verteilt werden und zur Berechnung des Status‘ „Bewässern“ oder „nicht Bewässern“ mit einer individuellen Priorität versehen werden können.
Das Konzept
Das System besteht aus einem Master mit zwei Ausgängen zur Ansteuerung des Gardena Bewässerungscomputers und max. 10 Slaves zur Feuchtemessung. Die Slaves werden von jeweils einem Akku 18650 3.7V 3200 mAh versorgt. Dem Master habe ich drei dieser Akkus spendiert, da er wesentlich öfter geweckt wird und daher mehr Energie benötigt.
Als „Rechenknecht“ werkelt in beiden Typen ein Wemos D1 mini ESP8266. Sowohl Master als auch die Slaves wachen nach einer einstellbaren Zeit auf und werden nach dem Ablauf des Programms wieder in den Deep-Sleep versetzt. Damit die Akkus lange halten, muss neben genauen Softwareabläufen auch die Hardware etwas modifiziert werden. Ein gutes Video zum Thema Deep-Sleep und Energieverbrauch hat „The guy with the schwizer aczent“ – Andreas Spiess auf Youtube veröffentlicht.
Zum ersten Programmieren nutzt man natürlich die vorhandene USB-Schnittstelle. Da aber der USB/Seriell-Wandler dauerhaft etwas Strom zieht, auch wenn per USB keine Daten fließen, gehört er abgeklemmt. Dazu wird Pin 1 (GND) des CH340G abgelötet und etwas nach oben gebogen. Damit die Software dennoch aktualisiert werden kann, ist ein OTA Update eingebaut. Dazu guckt der ESP auf einem parametrierbaren Pfad auf einem der beteiligten Server auf dem ein http-Dienst läuft, vergleicht zunächst mit einer dort vorhandenen Datei die Versionsnummer der aktuellen Firmware mit seiner eigenen und lädt die neue Firmware, sofern es eine Datei mit seiner MAC-Adresse als Dateinamen gibt, führt das Update durch und startet neu.
Last but not least geht es natürlich um die Ermittlung, Übertragung und Auswertung von Sensordaten. Am Ende der eingestellten Schlafenszeit wird im jeweiligen Slave der Gies-O-Mat-Sensor aktiviert, die Frequenz gemessen und an den MQTT-Server (siehe Abschnitt „Die Datenhaltung – MQTT“) übertragen. Der Master wird ebenfalls regelmäßig geweckt, holt sich die Sensordaten vom MQTT-Server, berechnet die Grenzwerte und schaltet den eingebauten Widerstand, an dem der Bewässerungscomputer erkennt, ob er das Ventil zur vorprogrammierten Zeit öffnen soll oder nicht.
Der Master
Der Master besteht aus in drei Ebenen gestapelten Leiterplatten. In der Mitte der Wemos D1 mini, oben die Platine mit den Relais und 3,5mm-Klinkenbuchsen zum Anschluss der Verbindungsleitungen zum Bewässerungscomputer und unten ein paar Widerstände (R10, evtl. R9 und R8) . Da der ESP mit passenden Pin-und Buchsen-Leisten geliefert wird, kann die Konstruktion so montiert werden, dass die beiden äußeren Platinen auch wieder entfernt werden können. Die Verschaltung auf der oberen und unteren Platine erfolgt mit lackiertem Kupferdraht.
Hinweis: Für den Master wurde versuchsweise ein HUZZAH Modul mit ESP-12F ohne USB zu Seriell-Wandler verwendet, um beim Thema Stromverbrauch auszuschließen, dass trotz der oben beschriebenen Maßnahme ein erhöhter Ruhestrom fließt. Es konnte aber kein Unterschied festgestellt werden. Für die Programmierung ist in dem Fall ein externer USB/Seriell-Wandler erforderlich. Die Widerstände R8 und R9 fehlen ebenfalls und sind mit auf der unteren Ebene integriert. Die Markierung A0 im Schaltplan bezieht sich auf die Verwendung eines D1 mini Modul.
Das Ausgabesignal an den Bewässerungscomputer
Der verwendete Bewässerungscomputer (BC) erkennt an den beiden Eingängen, ob zu den vorprogrammierten Zeiten die Ventile geöffnet werden sollen oder nicht, in dem der am Eingang gemessene Widerstand ausgewertet wird. Werden 0 (Null) Ohm gemessen, also ist ein am Eingang angeschlossener Schalter geschlossen, ist dies mit ausreichend feuchtem Boden gleichzusetzen und die Ventile öffnen nicht. Sind es dagegen 10kOhm (R11, R12) wird das voreingestellte Programm des BC abgearbeitet. Ist der Widerstand >>10kOhm, ist des gleichbedeutend mit einem nicht angeschlossenem oder defektem Sensor oder einem Drahtbruch. Dann wird in jedem Fall das Programm abgearbeitet. So wird verhindert, dass bei einem Defekt im Sensorkreis die Pflanzen vertrocknen.
Im Deep-Sleep-Modus soll natürlich das Sensorsignal weiterhin dauerhaft am Eingang des BC’s anstehen. Ein ständig stromdurchflossenes Relais ist wegen des Energiesparansatzes natürlich nicht möglich. Daher kommen zwei bistabile Relais vom Typ omron G6SK-2 3VDC zum Einsatz. Der jeweils zweite Umschalter wird als Statusrückmeldung genutzt, damit auch nach einem Reset oder sonstigen undefiniertem Softwarezustand dem ESP immer bekannt ist, welchen Zustand der Sensor gerade an den BC ausgibt.
Auf der Relaisplatine des Masters sind für die beiden Ventil-Kanäle zwei 3,5mm Klinkenbuchsen montiert.
Der BC hat jedoch sehr spezielle Eingangsbuchsen zur feuchteabhängigen Beeinflussung der beiden Kanäle. Leider habe ich keine passenden Stecker im Ersatzteilsortiment von Gardena gefunden. Es gibt allerdings Ersatzverbindungskabel mit einem passenden angegossenen Stecker für den „GARDENA Regensensor electronic 1189“ z.B. auf www.ersatzteil-fee.de mit der Artikelnummer 1190-00.901.00 . An das Ende des einen Kabels kann ein passender 3,5mm Klinkenstecker angelötet werden. Somit besteht eine perfekte Verbindung zwischen dem PSMSense-Master und dem Gardena BC, wenn beide Kabelenden zusammen gesteckt werden..
Den Master zum Leben erwecken
Nach dem Flashen und erstmaligen Start spannt der Master sein eigenes W-LAN auf, zu dem man sich per Handy oder Tablet verbindet. Nach erfolgreicher Verbindung erscheint eine Konfigurationsseite unter der IP 192.168.4.1.
Nach der erfolgten Eingabe des Namens für den Master und der optionalen Serverangaben für MQTT, OTA- und Zeitserver, kann der Master neu gestartet werden. Es ist empfehlenswert, die durch den Router vergebene dynamische IP-Adresse per Reservierung auf die MAC des ESP fest einzustellen.
Das Frontend
Im Normalbetrieb wird der Master ein paar Sekunden online sein, um sich die Werte vom MQTT-Server zu holen und die Relaisausgänge zu schalten sowie auf Firmware-Updates zu prüfen und sich dann wieder schlafen zu legen.
Möchte man mit dem Master über das Webfrontend interagieren, um z.B. Parameter für die Berechnung der beiden Ausgänge einzustellen, muss man dem Master mitteilen, dass er nach dem nächsten Wecken wach bleibt und dies auch mitteilt.
Für diese Aufgabe gibt es im MQTT-Baum für den Master (als auch für jeden Slave) jeweils zwei Topics. Über den Topic „PSMSense/wakeup/master/00“, der manuell mit z.B. dem MQTT-Explorer oder jedem anderen Werkzeug mit vergleichbarem Funktionsumfang auf den Wert „1“ zu setzen ist, wird dem Master mitgeteilt, dass er nach dem nächsten Erwachen aus dem Deep-Sleep sich nicht wieder sofort schlafen legen soll. Sein Erwachen hinterlegt er in dem Topic „PSMSense/iamawake/master/00“ ebenfalls mit einer „1“. Diesen Zustand kann man mit dem Smart-Home-Server seiner Wahl auswerten und sich melden lassen. Abhängig von der eingestellten Deep-Sleep-Phase kann das Erwachen bis zu 71 Minuten dauern. (Diese Zeit ergibt sich aus dem internen 32 Bit Register und dem Wert von 1µs/Decrementierungsschritt.)
Meldet der Master sein Erwachen, kann über die beim Inbetriebnahmeprozess festgelegte IP-Adresse auf das Web-Frontend zugegriffen werden.
Auf der Startseite werden die konfigurierten Slaves mit dem zuletzt auf dem MQTT-Broker hinterlegten Messwert, der aktuellen Spannung der Akkus von Master und Slave, den Zuständen der Relais sowie einige URL’s zum direkten Abfragen von Statusinformationen oder Erzeugen von Betriebszuständen angezeigt.
Über den Button „Configuration“ im Header der Seite sind die Einstellungen erreichbar. In der nachfolgenden Tabelle sind die einzelnen Optionen beschrieben. Nach der Anpassung der Einstellungen sind diese über den grünen „Save“-Button zu speichern und der Master über den roten „Reboot“-Button einmal neu zu starten. Die mit * markierten Werte wirken sofort nach dem Speichern.
Über den gelben Button „Update“ kann direkt ein OTA-Update durchgeführt werden. Nach erfolgter Installation des zuvor ausgewählten Firmwarefiles führt der ESP ein Reboot durch.
Update: Im Alltag hat sich herausgestellt, dass die häufige Berechnung der Relaiszustände durchaus dazu führen kann, dass während eines laufenden Programmes des Bewässerungscomputers die Sensordaten und damit das berechnete Ausgabeergebnis der Relais ändern kann. Das führt u.a. zum Schließen des Ventils. Dadruch können zum Einen undefinierte Zustände der einzelnen Ventile in den verschiedenen Bewässerungskreisläufen entstehen. Außerdem kann es dazu führen, dass gerade die Bereiche, die zu einem späteren Zeitpunkt programmiert sind, häufig kein Wasser bekommen, da sich der Gesamtfeuchtezustand schon vorher geändert hat. Um das Programm ohne Störung ablaufen zu lassen, kann jetzt eine Sperrzeit für die Statusänderung der Relais gesetzt werden.
| Parameter | Bedeutung |
|---|---|
|
HOSTNAME |
Legt den Namen für den Master fest. Wird z.B. im W-LAN angezeigt. Beispiel: PSMMASTER |
|
MQTT SERVER |
IP-Adresse oder DNS-Name des MQTT-Servers (Broker). |
|
MQTT ENABLED?* |
Nach dem Erststart ist die Verbindung zum MQTT-Server deaktiviert. Muss hier explizit eingeschaltet werden. |
|
NTP SERVER |
IP-Adresse oder DNS-Name eines Zeitservers. Default: europe.pool.ntp.org |
|
NTP ENABLED? |
Nach dem Erststart ist die Verbindung zum Zeitserver-Server deaktiviert. Muss hier explizit eingeschaltet werden. |
|
OTA-UPDATE SERVER* |
IP-Adresse oder DNS-Name des Update-Servers. Anfragen laufen per HTTP. Der Ordner mit den Firmewaredateien ist im Quelltext definiert. Beispiel: http://<ip>/PSMSenseReceiver/ |
|
OTA-UPDATE ENABLED?* |
Nach dem Erststart ist die Verbindung zum OTA-Update-Server deaktiviert. Muss hier explizit eingeschaltet werden. |
|
MEASURE FREAQ POWER MODE (MINUTES) |
Häufigkeit der Berechnungen im Netzbetrieb (D6=GPIO12=High). System bleibt dauerhaft wach. |
|
MEASURE FREQ BATTERY MODE (MINUTES) |
Deep-Sleep-Time im Akku-Betrieb (D6=GPIO12=Low). |
|
NUMBER OF SENSORS* |
Anzahl auszuwertender Sensoren (Slaves). Max. 10 |
|
BATTERY VOLTAGE CORRECTION* |
Korrekturwert der gemessenen Akku-Spannung des Masters. [V] |
|
BLOCKING TIME FROM* |
Beginnzeit der im Beregnungscomputer programmierten Bewässerungszeit |
|
BLOCKING TIME TO* |
Endzeit der im Beregnungscomputer programmierten Bewässerungszeit |
Durch Klick auf den türkisfarbenen Button „Sensors“ gelangt man auf die Konfigurationsseite zur Einstellung der Berechnungsparameter für die Steuerung der BC-Ventile.
In der ersten Spalte der Konfigurationstabelle ist der Name des Slaves einzutragen. Dies muss nicht zwingend der Name aus der Grundkonfiguration sein. In den beiden folgenden Spalten werden sowohl die zuletzt gemessenen Frequenzen des Gies-O-Mat-Sensors als auch die aktuellen Akku-Spannungen angezeigt. Über die Checkbox in der folgenden Spalte kann der jeweilige Sensor für die Berechnung aktiv oder inaktiv definiert werden. Bei defektem oder außer Betrieb befindlichen Sensoren wird so das Berechnungsergebnis nicht verfälscht. Mithilfe der Radio-Button in der nachfolgenden Spalte wird der Sensor einer von zwei Berechnungsgruppen zugeordnet, deren Ergebnis auf das jeweilige Ventil des BC wirkt.
Je nach Dynamik der Bodenfeuchte kann die zu berücksichtigende Priorität in der Berechnung definiert werden. Dazu wird ein Wert zwischen 1 und 100% in dem nachfolgenden Feld eingetragen. Als letztes wird der Schwellenwert in kHz definiert, über dem der Boden des jeweiligen Sensors als trocken und unter dem der Boden als feucht definiert ist. Oberhalb des eingetragenen Wertes würde man also selber zur Gießkanne greifen.
Update: Mit Version 3.1.434 wurde die Compiler-Direktive #define MQTT_PUBLISH eingeführt, mit der explizit das Publishen diverser Einstellungen aus dem Master aktiviert wird. Durch das Auskommentieren dieser Direktive kann man mit einem Test-Master arbeiten, der die echten Sensorwerte nutzt aber eigene Einstellungen verarbeitet ohne diese zu veröffentlichen.
Ab Version 3.2.517 wird ausreichend feuchter Boden im Vergleich zum eingestellten Schwellwert durch einen blauen Hintergrund und trockener Boden im Vergleich zum zugeordneten Schwellwert durch einen sandfarbenen Hintergrund in den Sensoreinstellungen markiert.
Hinweis: Das Layout des Webfrontends basiert auf dem front-end open source toolkit „bootstrap“. Die CSS-Datei wird direkt vom Server aus dem Internet geladen. Daher ist für den Betrieb von Master und Slave der Zugang zum Internet sehr zu empfehlen. Das gilt im Zweifel auch für die Zeitsynchronisation.
Vorbereitung des Gies-O-Mat-Sensors
In diesem Abschnitt soll. es kurz um den eigentlichen Feuchtesensor gehen. Es gibt verschiedene Messverfahren, die Erdfeuchtigkeit zu bestimmen. Man kann die Erde mit einem Widerstand aufheizen und nach dem Abschalten die Zeit messen, die das nachlaufende Wasser benötigt den Erdboden so zu durchdringen, dass die Ausgangsfeuchte erreicht ist. Diese Zeit ist dann das Maß für den Bewässerungsbedarf.
Oder man misst über zwei Elektroden schlicht den Widerstand des Erdbodens, der je feuchter dieser ist entsprechend kleiner wird. Das ist nach meinen Recherchen im Internet auch das Verfahren, welches am häufigsten beschrieben wird. Es wird aber auch gleichzeitig der größte Nachteil dieses Verfahrens beschrieben. Die Widerstandsmessung erfordert einen ständigen, wenn auch geringen, Stromfluss. Strom, Metall und Feuchtigkeit führen aber zu Ionenwanderung. Dadurch lösen sich die Elektroden – zumindest eine der beiden – relativ schnell auf.
Das dritte Verfahren ist die indirekte Messung einer Kapazität, deren Dielektrikum der Erdboden bildet und die sich je nach Feuchte ändert. Ist diese Kapazität Teil eines Frequenzgenerators, kann anhand der unterschiedlichen Ausgangsfrequenz ein Erdfeuchteäquivalent abgeleitet werden.
Dieses Verfahren macht sich der Gies-O-Mat zu nutze. Friedrich Ramser aus Salzburg hat diesen Sensor entwickelt. Der Sensor ist dort bestückt oder unbestückt beziehbar. Es werden für den zweiten Fall die SMD-Bauelemente mitgeliefert. Und mit ein klein wenig Löterfahrung lassen diese sich auch schnell und sauber auf die fertige Platine aufbringen. Die beiden Kondensatorplatten sind als dünne Kupferschicht des Leiterplattenmaterials ausgebildet und lackiert. Es wird aber dringend empfohlen, den Teil, der später im feuchten Erdboden steckt mit einer wasserfesten Beschichtung zu versehen. Dafür ist z.B. ECS Cleaning Solutions 71 URETHANE Polyurethan geeignet. Der Lack härtet aus und schütz die dünnen Kupferelektroden vor Korrosion.
Nach erfolgreicher Montage der Bauelemente und Anschluss an den D1 mini (siehe Inbetriebnahme) sollte die Software ca. 470 kHz anzeigen. Diese Frequenz entspricht der „Trockenheit“ des Raumes. Je nach Luftfeuchte schwankt sie auch um einige zig kHz. Durch Auflegen der Hand auf den Sensorteil wird man eine starke Veränderung hin zu weit niedrigeren Frequenzen feststellen. Die praktische Erfahrung des letzten Sommers hat reale Frequenzen zwischen 10kHz (kurz nach Regenereignissen oder der Bewässerung) bis zu 30 kHz, wenn es mal wieder Zeit wurde zu gießen, ergeben.
Hinweis: Auch wenn die Trockenfrequenz in der Praxis nicht vorkommt, führt sie zumindest in der Testumgebung dazu, dass ein bei 80MHz betriebener ESP durch die ca. 470.000 Interrupts/s aus dem „Takt“ kommt und das Programm sich aufhängt. Daher muss der Sketch mit einer Einstellung von 160 MHz Systemtakt kompiliert werden.
Die Slaves
Die Slaves bestehen nur aus dem Wemos-D1-mini-Modul, einem Akku und dem Gies-O-Mat-Sensor. Die Montagen für den Slave als auch den Master sind im Kapitel „Inbetriebnahme“ erläutert.
Update 1 vom 04.05.2021: Eines der ToDo’s war die Messung der Temperatur. Die Funktion ist ab der Softwareversion V1.20 implementiert.
Als Sensor wird ein DS18B20 verwendet. Die Beschaltung des ESP8266 mit dem Sensor und dem erforderlichen Pull-Up Widerstand R14 für den 1-Wire-Bus ist im Schaltplan ersichtlich. Um die Energie des Akku’s zu schonen, wir für die Stromversorgung der geschaltete Plus des Gies-O-Mat-Sensors mit genutzt. Die Quelltextpassagen für die Nutzung des Sensors können per Compilerdirektive (aktuell in Zeile 105) aktiviert werden.
Hinweis zum DS18B20: Offensichtlich kursieren vom DS18B20 diverse Nachbauten, die nicht die erwarteten Messergebnisse zur Verfügung stellen. Die Erkennung von Original-Dallas-Chips ist neben wenigen äußeren Merkmalen mit Arduino-Sketchen möglich. Beides ist auf dieser Seite sehr gut dokumentiert.
Das Web-Frontend der Slaves ist gegenüber dem des Masters etwas einfacher gehalten. Im oberen Bereich der beiden Webseiten wird die aktuelle Firmwareversion sowie die Nummer des Slaves angezeigt. Darunter befindet sich die Statusleiste, in der der Name des Slaves, die aktuelle IP-Adresse sowie die MAC-Adresse des ESP-Moduls angezeigt werden. Ebenfalls in der Statusleiste platziert ist der Button zur Anzeige der Konfigurationsseite.
Auf der Startseite werden die zuletzt gemessene Frequenz des Gies-O-Mat-Sensors, die aktuelle Akku-Spannung sowie einige Links zur Steuerung des ESP und Aufruf von Statusseiten angezeigt.
Die Fußzeile gibt Auskunft über die erfolgreiche Verbindung zum MQTT-Broker, die korrekt eingestellte Zeit durch einen konfigurierten NTP-Server sowie die URL des OTA-Updates.
Über den Button „Configuration“ im Header der Seite sind die Einstellungen erreichbar. In der nachfolgenden Tabelle sind die einzelnen Optionen beschrieben. Nach der Anpassung der Einstellungen sind diese über den grünen „Save“-Butten zu speichern und der Slave über den roten „Reboot“-Button einmal neu zu starten. Die mit * markierten Werten wirken sofort nach dem Speichern.
Über den gelben Button „Update“ kann direkt ein OTA-Update durchgeführt werden. Nach erfolgter Installation des zuvor ausgewählten Firmwarefiles führt der ESP ein Reboot durch.
| Parameter | Bedeutung |
|---|---|
|
HOSTNAME |
Legt den Namen für den Slave fest. Wird z.B. im W-LAN angezeigt. Beispiel: PSMSLAVE01 |
|
MQTT SERVER |
IP-Adresse oder DNS-Name des MQTT-Servers (Broker). |
|
MQTT ENABLED? |
Nach dem Erststart ist die Verbindung zum MQTT-Server deaktiviert. Muss hier explizit eingeschaltet werden. |
|
NTP SERVER |
IP-Adresse oder DNS-Name eines Zeitservers. Default: europe.pool.ntp.org |
|
NTP ENABLED? |
Nach dem Erststart ist die Verbindung zum Zeitserver-Server deaktiviert. Muss hier explizit eingeschaltet werden. |
|
OTA-UPDATE SERVER |
IP-Adresse oder DNS-Name des Update-Servers. Anfragen laufen per HTTP. Der Ordner mit den Firmewaredateien ist im Quelltext definiert. Beispiel: http://<ip>/PSMSenseSlave/ |
|
OTA-UPDATE ENABLED? |
Nach dem Erststart ist die Verbindung zum OTA-Update-Server deaktiviert. Muss hier explizit eingeschaltet werden. |
|
MEASURE FREAQ POWER MODE (MINUTES) |
Häufigkeit der Sensorabfragen im Netzbetrieb. (D6=GPIO12=High). System bleibt dauerhaft wach. |
|
MEASURE FREQ BATTERY MODE (MINUTES) |
Deep-Sleep-Time im Akku-Betrieb (D6=GPIO12=Low). |
|
SENSORNUMBER |
Nummer des Sensors (Slaves) Werte: 1-10 |
|
BATTERY VOLTAGE CORRECTION |
Korrekturwert der gemessenen Akku-Spannung des Slaves. [V] |
Die Datenhaltung - MQTT
Wenn es nicht gerade wie aus Eimern gießt, ändert sich der Zustand der Bodenfeuchtigkeit eher moderat. Es ist daher sinnvoll, die Slaves in einem Abstand von 3-6 Stunden wach werden zu lassen um den aktuellen Wert zu ermitteln.
Der Master kann und sollte häufiger nach geänderten Werten seiner Slaves Ausschau halten. Da das Übertragen der Werte von den Slaves zum Master quasi asynchron abläuft, ist eine Zwischenspeicherung notwendig. Dafür bietet sich ein MQTT-Dienst an. In meinem Fall läuft auf einem der Server der Open Source Message Broker mosquitto. Der Dienst wird auch von anderen SmartHome-Komponenten genutzt – z.B. der Wetterstation , um Daten auszutauschen. Zudem können die Messwerte der Sensoren und das Berechnungsergebnis des Masters die Basis für eine Visualisierung in der Homeautomatisierung bilden, die dann ebenfalls Topics abonnieren kann.
Im Normalfall wird ein veröffentlichter Wert, der dem Broker durch eine Publisher übermittelt wird, sofort an die Subscriber genannten Abonnenten weitergeleitet. Da es recht unwahrscheinlich ist, dass der Master immer genau dann wach ist, wenn einer der Slaves sendet, müssen die Werte im Broker zwischen gespeichert werden. Sobald der Master wach geworden ist und sich beim MQTT-Broker angemeldet hat, bekommt er diese Werte, die er abonniert hat, zugeschickt und kann sie verarbeiten. Das Zwischenspeichern wird dem Broker durch ein gesetztes Bit, dem retain-Bit, mitgeteilt.
Hinweis: Möchte man auf das Webfrontend eines Slaves oder des Masters zugreifen, muss dem jeweiligen ESP gesagt werden, dass er nach dem nächsten Wecken wach bleiben soll (z.B. PSMSense/wakeup/master/00=1 oder PSMSense/wakeup/sensor/01=1). Diese Nachricht muss auch mit dem gesetzten retain-Bit übertragen werden, damit das jeweilige Gerät sie nach dem Erwachen zugestellt bekommt.
Im oben abgebildeten Screenshot ist der gesamte „MQTT-Baum“ des Projektes dargestellt. Im Beispiel sind fünf Sensoren konfiguriert. Der Master sowie Sensor01 sind gerade zum Wachbleiben aufgefordert worden. Der Master hat diesen neuen Betriebszustand bereits quittiert (PSMSense/iamawake/master/00=1). Diese Meldung kann in der Hausautomation ausgewertet und z.B. per Pushover o.ä. versandt werden. Denn im „schlimmsten“ Fall kann die Rückmeldung 71 Minuten auf sich warten lassen. Danach steht der Zugriff auf das Webfrontend zur Verfügung. Am Ende der Konfigurationsanpassung oder Überprüfung von Statusdaten darf nicht vergessen werden, den Master oder Slave wieder in den DeepSlepp zu versetzen. Andernfalls ist am nächsten Tag der Akku leer.
Als weitere Statusmeldungen sind PSMSense/humid/master/state/1 und PSMSense/humid/master/state/2 zu erwähnen. Sie stellen den aktuellen Zustand der Relaisausgänge des Masters in Richtung BC da.
Zudem können beide Ventilkreise per Vorgabe über die Topics PSMSense/humid/master/enaHumidCalcSensor[1,2]/00=0 vom Berechnen ausgenommen werden, so dass der BC nur nach seinem voreingestellten Zeitprogramm arbeitet.
Die Deep-Sleep-Steuerung
Über den Deep-Sleep-Modus des ESP8266 wird viel im Internet geschrieben. Daher möchte ich hier nur meine Umsetzung für dieses Projekt kurz erläutern.
Damit der Ablauf des internen Timers den ESP per Reset aus dem DeepSleep wecken kann, ist zwischen D0 und RST eine Brücke einzulöten. Bei manchen Modulen ist diese Brücke schon vorbereitet und muss mit etwas Lötzinn nur noch geschlossen werden.
In der Core-Firmware des ESP ist der Timer für den Deep-Sleep in einer vorzeichenlosen 32-Bit-Variable definiert. Daraus ergeben sich max. 4294967295 bzw. 0xffffffff µs, was ca. 71 Minuten entspricht.
Bei den ersten „Versuchen“ mit dem Deep-Sleep-Modus wurde der ESP jedoch schon nach 35 Minuten wieder wach. Nach etwas Recherche im Internet hat sich herausgestellt, dass den „Erfindern“ des ESP 71 Minuten scheinbar auch zu wenig waren und so wurde statt der 32-Bit-Variable eine 64-Bit-Variable für den Timer eingeführt. Das hat aber offensichtlich nicht zum entsprechenden Erfolg geführt. Daher habe ich in der Firmware diese Variable wieder auf 32 Bit geändert und habe so wieder die 71 Minuten max. Deep-Sleep Zeit erreicht.
void EspClass::deepSleep(uint32_t time_us, WakeMode mode)
{
system_deep_sleep_set_option(static_cast<int>(mode));
system_deep_sleep(time_us);
esp_yield();
}
Neben der Anpassung in der Esp.cpp muss die Definition der Funktion deepSleep() auch in der Headerdatei Esp.h angepasst werden.
void deepSleep(uint32_t time_us, RFMode mode = RF_DEFAULT);
C:\Users\<username>\AppData\Local\Arduino<version>\packages\esp8266\hardware\esp8266\<coreVersion>\cores\esp8266
Unter dem oben angegebene Pfad sind bei einer Standardinstallation der Arduino-IDE die beiden Dateien zu finden.
Natürlich soll es nicht bei 71 Minuten maximaler Schlafenszeit bleiben. In der Konfiguration sowohl des Masters als auch der Slaves kann ein weitestgehend beliebiger Wert in Minuten eingetragen werden. Das Programm merkt sich den Faktor im EEPROM des ESP, wenn er größer als 71 Minuten ist und decrementiert diesen Faktor bei jedem Aufwachen um eins, bis er Null ist. Nach den verbleibenden Minuten startet der ESP normal und arbeitet sein Programm ab. Somit wird ein Timer mit (n mal 71)+m Minuten erreicht.
Um bei dem mehrfachen Wecken Energie zu sparen, wird dem Deep-Sleep-Modus bis zum vorletzten Aufwachen auch immer die Option mitgegeben, beim kurzen Wachwerden zur Dekreminierung der Weckzyklen das WLAN-Modul ausgeschaltet zu lassen.
Hinweis: Diese Funktion ist aktuell nur in den Slaves realisiert.
Spannungsmessung des Akkus
Die Lage der einzelnen Bauelemente, sowie die Anschlussbelegung sind in diesem Dokument ganz gut erkennbar.
Die oben erwähnten Spannungsmessung soll natürlich nicht die aufbereiteten 3,3V messen, sondern die „Rohspannung“ des Akkus. Der interne Spannungsteiler des D1 mini besteht aus R8 (100k) und R9 (220k). Bei einer Betriebsspannung von 3,3V bleiben so ca. 1V über R8 stehen, was der max. erlaubten Eingangspannung an A0 entspricht. Da ein voll geladener 18650 Akku bis zu 4.7V haben kann, wird der Spannungsteiler auf eine max. Eingangspannung von 5V ausgelegt. Daraus ergibt sich R10 mit 180k. Die Werte der drei Widerstände unterliegen einer starken Streuung. Es empfiehlt sich, aus einer Hand voll 180k-Widerständen den auszumessen, der zusammen mit den beiden auf dem D1 mini verlöteten genau 500kOhm ergibt. Beim Einlöten von R10 zwischen A0 und 5V+ empfiehlt sich zudem, diesen zur Isolierung in Schrumpfschlauch zu betten. Eine sehr gute Dokumentation der Spannungsteilertheorie und Lage der entsprechenden Widerstände auf dem D1 mini ist auf dieser Webseite zu finden.
Bei Nutzung des HUZZAH Modul muss der Spannungsteiler 100kOhm A0-GND / 400 kOhm A0- Akku komplett mit externen Widerständen realisiert werden.
Hinweis: Bei ca. 4,7V und 500kOhm Spannungsteiler ergibt sich ein zusätzlicher Querstrom von ca. 9 µA, der die Akku-Laufzeit belastet. Es ist also ein Abwägungsprozess. Will ich wissen, wann der Akku geladen werden muss, dann muss gemessen werden und die Standzeit des Akkus verkürzt sich. Oder habe ich die Werte der letzten Übertragung in MQTT im Auge und wechsle den Akku, wenn die Werte nicht mehr aktualisiert werden, weil dem Slave die Energie ausgegangen ist.
Geht dem Master die Energie aus, verbleiben die beiden Relaisausgänge dennoch in ihrer letzten Position, was im ungünstigsten Fall zur Deaktivierung des Bewässerungsprogramms führt und bei längerer Abwesenheit die Vertrocknung der Pflanzen zur Folge haben kann.
Over-the-Air-Update (OTA) der Firmeware
Nachdem beim Wemos D1 mini aus Gründen der Energieeinsparung nach dem ersten Überspielen der Firmeware per USB diese Schnittstelle – wie oben beschrieben – außer Betrieb genommen wird, bleibt nur noch die Möglichkeit des Übertragens per USB/Seriell-Wandler und Nutzung von Rx und Tx oder die Luftschnittstelle per W-LAN und OTA.
Die manuell angestoßene Übertragung erfolgt aus der Konfigurationsseite des Webfrontends heraus. Der orangefarbene „Update“-Button führt zu einer minimalistischen Seite, auf der die Firmware-Datei in Form einer *.bin ausgewählt und sofort per W-LAN zum ESP geschickt wird. Nach einem automatischen Neustart steht die neue Version (was auch eine älter als die gerade installierte sein kann) zur Verfügung.
Für das automatische Update sind ein paar Voraussetzungen zu schaffen.
Zunächst muss in der Konfiguration ein Http-Server definiert sein, auf dem die Updatefiles zu finden sind. Das kann ein lokaler und/oder minimaler Webserver, z.B. ein Verzeichnis innerhalb des SmartHome-Servers, sein, wenn dieser Http als Protokoll zur Verfügung stellt. Oder es kann auch ein Unterverzeichnis auf dem eigenen öffentlichen Webserver sein. Dann sollte man aber den Zugriff mit der .htaccess entsprechend absichern.
Ich nutze einen kleinen Webserver, der ohnehin auf dem FHEM-Server läuft. Auf diesem habe ich zwei Unterverzeichnisse angelegt: PSMSenseSlave und PSMSenseReceiver. In beiden Ordnern gibt es eine Datei namens firmware.version und die *.bin – also die per „Sketch->Kompilierte Binärdatei exportieren Strg+Alt+S“ aus der Arduino IDE gespeicherte Firmware-Datei. Die Bin-Datei gelangt per (S)FTP z.B. mithilfe von WinSCP auf den Webserver. Pro ESP existieren auf dem Webserver zwei Links auf diese beiden Dateien. Diese Links sind in der Form <MAC>.version und <MAC>.bin aufgebaut. Die ESP-Firmware guckt nach ihrer individuellen Datei und vergleicht die in der *.version hinterlegte Versionsnummer mit der aktuell installierten Version um zu entscheiden, ob die Server-Version neuer ist. Die Versionsnummer wird ohne Punkte in der Datei hinterlegt. Die aktuelle Slave-Version ist z.B. 1.19.97 (siehe Screenshot MQTT-Baum), die in der *.versions-Datei als 11997 hinterlegt ist.
Die beiden statischen Links müssen bei der Inbetriebnahme des ESP auf dem Webserver einmalig manuell mit folgenden Kommandos angelegt werden (sofern Linux als Betriebssystem verwendet wird). Der Dateiname ESP_PSMSense.ino.d1_mini.bin ergibt sich aus den Einstellungen in der Arduino-IDE und kann sich unterscheiden. Die MAC-Adresse des ESP-Moduls wird u.a. im Header des Frontends angezeigt und wird im Link ohne Punkte oder Doppelpunkte geschrieben.
ln -s ESP_PSMSense.ino.d1_mini.bin F4CFA2D84AE5.bin
ln -s firmware.version F4CFA2D84AE5.version
Der Vorteil bei der Verwendung von Links ist der, dass nur die exportierte BIN-Datei ausgetauscht werden muss und alle Slaves „sehen“ sofort diese neue Datei. Würde man die Datei je Slave physisch vorhalten, müsste man bei jedem Update soviel Kopien erzeugen, wie es Slaves gibt und jede Kopie so umbenennen, dass die MAC wieder im Dateinamen steht.
Wie wird nun die Versionsnummer automatisch inkrementiert?
Um das Autoincremet der build number zu aktivieren, sind drei Schritte notwendig. Die Zeichenkette ist natürlich durch den entsprechenden Namen des Windows-Benutzerverzeichnisses zu ersetzen.
Schritt 1: Zunächst wird eine Batch-Datei benötigt, die beim Kompilieren vom Compiler aufgerufen wird und die Versionsnummer in der Datei version.h, die innerhalb des Projektpfades liegt, um eins erhöht. Haupt- und Nebenversion müssen bei Bedarf manuell angepasst werden.
Die Datei increment.bat kann im Prinzip an einer beliebigen Stell liegen. Wo sie gespeichert ist, wird in Schritt zwei definiert. Nehmen wir an, sie liegt an folgender Stelle:
C:\Users\<username>\Documents\Arduino\increment.bat
@echo off
echo ------------------------------- increment.bat script ----------------------------------
rem ========================================================================================
rem == This script automatically increments build number in "version.h" file.
rem == Instructions and more information:
rem == http://codeblog.vurdalakov.net/2017/04/autoincrement-build-number-in-arduino-ide.html
rem ========================================================================================
setlocal
set output=%1
echo output=%output%
set source=%2
echo source=%source%
set filename=%source%\version.h
echo filename=%filename%
for /f "delims=" %%x in (%filename%) do set define=%%x
echo %define%
for /f "tokens=1-3 delims= " %%a in ("%define%") do (
set macro=%%b
set version=%%c
)
echo macro=%macro%
set version=%version:~1,-1%
echo version=%version%
for /f "tokens=1-3 delims=. " %%a in ("%version%") do (
set version=%%a.%%b
set build=%%c
)
echo build=%build%
set /a build=%build%+1
echo build=%build%
set version=%version%.%build%
echo version=%version%
set line=#define %macro% "%version%"
echo %line%
echo filename=%filename%
echo %line% > %filename%
type %filename%
set filename=%output%\sketch\version.h
echo filename=%filename%
echo %line% > %filename%
type %filename%
set curdir=%cd%
cd %source%
rem == Uncomment following line to commit updated version.h file to Git repository
rem == Uncomment second line to tag commit
rem git commit -am "Version %version%"
rem git tag %version%
cd %curdir%
echo --------------------------------- increment.bat script ---------------------------------
Schritt 2: Der Arduino-IDE muss mitgeteilt werden, wo sie die Batch-Datei findet. In diesem Fall ist die Datei plattform.txt speziell für ESP8266-Sketche zuständig. Diese Datei liegt innerhalb des nachinstallierten Bord spezifischen Orderns für den ESP8266. In dieser Datei gibt es schon einige Abschnitte, die mit recipe.hooks…. beginnen. Die neuen Zeilen können einfach an den Anfang des Bereichs kopieren werden. A wie Autoincrement steht dann quasi alphabetisch an der ersten Stelle dieser hooks-Liste.
C:\Users\<username>\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\<$VERSION>\plattform.txt
##Autoincrement version number
recipe.hooks.sketch.prebuild.0.pattern=C:\Users\<username>\Documents\Arduino\increment.bat {build.path} {build.source.path} {build.project_name}
Schritt 2a (optional): Soll die Funktion Autoincrement auch bei Arduino-Sketchen funktionieren, kann diese Einstellung nach demselben Schema noch in einer weiteren plattform.txt-Datei vorgenommen werden, die für Boards vom Typ Arduino zuständig ist.
In der unten aufgeführten Datei die Zeichenkette „##AVR compile patterns“ suchen und die beiden Autoincrement-Zeilen direkt darunter in die Datei kopieren.
C:\Programme\arduino-<version>\hardware\arduino\avr\plattform.txt
# AVR compile patterns
# --------------------
##Autoincrement version number
recipe.hooks.sketch.prebuild.0.pattern=C:\Users\<username>\Documents\Arduino\increment.bat {build.path} {build.source.path} {build.project_name}
Schritt 3: Im Sketch sollte dann noch eine Konstante definiert werden, die die Versionsnummer aus version.h übernimmt. Somit kann die jeweils aktuelle Version im Programm zur Abfrage und Anzeige verwendet werden. (In den beiden Sketchen dieses Projektes ist das natürlich realisiert.)
const String VERSION = SKETCH_VERSION;
Inbetriebnahme
Für die Inbetriebnahme habe ich mir einen 13-Punkte-Plan (mit DS18B20 sind es 14 Punkte) aufgestellt, damit am Ende nichts fehlt. Einige Schritte treffen allerdings nicht gleichermaßen für Master und Slave zu, daher sind die Schritte mit M und/oder S markiert.
Schritt 1 (M/S): Flashen. D.h., das Sketch wird per USB oder per Wandler (wenn ein Modul ohne integrierten USB/Seriell-Wandler verwendet wird) auf den ESP8266 übertragen. Beim ersten Starten sind noch keine W-LAN-Daten hinterlegt, daher spannt der ESP über den im Sketch eingebundenen WiFi-Manager ein eigenes W-LAN unter der SSID „PSMSense-Config-<ChipId>“ auf. An dieser Stelle muss man sich mit einem Handy oder Tablet zu diesem (ungesicherten) W-LAN verbinden. Im Idealfall wird die Konfigurationsseite des ESP nun automatisch angezeigt. Alternativ ruft man mit dem gerade verbundenen Gerät die Konfigurationsseite unter http://192.168.4.1 auf. Im oberen Bereich der Seite werden die erkannten W-LAN’s angezeigt. Nach Antippen der gewünschten SSID wird diese in das entsprechende Eingabefeld übertragen. Nun muss das W-LAN-Passwort noch ergänzt und alternativ die Daten der wichtigsten Server erfasst werden. (Beschreibung siehe oben).
Diese Verfahren der W-LAN-Konfiguration hat den Vorteil, dass im Sketch keinerlei W-LAN-Credentials hinterlegt werden müssen.
Schritt 2 (M/S): Um später den Widerstand R10 (siehe Kapitel Spannungsmessung) passend aus der Bauteilkiste rauszusuchen, wird nun zwischen A0 und GND die Summe der beiden auf dem D1 mini verlöteten Widerstände R8 und R9 gemessen.
R10 = 500kOhm – (R8+R9).
Der Wert von R10 liegt dann erfahrungsgemäß zwischen 177 und 183 kOhm. Sollte sich kein passender Widerstand in der Bastelkiste finden, kann der Spannungswert auch über das Setup des PSMSense korrigiert werden.
Schritt 3 (M/S): Verbindung +5V mit Plus-Pol-Batterie – vorzugsweise mit einem roten Schaltdraht.
Schritt 4 (M/S): Verbindung GND mit Minus-Pol-Batterie – vorzugsweise mit einem blauen Schaltdraht.
Schritt 5 (S): Verbindung Minus-Pol-Batterie mit Gies-O-Mat-Sensor-GND – vorzugsweise mit einem blauen Schaltdraht.
Schritt 6 (S): Verbindung D1 mit Plus-Pol des Gies-O-Mat-Sensor – vorzugsweise mit einem roten Schaltdraht. Über diesen Anschluss wird der Sensor nur mit Spannung versorgt, wenn der Messvorgang läuft. Das dient der Energieeinsparung.
Schritt 7 (S): Verbindung D7 mit SensorOut des Gies-O-Mat-Sensors – vorzugsweise mit einer dritten Farbe für den Schaltdraht.
Schritt 8 (M/S): Den unter Schritt 2 ermittelten Widerstand mithilfe eines kleinen Stück Schrumpfschlauches isolieren und zwischen +5V und A0 einlöten.
Schritt 9 (M/S): Verbindung D0 mit RST. Entweder ist schon eine zu schließende Lötbrücke vorhanden oder es hilft ein kurzes Stück Schaltdraht. Diese Brücke benötigt der ESP, um sich aus dem Deep-Sleep zu wecken. D0 wird auf GND gezogen, wenn der interne Sleep-Timer einen Nulldurchgang auslöst.
Schritt 9a (S): DS18B20 (Pin 2 und 3) und 4,7kOhm-Widerstand (R14) zusammenlöten. Drei kurze (5cm) Schaltdrähte (z.B. rot, grün, blau) an den Sensor anlöten und diese mit GND, D1 (+) und D4 (1-Wire) verbinden. Sensor durch ein Stück Schrumpfschlauch isolieren.
Schritt 10 (M/S): Testen.
Schritt 11 (M/S): Pin 1 des CH340 ablöten. Damit ist keine Verbindung per USB mehr möglich. Für das Debugging muss nun ein USB/seriell-Wandkler an RX und TX angeschlossen werden.
Schritt 12 (M/S): Spannung des verwendeten Akkus messen und mit dem im Web-Frontend angezeigtem Wert vergleichen. Evtl. Korrekturfaktor auf der Konfigurationsseite eintragen.
Schritt 13 (M/S): Brücke zwischen D5 und GND löten. Damit wird dem Sketch mitgeteilt, dass der ESP im Akku-Betrieb läuft und geht nach dem Durchlaufen des Programms in den Deep-Sleep-Mode.
Gehäuse und Energieversorgung für Master und Slave
Sowohl das Master- als auch das Slavegehäuse sind mit dem 3D-Drucker erstellt. Die Witterungsbeständigkeit wird sich im Laufe der Zeit noch zeigen. Nach einem Sommer sehen sie noch ganz gut aus. Als Material wurde schwarzes PLA verwendet. Der Gies-O-Mat-Sensor benötigt zwei Kerben (siehe rote Markierung im Bild Gies-O-Mat-Sensor) um nicht aus dem Gehäuse zu rutschen. Dafür sind im Gehäuse zwei Nasen vorgesehen. Eine weitere Fixierung ist nicht notwendig.
Beide Gehäuse bestehen aus einem zusammenhängenden Körper. Der Slave ist mit drei separaten Deckel für D1 mini, Akku, und Sensoranschluss mit 2x10mm Schrauben verschlossen.
Der Master benötigt nur zwei Deckel.
Update 16.05.2021: Für die Platzierung des PSMSensor-Slaves auf dem Rasen, der regelmäßig durch den Auto-Mower oder Rasenmäher bearbeitet wird, darf das Gehäuse natürlich nicht zu weit über die Grasnabe hinaus ragen und muss im Zweifel auch durch den Mähroboter überrollt werden können. Dafür gibt es jetzt noch ein zweites Gehäuse, bei dem der Gies-O-Mas-Sensor im Winkel von 90 Grad am Gehäuse montierbar ist.
PSMSense Master Gehäuse
PSMSende Master geöffnet
Master am Garde BC montiert
PSMSense Slave im Gehäuse
PSMSlave geöffnet
PSMSense-Slave 90grd Montage
PSMSense-Slave 90 grd
PSMSense Slave DS18B20 Sensor
Als Stromversorgung kommen Li-Ion-Akkus der Bauform 18650 mit 3.7V und ca. 3000-3600 mAh zum Einsatz. Da der Master, wie oben beschrieben, wesentlich häufiger aus dem Deep-Sleep erwacht, hat er drei Akkus in Parallelschaltung spendiert bekommen.
Das Gehäuse des Slaves ist für einen Batteriehalter mit waagerechter Lötfahne ausgelegt.
Im unteren Teil des Mastergehäuses ist dagegen Platz für einen Dreifach-Batteriehalter vorgesehen.
Die meisten handelsüblichen Halterungen gehen von einer Reihenschaltung der drei Einzelzellen aus. In diesem Fall wollen wir aber eine Parallelschaltung erreichen, damit die verfügbare Energie bei gleicher Spannung größer ausfällt. Dazu müssen die Batteriekontakte auf der Plus- als auch auf der Minuspol-Seite mithilfe eines dünnen Schaltdrahtes verbunden werden.
Bei dem unten abgebildeten und verlinkten Exemplar ist die Verschaltung individuell an den Lötfahnen der Unterseite möglich.
Vor dem Kauf der Akkus ist es empfehlenswert, das Innenmaß der erworbenen Halterungen zu kennen. Da es Akkus mit ausgeprägtem Pluspol bzw. mit einer ebenen Kontaktfläche – so wie auch in beiden Fällen der Minuspol gestaltet ist – gibt, sind die Akkus des ersten Typs 1-2mm länger und könnten zu stramm in der Halterung sitzen.
Fallstricke und Besonderheiten
Bei der Entwicklung stößt man immer mal auf Effekte, die sich zunächst nicht erklären lassen und ungeplante Zeit in Anspruch nehmen, um gelöst zu werden. Einige davon möchte ich hier kurz erläutern, da sie evtl. beim Nachbau Fragen aufwerfen oder ebenfalls eintreten.
Eine etwas ungewöhnliche Baudrate für's Debugging
Üblicherweise wird in der Setup-Funktion die serielle Übertragung auf 115200 Bit/s festgelegt. Innerhalb der Arduino-IDE kann dann der Monitor auf eben diese Geschwindigkeit eingestellt werden, sodass Debug- oder Fehlermeldungen mitgelesen werden können.
Allerdings gibt der ESP-Core seine Fehlermeldungen oder auch die Meldungen des OTA-Prozesses mit 74880 Bit/s aus. Das führt dazu, dass z.B. bei solchen Fehlern, wie dem im folgenden Abschnitt beschriebenen, nur Hyroglyphen im Monitor-Fenster erscheinen und erst einmal unklar ist, welches Problem gerade aufgetreten ist.
Um diese zu entschlüsseln, muss die Übertragungsrate des Monitors kurzzeitig auf 74880 Bit/s eingestellt werden und sich der Fehler wiederholen.
Was liegt da näher, als auch die normalen Debug-Meldungen mit einer Geschwindigkeit von 74880 Bit/s auszugeben. Daher wird in beiden Sketchen die serielle Übertragung mit eben dieser Geschwindigkeit initialisiert.
Der Boot-Prozess endet mit (rst cause:2, boot mode:(3,6))
Wenn die Geschwindigkeit des Debug-Monitors auf 74880 Bit/s eingestellt ist, bekommt man mitunter solcher Fehlermeldungen zu sehen.
Die komplette Meldung sieht in etwa so aus. Wobei sich die Checksummen natürlich unterscheiden können.
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
Die hinter „cause:“ angegebene Nummer sind in der folgenden Tabelle aufgeführt. Ein Softreset führt nicht zur Änderung der Rst cause No.
Der boot mode gibt in der ersten Ziffen (3) an, von welchem Medium gebootet wird. Dies wird durch den logischen Pegel der Ein-/Ausgänge GPIO0, GPIO2 und GPIO15 zum Bootzeitpunkt festgelegt. In diesem Fall wird vom internen Flash gebootet.
Die zweite Ziffer (6) repräsentiert die Pins GPIO13, GPIO14 und GPIO15 und legt den Betriebsmodus beim Booten von SD-Card fest. Diese Stelle ist also für die Interpretation des Resets nicht relevant.
Eine sehr gute Zusammenfassung der Boot-Modes- und Error-Codes sind bei Riktronics und auf dieser Seite zu finden.
Soweit zur Vorrede.
Der Fehler trat erst gehäuft auf, als die Funktion OTA und der Deep-Sleep-Modus zusammentrafen.
Wurde der ESP aus dem Deep-Sleep wach, was ja bedingt durch die Brücke zwischen GPIO0 und RST einem „echten“ Reset – also cause:2 – entspricht, und hat festgestellt, dass eine neue Firmware vorhanden ist, hat er diese per OTA geflasht und einen Reboot durchgeführt. Der Reboot entspricht einem Softreset und wird daher beim erneuten Start nicht explizit angezeigt. Es bleibt beim cause:2. Soweit ist das alles normal. Dennoch bleibt der ESP im oben gezeigten Modus stehen und der Laie wundert sich.
Einige Hinweise aus verschiedenen Foren deuteten auf Spannungsprobleme durch Stromspitzen und fehlende Glättungskapazitäten hin. Das schien aber in diesem Fall nicht zu die Ursache zu sein.
In einem der Core-Software-Entwicklungsforen war dann zu lesen, dass es wohl beim Flashen über USB zu einem undefinierten Zustand eines Fuse-Bits kommen kann, was bei einem erneuten Flash – dann aber per OTA – zu diesem Effekt führt.
Dies Problem konnte nur im „Betriebssystem“ des ESP beseitigt werden. Mit der Version 2.4.7 des ESP Core, die aus diesem Grund dringend empfohlen wird, war dann auch der Fehler behoben.
Die beim Kompilieren zu linkende Core-Version ist in der Arduino-IDE unter Werkzeuge->Boardverwalter->Typ“ESP8266″ zu installieren.
DeepSleep endet schon nach 35 Minuten
Der Besonderheit der Dauer des DeepSleep-Timers ist ein eigenes Kapitel gewidmet. An dieser Stelle soll noch einmal auf die Effekte der verwendeten 64-Bit bzw. 32-Bit Variablen hingewiesen werden.