-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement external state restoration #58
Implement external state restoration #58
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #58 +/- ##
==========================================
+ Coverage 95.00% 95.25% +0.25%
==========================================
Files 61 61
Lines 9306 9335 +29
==========================================
+ Hits 8841 8892 +51
+ Misses 465 443 -22 ☔ View full report in Codecov by Sentry. |
This reverts commit 7ef8ba3.
I've foregone using the ZCL cache and instead just implement |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also looks good IMO
A few platforms in ZHA uses instance attributes and complex logic to derive their state, relying on Home Assistant to persist it and restore it after startup:
light
andcover
) for Home Assistant to store this information as extra state attributes, allowing it to be restore properly. I believe this was actually a bug in the past.binary_sensor
andlock
. These effectively perform operations that change a ZCL attribute so the attribute cache can be used to maintain state.state
from other information and unfortunately will have to be directly restored (siren
).In the future, we need to explore a way to store this extra state. I think zigpy can provide a hook. Alternatively, we can invert the storage logic and have ZHA implement a database driver for zigpy.