Native api vs mqtt when using deep sleep in ESPHome?

[Mr.Selfridge]

I created a very simple esp32 sensor device and tried to add deep sleep functionality but it failed to work after the wakeup period. I was using native API. I got no connection/events after the device should've woken up.

Q: In 2026: should native API + deep sleep work just fine or should we still use mqtt instead when esp32 uses periodic deep sleep?

[Karosm]

They both should work, one might be faster than another and thereon better battery life.

[neel-m (Neel Malik)]

@Mr.Selfridge

Q: In 2026: should native API + deep sleep work just fine or should we still use mqtt instead when esp32 uses periodic deep sleep?

Suggest you read this long thread:

Notes on ESPHome deep_sleep

When running from a battery it is often desirable to minimise the power consumption; particularly where the ESP32 is taking sensor reading on a regular basis but doing nothing between them. Deep_sleep allows ESPHome to power off the main CPU when it is not needed, and reboot it after a timer or an external signal. However I found a number of issues with deep_sleep – many are not problems, but just things which aren’t covered in much detail in the docs. This is my attempt to collect the various…

Native API doesn't know you are using deep sleep, so I suspect it is NOT the best choice.

Note that getting good results on battery with esp devices is VERY challenging. You might be able to get results that are acceptable to you, but it will require a fair amount of work and possibly a bigger battery or more frequent charging/replacement than you would like.

[Mr.Selfridge]

@neel-m

Note that getting good results on battery with esp devices is VERY challenging.

I'll keep this in mind. The plan is to read a sensor data from an ultrasound distance meter every (say) 10 minutes and then just sleep. But we'll see how viable this is.

[donburch888 (Don Burch)]

@Mr.Selfridge

Q: In 2026: should native API + deep sleep work just fine or should we still use mqtt instead when esp32 uses periodic deep sleep?

Native API does work fine with deep_sleep.

@neel-m

Native API doesn't know you are using deep sleep, so I suspect it is NOT the best choice.

Neel, what does MQTT know about deep-sleep, that native API does not ?

The Native API is more recent than MQTT, and of course took a while to stabilise with current functionality ... so I do understand that plenty of regular forum members still recommend MQTT, because they are well familiar with MQTT from using it for years. Nothing wrong with MQTT, and it does have advantages in a few situations. I used MQTT for the old Rhasspy voice assistant; but have used Native API exclusively for the last few years.

Native API or MQTT both require Wi-Fi, which isn't initiated till fairly late in the boot sequence. Both transport messages to/from the ESP32, so pretty much equivalent. If anything, I suggest MQTT is a little more complicated to understand and setup (since it is a more general protocol and requires an extra MQTT server) rather than the Native API which was optimised for Home Assistant and ESPHome.

@Mr.Selfridge

I created a very simple esp32 sensor device and tried to add deep sleep functionality but it failed to work after the wakeup period. I

Which model of ESP32 are you using ? Deep-sleep is actually a shutdown and power off, then a power on and boot. Some of the models incorporate a second (slower) microcontroller core which is used to wake up the main processor - but other models of ESP32 will require an external wake up. Of course that second core is sill using some power while it is waiting - so there is a trade-off.

Would you please post your ESPHome YAML code here (using the preformatted text </> button).

If you want to see the log during the ESP32's bootup, I recommend connecting the ESP32 to a PC using a USB cable and running a terminal emulation program. It's a bit fiddly, but does give a lot of useful information.

[neel-m (Neel Malik)]

@donburch888

what does MQTT know about deep-sleep, that native API does not ?

MQTT is totally driven by the device. It determines when to send an MQTT message.

Native API is totally driven by the HA controller. It determines when it will contact the device to see if it has an update.

See here:

API vs MQTT

This weekend I finally got around to changing all my ESP sensors from mqtt to the api and discovered a case where esphome mqtt is superior to the esphome api. It takes at least three times as long using the api as it does using mqtt to wake and report the state of a binary sensor. Using the api this regularly results in missed sensor states, even allowing for filters like this: filters: - delayed_on: 100ms - delayed_off: 10s With mqtt and the above filter I never miss a senso…

So yes you can use Native API and deep sleep, but it doesn't seem like the best choice.

[donburch888 (Don Burch)]

@neel-m

See here:

Certainly back in 2019 the Native API had failings - including that it didn't play nicely with deep_sleep; but in the last 7 years an awful lot of work has been done to improve many aspects of ESPHome.

In my "Notes on ESPHome deep_sleep" thread (which you referred to above), I even recommended MQTT in March 2025 ... but then by August 2025 I played with the (then new) HA Input Helpers and showed in post 9 how HA Input Helpers and the Native API achieve the same result. Also the ESPHome 2025.6 update included Native API Speed Enhancement, which I expect was mostly "Replace API deferred queue with efficient message batching system esphome#9012".

I now recommend Native API especially for new users, unless there is a particular reason for using MQTT.

As for "Native API is totally driven by the HA controller" ... I'm not sure its that simple. I understand that Native API running on the ESP32 device does operate as a server, so you are probably correct - but that suggests that HA is regularly polling the ESP device, and there would be a delay between polls to avoid flooding the network. Yet, looking at the logs during boot, I have never noticed that sort of delay between initialising the Wi-Fi and Native API communicating with Home Assistant.

@neel-m

Note that getting good results on battery with esp devices is VERY challenging.

@Mr.Selfridge

The plan is to read a sensor data from an ultrasound distance meter every (say) 10 minutes and then just sleep.

Other users have commented that Wi-Fi is a significant power drain, and so the less often you are firing up wi-fi to communicate (whether over MQTT or Native API), the better your battery life. I have certainly noticed this with my greenhouse ESP32.

I have also seen discussions that ESP32 chips are often chosen for their low power consumption - but that is the chip itself, while the development boards and other electronics are still powered on while the ESP32 core is asleep ... resulting in disappointing real-world battery life.

There have been several remedies suggested, including disabling the Power and other LEDs on the development board; and turning off power to the i2c and other buses (effectively turning off the sensors) while the ESP32 is asleep. These issues are not unique to the ESP32, but may be an effect of developers trying to add more "useful" functionality to the recent development boards without properly considering power & deep_sleep ... in which case a more basic ESP32-C3 would be better than an ESP32-S3 with lots of extra features.

[robertklep]

@donburch888

I have never noticed that sort of delay between initialising the Wi-Fi and Native API communicating with Home Assistant.

Really? Because I see it all the time during development. After the ESP32 has connected to WiFi, it always takes some time (rough estimate: somewhere between 5 to 20 seconds) before HA connects to it. The ESP32 has a fixed IP (or rather, my DHCP server uses long lease times).

[donburch888 (Don Burch)]

@robertklep

Because I see it all the time during development.

Robert are you looking at the log from the ESPHome Device Builder HA app, or log from the serial/USB port of the ESP32 ? Yes, there is a noticeable delay after downloading a new firmware and before the log starts on the Device Builder window. Unfortunately that is not what I was referring to.

I have found from the serial log that there is a lot that the ESP32 does when it boots, before the ESP32's Wi-Fi is initialised and connects to Home Assistant ESPHome device Builder. Serial log is very educational A recent log (captured with minicom on my PC via USB port) includes ...

[2026-06-20 17:48:22] ESP-ROM:esp32s3-20210327

[2026-06-20 17:48:28] [I][wifi:1570]: Connected

[2026-06-20 17:48:30] [D][api.connection:2461]: Home Assistant 2026.6.3 (192.168.1.97): connected

This shows 6 seconds before the ESP32 connected to wi-fi and starts listening; and only another 2 seconds before Home Assistant connected. I don't know much about ESPHome internals, but this suggests to me that home Assistant took around 1 second to poll the ESP32 ... which seems very reasonable to me.

[robertklep]

I'm oldschool, so I develop using vim and run everything from the command line, and I'm using the serial logs

Here's a log for a device I'm working on:

[09:10:55.672][I][wifi:1546]: Connected
...
[09:11:12.231][D][api.connection:2409]: Home Assistant 2026.6.1 (192.168.23.2): connected

So 17 seconds before HA reconnects. Which is fairly typical in my experience.

Here's a log for a minimal ESPHome device (basically just WiFi and native API enabled):

[09:30:46.685][I][wifi:1575]: Connected
...
[09:31:07.316][D][api.connection:2461]: Home Assistant 2026.6.1 (192.168.23.2): connected

[donburch888 (Don Burch)]

Well OK Robert, yours is definitely taking longer than my ESP32-S3 to connect to Home Assistant ... and I struggle to think of a good reason for that.