ESP8266 & ESP32 – Stromverbrauch und Stromversorgung

Ob Wetterstation auf der Fensterbank, smarter Türklingel oder batteriebetriebener Sensor im Garten – der ESP8266 und der ESP32 sind aus der DIY-IoT-Welt kaum noch wegzudenken. Beide Chips sind preiswert, WiFi-fähig und verfügen über eine breite Entwickler-Community. Doch wer schon einmal erlebt hat, wie sein Projekt unerwartet abstürzt, neu bootet oder den Akku innerhalb weniger Stunden leer saugt, kennt das eigentliche Kernproblem: den Stromverbrauch und eine saubere Stromversorgung.

Dieser Artikel richtet sich an Maker, Hobbyisten und Embedded-Entwickler, die ihre ESP-Projekte zuverlässig und langlebig aufbauen wollen. Wir beleuchten die Unterschiede zwischen ESP8266 und ESP32, erklären die verschiedenen Energiesparmodi, zeigen häufige Fehlerquellen und geben konkrete Empfehlungen für die Praxis.

Grundlagen: Betriebsspannung und Stromhunger

Beide Chips - sowohl ESP8266 wie ESP32 - arbeiten mit einer Betriebsspannung von 2,3 bis 3,6 V. Der typische Arbeitspunkt liegt bei 3,3 V. Das klingt simpel, hat aber weitreichende Konsequenzen: Fällt die Versorgungsspannung auch nur kurzzeitig unter etwa 2,55 V, führt das unweigerlich zu einem Reset – selbst wenn der Einbruch nur wenige Millisekunden dauert. Dies ist ein häufig unterschätzter Fehler, der sich in der Praxis als sporadischer, scheinbar unerklärlicher Absturz manifestiert.

Der entscheidende Unterschied zwischen den beiden Chips liegt bereits im Ruhebetrieb: Der ESP8266 verbraucht im aktiven WLAN-Betrieb typischerweise 80 mA, beim Senden von Datenpaketen können kurze Spitzen von 170–300 mA auftreten. Der leistungsfähigere ESP32 mit zwei CPU-Kernen, Bluetooth und schnellerem WiFi zieht im aktiven Modus 160–260 mA – mit Transienten von über 400 mA für wenige Millisekunden beim Senden. Wer ausschließlich auf einen günstigen Standard-USB-Port oder ein billiges Steckernetzteil vertraut, lebt damit gefährlich.

Vergleich: ESP8266 vs. ESP32

Eigenschaft ESP8266 ESP32
Betriebsspannung 2,3–3,6 V 2,3–3,6 V
Stromverbrauch (aktiv) ~80 mA 160–260 mA
Spitzenstrom (WiFi TX) bis ~300 mA bis ~400 mA+
Deep-Sleep-Strom ~16 µA ~10 µA
Max. Sleep-Timer ~71 Minuten Flexibel per RTC
Bluetooth Nein Ja (Classic + BLE)
CPU-Kerne 1 2

Die Energiesparmodi im Detail

Sowohl der ESP8266 als auch der ESP32 bieten Stromspar-Modi, mit denen sich der Verbrauch dramatisch reduzieren lässt. Wer batteriebetriebene Projekte baut, kommt an diesen Modi nicht vorbei.

ESP8266 Sleep-Modi

Der ESP8266 kennt im Wesentlichen drei relevante Modi:

  • Modem Sleep: Das WiFi-Modem wird zwischen Übertragungszyklen abgeschaltet, die CPU bleibt aktiv. Sinnvoll, wenn regelmäßig kleine Datenmengen gesendet werden sollen.
  • Light Sleep: CPU und Modem werden in einen Schlafzustand versetzt, der Betriebszustand bleibt im RAM erhalten. Aufwachen ist schnell möglich.
  • Deep Sleep: Nahezu alle Schaltkreise werden abgeschaltet. Nur der RTC-Timer läuft weiter. Der Stromverbrauch sinkt auf ca. 16 µA – ohne die oft auf Entwicklerboards verbaute rote Power-LED sogar auf ähnlich niedrige Werte. Der Deep-Sleep-Timer ist dabei auf ca. 71 Minuten begrenzt. Wichtig: Zum Aufwachen muss der RST-Pin mit dem GPIO16 verbunden werden.

