I’m trying to figure out the best way to go about this and really struggling.
What I have right now is a M5Stack AtomS3 Lite with a button connected and a battery. What I want to do is make it act kind of like an old “dash button” where you hit a button to do something. I also have a temperature sensor connected that I want to periodically check. Since this is battery powered, I want to use deep sleep to conserve power. I’d like to both wake the device up when the button is pressed and on a set period of time. It would send the temperature (over MQTT) both on button press and after a period of time. When the button is pressed, it would also send an MQTT message.
Using on_boot, I’ve been able to get the button press and periodic check in both working separately but I run into issues with combining them. I’ve left the temperature reporting in the on_boot section, but to get the button message to publish, it either has to be in on_boot (which causes it to send on the timed wake up as well, or the button has to be pressed twice. Is there a way to configure this?
While you might think what you are trying to do should be easy, it is not. Many have struggled before you and I don’t know that anyone has been generally successful AND shared how they did so anyone could replicate the results.
The first question is Why?
There are many that would say the esp32 is NOT the right tool for this job. That is not to say you can’t do battery projects with the esp chips. People have done them for years and some had even got what they consider to be acceptable or even good results.
There are readily available devices that are dash buttons in either Bluetooth or Zigbee. Many people have been successful with them AND have had great battery life.
There are readily available temperature and humidity sensors that are reasonable accurate again in BT or Zigbee that easily integrate with HA.
If the goal is to build something yourself for learning, start with a mains powered (AC adapter) device. They are easy (relatively speaking). Once you have mastered that you might be better able to solve all the things you need to solve to get acceptable battery life.
I’m not trying to dissuade you, but recognising you won’t be the first hobbyist that has gone through convoluted steps to attempt over many years to solve this challenge. I’m sure a quick search will find the subject of ESP32’s running off batteries has been done to death in these very forums over the last few weeks. A summary: Not really the best platform to do this with, especially the S3 flavor. Newer generation chips by Espressif have acknowledged this shortcoming and have worked around it.
A cheap alternate, with long battery life may be a pre-built Xiaomi LYWSD03MMC with an external switch connected, flashed with custom firmware, which can also be used to support ZigBee rather than BLE connection. Further reading at
You use a different SOC platform from Telink, not Espressif, and the smiley face on the tiny display kinda looks cute. The inbuilt temperature sensor does humidity too. If you find it boring, reflash it back to other software and use it as a thermometer, or BLE tracker, etc. Did I say cheap?
Look at the nRF52840 SOC series from Nordic too, They specialize in very low powered devices, often for batteries lasting a decade, and there is ESPHome support for them too, making integration into HomeAssistant a snap. An experimental board, similar to the ESP32-S3 series are quite cheap and readily available for experimentation.
Your S3 isn’t useless - just possibly not the most suited for long term battery operations.
If I understand correctly, you want the ESP32 to wake on two conditions:
after a set period of time, and
when the button is pressed.
and both of these cause an MQTT message containing the temperature; and a second message if it was a button press.
Both wakeup conditions are handled by the Deep_sleep component. The period of time is determined by the sleep_duration configuration option; and the button press should be a wakeup_pin trigger.
Every time the ESP32 wakes up it is doing a full power-on boot. You can detect the reason for the boot in a lambda …
Fairly late in the on_boot (at about priority 200) the wi-fi connection is started in another thread. This means that on_boot may finish before Wi-fi and then MQTT or Native API are connected. Attempting to send a message before the connection is established won’t work.
I agree with Karosm’s recommendation that you send the MQTT message in the MQTT’s on_connect action. And when the message(s) are sent you can go back to sleep straight away … having been awake a minimum time.
Certainly you could use separate button and temperature sensor devices instead of an ESP32. That might even be cheaper.
I assume that Neel and IOT7712’s dislike of ESP32 is because ESPHome and ESP Development Boards don’t deliver the very low power consumption which is promoted as a feature of ESP32 chips. That is certainly disappointing, but I don’t believe it is as bad as they have managed to convey.
I would also query whether you are using MQTT because you are already familiar with it; or because it is still recommended by many users who haven’t yet used the Native API.
As Karosm suggested, sharing your yaml code will allow for specific suggestions.
That’s often the point here.
Seed Studio claims 15uA deep sleep for their Xiao -S3 and -C6 boards which makes those totally suitable for applications where esp is mainly sleeping. But Atom S3 might draw 50x more, who knows and some older devkits draw even more.
I don’t know if esphome deep sleep component is capable to turn off all peripherals and reach the lowest levels though.
Situation is totally different if frequent wake-ups are needed. Esp is power hungry and boot time is ridiculously long, especially with esphome.
Is this an actual project or are you trying to learn ESP programming?
If you are trying to learn ESP, then congratulations; you are among a vanishing breed of builders. Others have already pointed out that ESP devices generally do not do well with battery power because the WiFi stack is the most power-intensive part of an ESP processor. But your project will work. What appears to “not work” is that waking an ESP starts a reboot and it has to connect to the WiFi all over again. That can take seconds. If you put it back to sleep before the WiFi connects, well, it never “works”, but it does exactly what you programmed it to do.
If this is a learning exercise, then it is a good project. You will learn how not to make a dash button.
Yes, the later generation flavors of the ESP32 range now appear to be split into two branches, low power and high performance, a tacit acknowledgement by Espressif that the hype surrounding low power in their original ESP documentation has been vastly overshadowed by offerings from other SOC vendors like ST Micro, TI, and Nordic are just some that run rings around the S3 being assaulted [sic] here.
Milli-amps vs nano-amps both used to describe low power doesn’t stack up when battery life is involved. Maybe (bitter) real life experience is showing in our comments. Our advice is free, and you are welcome to walk the same path well trodden many years ago, and recently regurgitated as hallucinations by freshly taught LLMs (artfully disguised as AI) to a fresh new generation of hopeful experimenters. That ESPressif has chosen not to update their documentation of the older chips to revise the hype and point to recent developments is telling. That a huge user of their chips such as Tuya moving away to other SOCs such as Telink must also be driving their R&D efforts quite keenly, where every hundredth of a cent saved, not only with power supply design, but pin count, heat buildup, and other related issues can have an enormous impact on their end product, and, most importantly, cashflow and returns to stakeholders. For us, the vendor competition is good - we benefit from the rampant frantic pace of development - both in price and capabilities.
The attraction of the ESP series was the adoption of the Arduino IDE platform to work with them, as well as the extensive documentation in understandable English, not Chinglish. Other chip vendors have noticed and the gap has narrowed to the point where platformio support for other chips is making it quite easy to add ESPHome integration with only small changes, standing on the shoulders of giants. Having just read through the ESPHome release notes for July 2026 and gone back to see the code diffs in GitHub re-enforces how easy it is to add support for a new platform such as the nRF52 SOC Family, and even the ESP32-S31 successor to the S3.
Long battery life for me is measured in years, not hours or days, hence my recommendation that having S3 and low power in the same sentence may not be wise.
So calculate what bare S3 module/ optimized dev board draws at your preferred sleep cycle.
At 15uA sleep I see it very suitable for low activity approach (don’t know if esphome deep sleep can get there).
NRF52 can do much better though. But support on esphome is quite limited.
It’s not the current draw during sleep, but the frantic activity when woken to get the data, bundle it, and transmit it that is the futile part of the exercise on the S3, but far easier with different chips and transmission media and protocols, rather than 802.11 2.4Ghz WiFi.
Maybe Ecclesiastes entire chapter one? King James version. Data sheet for a wise approach to life.
There seems to be confusion about the differences between an ESP32 chip or module; a Development Board; and ESPHome … resulting in Espressif being blamed for the way their chips are used. That would be like blaming Henry Ford personally for every drunk who uses a car and kills someone.
I found this article particularly helpful in putting it into context.
Most ESP32 projects are powered from USB adapters and run 24/7.
For battery-powered sensors, that approach kills the battery in a few hours.
Development Boards are initially designed by chip makers to give professional engineers a start to get familiar with new chips to develop their own products. Engineers making commercial products which utilise the low power are expected to custom make their own PCBs utilising low power components and designing to minimise power consumption. DevKits were not initially designed for mass market use.
When ESPHome was developed, hobbyists were using those first generation of Development Boards which used USB power, and - as IOT7712 points out - low power feature was not the priority at that time. It certainly feels that deep_sleep has been tacked on as an afterthought.
One of the main problems is that components on the devkit (eg power LED) and attached devices (eg i2c) remain powered on while the ESP core is asleep. A work-around is to power these components from a GPIO pin … but ESPHome is against us there because it initialises i2c before the GPIO pins which would power the i2c devices.
This has been discussed before, including Add priority configuration to i2c bus to allow users to power down during sleep #3069 which reveals that there is an undocumented setup_priority: option to adjust where in on_boot priority the i2c initialise occurs. ssieb on Mar 3, 2025 commented:
It’s not documented because we don’t want people generally using it as it’s more likely to cause problems than fix them.
I note that most of the major devkit makers now have boards with a LiPo connector and charging onboard … which suggests that these boards were designed with low power consumption in mind. I have recently got an Unexpected Maker FeatherS3 and am greatly impressed.
I suggest it would be good for ESPHome developers to take a step back and see if the wider issue of low power / deep-sleep can be incorporated better - like they have recently with Wi-Fi, memory and execution optimisations.
It is well known that wi-fi is the biggest power consumer in ESP32/ESPHome - hence the reason for deep_sleep - and yes, I agree the whole boot procedure should also be reviewed. Certainly other lower power transmission media and protocols are welcome … but as a non-electronic-engineer I’m curious how else you might get and bundle the data ?
With highly optimized code esp32 boot time from sleep is in range 10x compared to nrf52840. Another 10x when on esphome and another 10x if making wifi connection…
There are many ways. It all depends on what you are trying to do and what constraints you must meet.
This is a company I have been watching for a long time: About Low Power Lab | LowPowerLab
They are doing some very interesting things in low power and RF communication.
I wasn’t concerned about low power and the esp8266 came out which met my needs.
Battery powered is very hard to do well. You really have to make each coulomb count (or have a much bigger battery or charge it more frequently).
i think that battery powered esp with BLE or Espnow is easily doable (outside of esphome).
If Xiao -S3 draws 15uA in deep sleep and wakes up once an hour, read some sensor, send few BLE broadcast packets and go back to sleep, wake time would be few seconds per day.
One day at 15uA makes 0.36mAh and 5s at 100mA makes 0.14mAh, total 0.5mAh per day.
That’s less than common battery self discharge.
If it’s outside then there is always the Sun. Deep sleep waking every 5 mins, MCP73871, with 90x30mm solar panel and a lithium cell can run year round.
I’m at 54 degrees latitude so not a lot of daylight in Dec-Jan but always looking for ways to conserve battery to avoid those odd occasions when battery shuts off.
Yep. That’s the math for me as well if I develop battery powered device.
One month zero recharge, another month still on negative, rest of the year about full battery.