ESP32 Deep Sleep Modus: So läuft dein Projekt jahrelang mit Akku

Der ESP32 Deep Sleep Modus ist der wichtigste Hebel, wenn Ihr IoT-Projekt nicht nur Tage oder Wochen, sondern tatsächlich Monate oder sogar Jahre mit Akku laufen soll. Im aktiven Betrieb ist der ESP32 ein leistungsfähiger Mikrocontroller mit WLAN und Bluetooth – und genau das kostet Strom. Selbst wenn Ihr Code „nichts tut“, bleiben Taktgeneratoren, Peripherie und Funkmodule oft teilweise aktiv. Deep Sleep ist der Gegenentwurf: Der ESP32 schaltet den Großteil des Chips ab und lässt nur die RTC-Domäne (Real-Time Clock) sowie ausgewählte Wake-up-Quellen aktiv. Dadurch sinkt der Stromverbrauch im Idealfall auf einen Bruchteil des Active-Mode-Stroms. Entscheidend ist allerdings das Wort „idealfall“: Viele Projekte scheitern an Details wie ungeeigneten Development-Boards, leuchtenden LEDs, schlechten Spannungsreglern oder Peripherie, die trotz Sleep weiter Strom zieht. In diesem Praxisguide lernen Sie, wie Sie Deep Sleep korrekt einsetzen, welche Wake-up-Optionen es gibt, wie Sie Daten und Zustände über Sleep-Zyklen hinweg speichern und wie Sie eine realistische Batterielaufzeit berechnen – inklusive typischer Stolperfallen, die aus einem „Jahre“-Ziel schnell ein „ein paar Wochen“-Ergebnis machen.

Deep Sleep auf dem ESP32: Was passiert technisch?

Im Deep Sleep werden die CPU-Kerne, die meisten RAM-Bereiche und große Teile der Peripherie abgeschaltet. Aktiv bleibt typischerweise die RTC-Domäne, die unter anderem Timer-Funktionen bereitstellt und Wake-up-Events auslösen kann. Das bedeutet: Ihr Programm wird nach dem Aufwachen nicht „fortgesetzt“, sondern startet in der Regel neu (vergleichbar mit einem Reset). Die Kunst besteht darin, den Code so zu strukturieren, dass er in kurzen Aktivphasen (Wake-Fenstern) die nötigen Aufgaben erledigt und danach wieder in den Schlaf geht.

• Aktivphase (Wake): Sensoren einschalten, messen, Daten senden/speichern, Status aktualisieren.
• Schlafphase (Deep Sleep): Minimalverbrauch, Warten auf Timer oder externes Ereignis.
• Neustart-Charakter: Nach dem Wake-up läuft Setup/Init erneut; Zustände müssen bewusst gesichert werden.

Eine solide technische Referenz zu Sleep-Modi und Power-Management finden Sie in der offiziellen Dokumentation: ESP-IDF: Sleep Modes.

Deep Sleep vs. Light Sleep: Wann welches Modell passt

Viele Projekte wählen Deep Sleep, weil maximale Akkulaufzeit das Ziel ist. Light Sleep kann aber sinnvoll sein, wenn Sie häufiger reagieren müssen oder bestimmte Peripherie schneller wieder verfügbar sein soll. Der grundlegende Trade-off ist: Je „tiefer“ der Sleep, desto niedriger der Strom, aber desto stärker fühlt sich das Aufwachen wie ein Neustart an und desto mehr müssen Sie neu initialisieren.

• Deep Sleep: maximaler Spareffekt, ideal für „messen → senden → schlafen“ (z. B. alle 5–30 Minuten).
• Light Sleep: schnelleres Aufwachen, weniger „Reset-Feeling“, aber höherer Stromverbrauch.
• Modem Sleep: Funkmodule schlafen zeitweise, geeignet für WLAN-Stationen, die verbunden bleiben.

