-
Notifications
You must be signed in to change notification settings - Fork 687
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
Add Tuya cover _TZE200_eevqq1uv
#3114
base: dev
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #3114 +/- ##
==========================================
+ Coverage 89.44% 89.58% +0.13%
==========================================
Files 311 311
Lines 10031 10136 +105
==========================================
+ Hits 8972 9080 +108
+ Misses 1059 1056 -3 ☔ View full report in Codecov by Sentry. |
zhaquirks/tuya/mcu/__init__.py
Outdated
attributes = WindowCovering.attributes.copy() | ||
# cover direction and lift percent control attributes are not very useful to HA, but needed to | ||
# allow TuyaMCUCluster to map to the data point. | ||
attributes.update({ATTR_COVER_DIRECTION: (ATTR_COVER_DIRECTION_NAME, t.enum8)}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised I need a new attribute to track motor status (i.e. opening, closing, stopped) but I couldn't find anything in the standard zigbee WindowCovering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job, especially on the test coverage!
I'll have a closer look at this soon.
zhaquirks/tuya/mcu/__init__.py
Outdated
def __init__(self, *args, **kwargs): | ||
"""Init.""" | ||
super().__init__(*args, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Although it's a bit awkward if the DPToAttributeMapping converter needs to refer to self. I worked around it by instead using data_point_handlers, which finds a function by name and will call an instance method.
Thanks @TheJulianJES. Since raising the PR I've figured out some more tuya data points, and I've started changing it to use the quirks v2 registration. If you'd prefer to wait a few days it might be easier to review it all at once? |
Yep, feel free to change the PR. Btw., if you're exposing custom entities to ZHA via quirks v2, the translation keys are added with the "quirks bump PR" in HA. Just let me know what translation keys I should add to the file when bumping quirks then. (only applicable if you're using custom entities) |
I tested with _TZE200_68nvbio9 and it works great! I propose to add _TZE200_68nvbio9 here |
@TheJulianJES , this PR is now ready for review again. It turned out to be much bigger than I expected, including some refactoring and a new base class. I'm happy for feedback to adjust the design, but thought it best to publish a proof of concept to show you. The new base class (TuyaCommandCluster) is used to provide generic processing of zigbee commands into tuya set_data commands, without needing to define cluster attributes for tuya data points that don't have sensible values to show. It does this similar to how TuyaMCUCluster maps cluster attributes to tuya set_data commands with dp_to_attribute. |
entity_type=EntityType.STANDARD, | ||
translation_key="small_step_open", | ||
).command_button( | ||
WINDOW_COVER_COMMAND_SMALL_STEP_NAME, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these command definitions are correct, but they currently cause an error 'Platform zha does not generate unique IDs'
I think that's because the zha component uses the command id to generate an unique id, but does not expect multiple instances of the same command or take the command parameters into account. I've created a proof of concept change to zha matt-sullivan/home-assistant-core@e7bdec2 that works by adding a simple index to each unique id.
I'm not sure if that's a good way to do it. Maybe the quirk should specify an id, or zha should include the translation_key in the id?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh, good that you noticed this!
There may be some bigger ZHA refactor changes coming soon. Hoping I don't forget about this, so this can be addressed soon-ish.
entity_type=EntityType.STANDARD, | ||
translation_key="small_step_open", | ||
).command_button( | ||
WINDOW_COVER_COMMAND_SMALL_STEP_NAME, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These command definitions create HA entities with ids like button.[device name]none[int]. I.e. there doesn't seem to be any sensible naming applied to the entity. is that expected behaviour, or something wrong with these definitions?
It's not really a problem, but feels like it could be better. Could the zha component use the translation key, command name, or another parameter to set the entity id?
@TheJulianJES, I created a zha commit with the translation keys this needs: matt-sullivan/home-assistant-core@1dff881 |
Hi @TheJulianJES, I'm sure you're busy, but could you please review and approve or provide feedback on this PR soon? |
I know it's been a long time. I've still not forgotten about this time, sorry that I couldn't get to it yet. |
Thanks @TheJulianJES. If you plan to look at it soon I can update it for those quirks v2 changes you mentioned. Please let me know if there's anything else I can do to make it easier to review. At one stage I had implemented mostly in one new class/quirk, but I gradually understood how to re-use and share more of the existing Tuya code. If there's anything about the design you're not happy with I'm happy to change it. I think it's low risk to existing Tuya covers - most of the changes are either new code or simple renaming of existing variables and methods. At least one person tested an early version of this, but I'm not sure if/how we can test other covers before it's merged. |
Similar to other Tuya window cover devices, but reports multiple tuya data points in set_data_response, so this implementation is based on the newer TuyaMCUCluster rather than TuyaManufCluster. Sold as Zemismart ZM25R3 roller blind motor.
TuyaManufCluster has a TUYA_MCU_COMMAND listener that is passed a command to send. Many existing calls to TUYA_MCU_COMMAND were calling the TuyaMCUCluster variant which takes a TuyaClusterData structure. I've renamed those calls to TUYA_MCU_SET_CLUSTER_DATA so sit alongside TUYA_MCU_SET_DATAPOINTS and distinguish the data type they accept.
…itialization/state
Update tests to use new zigpy request kwarg format
Similar to other Tuya window cover devices, but reports multiple tuya data points in set_data_response, so this implementation is based on the newer TuyaMCUCluster rather than TuyaManufCluster.
Sold as Zemismart ZM25R3 roller blind motor.
Proposed change
Additional information
Fixes #3068
Once merged it might make sense to change other existing tuya covers to use the new cluster implementations added in this PR. I think they could be replaced/consolidated with very little change, but I'm not sure how to how to test that sort of refactoring.
Checklist
pre-commit
checks pass / the code has been formatted using Black