ESP32 Sleep-Modi

Der ESP32 bietet fünf Modi, die deutlich feiner konfigurierbar sind:

  • Active Mode: Alle Einheiten (CPU, WiFi, BT, Peripherie) laufen vollständig. Verbrauch: 160–260 mA.
  • Modem Sleep: WiFi und Bluetooth schlafen, die CPU läuft weiter. Der DTIM-Mechanismus des Access Points koordiniert das Aufwachen.
  • Light Sleep: CPU-Kerne und digitale Peripherie werden angehalten, der RAM-Inhalt bleibt erhalten. Aufwachen aus verschiedenen Quellen (Timer, GPIO, UART) möglich. Verbrauch fällt auf 0,8–1,0 mA.
  • Deep Sleep: Nur der ULP-Coprozessor (Ultra Low Power) und der RTC-Speicher bleiben aktiv. CPU, RAM, WiFi und BT sind komplett abgeschaltet. Verbrauch sinkt auf 0,15 mA bis 10 µA – abhängig von aktivierten Peripheriegeräten.
  • Hibernation: Nur ein einzelner RTC-Timer läuft. Verbrauch unter 5 µA. Alle anderen Einheiten sind tot.

Stromverbrauch im Deep Sleep in der Praxis

In realen Messungen (z. B. mit dem Nordic Power Profiler Kit II) lässt sich beim ESP32 im Deep Sleep, zusammen mit einem Bosch BME280-Sensor bei freier Verdrahtung, ein Wert von ca. 330 µA erreichen. Auf einem optimierten PCB-Design oder mit einem speziell auf Energiesparen ausgelegten Board wie dem "ECO Power" kann dieser Wert weiter sinken. Der ESP8266 schafft im Deep Sleep sogar unter 20 µA – allerdings ist der Schlaf-Wach-Zyklus weniger flexibel konfigurierbar als beim ESP32.

Praktisches Code-Beispiel: Deep Sleep mit dem ESP32

#include "esp_sleep.h"

#define SLEEP_DURATION_US 30 * 1000000ULL  // 30 Sekunden

void setup() {
    Serial.begin(115200);
    Serial.println("Aufgewacht! Messe Sensordaten...");

    // Hier: Sensoren auslesen, Daten senden

    Serial.println("Gehe in Deep Sleep...");
    esp_sleep_enable_timer_wakeup(SLEEP_DURATION_US);
    esp_deep_sleep_start();
}

void loop() {
    // Wird nach Deep Sleep nie erreicht
}

Das Grundprinzip: Der ESP32 wacht auf, erledigt seine vorgegebene Aufgabe, schickt die Daten anschließend per WiFi und schläft dann sofort wieder ein. Je kürzer die Wachzeit, desto länger die Akkulaufzeit.

Die größte Fehlerquelle: Die Stromversorgung selbst

Viele unerklärliche Abstürze und Verbindungsabbrüche haben nichts mit der Software oder dem WLAN zu tun – sie sind ein Stromversorgungsproblem. Das zeigt sich besonders deutlich, wenn man die Versorgungsspannung mit einem Digitaloszilloskop unter Last beobachtet: Beim Senden von WiFi-Datenpaketen bricht die 3,3-V-Spannung oft auf 2,8 V oder darunter ein. Das reicht für einen Reset.

Häufige Fehlerursachen

  • Minderwertige USB-Netzteile: Billige Steckernetzteile erzeugen teils 500 mV Ripple auf der 5-V-Leitung (Sägezahnsignal mit 2 kHz wurde direkt messtechnisch nachgewiesen). Unter Last wird es noch schlimmer.
  • Zu lange oder zu dünne USB-Kabel: Selbst ein 1-Meter-USB-Kabel mit dünnen Leitern verursacht bei 400-mA-Spitzen einen signifikanten Spannungsabfall. Das Ergebnis: Spannungseinbrüche von 0,5 V und mehr direkt am ESP-Modul.
  • Fehlende Stützkondensatoren: Ohne ausreichende lokale Pufferkapazität kann der LDO-Regler die Stromspitzen nicht schnell genug ausgleichen.

Die bewährten Lösungen

1. Qualitatives Netzteil verwenden

Raspberry-Pi-Netzteile oder Industrienetzteile mit niedrigem Ausgangswiderstand sind deutlich stabiler als generische USB-Ladegeräte. Wer sicher gehen will, misst die Ausgangsspannung unter Last mit einem Oszilloskop.

2. Kurze, dicke Kabel

AWG22 (0,35 mm²) oder AWG24 (0,25 mm²) sind für kurze Versorgungsleitungen geeignet. Alternativ: fertige USB-Kabel der Kategorie USB 3.0 mit Stromtragfähigkeit bis 3 A verwenden.

3. Stützkondensatoren direkt am ESP-Modul

Diese Maßnahme ist günstig und hochwirksam. Die bewährte Kombination:

  • 47 µF Tantalkondensator direkt parallel zwischen VDD und GND am ESP-Modul (schnell, niedriger ESR, puffert kurze Stromspitzen innerhalb von Mikrosekunden)
  • 470 µF bis 2000 µF Low-ESR-Elektrolytkondensator ebenfalls parallel (lädt den Tantalkondensator nach und stabilisiert längere Einbrüche)

4. Spannungsregler richtig wählen

  • Viele Entwicklerboards nutzen den weit verbreiteten AMS1117-3.3 LDO-Regler. Er ist günstig, aber nicht für hohe Lasttransienten ausgelegt.
  • Besser: Ein moderner LDO mit höherer Slew-Rate oder ein Buck-Converter (Step-Down-Regler), der effizienter ist und weniger Wärme produziert.
  • Wer lange Zuleitungen (z. B. im Garten oder in der Garage) hat, sollte 12 V oder 24 V über die Leitung führen und erst am Einbauort per Step-Down auf 5 V (und dann per LDO auf 3,3 V) regeln. Der Spannungsabfall bei gleicher Leistung ist bei höherer Spannung deutlich geringer.

5. Schalten statt Regeln: 3,3V direkt aus LiFePO4

Eine elegante Lösung für batteriebetriebene Anwendungen ist der Einsatz einer LiFePO4-Zelle (Lithiumeisenphosphat). Deren Nennspannung liegt bei ca. 3,2–3,3 V, mit vollem Ladezustand bei 3,6 V – damit ist sie direkt innerhalb des Versorgungsbereichs des ESP32. Kein LDO-Regler nötig, minimale Verluste, hohe Stromlieferfähigkeit. Messungen zeigen, dass ESP32-Module im WiFi-Betrieb mit kurzen LiFePO₄-Zuleitungen (wenige Zentimeter) stabil laufen und nur minimale Spannungseinbrüche aufweisen.

Batterie- und Akkubetrieb: Was hält wie lange?

Die theoretische Laufzeit lässt sich mit einer einfachen Formel schätzen:

​Wobei C die Kapazität in mAh und I der gemittelte Stromverbrauch in mA ist.

Beispiel: ESP32 mit Deep-Sleep-Strategie

  • Wachzeit pro Zyklus: 5 Sekunden (WiFi verbinden, Daten senden, Sleep)
  • Schlafzeit pro Zyklus: 55 Sekunden
  • Stromverbrauch aktiv: ~160 mA
  • Stromverbrauch Sleep: ~0,5 mA

Gemittelter Strom: (5 × 160 + 55 × 0,5) / 60 ≈ 13,8 mA

Mit einem Standard-18650-LiIon-Akku (3000 mAh) ergibt das theoretisch ca. 217 Stunden ≈ 9 Tage Laufzeit. Ohne Sleep-Modus (dauerhaft aktiv, 160 mA) wären es nur etwa 18 Stunden. Der Unterschied ist dramatisch.

Zum Vergleich: Ein ESP8266 im Deep Sleep (16 µA) mit nur kurzen Wachphasen alle 10 Minuten läuft mit 2 AAA-Batterien (ca. 1000 mAh) mehrere Jahre – aus der Community sind Laufzeiten von über 2,5 Jahren dokumentiert.

Solarbetrieb: Dauerhaft autark

