ESPHome - Sensor value is shown as Unavailable after several minutes of deep sleep #98221
Assignees
Labels
Comments
|
Hey there @OttoWinter, @jesserockz, @bdraco, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) esphome documentation |
|
Please provide diagnostics and debug logs The investigation is going to be the same as #97761 |
|
Thanks for your fast reply! here are the logs: and the yaml esphome:
name: "umgebungssensor-wohnzimmer"
friendly_name: Umgebungssensor Wohnzimmer
esp8266:
board: esp01_1m
# Enable logging
logger:
level: DEBUG
# Enable Home Assistant API
api:
encryption:
key: …
ota:
password: …
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Test Fallback Hotspot"
password: "GYrvOg0hpAtq"
captive_portal:
deep_sleep:
run_duration: 15s
sleep_duration: 5min
i2c:
sda: 4
scl: 5
scan: false
id: bus_a
# Example configuration entry
sensor:
- platform: sht3xd
temperature:
name: "Temperatur"
humidity:
name: "Luftfeuchtigkeit"
address: 0x45
update_interval: 300s
- platform: adc
device_class: battery
pin: A0
name: "Batterie"
update_interval: 300s
filters:
- multiply: 100
unit_of_measurement: "%" |
|
Thats good as the device is sending the disconnect request so it definitely should still be available |
|
I am attaching logs - the issue is with carvoltage-esp device: |
This one is a problem with the device itself. Its not cleanly disconnecting like fellnerse's device. With this device it just stops talking to Home Assistant so it has no way of knowing what happened. Its expected to go unavailable when it doesn't announce to Home Assistant its about to disconnect and go to sleep
|
|
Maybe it has to do with weak wifi signal and the device enters deep sleep too early. Should not it wait for confirmation that communication with HA is completed before deep sleep ? |
Thats a good question, but not for the core repo. Please continue at https://github.com/esphome/issues/issues/new/choose |
|
As you suggested I also opened the issue for EspHome |
Thanks for that quick reply, but the dashboard still shows unknown state. Do you have an idea how to track the issue down? Or how to debug it? Here is how it looks like in the dashboard: 
|
We need to know if its the same issue as esphome/issues#4794 and its not disconnecting cleanly only sometimes, and disconnecting cleanly some other times. Can you provide a few more hours of logs? If everything is always cleanly disconnecting than there is a different issue. At that point I'll try to build something with your exact config since I can't replicate the issue with all of my sleepy devices (but they all do have good wifi signal) |
|
I have now a log for like a day I think. |
|
It looks like you partially have the same issue as esphome/issues#4794 as there is an unexpected disconnect, but the rest of the disconnects are expected which should keep it available. My deep sleeps are esp32s so that might be the difference on the esphome side. |
20 tasks
|
I made the tests a bit more robust in #98535 I can't find a bug in the code so I'll have to find some time to build a test device matching your config. That might take a while though as I need to order the hardware |
|
That is really some dedication. Let me know when I can help you in any way, would also be open in working on this fixOn 16. Aug 2023, at 17:33, J. Nick Koston ***@***.***> wrote:
I made the tests a bit more robust in #98535
I can't find a bug in the code so I'll have to find some time to build a test device matching your config.
That might take a while though as I need to order the hardware
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
|
I found an old chip in the shed and flashed it. So far the battery stays available. I don't have anything to connect it to monitor the temp though. Is it just the temp sensor thats going unavailable, or is the battery as well? 
|
I added some debug logging Its definitely going to sleep and keeping the battery state available |
|
Mhm for us it’s the same for all Sensor values. What did you use for visualisation? What might be relevant: we had to solder rst and d0 togetherOn 16. Aug 2023, at 18:22, J. Nick Koston ***@***.***> wrote:
2023-08-16 11:00:02.261 WARNING (MainThread) [homeassistant.components.esphome.entity] sensor.umgebungssensor_wohnzimmer_temperatur: _entry_data_available: True has_deep_sleep: True expected_disconnect: True
2023-08-16 11:00:02.284 WARNING (MainThread) [homeassistant.components.esphome.entity] sensor.umgebungssensor_wohnzimmer_luftfeuchtigkeit: _entry_data_available: True has_deep_sleep: True expected_disconnect: True
2023-08-16 11:00:02.316 WARNING (MainThread) [homeassistant.components.esphome.entity] sensor.umgebungssensor_wohnzimmer_batterie: _entry_data_available: True has_deep_sleep: True expected_disconnect: True
2023-08-16 11:00:14.036 INFO (MainThread) [aioesphomeapi.reconnect_logic] Processing expected disconnect from ESPHome API for umgebungssensor-wohnzimmer @ 192.168.214.250
2023-08-16 11:00:14.036 WARNING (MainThread) [homeassistant.components.esphome.entity] sensor.umgebungssensor_wohnzimmer_temperatur: _entry_data_available: False has_deep_sleep: True expected_disconnect: True
2023-08-16 11:00:14.038 WARNING (MainThread) [homeassistant.components.esphome.entity] sensor.umgebungssensor_wohnzimmer_luftfeuchtigkeit: _entry_data_available: False has_deep_sleep: True expected_disconnect: True
2023-08-16 11:00:14.039 WARNING (MainThread) [homeassistant.components.esphome.entity] sensor.umgebungssensor_wohnzimmer_batterie: _entry_data_available: False has_deep_sleep: True expected_disconnect: True
I added some debug logging
Its definitely going to sleep and keeping the battery state available
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
I clicked on the battery to see the more info: 
|
|
That’s how it looks from my side:
how can I run your debug build? |
|
Ok I think I found the issue: I was tinkering with the setup to make the battery last longer and changed the config.yaml to this: esphome:
name: "umgebungssensor-wohnzimmer"
friendly_name: Umgebungssensor Wohnzimmer
esp8266:
board: esp01_1m
# Enable logging
logger:
#baud_rate: 0
#level: NONE
# Enable Home Assistant API
api:
encryption:
key: ""
ota:
password: ""
wifi:
#power_save_mode: LIGHT
#fast_connect: true
networks:
- ssid: !secret wifi_ssid
password: !secret wifi_password
manual_ip:
static_ip: 192.168.178.202
gateway: 192.168.178.1
subnet: 255.255.255.0
dns1: 192.168.178.1
deep_sleep:
run_duration: 15s
sleep_duration: 10min
i2c:
sda: 4
scl: 5
scan: false
id: bus_a
# Example configuration entry
sensor:
- platform: sht3xd
temperature:
name: "Temperatur"
humidity:
name: "Luftfeuchtigkeit"
address: 0x45
update_interval: 300s
- platform: adc
device_class: battery
pin: A0
name: "Batterie"
update_interval: 300s
filters:
- multiply: 100
unit_of_measurement: "%"So the difference is mostly the wifi, it should connect faster. And now I notices this in the logs: The lines: |
|
When I tested yesterday, I put in my wifi network and didn't include I'll give it a try with |
|
Everything still ok with |
|
Same issue here (I guess) since 2023.8.1 on D1 mini + bme280. |
|
I confirm that when my device disconnects correctly from HA api then the value does not disappear from HomeAssistant and it works as expected. It looks like the issue is only connected with esphome firmware exactly as @bdraco pointed out. |
What does that mean? |
|
It means that at least in my case I originally created the issue the problem does not exist in home-assistant/core but in esphome itself. However it is still possible there is a problem in your particular scenario. |
|
Same issue here since HA core 2023.7.1. Everything worked perfectly fine before this update. Have been doing all ESPHome firmware and HA updates since but problem is still the same. |
|
I created a simple test node with template sensor as a counter and observed the same issue. The value in HA is unavailable most of time.
Logs: This device has excellent wifi signal and it looks like it disconnects from api gracefully.
|
|
Does it make a difference if you turn off noise encryption? |
|
found this issue but I don't think its the cause esphome/aioesphomeapi#538 |
|
FWIW, I can't replicate the issue with the above config 
|
|
Also tried to 2023.8.2 just to be sure it wasn't the esphome version |
|
The connection logic is a lot faster in newer versions. Maybe the cooldown isn't long enough now |
bdraco
added a commit
to esphome/aioesphomeapi
that referenced
this issue
Sep 5, 2023
bdraco
added a commit
to esphome/aioesphomeapi
that referenced
this issue
Sep 5, 2023
Since the connect logic is much faster now we might be reconnecting before the device goes into deep sleep after an expected disconnect. Increase the expected disconnect cooldown from 3.0s to 5.0s related issue home-assistant/core#98221
bdraco
added a commit
that referenced
this issue
Sep 6, 2023
changelog: esphome/aioesphomeapi@v16.0.4...v16.0.5 fixes `RuntimeError: set changed size during iteration` esphome/aioesphomeapi#538 some added debug logging which may help with #98221
bdraco
added a commit
that referenced
this issue
Sep 6, 2023
changelog: esphome/aioesphomeapi@v16.0.4...v16.0.5 fixes `RuntimeError: set changed size during iteration` esphome/aioesphomeapi#538 some added debug logging which may help with #98221
bramkragten
pushed a commit
that referenced
this issue
Sep 6, 2023
changelog: esphome/aioesphomeapi@v16.0.4...v16.0.5 fixes `RuntimeError: set changed size during iteration` esphome/aioesphomeapi#538 some added debug logging which may help with #98221
|
@bdraco I have just installed the most recent home assistant 2023.08.3 and esp-test device started working correctly.
I do not know if there were any changes between last versions which could improve the situation or something different helped (for example I removed this device and added again). |
|
I increased the cooldown time in the library. It was a bit of a guess that HA would reconnect before the device could finish going into deep sleep and than get disconnected uncleanly as it shutdown. |
teharris1
pushed a commit
to teharris1/home-assistant
that referenced
this issue
Sep 7, 2023
changelog: esphome/aioesphomeapi@v16.0.4...v16.0.5 fixes `RuntimeError: set changed size during iteration` esphome/aioesphomeapi#538 some added debug logging which may help with home-assistant#98221
|
Thanks @bdraco for quick fixes and your help! Home Assistant and ESPHome are amazing thanks to people like you. Thinking about the issue I am still a bit worried that the problem will re-appear in the future as this timeout is strictly empirical. It's worth of thinking about more reliable mechanism based on some information exchanged from a device during disconnect process or maybe for doing this configurable per device. |
|
It would be better if the device told us how long it was going to sleep for and we set the cooldown to that value, but thats probably a feature request for the esphome repo |
|
I'm glad its working for you now. I'm going to close this issue as any future work should to be done in ESPHome itself and not Home Assistant. Please continue in esphome/issues#4794 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This issue is waiting for the following issue to be resolved
esphome/issues#4794
The problem
I have a node (ESP8266) which reports a voltage value (adc sensor) and then goes into deep sleep for about 1h, and again...
When I added such a sensor to dashboards its value is presented as Unavailable after a few minutes when the node is asleep.
Version of esphome at the node: 2023.7.1
What version of Home Assistant Core has the issue?
2023.8.1
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
esphome
Link to integration documentation on our website
https://www.home-assistant.io/integrations/esphome/
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: