Why an ESP32 makes a terrible battery-powered sensor (match the board to the job)

Last reviewed: 21 July 2026

You build a little sensor around an ESP32 because that's what every tutorial uses, put it on a battery, and it's flat in a day or two. The board isn't broken, it's just the wrong board for a battery. Here's how to pick the right one.

The numbers that decide it

It comes down to how much current a board draws, especially when it's meant to be doing nothing:

• A plain ESP32 or ESP32-S3 pulls roughly 35-50 mA while it's awake, and it has no real deep-sleep worth the name, even "asleep" it keeps drinking. On a small battery that's a day or two, tops. It's a mains or USB board that happens to be small.
• A low-power board (CubeCell class) drops to around 21 microamps, that's 0.021 mA, in deep sleep. Roughly a thousand times less. On the same small cell it runs for years, waking briefly to take a reading and going straight back to sleep.

That gap is the whole story. It's not a tuning problem you can fix in firmware, it's what the silicon does.

Why the ESP32's "deep sleep" isn't

The ESP32 has a deep-sleep mode on paper, so people assume battery life is just a config setting. In practice it doesn't get you there:

• Its idle draw is still far higher than a purpose-built low-power chip.
• Everything it's good at, WiFi and Bluetooth, is power-hungry. Firing up WiFi to send a reading is an expensive event, and doing it often wipes out any sleeping you managed in between.
• The ESP32 earns its keep when it's plugged in and you want that WiFi, Bluetooth and processing grunt. Take the power away and its strengths become dead weight.

None of this makes the ESP32 a bad board. It makes it a mains board. Use it as one.

The board-choice guide

Pick the board from how the sensor is powered and what it needs to talk to:

• Battery sensor, occasional readings. Reach for a low-power board (CubeCell class) plus LoRa. Around 21 µA asleep means years on a small cell.
• Mains or USB powered, anything. Reach for an ESP32 or ESP32-S3. Power is no concern and you get WiFi, Bluetooth and grunt.
• Needs WiFi or Bluetooth. Reach for an ESP32. It's what the chip is for, but plan to power it.
• Long range, tiny data, no mains. Reach for a low-power board plus LoRa. It sips power and reaches far.

This is the choice behind every good battery build, like a washing-machine-done alert or a car presence alarm that runs for months on a small cell.

The rule of thumb: battery means a low-power board; plugged in or needs WiFi or Bluetooth means an ESP32. Decide how it's powered first, then pick the board. Don't start with the ESP32 because it's familiar and then try to diet it onto a battery, you'll lose.

The one exception

There's a case where all of this stops mattering: when the sensor itself is the power hog.

Say you're running a continuous radar presence sensor that, by its nature, draws around 50 mA the entire time it's on. Now the sensor swamps everything else. A low-power board asleep at 21 µA sitting next to a part pulling 50 mA non-stop is rounding error, the board's efficiency can't rescue a load that never lets up. At that point the board choice barely moves the battery life, so you may as well use the ESP32 for its WiFi and convenience, or accept that this particular sensor wants mains power regardless.

The lesson underneath it: the low-power board only wins when it's allowed to sleep. Pair it with a sensor that also sleeps between readings and you get years. Pair it with something that's awake and drawing the whole time and you're back to needing mains, whatever board you picked.

The short version

A plain ESP32 or ESP32-S3 draws about 35-50 mA awake with no real deep-sleep, so on a battery it's flat in a day or two, treat it as a mains or USB board. A low-power CubeCell-class board hits around 21 µA in deep sleep and runs for years on a small cell, so that's your battery-sensor board. Save the ESP32 for anything mains-powered or needing WiFi or Bluetooth. The one exception: if the sensor itself draws around 50 mA continuously (like a continuous radar), it swamps the board and the choice barely matters.

Field-tested rules of thumb from our own sensor builds; exact figures vary by board revision, firmware and sensor, so measure your own draw before committing to a battery.

Building a battery sensor and not sure which board or radio to trust? That's the kind of thing we work out properly. No lock-in, no upsell to gear you don't need. Tell us what you're building and we'll point you at the right parts.