Conversation
The attribute cache restore in load() cleared every quirked cluster's cache before replaying persisted rows, erasing unsupported-attribute declarations made by the active quirk. A stale SUCCESS row for such an attribute then restored the value and the row kept being re-persisted. Clear only the cached values (keep the declared unsupported marks) and skip restoring SUCCESS rows for attributes the cluster has declared unsupported, so stale rows can be rewritten as unsupported instead of resurrecting the attribute. Fixes zigpy#1875.
Quirk cluster replacement copies the restored cache onto a newly instantiated cluster, which discarded unsupported-attribute declarations made in the replacement's __init__. Union those marks into the clone so a stale SUCCESS row cannot resurrect the attribute on restore.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #1887 +/- ##
=======================================
Coverage 99.50% 99.50%
=======================================
Files 59 59
Lines 12415 12418 +3
=======================================
+ Hits 12353 12356 +3
Misses 62 62 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This is a bit of a tricky case. I think calling This isn't a common pattern. I think the better approach would be to use |
|
Pushed 70e5357 for the ruff-format failure. On The zigpy-level bug looks separate from entity creation. So the question is whether zigpy wants |
2 participants
Restoring the attribute cache from
zigbee.dbclears unsupported-attribute marks that a quirkdeclared. The quirk knows the device does not support an attribute, and a stale cached value from
before the quirk applied overwrites that knowledge, so zigpy resumes polling an attribute the device
will never answer.
The database is a record of what was read previously. A quirk is a statement about the device itself,
so where the two disagree the quirk is the better authority: the cached value is evidence the
attribute was readable under a different set of assumptions.
zigpy/appdb.pynow leaves an attribute alone during restore when the cluster already marks itunsupported, and
zigpy/zcl/helpers.pycarries the supporting change. Attributes with no such markrestore exactly as before, so the cache still does its job for everything the quirk says nothing
about.
The test builds a quirked cluster declaring an attribute unsupported, seeds the DB with a stale value
for it, and asserts the mark survives the restore.
Fixes #1875