I use an ESP32 as a sensor and run it on battery power. Therefore I use the Deep Sleep. The problem is that during sleep the entities in Home Assistant change to “unavailable” at some point. On the HA console this error appears:
2023-08-13 19:42:18.476 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for battery-test @ 192.168.178.123: Error connecting to ('192.168.178.123', 6053): [Errno 113] Connect call failed ('192.168.178.123', 6053) (SocketAPIError)
I think that an appropriate behaviour would be, that the entities do not become unavailable while the device is sleeping. It wouldn’t be too difficult for esphome to communicate the sleep duration and for home assistant to reconnect after sleep.
So far I have used MQTT with empty topics for will/birth message to retain the state values. Now I thought switching to the native API would reduce overhead and connection time to allow reduction of the wake time.
Any chance you added deep_sleep only after sensors were known to HA Core?
I experienced a similar issue, but noticed when I added another sensor it was ok.
I then deleted the sensors that did not work as expected (commented out, rebooted, deleted), and then commented it in again.
Then it works for me.
I see similar behavior for a esphome DHT sensor where I added deep_sleep to after using it for a while.
I’ve tried powering off the esp32, deleting the device in HA, deleting all the retained entries in MQTT, restarting HA, then powering the esp32 on again. When it populates in HA it is marked as unavailable.
I’m not using the native api. I prefer to have it run through MQTT.
ESPHome uses the last will testament and birth message feature of MQTT to achieve availability reporting for Home Assistant. If the node is not connected to MQTT, Home Assistant will show all its entities as unavailable (a feature ).
If this is by design, then it’s a bad design. By their nature, battery-powered sensors go to sleep to conserve battery. This “design” would have me be available to see values when the sensors wake up, or create work-around code to make for this deficiency. Values should be sticky in HA until updated or user-defined timeout for no contact after which be marked as overdue. This is the obvious, intuitive solution.
I’m seeing this right now for a sensor that wakes up once an hour
This and details explained lower in that thread is the only workaround that keeps my deep sleep devices always showing ‘available’ with latest values.
I have increased the DisconnectRequest in the API code from 10 to 500 (=ms) as explained there.
While switching the device over to MQTT I accidently commented out the AP code instead of the API code in the device’s configuration file. Strangely it was working with both MQTT and API enabled in the yaml file and it was not showing “unavailable” in HA anymore. I thought I had it running under MQTT but it was not. I removed MQTT from the yaml file and left AP disabled, so now it is working with the HA API and not showing unavailable. So it appears, by what I’m seeing, that this unavailable condition during deep sleep had been removed.