Für Sensoren im Außenbereich bietet sich Solarbetrieb an. Die klassische Kombination:

  • Kleines Solarpanel (z. B. 6 V / 2 W)
  • TP4056-Lademodul für sichere 18650-LiIon-Akku-Ladung mit Überladeschutz
  • 18650-Akku als Puffer für Nacht- und Schlechtwetterphasen
  • ESP32 oder ESP8266 mit optimierter Deep-Sleep-Strategie

Mit diesem Setup und einem Abfrage-Intervall von 10 Minuten sowie optimiertem Deep Sleep sind ganzjährig autarke Sensoren realistisch – vorausgesetzt, das Solarpanel bekommt ausreichend Licht.

Muntzing: Hardware-seitiges Stromsparen

Neben den Software-Modi gibt es eine ebenso wirkungsvolle Methode: Muntzing – benannt nach dem Elektronikingenieur Mort Muntzing. Gemeint ist das schrittweise Entfernen aller nicht unbedingt notwendigen Komponenten vom Board:

  • Power-LEDs auf Entwicklerboards verbrauchen oft 3–10 mA dauerhaft. Einfach die LED desoldering oder den Vorwiderstand entfernen. Beim beliebten ESP8266-basierten Wemos D1 Mini macht die rote Power-LED den entscheidenden Unterschied im Deep-Sleep-Modus aus.
  • Spannungsregler auf dem Board verbrauchen selbst im Leerlauf Querstrom. Wer den ESP-Chip direkt mit 3,3 V versorgt (z. B. aus einem externen LDO), umgeht diesen Verlust.
  • Pull-up/Pull-down-Widerstände auf Erweiterungsmodulen können ebenfalls dauerhaft Strom ziehen. Im batteriebetriebenen Design jeden Strompfad kritisch prüfen.

Tipps für die Praxis: Checkliste für stabile ESP-Projekte

Stromversorgung:

  • Qualitatives Netzteil mit ≥ 500 mA für den ESP allein einplanen (bei gleichzeitigem WiFi + BT ggf. mehr)
  • Kurze, dicke Zuleitungen verwenden (< 30 cm, AWG22 oder besser)
  • 47-µF-Tantalkondensator + 470-µF-Low-ESR-Elko direkt an VDD/GND des ESP-Moduls löten
  • Bei langen Leitungen: höhere Eingangsspannung (12/24 V) mit lokalem Step-Down nutzen

Akku-/Batteriebetrieb:

  • Deep Sleep so früh wie möglich aktivieren
  • WiFi-Verbindungszeit minimieren (statische IP statt DHCP spart ca. 50–200 ms)
  • LiFePO₄-Akkus als direkten 3,3-V-Lieferanten erwägen
  • Power-LEDs auf dem Board deaktivieren oder entfernen

Software:

  • WiFi nur bei Bedarf einschalten, dann sofort wieder abschalten
  • Bei ESP32: WiFi.disconnect(true) vor dem Sleep aufrufen
  • CPU-Frequenz reduzieren wenn möglich: 80 MHz statt 240 MHz spart erheblich Strom
  • MQTT-Sessions und Keep-Alive-Intervalle optimieren, um unnötige Übertragungen zu vermeiden

Fazit

ESP8266 und ESP32 sind sparsame, leistungsfähige Mikrocontroller – aber nur dann, wenn man ihre Eigenheiten kennt und respektiert. Der größte Fehler in der Praxis ist nicht falsche Software, sondern eine instabile oder zu schwache Stromversorgung. Wer Stützkondensatoren nachrüstet, auf kurze und dicke Kabel setzt, ein qualitatives Netzteil wählt und die Energiesparmodi konsequent nutzt, baut in der Regel Projekte, die jahrelang zuverlässig laufen – ob am Netzteil oder an einer kleinen Batterie.

Letzte Aktualisierung am 14. Mai 2026 / Affiliate Links / Bilder von der Amazon Product Advertising API

Stefan Kröll

Über den Autor

Gründer von Xgadget.de und IT-Experte mit über 15 Jahren Erfahrung in den Bereichen macOS, Windows und Smart Home. Als leidenschaftlicher Tech-Enthusiast zudem auch spezialisiert auf Raspberry Pi Projekte und individuelle IT-Lösungen, um komplexe Technik für Anwender verständlich und nutzbar zu machen.

Alle Artikel von Stefan Kröll →
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

* gesponserter Link
Blogverzeichnis - Bloggerei.de