Bump zha-quirks from 2.1.1 to 2.2.0 - #853
Conversation
Bumps [zha-quirks](https://github.com/zigpy/zha-device-handlers) from 2.1.1 to 2.2.0. - [Release notes](https://github.com/zigpy/zha-device-handlers/releases) - [Commits](zigpy/zha-device-handlers@2.1.1...2.2.0) --- updated-dependencies: - dependency-name: zha-quirks dependency-version: 2.2.0 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
@zigpy-review-bot Push regenerated diagnostics. EDIT: Ignore, you were too slow, so I did it. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #853 +/- ##
=======================================
Coverage 97.26% 97.26%
=======================================
Files 55 55
Lines 10906 10906
=======================================
Hits 10608 10608
Misses 298 298 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
These diagnostics changes are expected, I think. Some devices were missing a few entities but once #802 is merged, the ZHA ones will be fully replaced by quirks v2 entities in diagnostics. (ZHA entities take priority when unique ID "conflicts")
| "attributes": [ | ||
| { | ||
| "id": "0x0002", | ||
| "name": "off_to_on_delay", | ||
| "zcl_type": "uint16", | ||
| "unsupported": true | ||
| }, | ||
| { | ||
| "id": "0x0001", | ||
| "name": "on_to_off_delay", | ||
| "zcl_type": "uint16", | ||
| "unsupported": true | ||
| }, | ||
| { | ||
| "id": "0x0000", | ||
| "name": "reset_summation_delivered", | ||
| "zcl_type": "uint8", | ||
| "unsupported": true | ||
| } | ||
| ] | ||
| "attributes": [] | ||
| } |
There was a problem hiding this comment.
Hmm, I think this is just either because the attributes were renamed (shouldn't be?) or because of the manufacturer code changes..? Related PR:
@zigpy-review-bot Explain (check how diagnostics import + regeneration works).
Also check what happened to the previous run where I asked you to regenerate diagnostics. Why was it so slow and why did it never respond (because I edited comment to say "ignore")?
There was a problem hiding this comment.
Short version: mechanically it's the rename. The manufacturer code change is why those three attributes were marked unsupported in the first place, but it plays no part in them disappearing from the snapshot.
Why they disappeared
zigpy_device_from_device_data in tests/common.py resolves each snapshot attribute by name first (deliberately — the comment says "Look up by name to avoid ambiguity with manufacturer-specific attrs"), and gives up when the name doesn't resolve:
if attr_name is not None:
attr_def = real_cluster.find_attribute(attr_name)
...
if attr_def is None or attr_def.id != attrid:
if attr.get("value", None) is not None:
real_cluster._attr_cache.set_legacy_value(attrid, attr["value"])
real_cluster.PLUGGED_ATTR_READS[attrid] = attr["value"]
continuezha-quirks 2.2.0 renamed reset_summation_delivered / on_to_off_delay / off_to_on_delay to reset_total_energy / countdown_to_turn_off / countdown_to_turn_on, and moved 3RSP02064Z off the 3RSP02028BZ builder onto the new ThirdRealityPlugClusterGen3 (hence the quirk_class change in the same diff). So find_attribute("off_to_on_delay") raises KeyError, attr_def is None, and the entry is skipped. Those entries carried only unsupported: true and no value, so nothing is restored at all — and on the way back out get_cluster_attr_data skips every attribute that has neither a cached value nor an unsupported flag (zha/zigbee/device.py:126), leaving "attributes": [].
The attribute ids are unchanged — 0x0000/0x0001/0x0002 all still resolve on the new cluster — and the manufacturer code never enters the lookup at all. The name is the entire cause.
Verification (isolated worktree on dev @ a2705409, zha-quirks 2.2.0)
Lookups the importer performs against ThirdRealityPlugClusterGen3:
find_attribute('off_to_on_delay') -> KeyError => attr_def=None => `continue`
find_attribute('on_to_off_delay') -> KeyError => attr_def=None => `continue`
find_attribute('reset_summation_delivered')-> KeyError => attr_def=None => `continue`
find_attribute(0x0000) -> reset_total_energy (mfg=5127)
find_attribute(0x0001) -> countdown_to_turn_off (mfg=5127)
find_attribute(0x0002) -> countdown_to_turn_on (mfg=5127)
Full import + regen round-trip on the pre-bump snapshot (2772871), plus a counterfactual where only the three names are updated:
A) old snapshot as-is -> "attributes": []
B) same snapshot, names updated to 2.2.0 -> all three preserved, still "unsupported": true
C) old name carrying a value (42) -> "attributes": []
B is the decisive one: nothing but the names differs, and the flags survive. C shows the loss isn't limited to unsupported markers — a renamed attribute that had a cached value also vanishes from the regenerated file. It's kept as an id-keyed legacy cache entry, but get_cluster_attr_data iterates cluster.attributes and reads by name, so it never comes back out.
Is the empty list wrong?
For this device I'd say the end state is right, by luck rather than design. The device's real manufacturer code is 0x1407 (manufacturer_code: 5127, same in the node descriptor), and 2.1.1 framed those ff03 attributes with 0x1233 — which is presumably exactly why the real device answered UNSUPPORTED_ATTRIBUTE and why the flags were in the fixture at all. zigpy/zha-device-handlers#5024 corrected the code to 0x1407 for the gen3 plugs, so carrying the old flags across the rename would have wrongly marked the newly-correct attributes as unsupported.
What's genuinely lossy is the mechanism, not this instance: any quirk attribute rename silently drops unsupported markers and cached values from the affected snapshots, with no warning on either side. Entity unique_ids are unaffected here only because #5024 pinned unique_id_suffix to the old names — the diff confirms it (-1-reset_summation_delivered etc. unchanged while translation_key/fallback_name moved).
How import and regeneration actually work
Import — python -m tools.import_diagnostics <ha-diagnostics.json>: builds a fake zigpy device from a real HA "Download diagnostics" file, gives it a deterministic fake IEEE (sha256(manufacturer + model)), joins it to a test gateway, and serializes zha_device.get_diagnostics_json(). It then does a round-trip check — re-join the device from the serialized form and compare — and refuses the import if the two differ ("quirk has modified the device signature"). The filename is slugify(manufacturer-model-fwversion).json, which is where the -0x0000002f suffix comes from.
Regeneration — python -m tools.regenerate_diagnostics: for every file under tests/data/devices/, rebuild the fake device from that file, resolve the quirk against the currently installed zha-quirks, join it, and write get_diagnostics_json() back over the same path.
That last part is the reason this class of change is invisible: each file is both the input and the output. Anything the importer can't resolve is dropped on the way in and simply never written on the way out — and the idempotence check that would have caught it only runs at import time, against whatever quirks version was installed back then.
There was a problem hiding this comment.
Ah, I forgot Third Reality has different manufacturer codes for similar devices. So the unsupported thing makes sense then and it's correct the (incorrect) attribute values were dropped from diagnostics, I guess. All good 😄
There was a problem hiding this comment.
@zigpy-review-bot If it makes sense to fix, open an issue about the diagnostics thing with "enhancement" label.
3 participants
Bumps zha-quirks from 2.1.1 to 2.2.0.
Release notes
Sourced from zha-quirks's releases.
Commits
b139f81Add mmWave area commands and reports for Inovelli VZM32-SN (#4944)d657eb0Add entities for Inovelli VZM32-SN mmWave dimmer (#5014)4fd035ePort Inovelli VZM entities from ZHA to quirks v2 (#5122)4cf1dd4Fix Sonoff S60 plug v2.0.3 not updating voltage when off (#5092)5b241c3Remove entities for Tuya MG-ZJQ100 USB-C Zigbee repeater (#5019)91722adAdd LED brightness, power thresholds and metering-only mode to Third Reality ...ec2091eDrop auto-registration compat for unregistered v2 quirks (#5217)2967595Parse manufacturer-framed metering reports on Innr SP 120 plug (#5082)7c0b51eImprove battery calculation for frient/Develco Humidity Sensors (HMSZB-110/12...e3362afFix Tuya IR blaster TS1201 learn state at class level (#5210)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)