Add Tuya cover _TZE200_eevqq1uv
#3114
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #3114 +/- ##
==========================================
+ Coverage 88.14% 88.29% +0.14%
==========================================
Files 299 299
Lines 9389 9498 +109
==========================================
+ Hits 8276 8386 +110
+ Misses 1113 1112 -1 ☔ 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.
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.
TheJulianJES
added
Tuya
zhaquirks/tuya/mcu/__init__.py
Outdated
| def __init__(self, *args, **kwargs): | ||
| """Init.""" | ||
| super().__init__(*args, **kwargs) |
There was a problem hiding this comment.
This can be removed.
There was a problem hiding this comment.
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 |
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
|
@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.
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.
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.
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 |
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-commitchecks pass / the code has been formatted using Black