Energieeffiziente Programmierung

Viele IoT-Anwendungen müssen über lange Zeiträume autonom arbeiten und dabei möglichst wenig Energie verbrauchen. Besonders bei batteriebetriebenen Systemen ist ein effizienter Umgang mit der verfügbaren Energie entscheidend, um Wartungsaufwand zu reduzieren und lange Laufzeiten zu erreichen. Der ESP32 bietet dafür verschiedene Energiesparmodi, mit denen sich der Stromverbrauch im Vergleich zum normalen Betrieb deutlich senken lässt.

Ziele:  

In diesem Tutorial werden die beiden wichtigsten Schlafmodi des ESP32 betrachtet: Lightsleep und Deepsleep. Beide Verfahren verfolgen das Ziel, ungenutzte Hardware-Komponenten temporär abzuschalten, unterscheiden sich jedoch deutlich hinsichtlich Stromverbrauch, Aufwachverhalten und möglicher Einsatzszenarien. Während Lightsleep einen schnellen Wiedereinstieg in den normalen Betrieb ermöglicht, ist Deepsleep besonders für Anwendungen mit langen Ruhezeiten geeignet.

Zur praktischen Umsetzung wird im Verlauf des Tutorials ein zyklisch arbeitender Datenlogger entwickelt. Das System erfasst in regelmäßigen Zeitabständen Messwerte, sendet diese an einen Cloud-Dienst und wechselt anschließend in einen der Energiesparmodi. Auf diese Weise lässt sich exemplarisch zeigen, wie sich energieeffiziente IoT-Systeme mit dem ESP32 realisieren lassen, ohne auf regelmäßige Datenerfassung und Vernetzung zu verzichten.

Lightsleep: Hier wird nur die CPU pausiert, während große Teile der Peripherie (z. B. RAM und bestimmte Schnittstellen) aktiv bleiben. Der Systemzustand (z. B. Inhalte aller Variablen) bleibt vollständig erhalten. 

• Sehr schnelle Reaktionszeit: Aufwachen in wenigen Mikrosekunden
• Kein Neustart erforderlich: Programm läuft an derselben Stelle weiter, an der es pausiert hat
• Geeignet für Echtzeitanwendungen: z. B. bei häufigen Events
• Komplexeres Power-Management, da Komponenten gezielt gesteuert werden müssen

Im Deepsleep dagegen wird der Großteil des Systems einfach abgeschaltet. Nur ein kleiner Teil, der sogenannte RTC-Bereich (Real-Time Clock), bleibt aktiv, um ein späteres Aufwachen zu ermöglichen. Im RTC-Speicher können wir unsere Variablen speichern, sodass auch trotz Reset eine Zustandsmaschine realisiert werden kann.

• Sehr geringer Energieverbrauch: ideal für Batteriebetrieb (µA-Bereich)
• Perfekt für periodische Messungen
• Kein Erhalt des Programmzustands: Neustart nach jedem Aufwachen
• Initialisierungskosten: WLAN-Verbindung muss jedes Mal neu aufgebaut werden
• Längere Aufwachzeit im Vergleich zu Lightsleep

Die folgende Tabelle gibt die Größenordnung des Strombedarfs der CPU in den einzelnen Sleep-Modi wieder. 

 CPU aktiv (WiFi)  ~80–240 mA      
 Lightsleep           ~0,8–10 mA        
 Deepsleep           ~10–150 µA        

Daneben spielt natürlich auch die Peripherie (OLED, Sensoren, Aktoren) eine große Rolle. Beim Makey sind es vor allem der Audioverstärker und das OLED, welche erheblichen zusätzlichen Energiebedarf aufweisen. Im Tutorial zum Starkregenpegel wird eine effiziente Outdoorplatine entworfen und die Möglichkeiten einer solargestützten 24/7 Betriebsweise erläutert.

