ts0601_energy_meter quirk for Tuya power meter devices (v2 quirk)

[jeverley]

Proposed change

Adds support for Tuya Energy Meter devices.

Reimplementation of my original PR #2961 using the v2 Tuya quirk builder.

Uses zigbee2Mqtt https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/devices/tuya.ts as reference for device datapoints (with amendments from community testing in the respective device support issues).

Meter devices providing energy direction will report signed values for their ZCL mapped attributes in accordance with the Zigbee cluster spec (instantaneous demand, active power and reactive power specifically).

To keep the change size manageable this initial PR will not calculate additional power metrics that are not reported by the device (reactive power etc), I can explore re-introducing this if users are keen for the functionality.

Device configuration entities

• Virtual channel: choose the calculation on 2 clamp devices for calculating the virtual value.
  • Total
  • A minus B
  • B minus A
• Calibration: adjust reported values by a percentage (_TZE204_81yrt3lo).
• Energy direction delay mitigation: this controls whether the quirk will compensate for delayed direction data point reporting (_TZE204_81yrt3lo).
  • Automatic (enabled based on device and firmware version)
  • Disabled (values reported immediately)
  • Enabled (value updates are delayed until the next direction is reported).

Supports 1 clamp devices:

• _TZE204_ac0fhfiq
  • [Device Support Request] _TZE204_ac0fhfiq TS0601 BiDirectional ZigBee Energy Meter with 150A Clamp Current Sensor #2420
    Prerequisite PR Add support for Tuya DPs mapped to multiple cluster attributes #3643
• _TZE204_cjbofhxw, _TZE284_cjbofhxw
  • [Device Support Request] TUYA DIN ENERGY METERING #1973
  • [Device Support Request] TS0601_TZE284_cjbofhxw PJ-1203 clamp power meter #3152

Supports 2 clamp devices:

• _TZE204_81yrt3lo, _TZE284_81yrt3lo
  • [Device Support Request] _TZE204_81yrt3lo TS0601 Zigbee power meter with clamp #2549
• _TZE200_rks0sgb7
  • [Device Support Request] PC311-Z-TY Single-Phase Power Clamp Zigbee model 'TS0601' and manufacturer name '_TZE200_rks0sgb7 #2650

Supports 3 clamp devices:

• _TZE200_nslr42tt
  • [Device Support Request] TS0601 PC321-TY 3-phase Clamp Power Meter #1954
• _TZE204_v9hkz2yn, _TZE200_v9hkz2yn

Additional information

• Users of the original draft v1 quirk will need to remove and re-add devices to remove redundant entities.
• Prerequisite pull requests:
  • Add support for Tuya DPs mapped to multiple cluster attributes #3643
  • Remove unnecessary unit validation zha#352
  • Corrections to ElectricalMeasurement attribute type masks zigpy#1542
  • Allow custom v2 quirks to override built-in ones zigpy#1534

Checklist

• The changes are tested and work correctly
• pre-commit checks pass / the code has been formatted using Black
• Tests have been added to verify that the new code works

[codecov]

Codecov Report

Attention: Patch coverage is 90.90909% with 19 lines in your changes missing coverage. Please review.

Project coverage is 90.91%. Comparing base (ab4e4f5) to head (a6a0eda).
Report is 14 commits behind head on dev.

Files with missing lines	Patch %	Lines
zhaquirks/tuya/ts0601_energy_meter.py	90.90%	19 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##              dev    #3824    +/-   ##
========================================
  Coverage   90.91%   90.91%            
========================================
  Files         324      326     +2     
  Lines       10562    10775   +213     
========================================
+ Hits         9602     9796   +194     
- Misses        960      979    +19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jeverley]

This should be ready for testing once #3643 is merged.

[wolsty7]

It might be worth adding support for "_TZE284_81yrt3lo" #3658 (comment)

[jeverley]

I'm going to split this into two separate PRs and files to make it easier to review and add devices moving forward.
One for devices that require the direction attribute logic (e.g. *_81yrt3lo) and those that don't.

[jeverley]

Hi @TheJulianJES, I'll be looking at progressing support for these devices again next week, but before I do I would much appreciate your opinion on how best to implement these.

So far I've taken the approach of using common Metering/Electrical measurement clusters that handle logic for applying the positive/negative sign to power values (amongst other things) - similar to the draft v1 quirk I'd made last year.

I'm mindful however that with v2 quirks I could instead take the approach of using custom sensor entities - this would allow us to specify a suffix for entity names (i.e. 1/2, or A/B) useful as these devices often have multiple clamps for measuring energy on different circuits.

Also, would you prefer if I broke this out into a PR per device? I don't want to be causing reviewers headaches.

Many thanks, Jack

[ouafnico]

Any idea when zha will works with this devices ?

[jaromanda]

FYI, there's a _TZE284_ac0fhfiq which seems to work identically as _TZE204_ac0fhfiq - support was just added in zigbee2mqtt dev branch, I can confirm that it is functional in Z2M Edge

[jaromanda]

Any progress on this?

[gillenoarbe]

Hi @jeverley , thanks for the quirk and the long history with this device.

I've been struggling with this device for air conditioning power consumption monitoring to get the data right... With your quirk, main DP seem to be exposed and working (including W and VA power, voltage and frequency.

The problem I am finding is that there is some weird power measurement cap and the deviceisn't capable of measuring (not sure if right or wrong) more than 85W in a >1kW device (measured via external powermeter in the main), idem with 0.5A max of intensity.

Has anyone experienced this? Also the reactive power seems not to work all the time.

Thank you.

[Dwouglaz]

Nada ainda para o TZE204_81yrt3lo?

[epenet]

@jeverley please note that the quirk here did not work for me with a _TZE284_81yrt3lo

After a few interations, and looking at attempts by others to adapt your quick in #3658, I came up with this gist: https://gist.github.com/epenet/39050e3f47f0a8ac4a3aaf526173d5d7 (just for _TZE284_81yrt3lo)

[epenet]

Why is this an enum?
From my testing, it adds confusion on the unique_id as it ends up with a string-formatted enum rather than a simple integer.

[epenet]

I think this should be the unsigned attribute:

Suggested change

	_EXTENSIVE_ATTRIBUTES: tuple[str] = (
	TuyaZBMeteringClusterWithUnit.AttributeDefs.instantaneous_demand.name,
	)
	_EXTENSIVE_ATTRIBUTES: tuple[str] = (
	TuyaZBMeteringClusterWithUnit.AttributeDefs.instantaneous_demand.name
	+ EnergyDirectionHelper.UNSIGNED_ATTR_SUFFIX,
	)

[jaromanda]

Is this progressing or stalled?