Home Assistant Entities unavailable while ESP in deep sleep

ESPHome
1

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)

How can I solve this problem?

1 Like
2

This is by design.

How do you want it to behave?

If you want to retain the last known value rather than show unavailable, I’m sure this has been answered many times already (the approach I’ve seen the most involves using helpers).

3

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.

Actually I thought that entities becoming unavailable during sleep is not intended, as there is an issue reported which has been fixed (although not fixed for me):
ESPhome deep sleep sensor values get ‘unavailable’ as soon as api is not connected · Issue #90923 · home-assistant/core (github.com)

I couldn’t find any relating topic here in the community forums.

4

Want to share some more information maybe like esphome version and the yaml you are using for example? :thinking:

Also you can consult this thread on how to ask a good question :point_down:

Actually only for “permanent” connections. Setting deep_sleep on a esphome node should actually retain the values in HA even the times the node is offline.

1 Like
5

Hmm yeah whoops I seem to have gotten myself mixed up on this one…

6

Sure :slight_smile:

I’m on the latest ESPhome 2023.7.1 using this yaml:

esphome:
  name: battery-test
  friendly_name: Battery Test

esp32:
  board: esp32dev
  framework:
    type: arduino

logger:

deep_sleep:
  run_duration: 10s
  sleep_duration: 5min

ota:
  password: "ad195a60b344a1154b8af7e5c28465c3"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: True

api:
  encryption:
    key: "XXXX"

web_server:

sensor:
  - platform: bme680
    temperature:
      name: "Temperatur"
      oversampling: 16x
    pressure:
      name: "Luftdruck"
    humidity:
      name: "Luftfeuchtigkeit"
    gas_resistance:
      name: "Gas Resistance"
    address: 0x77
    update_interval: 60s

i2c:
  sda: 26
  scl: 25
  scan: true
  id: bus_a

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.

7

Looks perfectly fine to me :+1:

This fix (and bug) was actually in HA core. You are also running HA 2023.4.1 or greater I guess?

8

Yes, running HA Core 2023.8.2.

9

Since it solves so many problems; delete integration and add back again? I am shooting from the hip

10

Latest & greatest :muscle:

Last question from me before I send you over to the devs (github/discord) would be: Can you reproduce the behavior on a different device (esp32 and/or esp82xx)? :thinking:

11

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.

2 Likes
12

Good point! Maybe @AndrejDelany could even try to delete the itegration of the troublesome esphome node and add it again to have it fresh as possible :clinking_glasses:

13

Yes, maybe I added deep_sleep after the sensor components. I will try your recommendation, thanks!

14

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.

15

Native api should just work :tm: :muscle:

For mqtt (as always) more time/fiddling is needed to achieve the same - guess you read the docs @mvgrimes?

Last Will And Birth Messages

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 :wink:).

16

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

17

I have same issue with ESPHome, ESP8266 device, deep-sleep on, HA API, getting unavailable in HA when device goes to sleep. Has this behavior been fixed in the HA API or do I still need to use MQTT?

I’m at these versions:

  • Core 2023.11.2
  • Supervisor 2023.11.0
  • Operating System 11.1
  • Frontend 20231030.2
18

Please see Increase expected disconnect cooldown to 5.0 seconds by bdraco · Pull Request #540 · esphome/aioesphomeapi · GitHub

We do keep making the connection logic faster so its possible we need to increase the cooldown again.

Please open an issue with

  • Your YAML configuration
  • Debug logs of what happens when the device goes to sleep from the aioesphomeapi logger
19

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.

20

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.