-
Notifications
You must be signed in to change notification settings - Fork 975
Tuya PJ-1203A MatSeePlus Energy Meter (TS0601 _TZE204_81yrt3lo/_TZE284_81yrt3lo) v2 quirk #4498
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
base: dev
Are you sure you want to change the base?
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #4498 +/- ##
==========================================
+ Coverage 92.24% 92.35% +0.11%
==========================================
Files 369 372 +3
Lines 12094 12274 +180
==========================================
+ Hits 11156 11336 +180
Misses 938 938 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Quirk itself validated working in all scenarios with the last commit - will update the validate the tests cases tomorrow prior to making a final commit (haven't got access to my dev container today to automate testing these). |
…o 2 CT Bidirectional Energy Meter - Removed the over-engineered channel logic implemented in previous v2 PR - ElectricalMeasurement and Metering clusters just handle reporting, no calculations - Implements interval based signing logic to ensure the correct energy flow value is used to sign power - Ensures that the calculated total (replacing DP 115 due to a device bug in _TZE204) uses the correct pairing of power values - Allows selective enablement of the late flow report bug mitigation (off by default)
d955c00 to
2dc9886
Compare
…ers missing Codecov line
|
Ready for review, let me know of any issues👍 |
…simplify _process_power_and_energy_flow. No functional change in outcome
…uces code repetition - Improve clarity of comments - Use TuyaEnergyFlow type value for _align_value_with_energy_flow comparision
|
Hi @YarekTyshchenko , if you delete and re-pair the device it should remove the redundant sensors. I simplified a lot of things from that original quirk to make things easier to support and review. Let me know if that resolves things for you, or if you still have issues. |
|
Thanks for checking @YarekTyshchenko , I'll try and replicate the issue you're seeing with the extra sensors remaining this morning. The naming of different sensors should be addressed by zigpy/zha#525 once it is merged (it would number them Power 1, Power 2, Power 3 etc). |
|
Adding additional data point for you in case it's useful. I have seemingly the same device as YarekTyshchenko - labeled "Model PJ-1203A" with a marked measuring range of 0.2-80A. I paired it and it appeared with no entities. I then installed the quirk and hit Reconfigure and got the 1, 2, or 3 of each of the expected sensors. Some of which are reporting numbers and some saying "Unknown".
I then removed the device entirely and added it back and got this: The difference between the two screen shots is that one of each of Current, Power, and Power Factor disappeared. |
…attribute for total value
|
Hi @YarekTyshchenko, @therealcmj thank you both for testing the quirk, I've just pushed 6e44bbb which declares those redundant entities as explicitly unsupported. This should prevent their creation, let me know if this resolves the issue you both had with the previous version. I've also switched to using the I've attached a screenshot below from my local instance.
|
…es on unaffected device versions, move to Diagnostic entity type
… class to address missing line in codecov
|
@jeverley FWIW here's a screen shot after update and remove/re-add If you need any logs or other data please let me know. |
|
Thanks for checking both. @ksihota I'm glad switching the leads fixed the +/- issue on the power readings, that confirms there isn't an issue with the signing logic. I can look at adding toggles for this, though I'm very mindful that we should keep quirk complexity to a minimum (It's taken long enough to add support for this device!). The I'd rather tackle the attribute naming in a standard way (outlined in zigpy/zha#525), you're correct for now that B CT can be identified as the entity IDs with the @therealcmj I note you're using the Would it be possible to share the device debug information with and without the custom quirk loaded? |
|
@jeverley I found that with the TZE204 devices that I have, I could switch the +- by either
I can't remember for sure but I believe that originally when I set them up they only displayed Power and Summation (A, B and Total) and the +- indicated direction. Its been a few years so I don't really recall clearly and I am not sure what custom quirk I used originally to get anything to show. The biggest issue I have is the naming problem (knowing which is A and B) so I originally started renaming myself which can become a nightmare if you don't know what is really happening and you don't think it through. In a few cases I ended up getting the Power A and Energy B instead of AA and BB etc. I do have a couple of questions that are related.
|
|
I agree that quirks should not have to be doing the job of patching poor hardware/software but in the end that is what they do. As a user I would like my hardware to just work but lets face it, that is not going to happen. As a user I want something that will work easily and if it means I have to build a fix that will save me work than that's what I will do. My problem is that I am just barely grasping the concept of how these quirks work and the syntax used to write them. |
I don't think its up to each quirk to provide this. If this is a common scenario, HA itself would allow reversing of sensor values, so that all devices get this functionality.
Of course its possible: Copy the quirk file into your own quirk dir, and edit it to your hearts content. It should override these quirks. You can start by duplicating one of the existing boolean setting switches, renaming it, then wiring it up in the code to reverse the polarity |









Proposed change
Adds support for MatSeePlus PJ-1203A 2 CT clamp Energy Meter.
Addresses Device Support Requests
Simplifies original pull requests
Separated from other Tuya devices to isolate logic handling the late flow reporting behaviour summarised below:
There is a known issue on the _TZE204_81yrt3lo (with appVersion 74, stackVersion 0 and hwVersion 1).
The energy_flow datapoints are (incorrectly) emitted during the next update. This is quite problematic
because that means that the direction can be inverted for up to update_frequency seconds.
More detail in the Zigbee2MQTT tuya.ts device handler
The quirk makes use of common power value signing logic for both device variations (combining power and energy flow DP values), however the mitigation for the late energy flow bug is disabled by default.
This is because it is not required in the
_TZE284device revision (sharing the same data points, but reporting the correct direction in the current interval), nor is it required if the_TZE204device is used to measure power that always flows in the same direction.Sensor Entities
Electrical Measurement
Metering
Configuration Entities
Diagnostic Entities
Additional information
Checklist
pre-commitchecks pass / the code has been formatted using Black