Repository: zigpy/zha-device-handlers

Issue:
[Device Support Request] TS130F Add new attribute "motor mode" (0x8000) 
**Is your feature request related to a problem? Please describe.**
In reference to the comments in https://github.com/zigpy/zha-device-handlers/issues/2120#issuecomment-1402381602

**Describe the solution you'd like**
Add attribute to cluster and frontend

<details>
<!-- Device signature can be acquired by clicking on the "Zigbee Device Signature" button in the device settings view -->
<summary>Device signature</summary>

```yaml
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0202",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0102"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_vd43bbfq",
  "model": "TS130F",
  "class": "zhaquirks.tuya.ts130f.TuyaTS130FTO"
}
```

</details>

**Additional context**

"0x8000": { "attribute_id": "0x8000","attribute_name": "32768","value_type": ["0x30","enum8","Discrete"],"access":"REPORT|WRITE|READ","access_acl": 7,"attribute_value": 0},

![image](https://user-images.githubusercontent.com/15717847/215216779-9c4efd5c-918d-472d-94f7-a25b92d868ef.png)


According to the TUYA app is:
Value 0x00 = STRONG MOTOR
Value 0x01 = WEAK MOTOR


Discussion:
Can you add the full device diagnosis?
Just to check which cluster comes from that attribute.
Attached is the FULL scan of ZHA-tookit and the device diagnosis.

If you need anything, let me know, the values according to the zigbee network sniffing are the ones I indicate above, I don't know if in production it will do something, but if the option this would have to be taken into account, even do it as the motor address, with a dropdown, don't you think?

Thanks @javicalle 

[TS130F__TZ3000_fccpjz5z_6479535baa_scan_results.txt](https://github.com/zigpy/zha-device-handlers/files/10530851/TS130F__TZ3000_fccpjz5z_6479535baa_scan_results.txt)
[zha-3df2a33f982b752c7f40a93703c20928-_TZ3000_fccpjz5z TS130F-b746132a7f6eee040e91e719f9aa5889.json.txt](https://github.com/zigpy/zha-device-handlers/files/10530852/zha-3df2a33f982b752c7f40a93703c20928-_TZ3000_fccpjz5z.TS130F-b746132a7f6eee040e91e719f9aa5889.json.txt)

Ok, the attribute is from the `WindowCovering` cluster. Not what I would expect but it is.

It is the first time that I am aware of this type of configuration, so I do not think it is a very common or demanded option. @MattWestb any thoughts in this topic?

My first impression is just to add it as a cluster attribute (possibly within the `TuyaCoveringCluster`), but for now not to define an entity in ZHA.

Another possibility would be to create also the ZHA implementation and trust that devices that do not initialize the attribute (those that do not have it implemented) will not create the ZHA entity (avoiding error reports and questions about 'how do I activate the property in my device (that doesn't implement it but I want)?').
For the second approach I am not familiar how the ZHA entity creation code works so I'm not sure if it's the way to go.
For the second opcion, maybe with signature or manufacturer?

If the signature or manufacturer matches then generate the entity.
> For the second opcion, maybe with signature or manufacturer?

(If accepted) we already have the `ep_attribute="tuya_window_covering"` approach. 
But in this case I'm not sure if it is a common function like the other ones from the `TuyaCoveringCluster` (`calibration`, `motor_reversal`...). I have doubts that ALL `TS130F` devices that would have the quirk applied to them also implement that `motor_mode` functionality and because of that my reluctance.

By the way, can you add the link to the manufacturer or vendor of the device?
Our experience with tuya zigbee devices is that we have mush more to expected then we is getting then its coming to Zigbee standard.
Implanting the attribute in ZHA GUI i like and if the device is having the attribute its showing up but we knowing that devices is having the attribute implanted in zigbee side but not working in the device code. Then its the question if selecting devices that have working attribute (tuya cloud is matching device ID for functions in the cloud) many user is complaining they is not having it and like have it implanted for there device if its have working one or not and making long issues. One way is making it for all devices that have the attribute reported (like ZCL power on beehive) and if the device is not implanting the user can deleting  or hid it in the ZHA GUI or making only devices with quirk using it.
In the end one maintainer question.
 
On the quirk side is possible making device classes with device ID in the beginning of the quirk and one general for not matched in the end so its loading the right if ID is matching and if not its loading the general with only matching TS130F (TS004F is using the same scheme and its working) and ZHA is only adding the ZHA GUI handle if the device class for it is loaded in the quirk.

One PS of using ZHA-Toolkit: The scanning one device ZHA is saving all attributes known or not and also device can changing there behavior (LIDL RGB lights is doing it) that shall not being any problems then testing but can being bad if user is scanning trying getting there missed functions in there devices.

I like getting more elements in ZHA GUI for our tuya zigbee devices but is one rabbit hole and in the end the maintainer must helping saying how we shall doing it right for bot putting efforts in wrong things and wasting time. 
Manufacture quirks is one part of ZCL and shall being standard implanting in ZHA for all devices that is more or less good Zigbee implanted (exception tuya MCU devices that shall have being only made in ZHA with the MCU cluster only piped to ZHA or other integration) like IKEA Starkvid is getting there extra function nice integrated.

Sorry for writing too mush and not so constructive :-((
I more or less agree with what you say, also we are also aware (I think) that TUYA has a very high percentage of the zigbee market for its variety of products and models, which on the one hand is quite good because it helps the home automation is managed from one place (is what they try with their APP, a single application to manage everything from temperature sensors to door locks), but of course, when implementing or "adapt / translate" is a problem given the peculiarities outside the tuya standard.

I am of the opinion that the HA UI should show all the configurable properties of the device, whether the user uses them or not (we always have the possibility to hide it) as it would remove problems when having to touch the cluster to modify, for example the case of the issue we saw last week with the engine direction, it is not the same a drop-down that navigate through the attributes of the cluster and edit the parameter in question to turn the system up and down the device.

Besides, I think (and this is a personal opinion) that ZHA should have AT LEAST the options that the TUYA application allows, since that would make, apart from a more complete integration, easier the migration from TUYA to ZHA, especially for users who have perhaps a low level of knowledge of the subject.
Thanks for repaying and comment my writing.

The "easy" thing is tuya zigbee device that i think it very good adding as much functionality in ZHA GUI  Also if 90% of one device type is working well and 10 % dont support one function then i think its up to the devs making one new device class for it and the is better then not have any GUI elements at all for the device class.

By ZCL is it always possible for one manufacture making private clusters, attribute and commands and implanting then in the host system as long the not braking the moderate parameters of the ZCL. Problem is tuya and many others is not following the implementation like attribute and cluster is not in manufacture range or using wrong parameters (tuya power on defaults).

The tuya MCU is one other thing and need being re designed how it shall being handles in ZHA (i still think only piping the tuya cluster to ZHA and all is dont in ZHA) and some very strange hybrid device that need both "normal" tuya zigbee and MCU like https://github.com/zigpy/zha-device-handlers/issues/2151 and some switches.

For my is more ZHA GUI element very important for normal users and is needed for getting user using ZHA and not going other ways like tuya cloud and Z2M.
This attribute could be extremely useful 😊
Returning to this, the problem I see of not adding it is having to configure it from the application of yours (you must have the gateway) and then migrate it to ZHA, the settings are not lost with the change of controller, but it already forces to have a gateway of yours to be able to do it.
It's not the intention here. It would be added to some cluster as a new attribute. And would be possible to setting through the cluster attributes.
Maybe the question is if must be added to the 'generic' `TuyaCoveringCluster` or create a new one. And if/how create the HA entity.

Let's see if I can get some spare time to take a look. 
If you need anything, let me know, and I'll help you if possible.
I believe that could be enought to add the new attribute to the `TuyaCoveringCluster`.

Copy the current `ts130f.py` file:
* https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/ts130f.py

Add the `MotorMode` class and the new attribute `motor_mode` like:
```python
class MotorMode(t.enum8):
    """Tuya motor mode enum."""

    STRONG_MOTOR = 0x00
    WEAK_MOTOR = 0x01


class TuyaCoveringCluster(CustomCluster, WindowCovering):
    """TuyaSmartCurtainWindowCoveringCluster: Allow to setup Window covering tuya devices."""

    attributes = WindowCovering.attributes.copy()
    attributes.update({0x8000: ("motor_mode", MotorMode)})
    attributes.update({0xF000: ("tuya_moving_state", t.enum8)})
    attributes.update({0xF001: ("calibration", t.enum8)})
    attributes.update({0xF002: ("motor_reversal", t.enum8)})
    attributes.update({0xF003: ("calibration_time", t.uint16_t)})

    .../...
```


The new attribute will be editable from the cluster management.
You can set values just like 0/1.
Yeah!


![image](https://user-images.githubusercontent.com/15717847/217649423-fcc07359-5d92-4863-94bf-3f658e0e2ee4.png)

And I add the select :)
![image](https://user-images.githubusercontent.com/15717847/217651351-5c4c2060-d67e-4abd-ac6d-a41ced2391e5.png)


You rocks! :love_you_gesture:


Do I write a PR?
> Do I write a PR?

Yes, but...

The new attribute will be added to all `TS130F` devices regardless of whether they implement it or not (we don't know and we can't know it).
As long as it is as a cluster attribute I don't think there is a problem.

The next question will be: do you add it as an entity in HA?
With any of the current approaches, all `TS130F` devices would be candidates for generating the new `Motor mode` entity regardless of whether they implement the attribute or not. And that could be a problem. 🤔 

Apparently, if the device does not implement it, the attribute will have a value of `None` and the entity will not be generated. This would be correct and desirable.
It also seems that this does not generate error logs, so incidents due to error messages would be avoided. 👍🏻 

Therefore, my position is not against generating the entity in HA, but if the implementation generates incidents, I think a more specific approach should be chosen.

So, for the quirk part go ahead with the PR.
And the possible HA PR, is up to you.
Umm right, you are right, the problem is perhaps exposing too many entities that in many cases will not work, the only option we would have would perhaps be to filter what is exposed using the manufacturer or the signature? (I think we already discussed this).
I see 2 approachs here:
1. duplicate the `TuyaCoveringCluster` (just extending it) ans using the new class only in the known devices/quirks
2. controlling it at ZHA integration, but this would add again the fine tunning that we are trying to avoid

Here has been discussed and it seems to be a save approach, but I haven't checked myself and I don't have an strong opinion on this matters:
* https://github.com/home-assistant/core/pull/87546#issuecomment-1420760571

Let's see where drives us the https://github.com/home-assistant/core/pull/87653 and then we can move forward in the HA part.

Resolving patch:
diff --git a/zhaquirks/tuya/ts130f.py b/zhaquirks/tuya/ts130f.py
--- a/zhaquirks/tuya/ts130f.py
+++ b/zhaquirks/tuya/ts130f.py
@@ -39,10 +39,18 @@ class TuyaWithBacklightOnOffCluster(CustomCluster):
     attributes = {0x8001: ("backlight_mode", t.enum8)}
 
 
+class MotorMode(t.enum8):
+    """Tuya motor mode enum."""
+
+    STRONG_MOTOR = 0x00
+    WEAK_MOTOR = 0x01
+
+
 class TuyaCoveringCluster(CustomCluster, WindowCovering):
     """TuyaSmartCurtainWindowCoveringCluster: Allow to setup Window covering tuya devices."""
 
     attributes = WindowCovering.attributes.copy()
+    attributes.update({0x8000: ("motor_mode", MotorMode)})
     attributes.update({0xF000: ("tuya_moving_state", t.enum8)})
     attributes.update({0xF001: ("calibration", t.enum8)})
     attributes.update({0xF002: ("motor_reversal", t.enum8)})


Test patch: