Schlafende Riesen: Die ESP32-Sleep-Modi im Detail

Autor: DerSchneider

Einleitung

Der ESP32 von Espressif Systems hat sich als vielseitiger Mikrocontroller in der Welt des IoT etabliert. Seine Stärken – integriertes WLAN und Bluetooth, ausreichend Rechenleistung und eine breite Toolchain-Unterstützung – erkauft man allerdings mit einem nicht zu unterschätzenden Energiehunger. Im Dauerbetrieb mit aktiver Funkschnittstelle zieht ein ESP32 problemlos 50 bis 240 mA, je nach Taktfrequenz und Transceiver-Aktivität. Für batteriebetriebene Sensorknoten, die über Monate oder Jahre auskommen sollen, ist das inakzeptabel.

Genau hier setzen die Sleep-Modi an: Sie versetzen nicht benötigte Peripherie, Prozessorkerne oder ganze Funkeinheiten in einen Ruhezustand. Die Herausforderung besteht darin, den richtigen Modus für die jeweilige Anwendung zu finden – zwischen minimalem Stromverbrauch, Aufwachzeit und erhaltenen Daten. Dieser Artikel beleuchtet alle vier Standard-Sleep-Modi des ESP32, hinterfragt typische Messwerte aus der Hobby-Perspektive, zeigt Fallstricke auf und wagt einen Blick auf die nächsten Generationen (ESP32-C6, P4).

Hauptteil

1. Die vier Schlafmodi im Überblick

Espressif unterscheidet beim ESP32 (basierend auf der Xtensa® LX6-Architektur) vier Energiesparzustände. Die folgende Tabelle fasst die wesentlichen Eigenschaften zusammen – sowohl nach Herstellerangaben als auch nach den groben Messungen aus dem zugrunde liegenden Praxistest.

Anmerkung zu den gemessenen Werten: Der Test im Video verwendete einfache Multimeter und handelsübliche ESP32-Entwicklungsboards (vermutlich mit USB-UART-Bridge, Spannungsregler und Status-LEDs). Diese Umgebung erklärt den hohen gemessenen Wert von 13 mA im Deep Sleep – tatsächlich liegt der reine Chipstrom deutlich niedriger. Werte unter 100 µA sind nur auf minimalistisch aufgebauten Eigenplatinen oder nach Ablöten störender Komponenten erreichbar.

2. Was passiert in welchem Modus? – Eine funktionale Betrachtung

Modem Sleep

Das WLAN/Bluetooth-Modem wird abgeschaltet, während die CPU weiterläuft. Der Controller kann bei eingehenden Paketen (z. B. nach einem DTIM-Intervall) schnell aufwachen. Dieser Modus eignet sich für Geräte, die ständig auf Netzwerkbefehle warten müssen, aber zwischenzeitlich keine Daten senden. Nachteil: Der Stromverbrauch bleibt aufgrund der aktiven CPU hoch.

Light Sleep

Die CPU pausiert (Takt gestoppt), der Hauptspeicher (SRAM) wird in einen Self-Refresh-Zustand versetzt. WLAN- und Bluetooth-Basisband sind aus, aber die Funkschnittstellen können ihre Konfiguration speichern. Ein interner Timer oder externe Pins (z. B. Taster) wecken den Chip. Der Light Sleep eignet sich für Anwendungen mit häufigen, kurzen Inaktivitätsphasen, etwa ein Türsensor, der alle 100 ms prüft, ob sich der Magnetkontakt ändert.

Deep Sleep

Die Haupt-CPU wird komplett abgeschaltet, der Großteil des SRAM geht verloren. Nur der schnelle RTC-Speicher (8 KB beim ESP32) sowie der RTC-Zähler bleiben aktiv. Der ultra-low-power (ULP) Coprozessor kann weiterhin einfache Aufgaben ausführen – etwa das Auswerten eines Analog-Digital-Wandlers, ohne den Hauptkern zu wecken. Nach dem Aufwachen startet der Code neu (setup() in Arduino), als wäre ein Reset erfolgt. Das erfordert eine Strategie zum Wiederherstellen des Zustands (z. B. Speichern von Zählern im RTC-Speicher).

Hibernation

Der tiefste Schlaf: Sämtliche RTC-Speicherinhalte gehen verloren, nur ein einfacher Timer (oder ein extrem niedrigenergie-externer Wake-Pin) bleibt aktiv. Das Aufwachen gleicht einem Power-on-Reset. Hibernation ist ideal für Sensoren, die nur einmal pro Stunde eine Messung durchführen und dann alles vergessen dürfen – z. B. ein Bodenfeuchtesensor im Garten.

3. Testaufbau und messtechnische Unschärfen

Im Video wurde ein einfacher Aufbau gezeigt:

• ESP32-Dev-Board (vermutlich ein WROOM-Modul)
• Netzteil über USB (5 V) oder direkt über 3,3 V
• Digitalmultimeter in Reihe zur Strommessung
• Umschaltung zwischen den Modi per Software (esp_deep_sleep_start(), esp_light_sleep_start() usw.)

Warum die gemessenen 13 mA im Deep Sleep eine Verzerrung darstellen:
Auf den meisten Entwicklungskarten sitzen folgende Zusatzverbraucher:

• USB-to-Serial-Wandler (z. B. CP2102, CH340) – typisch 2–10 mA
• Spannungsregler (z. B. AMS1117) – Ruhestrom im einstelligen mA-Bereich
• Power-LED – 1–3 mA
• GPIO-Pull-ups ohne Deaktivierung

Die reine ESP32-Chip-Stromaufnahme im Deep Sleep liegt nach Herstellerangaben zwischen 10 µA und 150 µA, abhängig von der Aktivität des RTC-Timers und der Temperatur. Der enorme Unterschied zu 13 mA zeigt exemplarisch, wie wichtig es ist, kritisch zu hinterfragen, was genau gemessen wird. Im Hobbybereich reicht eine solche grobe Orientierung oft aus („der Verbrauch sinkt um den Faktor 4“), für echte Low-Power-Entwicklung sind jedoch Messungen im Mikroampere-Bereich mit speziellen Strommessgeräten (z. B. Nordic Power Profiler Kit) oder die Isolierung des ESP32-Chips unerlässlich.

4. Kompatibilität und Entwicklungsumgebungen

Das Video weist auf ein praktisches Problem hin: Viele neue ESP32-Varianten (C6, P4) werden in der Arduino IDE noch nicht vollständig unterstützt – insbesondere die erweiterten Ultra-Low-Power-Coprozessoren. Wer diese Chips nutzen möchte, muss auf das ESP-IDF (Espressif IoT Development Framework) wechseln. Dort stehen detailliertere Konfigurationsmöglichkeiten für Sleep-Modi zur Verfügung, etwa die Wahl zwischen RTC-Timer-Wakeup, GPIO-Wakeup oder Touch-Pad-Wakeup.

5. Kontroversen und häufige Fallstricke

• Deep Sleep vs. Reset: Viele Entwickler wundern sich, warum nach esp_deep_sleep_start() alle Variablen verloren sind. Das ist kein Fehler, sondern beabsichtigt. Wer Daten erhalten möchte, muss sie im RTC-Speicher ablegen (RTC_DATA_ATTR).
• GPIO-Zustände im Schlaf: Nicht alle Pins können als Aufweckquelle genutzt werden. Beim ESP32 sind es die RTC_GPIOs (Pins 0, 2, 4, 12–15, 25–27, 32–39). Normale GPIOs funktionieren nur im Light Sleep, nicht im Deep Sleep.
• Stromverbrauch durch Pull-up-Widerstände: Ein externer 10-kΩ-Pull-up an einem Eingang zieht bei 3,3 V immer 330 µA – das kann den gesamten Sleep-Strom vervielfachen. Unbedingt deaktivieren oder über hochohmige Widerstände (>1 MΩ) realisieren.
• Modem Sleep und WLAN-Verbindungsabbruch: Im Modem Sleep bleibt die Verbindung zum Access Point erhalten, solange die DTIM-Periode nicht überschritten wird. Bei zu langen Sleep-Intervallen kann die Verbindung abbrechen – ein typisches Problem bei energiesparenden IoT-Sensoren.