Der wichtigste Praxispunkt: Nicht jedes ESP32-Board ist „Deep-Sleep-tauglich“

Wenn Sie wirklich jahrelang mit Akku arbeiten möchten, ist die Boardwahl oft entscheidender als die Firmware. Viele beliebte DevBoards wurden für Entwicklung gebaut – nicht für Minimalverbrauch. Typische Stromfresser auf DevBoards sind Power-LEDs, USB-UART-Chips, ungünstige LDO-Regler und Schutzbeschaltungen, die zwar praktisch sind, aber dauerhaft Milliampere ziehen können. Für „Jahre mit Akku“ brauchen Sie entweder ein Low-Power-Board oder ein eigenes, schlankes Design.

• Power-LED: klingt harmlos, kann aber dauerhaft mehrere mA ziehen.
• USB-UART-Bridge: bleibt oft aktiv und erhöht den Ruhestrom deutlich.
• Spannungsregler: manche LDOs haben hohen Eigenverbrauch (Quiescent Current).
• Peripherie am Board: Sensoren, Displays oder Pegelwandler können im Sleep weiterziehen.

Wake-up-Quellen: So wacht der ESP32 gezielt auf

Deep Sleep ist nur dann praktisch, wenn Ihr ESP32 zuverlässig wieder aufwacht – entweder zeitgesteuert oder ereignisbasiert. In den meisten IoT-Szenarien nutzen Sie einen RTC-Timer (z. B. alle 10 Minuten) oder ein externes Signal (z. B. Reedkontakt, Taster, Bewegungsmelder). Wichtig ist: Nicht jeder GPIO kann jede Wake-up-Funktion erfüllen. Prüfen Sie Pin-Kompatibilität und Board-Layout sorgfältig.

• Timer Wake-up: Wake nach X Sekunden/Minuten – der Standard für Sensor-Logger.
• EXT0 Wake-up: Wake über einen RTC-GPIO (typisch einzelner Pin, Level-basiert).
• EXT1 Wake-up: Wake über mehrere RTC-GPIOs (Maskenlogik, je nach Konfiguration).
• Touch Wake-up: Kapazitive Touch-Pads als Wake-Quelle (praktisch für berührungsbasierte Geräte).

Für Details zu EXT0/EXT1, RTC-GPIOs und Einschränkungen ist die offizielle Referenz sehr hilfreich: ESP-IDF: Wakeup Sources und Deep Sleep.

Wake-up-Design: Interrupt-Logik, Pullups und Entprellung

Ereignisbasiertes Aufwachen klingt einfach, wird aber in der Praxis durch Kontaktprellen und unstabile Pegel anspruchsvoll. Ein Taster kann den ESP32 mehrfach wecken, ein Sensor kann beim Einschalten kurz „flattern“, und ein offen gelassener Eingang kann durch Störungen zufällige Wake-ups erzeugen. Deshalb gehört zum Deep-Sleep-Design immer ein sauberes Eingangsdesign: klare Pullups/Pulldowns, stabile Pegel und eine Entprellstrategie.

• Pullup/Pulldown: Eingang nie „floaten“ lassen, sonst drohen Zufalls-Wake-ups.
• Entprellung: nach dem Wake kurz prüfen, ob das Signal stabil ist, bevor Aktionen ausgelöst werden.
• Wake-Ursache loggen: Diagnose, ob Timer oder Pin geweckt hat (wichtig für Fehlersuche).

Zustand über Deep Sleep hinweg: RTC Memory, NVS und externe Speicherung

Da der ESP32 nach dem Wake-up typischerweise wie nach einem Neustart startet, müssen Sie Zustände bewusst speichern: Zähler, Kalibrierwerte, Messhistorie, „letzter Sendestatus“, Backoff-Zeiten oder die Info, warum das Gerät aufgewacht ist. Dafür gibt es mehrere Ebenen, die sich in Geschwindigkeit, Energiebedarf und Lebensdauer unterscheiden.