Ausgehend von einer typischen Datenlogger-Anwendung (ohne Anzeige) wollen wir den Energiebedarf weiter reduzieren. Wir starten wie beim Thingspeak-Tutorial mit einer zyklischen Temperaturmessung. Dazu verwenden wir den BME680-Umweltsensor bewußt nicht mit der BSEC - Unterstützung, sondern verwenden nur den einfachen Sensorwert. Die BSEC-Lib erwartet alle drei Sekunden ein Update der internen Zustände, so dass ein längerer Sleep hier nicht möglich wäre. Der Energiebedarf des Systems wird mit einem Power Profiler Kit II von Nordic ermittelt. Dieses USB-Gerät liefert verläßliche Messungen bis in den µA Bereich. Dabei sind vor allem Spitzenstrom ( = kritischer Innenwiderstand der Batterie) und mittlerer Strom( = Batteriekapazität) von Interesse.

Anwendung: Lightsleep

Im nächsten Schritt nutzen wir statt des normalen Delays eine Lightsleep Pause. Diese hält die CPU in unserem Fall einfach für 20 Sekunden an. Da dabei auch das WLAN den Kontakt zum Accesspoint verliert, muss die Verbindung anschließend wiederhergestellt werden. Als Resultat sehen wir einen mittleren Strom von ca. 25 mA. Damit würde eine Batterie praktisch fast dreimal so lange durchhalten. 

Anwendung: Deepsleep

Um den Ressourcenverbrauch noch weiter zu reduzieren, können wir den Deepsleep nutzen. Leider gehen dabei alle gespeicherten Informationen verloren, so dass wir praktisch wie nach einem Neustart aufwachen. In unserem Fall spielt das aber keine Rolle, denn wir bauen einfach eine erneute WLAN-Verbindung auf, messen und senden den Wert, bevor es wieder in den Tiefschlaf geht. So eine Strategie lohnt sich immer dann, wenn die Pausenzeiten deutlich länger sind, als der zusätzliche Aufwand beim aufwachen - und wenn die CPU eine der wesentlichen Verbraucher darstellt. In unserem Beispiel ist die Wartezeit eigentlich zu kurz und die restlichen Verbraucher (OLED, Audioverstärker) dominieren den Verbrauch auch im Tiefschlaf. Auch die rote Power-LED auf dem D1mini-Modul trägt einige mA zum Verbrauch bei (und kann bei Bedarf problemlos mit dem Fingernagel entfernt werden). 

Die folgenden Bilder zeigen das finale Ergebnis für unser ESP32-D1mini-Modul (ohne Makey:Lab Platine). Bei freier Verdrahtung ist ein Deepsleep-Strom (inclusive Bosch BME 280) von 330 µA zu erreichen. 

Die Wahl des geeigneten Verfahrens hängt stark vom Anwendungskontext ab:

• Im Lightsleep ist die CPU praktisch „eingefroren“, aber nicht abgeschaltet. Alle GPIO-Pins behalten ihr Potential, Timer laufen weiter. Dadurch liegt der Stromverbrauch im Milliampere-Bereich – deutlich niedriger als im aktiven Betrieb, aber um Größenordnungen höher als im Deepsleep.
• Der Deepsleep ist quasi die absolute Sparversion. Hier vergißt die CPU alle internen Zustände, auch die GPIO verlieren teilweise ihren Spannungspegel. Besondere RTC-GPIO schaffen dort ggf. Abhilfe. Dafür ist der Verbrauch im Bereich weniger µA natürlich unschlagbar und erlaubt lange Batterielaufzeiten. Die Variablen im Ardublock werden beim ESP 32 immer in das RTC-RAM gemapped und stehen uns damit auch nach Deepsleep noch zur Verfügung (außer Datenfelder).

Der tatsächliche Verbrauch stark ab von:

• WLAN aktiv oder deaktiviert
• Bluetooth aktiv
• angeschlossene Peripherie
• Taktfrequenz der CPU (s. alternative Boardkonfiguration “Makey on Battery” mit 10 MHz bzw. 80 MHz)
• Spannungsregler und Board-Design (DevKit vs. Bare Chip). Der Makey ist nicht auf Energieeffizienz getrimmt. Für den Batterieeinsatz gibt es alternative Designs wie z.B. den Starkregenpegel, der auch auf einem ESP32 D1mini basiert ("Makey on Battery").

Wir haben auch erste Untersuchungen gestartet, um am Beispiel des Starkregenpegels zu evaluieren, inwieweit Gen AI heute beim automatischen “green coding” unterstüzen kann.