ProcirelESP32 Deep Sleep: Months of Battery From One Cell
Deep sleep drops the ESP32 to ~10 µA, keeping only the RTC and wake sources alive. A sensor that wakes, reads and sleeps can run a year on a small cell. The catch: deep sleep is a reset plan your state machine accordingly.
> At a glance: 8 minute guide · part 8 of 10 in the complete IoT and ESP32 guide track · includes a worked example and a quick-reference table.
## Wake sources
Timer (esp_sleep_enable_timer_wakeup) is the everyday choice. EXT0/EXT1 wake on RTC GPIO low levels perfect for door sensors. Touch and ULP wake exist for specialised builds. Multiple sources OR together, so timer plus button is standard.
| M | o | d | e | | | | | | | | | | | |
| — | — | — | — | — | — | — | — | — | — | — | — | — | — | — |
| T | y | p | i | c | a | l | | c | u | r | r | e | n | t |
| W | a | k | e | | l | a | t | e | n | c | y | | | |
| Active + WiFi | 120–250 mA | | | | | | | | | | | | | |
| Modem sleep | 20–30 mA | ms | | | | | | | | | | | | |
| Light sleep | ~0.8 mA | ms | | | | | | | | | | | | |
| Deep sleep | ~10 µA | Reset + boot (~150 ms) | | | | | | | | | | | | |
| Hibernation | ~5 µA | Like deep sleep | | | | | | | | | | | | |
## What sleeps and what survives
What this means at the bench: RAM contents vanish. RTC slow memory survives if you declare data RTC_DATA_ATTR. Boot resumes at setup(). Your sketch must detect the wake cause (esp_sleep_get_wakeup_cause) and skip full re-initialisation where it can. WiFi costs seconds of battery per wake batch aggressively.
## The runtime mathematics
Suppose 150 mA active for 3 s and 20 µA sleeping. Daily cost with hourly wakes ≈ 24×(3 s × 150 mA) = 12. 6 mAh sleep component ≈ 0. 48 mAh/day a 2500 mAh cell lasts months. The lesson: cut active time before anything else; every second awake dwarfs a day asleep.
## How to apply this in your build
Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.
1. Move rarely-changing logic out of the wake path
2. Store counters and state in RTC memory
3. Batch sensor reads and one transmission per wake
4. Measure actual sleep current once clones vary
### Worked example
A soil-moisture probe woke hourly, read for 2 s, published one MQTT message and slept. Measured average 380 µA a 18650 cell computes to seven months of service. Run the numbers yourself with the Battery Life Calculator and the result should agree to within rounding.
> Practical note from the bench. Battery milestones on our bench log: measure active seconds and sleep µA once, and runtime stops being a mystery forever.
## Field mistakes we see again and again
– Re-running full WiFi connect every wake for one measurement
– Forgetting pull-ups drift during sleep and phantom-trigger the sensor
– Assuming delay() saves power it does not; only sleep modes do
## Key takeaways
– Wake sources the foundation of this guide; revisit it if any measurement here surprises you.
– What sleeps and what survives the foundation of this guide; revisit it if any measurement here surprises you.
– The runtime mathematics the foundation of this guide; revisit it if any measurement here surprises you.
## Prerequisites and preparation
Before starting. Move rarely-changing logic out of the wake path and store counters and state in rtc memory. Keep the [Battery Life Calculator](/tools/battery-life) open every number in the worked example is reproducible. Total time including the bench steps: about 6–8 minutes.
## Who benefits most
Hobbyists meeting this topic for the first time, students who want the version with real numbers instead of abstract symbols. Returning engineers refreshing a corner of the craft. The mistake list alone justifies the visit every entry in it was learned the expensive way.
### Quick reference card
| Aspect | Where to find it in this guide |
| — | — |
| Core theory | Wake sources |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Field mistakes we see again and again |
## How this fits the complete IoT and ESP32 guide track
This guide is one stop in the structured learning path. Start from the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [reconnection after wake](/tutorial/esp32-wifi-reconnection-strategies) and [IoT security basics](/tutorial/iot-security-best-practices). For the arithmetic, open the [Battery Life Calculator](/tools/battery-life).
## Frequently asked questions
Is deep sleep bad for the flash?
Each wake is a boot. Flash wear only matters if you write NVM every cycle keep counters in RTC memory.
How do I keep WiFi fast after wake?
Persist channel and BSSID hints the radio re-associates in a fraction of the usual scan time.
Is there a calculator for this?
Yes the [Battery Life Calculator](/tools/battery-life) tool runs the formulas from this guide instantly, client-side, with no signup.
## Related guides and tools
– The complete iot, sensors & esp32 guide: [IoT, Sensors & ESP32 complete guide](/tutorial/iot-esp32-complete-guide)
– Read next: [lorawan for beginners: long-range iot without wifi](/tutorial/lorawan-tutorial-beginners)
– Also in this track: [antenna basics for iot: wavelength, gain and matching](/tutorial/antenna-basics-tutorial)
– Continue with: [biomedical sensors: how wearables measure the body](/tutorial/biomedical-sensor-guide)
– Calculate as you go: [battery life estimator](/tools/battery-life) · [LM317 regulator designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)
– From here, the natural continuation is the next guide in the track index. It assumes exactly the vocabulary this page built and adds the next layer of practice.
## Verification routine
Component substitution is a legitimate experiment as long as it is deliberate. Swap one part, predict the effect, measure, and record. That single habit converts a parts bin into a teaching lab and makes every future guide in this track faster to absorb.
The fastest way to internalise this topic is to change one variable deliberately and predict the result before measuring. Wrong predictions are the curriculum, they show exactly which mental model needs revisiting, and the bench grades honestly.
## Formulas and checks from this guide
Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts. Confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.
Bookmark this page against your next build in the track. The checklist above is the same one used across 23 guides in this series.
## Notes from the bench
Location, then device, then measurement. Document the tree before flashing the first device.
Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.