Convert the ZLinky_TIC quirk to v2 and add manufacturer-specific metering attribute definitions - #4730
Convert the ZLinky_TIC quirk to v2 and add manufacturer-specific metering attribute definitions#4730aauzi wants to merge 7 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #4730 +/- ##
==========================================
- Coverage 92.60% 92.59% -0.01%
==========================================
Files 424 424
Lines 14667 14652 -15
==========================================
- Hits 13582 13567 -15
Misses 1085 1085 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| # Standard mode: EAIT "Energie active injectée totale" (Production) / Int48 9 car | ||
| # Overwrite: current_summ_received | ||
| current_summ_received: Final = ZCLAttributeDef( | ||
| id=0x0001, type=t.uint48_t, manufacturer_code=0x1037 | ||
| ) | ||
|
|
||
| # Standard mode: PTEC "Période tarifaire en cours" / String 4 car | ||
| # Overwrite: active_register_tier_delivered | ||
| active_register_tier_delivered: Final = ZCLAttributeDef( | ||
| id=0x0020, type=t.LimitedCharString(4), manufacturer_code=0x1037 | ||
| ) |
There was a problem hiding this comment.
These overlap with existing ZCL definitions, right? Can we avoid that and give them another name?
What value is present on the ZCL definitions compared to these?
It might make sense to add quirks v2 entities for this quirk to read the values. I think both the debug UI and ZHA toolkit currently still have some issues with overlapping attribute IDs.
There was a problem hiding this comment.
I agree with the idea of renaming and actually gave it a try without changing the whole quirks into a V2 quirk.
The point is: I get an error if I keep the ZCL attribute definitions unchanged.
The following change though gives good results with both the debug UI and the zha-toolkit scripts.
# Standard mode: EAIT "Energie active injectée totale" (Production) / Int48 9 car
# Overwrite: current_summ_received
# ZCL definition (zigpy-2.0.0)
# current_summ_received: Final = ZCLAttributeDef(
# id=0x0001, type=t.uint48_t, access="r"
# )
current_summ_received: Final = ZCLAttributeDef(
id=0x0001, type=t.uint48_t, access="r", manufacturer_code=LIXEE_MANUFACTURER_CODE
)
# Rename according the new definition
total_active_energy_injected: Final = ZCLAttributeDef(
id=0x0001, type=t.uint48_t, access="r", manufacturer_code=LIXEE_MANUFACTURER_CODE
)
# Standard mode: PTEC "Période tarifaire en cours" / String 4 car
# Overwrite: active_register_tier_delivered
# ZCL definition (zigpy-2.0.0)
# active_register_tier_delivered: Final = ZCLAttributeDef(
# id=0x0020, type=RegisteredTier, access="r"
# )
active_register_tier_delivered: Final = ZCLAttributeDef(
id=0x0020, type=t.LimitedCharString(4), access="r",
manufacturer_code=0x1037
)
# Rename according the new definition
current_rate_period: Final = ZCLAttributeDef(
id=0x0020, type=t.LimitedCharString(4), access="r",
manufacturer_code=0x1037
)Let me know if this looks better.
There was a problem hiding this comment.
I agree with the idea of renaming and actually gave it a try without changing the whole quirks into a V2 quirk.
@aauzi could an alternative idea maybe be to do what @yoda-jm done in #5245 and Convert the ZLinky_TIC quirk to Quirk v2 by extracting it from #4499 which has already contrins a converted ZLinky_TIC quirk to v2, or? See:
and
The four v1 subclasses matched firmware variants by exact cluster list: the base signature, plus PowerConfiguration on v12, Time and the Tuya cluster on v14, and a different device type on v15. Matching on manufacturer and model covers all of them, so ZLinkyTIC, ZLinkyTICFWV12, ZLinkyTICFWV14 and ZLinkyTICFWV15 collapse into a single QuirkBuilder. PowerConfiguration is added unconditionally, as the v1 replacement already did for every variant. The two ZLinky entries in the test_suspicious_cluster_moves allow list go away with the v1 classes. No functional change intended: same clusters replaced, same entities.
Firmware v14 and later report a Tuya cluster in both directions that the device does not implement. The v1 quirk dropped it by listing it in the FWV14 and FWV15 signatures but not in their replacements, which is what the two ZLinky entries in the test_suspicious_cluster_moves allow list were about. The v2 conversion lost that, so restore it explicitly. RemoveCluster pops with a default, so this is a no-op on firmware that does not report the cluster, and a test now pins the behaviour rather than an allow list entry.
The repository squash-merges, so commit messages do not reach the branch history. Move the parts worth keeping into the code itself: what distinguished the four v1 firmware subclasses and why matching on manufacturer and model replaces them, and why the two ZLinky entries in the test_suspicious_cluster_moves allow list existed, now recorded in the docstring of the test that replaces them. Comments only, no behaviour change.
The test seeded the Tuya cluster as a server cluster only, so the assertion on out_clusters passed whatever the client-side removal did: dropping that .removes() call left the suite green. Parametrizing over both cluster types makes each removal fail on its own. Also pass ClusterType.Server explicitly instead of None. The fixture annotates cluster_ids as dict[int, dict[int, ClusterType]] and None only worked by falling through to the server branch.
6141f8e to
78450f3
Compare
…ZLinkyTIC clusters AttributeDefs Rename ZLinkyTICMetering attributes: * current_summ_received (id=0x0001) => total_active_energy_injected * active_register_tier_delivered (id=0x0020) => current_rate_period
78450f3 to
cdcaa80
Compare
Proposed change
Add AttributeDefs entries to provide 'default' manufacturer_code for zha_toolkit initiated attribute reads.
Additional information
Fixes #4729
Device diagnostics
Please refer to #4729
Checklist
pre-commitchecks pass / the code has been formatted using Black