ESP32 Forum

Continuation of thread previously on esp8266.com

I don't use EspHome myself but looking at documentation it would look like the run_duration in the config means that it will re-enter deep sleep 30 seconds after waking up. As you are waking up to measure and report every 10 minutes this means the esp8266 is awake for 5% of the time. Assuming 80mA current consumption while it is awake this would give an average consumption of 4mA. That will drain your battery in about 550 hours.

To get much better battery life you need to reduce the duty cycle of the wake to sleep time. Does it really need to be awake for 30 seconds to take the measurement and report it? If for example, you can reduce that to 5 seconds then you will reduce your average current by 6 times and get 6 times longer battery life.

Ignoring ESPHome for the moment it is possible to do a fast wifi connect, take a measurement, and report it in under 2 seconds which would give over a year of operation.

It takes about 20-25 seconds for home assistant connection. Should i be using mqtt to report in 2 seconds? What is the method?

25 seconds to make a connection sounds very bad. I'm not familiar with EspHome to know if that is normal. You first need to know where these delays are. Is it in making wifi connection, or some espHome initialisation?

MQTT should be able to report sensor values in 1 second after wifi connection is made after wake up. Normal default wifi connection is about 3 seconds but can be reduced to about 1 second by fast connect methods. There are details of using mqtt in EspHome documentation.

Associating and getting an IP address using DHCP can be done within a second after restart.

There are some conditions that need to be met for this to work though. Some of them are:
- SSID and password must be stored in flash and it must have been associated at least once before power cycling
- enable automatic "reconnect" in the SDK

Under certain circumstances (I am not certain which) this mechanism completely fails and the ESP won't associated, at all, even when the SSID and password in flash are correct. There is no clue in the logging or the AP's logging what's the cause. Also sometimes the wrong access point is associated to (not the nearest one).

To workaround these I am using the following procedure:

- use auto(re)connect to have SDK handle the initial association, which mostly is very quick
- if after 30 seconds there is still no association, initiate an explicit scan en connect explicitly to the best access point
- when associated, start a counter and when it reaches one minute, start an explicit scan, check if we're associated to the best access point and if not, connect explicitly to the best access point
- if after 60 seconds still no association, fall back to rescue mode (activate access point mode)
- if after 300 seconds still nothing, reboot the whole thing.

This works quite well.

It would be great if Espressif would reveal most of the SDK code (besides the low-level, RF license encumbered stuff), so we would be able to fix this.