Migrate Tuya's `PowerOnState` attribute to `start_up_on_off` OnOff cluster attribute

Now that @dmulcahey has added support for configuring from HA the power on state of ZHA devices, I’ve realized that the implementation followed with Tuya devices is not ideal.

In Tuya devices, the power_on_state (id: 0x8002) attribute has been added to manage this property instead of using the start_up_on_off (id: 0x4003) attribute, but if the standard Zigbee property is used, we can take advantage of the implementation made to also control those Tuya devices from HA without any extra coding.

I am in favor of quirks implementing standard Zigbee attributes/functionalities whenever possible, and for me this is a clear candidate to improve the implementation.

However, there are some aspects to review before tackling the task:

1. There is no match between the Tuya attribute values and Zigbee attribute:

Status	Zigbee	Tuya
Off	0x00	0x00
On	0x01	0x01
Toggle	0x02	don’t exists
PreviousValue	0xFF	0x02

1. In Tuya’s MCU devices this attribute is just a quirk attribute (fake) to read and set the value, but I am not sure about the behavior in Tuya’s (real) Zigbee devices. There is a real 0x8002 attribute in these devices?

In function of the answer to point 2. I see two approachs: a. remove the power_on_state (id: 0x8002) attribute and make use of a wrapper class to ‘translate’ values (¿?) b. overwritte the read/write start_up_on_off (id: 0x4003) attribute to make use of (and translate) the get/set power_on_state (id: 0x8002)

Any comment or help on this is welcome.

I can take care of the implementation and I can test with some MCU type devices that I have, but I think that the solution for the Tuya Zigbee devices can condition the implementation of the MCUs.

References:

• https://github.com/home-assistant/core/pull/70110
• https://github.com/zigpy/zigpy/blob/cab1032f7e8315682dcbaf4906bc644a3f99b4ee/zigpy/zcl/clusters/general.py#L606-L610
• https://github.com/zigpy/zha-device-handlers/blob/0163c7ca3dff3508544bca0d57b57d0156342c80/zhaquirks/tuya/__init__.py#L841-L846

[dmulcahey]

Do you have one tuya ZBGW then you can updating it and loosing the functionality on EP 2 and 3 and and only EP one is working for all (need tuya magic being casted on it for being “normal” and PR is made for fixing it).

I’m not sure if I want this improvement 😅

The problem is “normal” tuya devices that is not using / needing quirks for getting the “tuya standard Zigbee attributes” without quirking all of them.

Let’s take the Plug_3AC_4USB example. We can use it as a normal Zigbee device. But if we want to make use of any of the manufacturer attributes (child_lock, backlight_mode, power_on_state, switch_mode) we need to configure the quirk for the device, otherwise we could not use these attributes.

If the device uses the standard attributes, it can be controlled in HA. If the attribute uses manufacturer attributes, it will first need a quirk to expose it in HA and then it could be controlled from HA. If we already have to do the quirk, as long as is possible, let’s make it behave like the standard. I understand that this is the objective of the that library, in front of exposing the particularities of each manufacturer.

Surely in the long run it will be necessary to see how those attributes that do not have a counterpart in the standard are managed, but I see it more as the natural evolution of what is done with the standard attributes. Because, can you imagine how has to be to implement the controls for TRV devices?

But all this is still my personal opinion. I only speak for myself. Each one is free to interpret the needs and priorities that they consider. And whenever I can, I will help in any way possible.

We can target manufacturer / model / attribute name together in ZHA. What I would say is this: if it is as easy as extending the entity class in ZHA and overriding the attribute name it probably makes more sense to do it in ZHA. If it would drastically change how the support in ZHA works we should probably quirk the device to make it match the spec if it is functionality that the spec offers. For functionality that isn’t even in the spec it probably makes more sense to just do the work in ZHA.

A good example may be the new innovelli switch. We will probably have a ton of innovelli specific configuration entities in ZHA because there is a ton of stuff that isn’t part of the spec that the device can be configured to do.

All of this said… we need to evaluate what needs to be done to make this sustainable moving forward. if we follow the approach above things could get unruly very quickly.

@puddly @Adminiuga do either of you have any thoughts?

[Adminiuga]

We can target manufacturer / model / attribute name together in ZHA. What I would say is this: if it is as easy as extending the entity class in ZHA and overriding the attribute name it probably makes more sense to do it in ZHA

I also prefer this approach. ZHA was developed with the thought that vendors would stick to the specs and quirks were supposed to address some “minor” incompatibilities. Well, Tuya buried this idea and I think implementing Tuya in ZHA is more flexible approach in the long run.