Keep state of window sensor after restart of the SHC
Closed this issue · 5 comments
Checklist
- I have filled out the template to the best of my ability.
- This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
- This issue is not a duplicate feature request of previous feature requests.
Is your feature request related to a problem? Please describe.
After a restart of the SHC the window sensors always report "unavailable" until triggered again (opened or closed)
Describe the solution you'd like
It would be great if this add-in would keep the state of the last time the sensor was triggered and ignore the "Unavailable" state reported by the SHC.
Describe alternatives you've considered
manually open and close the window when one is wondering why the heating system is not working
Additional context
...
No, I don't want this. If the SHC reports "Unavailable" I want the integration to reflect this. Otherwise, we would never detect problems when a sensor breaks.
If you want this, build an automation in Home Assistant to simulate this behavior.
Would you reconsider this with different mechanisms to detect if something breaks?
E.g.
- a timed delay (say 1 day of staying in'Unavaible' state in the SHC) or
- or two sensors (one with the persisted state and one extra with a diagnostic sensor directly from the SHC)
Apart from this, I think there currently is a bug that does not change the state from 'Unavailable' to something else, because after a reload of the add-on it works.
Maybe „unavailable“ is wrong. We could check if the SHC reports „Unknown“ instead of unavailable if the sensor really does respond but cannot see the current state. I guess in the Livisi UI it reports „?“…
I‘m reopening this to at least investigate the bug you mention.
after the bugfix, it should be ok. The SHC keeps the state of the sensor if restarted via the API.
I did not understand the problem correctly I guess. When adding new window sensors, they are reported as "?" in the Livisi UI, but not after a restart. So this was indeed just a bug - thanks for the fix.