Power Management for Battery-Powered IoT Sensors

A battery-powered sensor node that needs charging every week is a liability, not an asset. In practice, sensors that require frequent maintenance get neglected, moved, or removed entirely. The target for most IoT sensor deployments is weeks to months on a small battery, ideally without the user thinking about it at all.

Getting to multi-week battery life requires systematic power management. It's not just about choosing low-power components — it's about understanding the duty cycle of your application and making sure the device spends most of its time in the lowest-power state consistent with its function.

The power breakdown

For an ESP32-based IoT sensor that periodically takes a reading and transmits it, the power consumption has a few distinct components:

Active processing: the ESP32 in active mode draws ~80–240mA depending on what's happening (WiFi transmit is the highest draw). At 3.3V, this is 250–800mW. If this were continuous, a 2000mAh LiPo would last about 4–16 hours.

WiFi transmission: the peak current during WiFi transmission is 200–320mA. Duration is typically 100–500ms per transmission depending on network conditions and packet size.

Sleep modes: ESP32 deep sleep draws ~10µA. This is three to four orders of magnitude less than active mode. If the device spends 99.9% of its time in deep sleep and only wakes for 100ms to take a reading and transmit, the average current drops dramatically.

Sensor current: the sensor drawing current while the microcontroller is sleeping is often the dominant power drain in deep-sleep designs. A BME280 in normal mode draws 3.6µA. A DHT22 draws ~1.5mA while sampling. If you're waking every minute but the sensor draws more than the microcontroller in sleep, the sensor is the problem.

The deep sleep pattern

The fundamental pattern for low-power sensor nodes:

1. Wake from deep sleep (RTC timer or external interrupt) 2. Initialise peripherals, take sensor reading 3. Connect to WiFi (if needed) and transmit 4. Enter deep sleep for the next interval

The power consumed per wake cycle: predominantly the WiFi connection and transmission phase. WiFi association from scratch takes 200–400ms. If you can optimise this — storing the BSSID, channel, and IP configuration in RTC memory to skip the full association process — you save significant energy per cycle.

For sensors on very slow update intervals (every 15 minutes), the WiFi association overhead is a small fraction of the total. For sensors that update every 30 seconds, WiFi power dominates.

Alternative to WiFi: BLE beacons use much less power for one-directional data transmission. ESP-NOW (ESP32's peer-to-peer protocol) has lower overhead than full WiFi. LoRa is lowest power of all for long-range applications but requires gateway infrastructure.

The sensor power problem

I/O pins can power sensors: pull a GPIO high, connect the sensor's VCC to that pin via a transistor, and the sensor only receives power when the GPIO is active. This is the right approach for sensors that draw significant current.

For a DHT22 (1.5mA average): power from a GPIO pin during the measurement window, not continuously. With a 30-second wake interval and 200ms measurement window, the duty cycle for sensor power is 0.7%.

For the BME280 in forced mode: trigger a measurement, wait ~10ms, read the result, put the sensor back to sleep. The sensor's built-in sleep mode draws ~0.1µA. No need for external power switching.

Plan the power budget on paper before building. Calculate: active current × active time + sleep current × sleep time, summed over a day. Compare against your battery capacity. If the numbers don't work, identify which component is dominant and attack that first.