• RTC Memory: schnell und energiesparend für kleine, volatile Daten (bleibt über Deep Sleep erhalten, nicht über Power-Off).
• NVS (Flash): persistent über Neustarts/Power-Off, aber Flash hat begrenzte Schreibzyklen; sparsam verwenden.
• Externer Speicher: FRAM/EEPROM oder SD-Karte, wenn viele Daten oder häufiges Schreiben nötig ist.
• Cloud/Server: Daten nach jeder Aktivphase hochladen, wenn Netzwerk zuverlässig verfügbar ist.

Wenn Sie auf Flash schreiben, planen Sie Schreibintervalle und Wear-Leveling ein. Für produktnahe Projekte ist die NVS-Dokumentation der ESP-IDF-Umgebung eine gute Quelle: ESP-IDF: NVS Flash.

Sensorik richtig schlafen lassen: Power-Gating und Messfenster

Der ESP32 allein im Deep Sleep bringt wenig, wenn Sensoren oder Aktoren weiter Strom ziehen. Viele Sensorboards haben eigene LDOs oder Pullups, die im Ruhestand weiter Energie verbrauchen. Für echte Akkulaufzeiten empfiehlt sich ein „Power-Gating“-Ansatz: Sensoren werden nur während der Aktivphase mit Spannung versorgt – über einen MOSFET, einen Load Switch oder einen dedizierten Power-Enable-Pin (falls der Sensor das unterstützt).

• Sensor-VCC schalten: Sensor nur zum Messen einschalten, danach komplett abschalten.
• Warm-up beachten: einige Sensoren brauchen Stabilisierung (z. B. 50–200 ms oder mehr).
• I2C/SPI-Leitungen: Pullups können ebenfalls Strom ziehen; prüfen, ob sie im Sleep nötig sind.
• Leckströme: Pegelwandler, ESD-Schutz und Analogpfade können unerwartet lecken.

WLAN ist der größte Energiefaktor: Strategien für kurze Online-Zeit

In vielen IoT-Sensorprojekten kostet das WLAN-Verbinden und Senden den Hauptteil der Energie. Das Ziel ist daher nicht, „perfekt zu sparen“ während der Schlafphase – sondern die Aktivphase radikal zu verkürzen. Dazu gehört: schneller WLAN-Reconnect, kleine Payloads, effiziente Protokolle und eine klare Retry-Logik, die nicht in Endlosschleifen läuft.

• Kurze Session: verbinden, senden, trennen – keine langen Online-Fenster.
• Payload minimieren: wenige Bytes, kompakte Formate, keine unnötigen JSON-Blöcke, wenn Bandbreite/Energie kritisch ist.
• Retries mit Backoff: bei Ausfall später erneut versuchen, statt Akku in einem Funkloch zu „verheizen“.
• DNS/HTTPS-Overhead: HTTPS ist sicher, aber teurer; wenn nötig, CA-Zertifikate sauber einsetzen und Verbindungen nicht unnötig oft neu aufbauen.

Für HTTPS und TLS-Hintergrund ist die Espressif-TLS-Dokumentation im ESP-IDF-Kontext hilfreich: ESP-IDF: mbedTLS.

Jahrelange Laufzeit berechnen: Realistische Batteriemodelle statt Wunschdenken

Um „jahrelang mit Akku“ seriös zu planen, brauchen Sie eine Laufzeitrechnung, die Aktiv- und Schlafanteile berücksichtigt. Entscheidend ist der mittlere Stromverbrauch, der sich aus einem zeitgewichteten Mittelwert ergibt. Dabei ist die Aktivphase oft kurz, aber stromintensiv; die Schlafphase ist lang, aber stromarm.

Durchschnittsstrom aus Duty Cycle berechnen (MathML)

Wenn Ihr ESP32 pro Zyklus t_active Sekunden aktiv ist mit einem Strom I_active und t_sleep Sekunden schläft mit I_sleep, ergibt sich der mittlere Strom I_avg als:

$\mathrm{I\_avg}=\frac{\mathrm{I\_active}·\mathrm{t\_active}+\mathrm{I\_sleep}·\mathrm{t\_sleep}}{\mathrm{t\_active}+\mathrm{t\_sleep}}$

Beispiel: 2 Sekunden aktiv mit 120 mA (WLAN + Messung), 598 Sekunden Schlaf mit 0,02 mA. Dann liegt der Durchschnitt deutlich näher am Schlafstrom als am Aktivstrom, aber die Aktivphase bleibt der „Kostenblock“.

Laufzeit aus Kapazität ableiten (MathML)

Wenn Ihre Batterie eine Kapazität C in mAh hat und der mittlere Strom I_avg in mA ist, ergibt sich die Laufzeit T in Stunden näherungsweise als:

$T\approx \frac{C}{\mathrm{I\_avg}}$

Für Tage teilen Sie durch 24, für Jahre durch 24·365. In der Praxis sollten Sie zusätzlich Faktoren einplanen: Selbstentladung, Temperatur, Spannungslage, nutzbare Kapazität bei hoher Last und Alterung.

Batterietypen: Li-Ion, LiPo, AA, Lithium-Primär und Supercaps

Die beste Deep-Sleep-Firmware bringt wenig, wenn die Batterie nicht zum Einsatz passt. Für jahrelange Laufzeiten sind Lithium-Primärzellen (z. B. Li-SOCl₂) in professionellen Sensoren beliebt, während LiPo/Li-Ion praktisch für wiederaufladbare Projekte ist. AA-Zellen (Alkaline oder NiMH) können ebenfalls funktionieren, erfordern aber eine saubere Spannungsregler- und Entladekurve-Planung.

• LiPo/Li-Ion: wiederaufladbar, gute Energiedichte, aber Selbstentladung und Schutzbeschaltungen beachten.
• AA Alkaline: günstig und überall, aber Spannungsabfall und Kälteempfindlichkeit berücksichtigen.
• AA NiMH: wiederaufladbar, robust, aber niedrigere Spannung pro Zelle und Selbstentladung je nach Typ.
• Lithium-Primär: sehr niedrige Selbstentladung, gut für Jahre, aber nicht wiederaufladbar und teurer.

Spannungsregler und Ruhestrom: Der „unsichtbare“ Akku-Killer

Ein häufiger Grund, warum Deep Sleep in der Realität nicht die erwartete Laufzeit bringt, ist der Eigenverbrauch des Spannungsreglers. Viele Regler haben einen Ruhestrom (Quiescent Current), der selbst dann fließt, wenn der ESP32 schläft. Wenn dieser Ruhestrom im Milliamperebereich liegt, ist die Deep-Sleep-Optimierung praktisch wirkungslos. Für Akku-Projekte sollten Sie gezielt Low-Iq-Regler einsetzen oder direkt aus einer passenden Zellspannung versorgen (wenn das Design es zulässt).

• Low-Iq-Regler wählen: Ruhestrom im Mikroamperebereich statt Milliampere.
• Dropout beachten: LDOs brauchen Headroom; bei fallender Batteriespannung kann das kritisch werden.
• Schaltregler vs. LDO: Schaltregler sind effizient bei Last, aber nicht immer im Idle; LDOs sind simpel, aber können ineffizient sein.

Messung statt Vermutung: Ruhestrom korrekt messen

Wenn Sie Akkulaufzeit ernsthaft optimieren wollen, müssen Sie messen. Viele Irrtümer entstehen, weil Strommessungen falsch durchgeführt werden: Multimeter im falschen Bereich, zu hoher Innenwiderstand, Messung nur im Active-Mode oder Messaufbau, der die Sleep-Phase verfälscht. Für zuverlässige Ergebnisse messen Sie sowohl Peak-Strom (WLAN-Sendeimpulse) als auch Ruhestrom im Deep Sleep über mehrere Zyklen.

