/esp32-stromsparend-betreiben-monate-laufzeit-mit-batterie-deep-sleep-wake-trigger-und-messwerte

ESP32 stromsparend betreiben: Monate Laufzeit mit Batterie – Deep Sleep, Wake-Trigger und Messwerte

Monatelange Batterielaufzeit mit einem ESP32 ist absolut machbar – aber nur, wenn du konsequent auf Durchschnittsstrom optimierst und nicht auf „Peak-Strom“. Der ESP32 kann im Funkbetrieb kurzzeitig zig bis hunderte Milliampere ziehen, aber wenn diese Peaks selten und kurz sind und du die meiste Zeit wirklich im Deep Sleep verbringst, landet der Mittelwert im zweistelligen Mikroamperebereich. Genau da entscheidet sich, ob dein Projekt Wochen, Monate oder nur Tage durchhält.

Der Knackpunkt: Viele messen „Deep Sleep“ auf einem DevKit und sehen plötzlich 0,2–2 mA. Das ist kein Beweis gegen Deep Sleep, sondern fast immer ein Hinweis auf Board-Peripherie (USB-UART, LDO, Power-LED, Pullups, Sensoren), falsche Pinzustände oder einen Messfehler. Auf dem nackten Modul sind einstellige µA realistisch – Espressif zeigt für ein ESP32-S3-WROOM-1 im Deep Sleep z. B. 8,14 µA in einer Messung mit Joulescope.

1) Der wichtigste Hebel: Durchschnittsstrom statt Momentanstrom

Batterielaufzeit ist grob:

Laufzeit (h) = Kapazität (mAh) / Durchschnittsstrom (mA)

Der Durchschnittsstrom ergibt sich aus Schlaf- und Aktivphasen:

I_avg = (I_aktiv · t_aktiv + I_sleep · t_sleep) / (t_aktiv + t_sleep)

Damit kannst du sehr schnell sehen, warum „ein paar hundert µA zu viel“ dir Monate kaputtmachen:

Gutes Setup: 10 µA Sleep, alle 10 Minuten 0,2 s aktiv mit 80 mA
→ I_avg ≈ 36–37 µA → theoretisch sehr lange Laufzeit (praktisch begrenzt durch Selbstentladung, Temperatur, Funkqualität, Batteriechemie).
DevKit-Realität: 500 µA Sleep (nur wegen Board/Regler), alle 10 Minuten 1 s aktiv mit 80 mA
→ I_avg ≈ 0,63 mA → aus 2400 mAh werden grob ~5 Monate (und das ohne Sicherheitsreserve).

Das ist der Kern: Deep Sleep bringt dir nur dann „Monate“, wenn du Sleep wirklich in den µA-Bereich drückst und die Aktivzeit kurz hältst.

2) Schlafmodi kurz einordnen: was bringt wirklich Monate?

Für „Monate mit Batterie“ ist Deep Sleep das Standardwerkzeug. Light Sleep kann helfen, wenn du schneller reagieren musst oder RAM/Peripherie weiterlaufen sollen – kostet aber Größenordnungen mehr.

Ein paar belastbare Richtwerte aus Datenblättern:

ESP32 (klassisch): Deep-sleep mit RTC-Timer + RTC-Memory ~10 µA, Hibernation (RTC-Timer only) ~2,5 µA; wenn der ULP-Coprocessor aktiv ist, steht dort ~0,15 mA.
ESP32-S3: Light-sleep typisch 240 µA; Deep-sleep typisch 7–8 µA (je nachdem, ob RTC-Peripherie an ist); „Power off“ typisch ~1 µA.

Wichtig: Diese Werte gelten für den Chip/Modul unter definierten Bedingungen – nicht automatisch für dein komplettes Board.

3) Deep Sleep in der Praxis: du wachst nicht auf – du bootest neu

Deep Sleep ist kein „Pause drücken“. Der ESP32 fährt die CPUs runter; beim Aufwachen ist es in vielen Setups wie ein Reset: dein Programm startet wieder bei setup()/app_main().

Das heißt:

Du brauchst eine saubere Boot-Logik („bin ich frisch gestartet oder aus Deep Sleep?“).
Zustände speicherst du entweder in RTC-Memory (überlebt Deep Sleep) oder in Flash (NVS/EEPROM), je nachdem wie oft du schreibst.

In ESP-IDF kannst du Variablen in RTC-Memory legen (z. B. mit RTC_DATA_ATTR). Die ESP-IDF Doku beschreibt auch, dass Deep-Sleep-Variablen in RTC-Speicher passen und wie Speicherbereiche zugeordnet sind.

Minimaler Ablauf (ESP-IDF, stark vereinfacht):

#include "esp_sleep.h"
#include "esp_log.h"

RTC_DATA_ATTR int boot_count = 0;

void app_main(void) {
    boot_count++;
    esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();

    // ... Sensor lesen, Daten senden, etc.

    // Timer-Wakeup in 10 Minuten:
    esp_sleep_enable_timer_wakeup(10ULL * 60ULL * 1000000ULL);
    esp_deep_sleep_start();
}

Arduino sieht ähnlich aus:

#include "esp_sleep.h"

RTC_DATA_ATTR int bootCount = 0;

void setup() {
  bootCount++;
  // ... Arbeit erledigen
  esp_sleep_enable_timer_wakeup(10ULL * 60ULL * 1000000ULL);
  esp_deep_sleep_start();
}

void loop() {}

4) Wake-Trigger: Timer, EXT0, EXT1, Touch, ULP – und die typischen Fallen

Der ESP32 hat mehrere Wake-Quellen, die du auch kombinieren kannst. In der Praxis sind für Batteriegeräte die häufigsten:

Timer-Wakeup

Der Klassiker: alle X Minuten kurz aufwachen, messen, senden, schlafen.

In ESP-IDF ist das esp_sleep_enable_timer_wakeup(time_in_us).

Achte darauf, dass der RTC-Slow-Clock nicht ultragenau ist – für „ungefähr alle 10 Minuten“ passt es, für eine Uhr eher nicht.

EXT0 (ein Pin, Level, RTC-IO)

EXT0 ist super, wenn du genau einen Wake-Pin hast (z. B. Taster, Reed-Kontakt). Er nutzt RTC_IO und braucht RTC-IO-fähige Pins. ESP-IDF listet für ESP32 z. B. GPIO 0, 2, 4, 12–15, 25–27, 32–39.

Wichtige Einschränkung: Auf ESP32 ist EXT0 nicht zusammen mit Touch oder ULP als Wake-Quelle nutzbar (Konflikte).

EXT1 (mehrere Pins, RTC-Controller)

EXT1 ist oft die bessere Wahl, wenn du mehrere Wake-Pins brauchst. Vorteil: EXT1 funktioniert auch dann, wenn du RTC-Peripherie im Sleep abschaltest; Nachteil: interne Pullups/Pulldowns funktionieren dann nicht mehr zuverlässig – du brauchst externe Widerstände oder musst RTC-Peripherie bewusst anlassen. Genau das beschreibt Espressif in der ESP-IDF Doku zu EXT1 inklusive Hinweis auf HOLD-Mechanismus.

Touch-Wakeup

Praktisch für Touch-Buttons, aber kann je nach Konfiguration Zusatzstrom bedeuten und kollidiert auf ESP32 mit EXT0.
Wenn du maximale Laufzeit willst, ist Touch oft eine Strombudget-Diskussion.

ULP-Coprocessor

Der ULP kann im Schlaf Messungen machen und nur bei Bedarf wecken (z. B. „weck mich, wenn ADC-Schwellwert überschritten“). Das ist mächtig, aber nicht „kostenlos“: beim klassischen ESP32 wird im Datenblatt für „ULP powered on“ deutlich mehr als 10 µA angegeben (Größenordnung 0,15 mA).
Beim S3 ist ULP moderner, aber: plane trotzdem sauber mit Messwerten statt Hoffnung.

5) Warum DevBoards oft keine Monate schaffen – und wie du es richtig machst

Wenn du „Monate“ willst, ist die Hardware mindestens so wichtig wie esp_deep_sleep_start().

Die drei üblichen Stromfresser

Spannungsregler (IQ / Quiescent Current)
Viele DevBoards haben LDOs mit dutzenden bis hunderten µA Ruhestrom. Das frisst deine µA-Ziele sofort auf. Für Batteriebetrieb suchst du LDOs/Schaltregler, deren Ruhestrom im einstelligen µA-Bereich liegt (je nach Lastprofil).
USB-UART und Power-LED
CP2102/CH340/FTDI und eine ständig leuchtende LED sind im Labor nett, für Batteriegeräte Gift. Auf manchen Boards kommst du nur durch „abtrennen“ oder eigenes Board wirklich runter.
Sensoren und Spannungsteiler, die immer anliegen
Ein Spannungsteiler für Batterie-Messung mit 2×100 kΩ zieht bereits ~16 µA bei 3,3 V – das kann mehr sein als der ganze ESP32 im Deep Sleep. Lösung: größere Widerstände (mit Blick auf ADC-Eingang), Messung nur kurz aktivieren (MOSFET), oder ein Fuel-Gauge/ADC mit Enable.

Pinzustände: floating kills

Pins, die im Sleep floaten, können Leckströme erzeugen oder externe Bauteile halb einschalten. Besonders kritisch sind Eingänge an Sensoren/Transistoren und „strapping pins“. In Deep Sleep solltest du:

Ausgänge auf definiertem Level lassen oder „Hold“ nutzen,
externe Pullups/Pulldowns sauber auslegen,
bei EXT1 beachten, dass interne Pulls bei abgeschalteter RTC-Peripherie nicht wirken (extern lösen oder RTC-Periph anlassen).

6) Reale Messwerte: was du erwarten kannst (und warum du oft daneben liegst)

Chip/Modul: µA sind real

Für ESP32-S3 zeigt das Datenblatt Deep-sleep typisch 7–8 µA (je nach RTC-Peripherie).
Espressif hat das auch praktisch gemessen: Beim ESP32-S3-WROOM-1 nennt die Messanleitung 8,14 µA Deep-sleep und ~23,88 mA im Active-Teil (gemessen als Waveform, Beispielprojekt, Touch-Wakeup deaktiviert).

Für den klassischen ESP32 taucht im Datenblatt u. a. 10 µA (RTC timer + RTC memory) als Größenordnung auf.

DevBoards: 100 µA bis >1 mA sind leider normal

Dass Leute im Deep Sleep statt 10 µA plötzlich 100 µA sehen, ist ein bekanntes Muster (oft Board-Design/Regler/Leckpfade).
Und wenn du ein Board hast, das im Deep Sleep Richtung ~1 mA läuft, ist das fast immer „nicht der ESP32“, sondern Peripherie, Pins oder Versorgungspfad.
Die Konsequenz ist simpel: Wenn du Monate willst, plane entweder mit einem Board, das explizit auf Low-Power gebaut ist, oder mach ein eigenes kleines Board/Breakout, bei dem du den Versorgungspfad kontrollierst.

7) Messen wie ein Profi: sonst optimierst du im Blindflug

Deep-Sleep-Ströme im einstelligen µA-Bereich sind fies zu messen, weil viele Multimeter im µA-Bereich eine merkliche Burden Voltage erzeugen. Das kann dein Systemverhalten verändern (Brownout, andere Reglerzustände, falsche Peaks).

So gehst du sauber vor:

Miss in Serie am Batteriepfad, aber mit einem Tool, das für dynamische Ströme taugt (Joulescope/Otii/Nordic PPK2 oder ein sauberer Shunt + Oszi). Espressif nutzt in der Anleitung z. B. Joulescope und zeigt die Waveform.
Achte auf Peak + Sleep: Ein Messwert „0,01 mA“ sagt nichts, wenn dein Gerät jede Minute 2 Sekunden WLAN macht.
Miss im finalen Zustand: Sensoren angeschlossen, Pullups drin, Gehäuse/Temperatur so ähnlich wie später.

Ein sehr praktischer Workflow: erst Sleep stabilisieren (µA), dann Aktivphase kürzen (ms), dann Funk optimieren (Retries reduzieren, RSSI verbessern).

8) Beispiel-Budget: so rechnest du dir „Monate“ hart durch

Nehmen wir einen typischen Batterielogger:

Alle 10 Minuten aufwachen
200 ms aktiv „alles erledigt“ (Sensor lesen + paketweise senden)
Deep Sleep

Fall A (sauber):
Sleep 10 µA, Aktiv 80 mA · 0,2 s / 600 s
→ Durchschnitt grob ~36–37 µA
Das ist die Welt, in der Monate leicht werden.

Fall B (DevKit):
Sleep 500 µA, Aktiv 80 mA · 1 s / 600 s
→ Durchschnitt grob ~0,63 mA
Mit 2400 mAh landest du in der Größenordnung ~5 Monate.

Und jetzt der Punkt, den viele übersehen: Wenn du statt 500 µA Sleep nur 50 µA erreichst, gewinnst du oft mehr als durch „noch 50 ms WLAN sparen“.

9)Ereignisgetriebene Sensorik und kurz getaktete Funkfenster für maximale Laufzeit

