andrew-codechimp
Entities unavailable for sleeping devices
System Health details
System Information
| version | core-2024.6.4 |
|---|---|
| installation_type | Home Assistant Container |
| dev | false |
| hassio | false |
| docker | true |
| user | root |
| virtualenv | false |
| python_version | 3.12.2 |
| os_name | Linux |
| os_version | 4.4.302+ |
| arch | x86_64 |
| timezone | Europe/Rome |
| config_dir | /config |
Home Assistant Community Store
| GitHub API | ok |
|---|---|
| GitHub Content | ok |
| GitHub Web | ok |
| GitHub API Calls Remaining | 4989 |
| Installed Version | 1.34.0 |
| Stage | running |
| Available Repositories | 1390 |
| Downloaded Repositories | 22 |
Home Assistant Cloud
| logged_in | false |
|---|---|
| can_reach_cert_server | ok |
| can_reach_cloud_auth | ok |
| can_reach_cloud | ok |
Dashboards
| dashboards | 2 |
|---|---|
| resources | 12 |
| views | 14 |
| mode | storage |
Recorder
| oldest_recorder_run | 19 giugno 2024 alle ore 19:53 |
|---|---|
| current_recorder_run | 28 giugno 2024 alle ore 19:17 |
| estimated_db_size | 972.75 MiB |
| database_engine | sqlite |
| database_version | 3.44.2 |
Spotify
| api_endpoint_reachable | ok |
|---|
Checklist
- [X] I have added
battery_notes:to my configuration.yaml and restarted. - [X] I have read the FAQ's.
- [X] I have enabled debug logging for my installation.
- [X] I have filled out the issue template to the best of my ability.
- [X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
- [X] This issue is not a duplicate issue of any previous issues..
Describe the issue
Some device are not always connected and shows some entities as unavailable:
Should be "restore" entity so to avoid this issue.
Reproduction steps
- install Motion Shelly or any other sleeping device
- configure battery notes
- check all is fine
- wait for device to go sleeping
- recheck entities
Debug logs
No response
Diagnostics dump
No response
Thanks for reporting this. I don't have any devices that sleep but you are correct, Battery+ should restore its state.
The new beta 2.3.12 now has this change, if you are able to validate I'll close this issue.
Feedback from #1843 suggests this isn't fixed unfortunately. Sorry, there is just something odd about the Shelly Door/Window sensor that's not getting it identified as a having a battery. There's little I can do about this without having one to test myself so having to close this as unfixable.
Hi,
The point is that those entities should be restored entity in order to work correctly.
Thank you for considering the code change.
The latest beta does change them to restored entities but doesn't seem to have an effect. It was a worthwhile change and may help with others but doesn't seem to fix the Shelly sensor.
@andrew-codechimp is this problem fixed? I have a similar experience with all of my Shelly TRVs. When they are awake and I add them to HA Battery Notes everything is working as expected. After some time all Battery+ Sensors get unavailable. There is no chance to get them back working except to delete the device and read it. Shall I open another new issue?
I made these entities restore entities so thought they were fixed but if you are running the latest version then that appears not to made a difference.
Unfortunately I don't have any of these devices to be able to test this further so I don't have a way to fix this for these devices.
@andrew-codechimp thanks for the info, even if that is of course a great pity. ;)
I will reopen this issue just as a reminder to myself if I ever get a device to test or more inspiration.
Hi @andrew-codechimp, is there anything I/we can do to help?
Thanks but I think I'll have to read through the Shelly BLE code to see if there's anything odd there I need to handle. I have some BLE devices myself (Xiaomi plant sensors) that do come back so it's not all BLE devices that have the issue.
Okay, well let me/us know if that changes. Happy to help. Actually it’s also not just BLE. I have them on wifi, but same issue 😉
Okay, well let me/us know if that changes. Happy to help. Actually it’s also not just BLE. I have them on wifi, but same issue 😉
Good to know, I'll expand my scope to the whole Shelly integration then.
Just to give some extra info, I have the same issue with my Shelly TRV (WIFI connected). But also with my Shelly Button (Also WIFI connected).
https://www.shelly.com/products/shelly-button1-white
All other battery devices seem to work.
If you need any info let me know.
Hi again,
since weeks, all my battery devices are working fine; with the only exception of the one above:
At each restart it goes unavailable for logon time, more than 10 minutes, then magically it comes back online.
Can you review the code or at least add some more debugging ? Thank you in advance,
Simone
P.S:> I have an automation that list all unavailable entities after 5 minutes of each reboot. This is the way I noticed ;-)
Can you delete the battery note for that device and add it again, I don't think it's tracking that battery properly. If the battery is showing 52% so should Battery+ Is there anything else in Diagnostics for that device?
Can you delete the battery note for that device and add it again, I don't think it's tracking that battery properly. If the battery is showing 52% so should Battery+ Is there anything else in Diagnostics for that device?
It does if:
- I delete and recreate the device in battery note
or
- If I wait a lot of time after restart
@nicx , @confucius78, @Woutch can you config that a reload of the device from Battery Note solves the issue for you as well ?
That's strange, it's like the integration is not broadcasting its initial setting of the value. Do you have more than one Shelly Motion 2 (SHMOS-02) and are the others working ok?
That's strange, it's like the integration is not broadcasting its initial setting of the value.
Can we add a few debug lines to better understand what happens (and why) ?
Do you have more than one Shelly Motion 2 (SHMOS-02) and are the others working ok?
Nope, is the only one of this kind.
I'll have a look at the code and see what I can add but I don't think it does too much from memory. If it receives a numeric value from the listener it will set it.
I also started using this integration just now and noticed that for a device of mine (Shelly H&T) the battery+ sensor is not created at all. For all other battery devices (shelly and non shelly) all is fine but for this specific device no battery+ is even created. I'm not sure this is the very same issue but I suspect it is. The percentage sensor included in the device seems ok:
I also started using this integration just now and noticed that for a device of mine (Shelly H&T) the battery+ sensor is not created at all. For all other battery devices (shelly and non shelly) all is fine but for this specific device no battery+ is even created. I'm not sure this is the very same issue but I suspect it is. The percentage sensor included in the device seems ok:
Hi, this is a different issue, try removing the battery note, then the Shelly H&T from the Shelly integration, re-add the Shelly, then add the battery note.
I've seen it twice before, I think there was an issue some time ago with the Shelly integration where the battery entity wasn't created quite right.
Finally back to this issue ;-)
Added a few log lines to help understand what's up:
Just to make you aware I'll be releasing a new version this week so you might have to re apply your logging. Big refactor and modernising but sensor.py shouldn't have changed too much to stop you. The code was merged today into main so if you want to manually grab that you can or wait for the release.
Thx a lot for the feedback. Do you mind adding some logging at debug level ? So we can identify easily all devices that have an issue and possibly why.
I'll see if I can add what you have there quickly before the next release. Would you mind linking to a gist of what you have in that image to allow me to copy/adapt.
Version 2.10.8 just released has this extra logging in it, without these types of sensors to test it's hard to work out what's going on but hopefully the logging may glean something.
Hi Andrew, thx so much for your help.
I hope to come back to you with more details about the issue in the next days, if still reproducible.