• Ruhestrom messen: Gerät schlafen lassen, mehrere Sekunden stabil messen.
• Peak messen: WLAN-Phasen erzeugen Peaks; ein Logging-Messgerät ist hilfreich.
• Zyklusprofil erstellen: Aktivdauer und Schlafdauer bestimmen, um I_avg korrekt zu berechnen.
• Board-Varianten vergleichen: DevBoard vs. Low-Power-Board kann Größenordnungen Unterschied bedeuten.

Programmlogik für Deep Sleep: „Wake → Work → Sleep“ als Architektur

Ein Deep-Sleep-Projekt wird am stabilsten, wenn Sie Ihren Code wie eine Zustandsmaschine entwerfen. Beim Boot prüfen Sie den Wake-Grund, initialisieren nur das Nötigste, erledigen Aufgaben in klarer Reihenfolge und gehen deterministisch wieder schlafen. Vermeiden Sie Endlosschleifen, die „nur zur Sicherheit“ auf WLAN warten – das kostet Akku. Stattdessen sollten Zeitbudgets und Fallbacks existieren.

• Zeitbudget: maximal X Sekunden aktiv, dann Sleep – auch bei Netzwerkfehlern.
• Persistente Zähler: Fehlversuche zählen und Intervalle dynamisch erhöhen.
• Selective Init: Nicht jede Peripherie bei jedem Wake initialisieren, wenn sie nicht gebraucht wird.
• Safeguards: Watchdog und klare Fehlerpfade, um Hänger zu vermeiden.

ULP-Co-Prozessor: Spezialwerkzeug für extreme Sparszenarien

Für fortgeschrittene Projekte bietet der ESP32 einen Ultra-Low-Power (ULP) Co-Prozessor, der einfache Aufgaben übernehmen kann, während die Haupt-CPU schläft. Damit lassen sich beispielsweise analoge Messungen oder einfache Schwellenwertprüfungen durchführen, ohne die Haupt-CPU zu wecken. Das ist kein Muss für jedes Projekt, kann aber bei „Jahre“-Zielen den Unterschied machen, wenn Wake-ups stark reduziert werden sollen.

• Vorteil: Weniger Wake-ups, geringere Energie pro Zeiteinheit.
• Nachteil: Komplexere Entwicklung, nicht jede Logik ist ULP-geeignet.
• Typischer Einsatz: Schwellenwert-Überwachung (z. B. Bodenfeuchte, Vibrationsalarm) mit seltenen Haupt-Wake-ups.

Typische Fehler, die jahrelange Akkulaufzeit verhindern

• DevBoard im Einsatz: USB-UART + LEDs + Regler ziehen zu viel Ruhestrom.
• Sensoren bleiben aktiv: Sensorboard oder Pullups ziehen im Sleep weiter.
• WLAN-Loop ohne Timeout: Gerät bleibt bei schlechtem Empfang minutenlang aktiv.
• Zu häufiges Senden: Alle 10 Sekunden „zur Sicherheit“ senden ist fast immer ein Akkukiller.
• Flash zu oft beschreiben: Häufige NVS-Schreibvorgänge belasten Flash und kosten Energie.
• Falsche Messung: Ruhestrom falsch gemessen, Optimierungen basieren auf falschen Annahmen.

Outbound-Links zu relevanten Informationsquellen

• ESP-IDF: Sleep Modes und Wakeup-Quellen (Deep Sleep, EXT0/EXT1)
• ESP-IDF: NVS Flash (persistente Speicherung, Wear-Leveling)
• ESP-IDF: mbedTLS (HTTPS/TLS – relevant für energieintensive Online-Phasen)
• Arduino-ESP32 Dokumentation (Sleep-Funktionen, Netzwerk-APIs, Praxisbeispiele)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.