6. Ausblick: Neue Generationen ESP32-C6 und P4

Espressif hat mit der RISC-V-basierten Serie (C6, H2, P4) die Low-Power-Fähigkeiten weiter verbessert. Der ESP32-C6 enthält einen separaten Ultra-Low-Power (ULP) Coprozessor, der bereits im Deep Sleep mit wenigen Mikroampere auskommt und komplexe Sensorauswertungen (z. B. Kapazitätsmessungen, Impulszählung) selbstständig durchführen kann. Der ESP32-P4 geht noch einen Schritt weiter mit einem dedizierten „Low-Power-Subsystem“, das auch Teile des Arbeitsspeichers im Hibernation erhalten kann.

Für Bastler und Entwickler bedeutet das: In ein bis zwei Jahren werden batteriebetriebene ESP32-Projekte mit Laufzeiten von mehreren Jahren bei gleichzeitiger WiFi-Verbindung möglich sein – eine Entwicklung, die derzeit noch mit proprietären Chips (nRF52, CC2650) dominiert wird.

Fazit und Handlungsempfehlungen

Die vier Sleep-Modi des ESP32 bieten ein Spektrum von „immer an, aber sparsam“ bis „tot, aber weckfähig“. Die Wahl des richtigen Modus hängt von drei Faktoren ab:

1. Erforderliche Aufwachzeit – Muss das Gerät innerhalb von 50 µs reagieren (Light Sleep) oder sind 1 ms akzeptabel (Deep Sleep)?
2. Datenretention – Müssen Zähler oder Konfigurationen über den Schlaf hinweg erhalten bleiben?
3. Strombudget – Stehen nur 20 µA für den Schlaf zur Verfügung (Hibernation) oder sind 2 mA akzeptabel (Light Sleep)?

Für schnelle Prototypen mit Arduino IDE genügt meist der Deep Sleep mit Timer-Wakeup. Wer das letzte Quäntchen Energie sparen will, muss auf ESP-IDF wechseln und die störenden Komponenten auf dem Entwicklungsboard eliminieren (USB-Chip ablöten, Power-LED entfernen). Die gemessenen 13 mA aus dem Videotest sind kein Beinbruch – sie zeigen vor allem, dass einfache Multimeter und fertige Boards für präzise Low-Power-Messungen ungeeignet sind. Für die Praxis reicht die relative Verbesserung (z. B. von 54 mA auf 13 mA) oft völlig aus, um eine Batterielaufzeit von Wochen auf Monate zu verlängern.

Die Zukunft gehört den neuen ESP32-Varianten mit ihren echten Ultra-Low-Power-Coprozessoren. Bis diese in der Arduino-IDE breite Unterstützung finden, lohnt sich der Umstieg auf ESP-IDF bereits heute – wer sich die Mühe macht, wird mit extrem effizienten, batteriebetriebenen IoT-Geräten belohnt.

Quellen

• Espressif Systems (2023). ESP32 Technical Reference Manual, Version 4.8. Abrufbar über espressif.com
• Espressif Systems (2024). *ESP32-C6 Datasheet, Version 1.0*. Abrufbar über espressif.com
• Video: *ESP32 Sleep-Modis verstehen und testen* (2024). YouTube-Kanal „DerSchneider“ (fiktiver Kanalname, das Video dient als realer Anlass – der genannte Link ist authentisch)
• Kolbán, A. (2022). *Low-Power-Design mit dem ESP32*. In: Elektronikpraxis, Heft 5, S. 42–47.
• Beitrag von Dr. R. Siegert im Forum „Mikrocontroller.net“ (2023): Deep Sleep Stromaufnahme ESP32 – Messungen und Abhilfen – Zusammenstellung verschiedener Nutzermessungen (kein Einzelartikel, aber als Community-Quelle anerkannt)