Beim Zusammenspiel aus Sensorik, WLAN und Bluetooth gewinnst du am meisten, wenn du alles konsequent ereignis- und paketorientiert betreibst: Sensoren bleiben aus oder in ihrem eigenen Low-Power-Modus, bis du wirklich messen musst, und du schaltest sie wenn möglich über einen Load-Switch (P-MOSFET/Power-IC) komplett stromlos, statt sie „nur per I²C schlafen zu schicken“. Achte dabei auf versteckte Dauerlasten wie Pullups am I²C-Bus, Spannungsteiler oder INT-Pins, die im Sleep floaten und Leckströme provozieren; definierte Pegel und saubere Pull-Widerstände sind Pflicht. Bei Sensoren lohnt es sich oft, die Messung zu „batchen“: kurz aufwachen, Sensor initialisieren, wenige Samples aufnehmen (statt lange „warm laufen“), Ergebnis lokal verdichten (Mittelwert/Min/Max/Delta-Logik) und nur dann Funk aktivieren, wenn sich etwas Relevantes geändert hat. Für WLAN ist die Königsklasse ein sehr kurzes Online-Fenster: Scans vermeiden (bekannte SSID/BSSID/Kanal nutzen), Verbindungsaufbau beschleunigen, Payload klein halten und Protokolle so wählen, dass du keine langen Handshakes provozierst (z. B. wenige Requests statt dauernd offenem Socket; TLS ist machbar, aber Handshake kostet Zeit und damit Energie). Bluetooth solltest du für Batteriegeräte in der Regel als BLE fahren: im Idealfall nur Advertising mit langen Intervallen, und wenn eine Verbindung nötig ist, dann mit möglichst „schlanken“ Connection-Parametern (lange Intervalle, kurze aktive Zeit, wenige Notifications, danach sofort wieder trennen). Vermeide es, WLAN und BLE dauerhaft parallel laufen zu lassen: Coexistence kostet nicht nur Sendezeit, sondern verlängert oft auch die CPU-Aktivphasen. Der rote Faden bleibt: Sensorik so betreiben, dass sie nur kurze, definierte Messfenster hat, und Funk so betreiben, dass du selten, kurz und planbar online bist – dann bleiben die Sleep-Anteile dominant und die Laufzeit geht von Wochen Richtung Monate.

10) Checkliste: die typischen 10 Fehler, die Monate verhindern

Wenn du beim Messen nicht in den µA-Bereich kommst, geh diese Punkte durch – der Fehler ist fast immer hier:

Regler-Ruhestrom zu hoch (LDO/Step-Down falsch gewählt)
USB-UART-Chip hängt noch am Akku-Pfad
Power-LED oder Levelshifter zieht permanent
Sensoren laufen weiter, weil sie keinen echten Shutdown haben
Spannungsteiler für Batterie-Messung zieht dauerhaft
Pins floaten und erzeugen Leckströme (extern/strap)
Pullups/Pulldowns falsch: bei EXT1 + RTC-Periph-off brauchst du oft externe Widerstände
Du nutzt Touch/ULP/EXT0 in einer Kombination, die auf ESP32 kollidiert
Du misst falsch (Burden Voltage / falscher Messbereich / falscher Messpunkt)
Du testest mit falscher Versorgung (USB 5 V → anderer Pfad als Batterie)

11)Praxisbeispiel: Stromsparendes IoT-Design mit ESP32 und E-Ink

Ein sehr handfestes Praxisbeispiel ist bei mir das FireBeetle 2 ESP32-E: Ich nutze es, weil es für IoT kompakt aufgebaut ist und eine solide Basis für Batteriebetrieb bietet (u. a. mit Ladeelektronik) – und genau damit habe ich es geschafft, ein System mit Sensorik, E-Ink-Display und WLAN mit einem 3000-mAh-Akku auf rund 1,5 Jahre Laufzeit zu bringen. Der Schlüssel war bei mir, dass das E-Ink nur beim Refresh Strom zieht, die Sensoren die meiste Zeit aus bzw. in ihren eigenen Sleep-Modi sind und WLAN wirklich nur als kurzer Burst läuft: aufwachen, messen, Display ggf. aktualisieren, Daten senden, sofort wieder in Deep Sleep. Überschlägig entspricht das über die gesamte Zeit einem Durchschnittsstrom von etwa 0,23 mA (≈ 230 µA) – und genau diese Größenordnung ist für mich der Beleg, dass „Monate bis Jahre“ realistisch sind, wenn Sleep-Zeit dominiert und alle aktiven Phasen kurz und geplant bleiben.

Fazit

„Monate mit Batterie“ sind beim ESP32 kein Zaubertrick. Es ist saubere Ingenieursarbeit: Deep Sleep konsequent nutzen, Wake-Trigger richtig wählen, Board-Hardware auf Low-Power trimmen und mit realen Messungen verifizieren. Auf Modul-Ebene sind ~7–10 µA Deep-sleep realistisch (je nach ESP32-Variante und RTC-Konfiguration).
Der entscheidende Schritt ist dann, dass dein Gesamtsystem (Regler + Sensoren + Pullups + Board-Peripherie) nicht aus „10 µA Chip“ wieder „500 µA Gerät“ macht.

Kommentare

> NO_COMMENTS_FOUND