Sensorknoten mit WLAN

Wie im letzten Post berichtet, plane ich mein Zuhause mit WLAN-Sensorknoten zu überwachen und habe dazu einige Teile in China bestellt. Nun ist alles da und ich habe ein wenig damit herumgespielt und berichte nun von meinem aktuellen Stand.

Das Entwicklerboard "NodeMCU"

Das Entwicklerboard enthält es zentralen Chip den ESP-12E, eine Variante des ESP8266. Daneben enthält das Board auch noch einen USB-Anschluss über den man den Chip mit Strom versorgen und programmieren kann. Außerdem führt das Board alle Pins des Chips nach außen sodass man diese mit Jumperkabeln verbinden kann. Das Board wird wahlweise per USB mit 5V oder über einen Stromanschluss am Board mit bis zu 9V versorgt. Ein Spannungsregler auf dem Board regelt die Spannung dann für den Chip herunter. Im Betrieb benötigt das Board ca. 70 mA.

Die Software für den Sensorknoten

Es war wirklich sehr leicht den Chip mit Arduino zu programmieren: einfach per USB anstecken, ein neues Board in Arduino installieren und schon kann man die Programme "Sketches" hochladen.

Auslesen der Sensoren

Für die beiden Sensoren BME280 und SHT-31D gibt es zahlreiche Arduino-Libraries, sodass sich die Sensoren mit einer Hand voll Codezeilen auslesen lassen. Wichtig für beide Sensoren ist, dass sie erst nach einer kleinen Wartezeit von ca. 250 ms sinnvolle Werte liefern. In der Zwischenzeit kann der Knoten aber schon eine WLAN-Verbindung herstellen um die Werte zu übermitteln. Dadurch ist die Wartezeit in den meisten Fällen kein großes Problem.

Datenübertragung

Ich lese derzeit die Sensoren alle 60 Sekunden aus und übermittle die Daten per WLAN an einen Server. Dazu muss der Knoten sich ins WLAN einwählen. Die meisten Tutorials im Internet verwenden hierfür DHCP. Das hat den großen Vorteil, dass der Knoten immer eine freie IP bekommt und man keine Netzwerkkonfiguration abspeichern muss. Leider dauert dadurch das Einwählen deutlich länger, weil der Knoten erst ein Paket senden und auf eine Antwort warten muss bis er tatsächlich seine Messwerte übertragen kann. Deshalb habe ich mich gegen DHCP und für eine statische Netzwerkkonfiguration entschieden.

Die Verbindung mit dem WLAN klappt einwandfrei. Mir ist dabei aufgefallen, dass sich der Knoten die Verbindungsdaten im Flash merkt und sich dann auch ohne Zugangsdaten im Sketch wieder in das WLAN einwählt. Das hat mich am Anfang sehr verwirrt aber scheint einen praktischen Nebeneffekt zu haben: Der Verbindungsaufbau wird mit der Zeit schneller. Die ersten paar Dutzend Male benötigt der Knoten ca. 3 Sekunden um ins WLAN zu kommen. Ab einem gewissen Punkt dauert es dann nur noch 200 ms. Ich muss das mal genauer untersuchen.

Zur Übertragung der Messwerte verwenden die meisten ähnlichen Projekte HTTP oder MQTT. Beide Protokolle haben deutliche Nachteile, die die Datenübertragung verlangsamen. HTTP und MQTT beruhen auf TCP, was bedeutet, dass der Knoten wieder eine Anfrage senden und eine Antwort empfangen muss bevor er seine Daten senden kann. Wenn der Empfänger im Internet steht kann das Sekunden kosten. Deshalb setze ich auf das Protokoll UDP, bei dem der Knoten seine Messwerte an das Netzwerk übergibt und sich direkt schlafen legt während das Netzwerk die Daten überträgt. Dabei kann es vorkommen, dass ein Paket und damit auch die Messwerte verloren gehen. Da das sehr selten vorkommt und einzelne Messwerte nicht so wichtig sind, ist das die höhere Akkulaufzeit wert.

Mit den genannten Optimierungen dauert die Datenübertragung unter 500 ms während andere Forenbeiträge bis zu 8 Sekunden angeben. Gerade wenn der Stromverbrauch wichtig ist, kostet jede unnötige Millisekunde die der Knoten nicht schläft Akkulaufzeit.

Die Serversoftware

Die Serversoftware habe ich komplett selbst programmiert. Sie besteht aus einem Server, der Messwerte über UDP empfangen und in eine Datei speichern kann. Das Dateiformat ist so optimiert, dass die Messwerte auch nach Jahren nur einige MBs benötigen und man daher nichts mehr wegwerfen muss. Der Server hat als zweiten Teil einen Webserver, der die Daten als interaktive Webseite über die die Daten der Sensoren (aktuelle und auch Werte aus der Vergangenheit) abgerufen und als Verlaufsgraph dargestellt werden kann. Die Webseite lässt sich auch als Icon auf einem Smartphone einrichten und bedient sich dann wie eine normale App.

Nachteile des Entwicklerboards

Eigentlich will ich die Knoten teilweise mit Akkus betreiben da ich nicht überall Kabel verlegen will. Der Chip verbraucht offiziell im Schlafmodus "deep sleep" nur 20 µA. Damit könnte er mit einem Akku mit 2000 mAh mehr als 11 Jahre schlafen. Wenn er dann alle 5 Minuten für 0,5 Sekunden 70 mA benötigt ergibt das einen Durchschnittsverbrauch von 137 µA und eine Laufzeit von immerhin 600 Tagen.

Leider ist das Entwicklerboard alles andere als stromsparend. Es verbraucht auch mit schlafendem Chip 40 mA. Das reicht für eine reine Schlafzeit von ca. 2 Tagen. Der hohe Verbrauch liegt unter anderem an den zusätzlichen Komponenten auf dem Board, dem Spannungsregler und dem USB-Programmierer.

Nach meinen Recherchen gibt es keine Entwicklerboards mit geringem Stromverbrauch. Wenn man den ESP8266 auf stromsparend trimmen will, muss man das selbst machen. Also habe ich mich hingesetzt und mein eigenes Board entworfen und auch gleich in China herstellen lassen. Ich berichte darüber wenn das Board ankommt.