Add ZHA support for TuYaERS10TZBVKAA

[saint2016]

New Device Support

Device Information

• Device Model: TuYaERS10TZBVKAA
• Device Description: Tuya knob, it already has a z2m controller
• Device Manufacturer: Tuya

Integrations

        "toggle": Light.TOGGLE,
        "step_0_13_1": Light.CLICK_BRIGHTNESS_UP,
        "step_0_25_1": Light.CLICK_BRIGHTNESS_UP,
        "step_0_37_1": Light.CLICK_BRIGHTNESS_UP,
        "step_0_52_1": Light.ON_FULL_BRIGHTNESS,
        "step_0_13_2": Light.CLICK_BRIGHTNESS_UP,
        "step_0_25_2": Light.CLICK_BRIGHTNESS_UP,
        "step_0_37_2": Light.CLICK_BRIGHTNESS_UP,
        "step_0_52_2": Light.ON_FULL_BRIGHTNESS,
        "step_0_13_3": Light.CLICK_BRIGHTNESS_UP,
        "step_0_25_3": Light.CLICK_BRIGHTNESS_UP,
        "step_0_37_3": Light.CLICK_BRIGHTNESS_UP,
        "step_0_52_3": Light.ON_FULL_BRIGHTNESS,
        "step_1_13_1": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_25_1": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_37_1": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_52_1": Light.ON_MIN_BRIGHTNESS,
        "step_1_13_2": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_25_2": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_37_2": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_52_2": Light.ON_MIN_BRIGHTNESS,
        "step_1_13_3": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_25_3": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_37_3": Light.CLICK_BRIGHTNESS_DOWN,
        "step_1_52_3": Light.ON_MIN_BRIGHTNESS,
        "step_color_temp_1_18_1_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_35_1_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_52_1_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_69_1_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_18_2_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_35_2_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_52_2_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_69_2_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_18_3_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_35_3_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_52_3_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_1_69_3_153_500": Light.CLICK_COLOR_UP,
        "step_color_temp_3_18_1_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_35_1_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_52_1_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_69_1_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_18_2_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_35_2_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_52_2_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_69_2_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_18_3_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_35_3_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_52_3_153_500": Light.CLICK_COLOR_DOWN,
        "step_color_temp_3_69_3_153_500": Light.CLICK_COLOR_DOWN,

Integration: [ Choose from z2m | deconz | zha ]

zha

Actions

• button_xyz_press: Sent when button xyz is pressed
• button_xyz_hold: Sent when button xyz is held

Notes

The ZHA integration is different than the Z2M one. I captured the commands above and suggested some actions but they're very hacky. The reason is that the commands are sent with accompanying args (which controllerx apparently can capture - impressive). However, they don't work well with dimming. For example:

step_0_13_1 is a one step turn towards the right. step_0_25_1 is 2 steps turn towards the right, 3 steps turn increases 25 to 37, and so forth. All patterns are the same. Click and turn converts into the step_color_temp command.

In general there are 5 extra arguments, the first 3 change and the last 2 only exist in step_color_temp + were always the same:

1. direction: 0 or 1 in step, 1 or 3 in step_color_temp
2. number of steps: start from 13, 12 increments in step, start from 18, 17 increments in step_color_temp
3. speed of turn: 1 slow, 2 normal, 3 fast (same in both)
   4 & 5) only in step_color_temp and always 153 & 500. I don't know what they are for.

It's the first time I'm customizing controllerx so I thought of these mappings above but obviously this mapping is very limited. If I turn the knob to the right 5 times in one go it doesn't result in anything with these mappings for example, controllerx might be taking care of this through some smart mapping but I couldn't find it.

[xaviml]

Hi @saint2016 ,

Thank you for opening this issue and for the detailed explanation of this controller. ZHA is one of the hardest integrations since the events are not as clear as Z2M and deCONZ, so it is normal you are facing this issue. Before proceding further, I have 2 questions:

• Could you maybe share 1 or 2 examples of a zha event?
• Does this controller fires any action when the dimmer has stopped turning? I suppose no since z2m mapping does not have release actions.

As done for other controllers with ZHA integration, I can code the rules of this arguments, but first I would like to know the answer to those 2 question, so I have a better idea on how to progress.

I would love your input once I have integrated this controller, so I would appreciate if you could test it.

Regards,
Xavi M.

[saint2016]

Hi @xaviml,

Thanks for your reply. Yes it does look complex. I thought of adding an option to bring to 25% dimming (you have 0.5 in the original code) and enable that after 3 turns, and bring to 50% in 2 turns, and 75% with one turn but catching 3 or 2 turns is also not so functional. So I'll leave it to the expert :)

Here are the two events:

event_type: zha_event
data:
  device_ieee: xx:xx:xx:xx:xx:xx:xx:xx
  unique_id: xx:xx:xx:xx:xx:xx:xx:xx:1:0x0006
  device_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  endpoint_id: 1
  cluster_id: 6
  command: toggle
  args: []
  params: {}
origin: LOCAL
time_fired: "2022-11-08T05:14:00.617878+00:00"
context:
  id: 01GHATHQ19PMA4JXJJYEE55K4M
  parent_id: null
  user_id: null

event_type: zha_event
data:
  device_ieee: xx:xx:xx:xx:xx:xx:xx:xx
  unique_id: xx:xx:xx:xx:xx:xx:xx:xx:1:0x0008
  device_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  endpoint_id: 1
  cluster_id: 8
  command: step
  args:
    - 1
    - 13
    - 1
  params:
    step_mode: 1
    step_size: 13
    transition_time: 1
    options_mask: null
    options_override: null
origin: LOCAL
time_fired: "2022-11-07T12:13:58.984974+00:00"
context:
  id: 01GHATHNE8PX74C1HM6M3FWF09
  parent_id: null
  user_id: null

And no, as you guessed there is no event fired when I stop.

Very happy to test it out whenever you are ready.

[xaviml]

Hi @saint2016 ,

I have created the following PR to add ZHA support for the TuYA knob: #661.

Would you mind downloading the code and test the integration? You can follow one of those 2 options specified in this section from contributing file: https://github.com/xaviml/controllerx/blob/main/CONTRIBUTING.md#run-code-with-appdaemon.

Let me know if you have any troubles or you need any help for it.

Regards,
Xavi M.

[xaviml]

Hi @saint2016 ,

To make it easy for you to test, I released ControllerX v4.25.0a0, which you can download from HACS (marking "show beta versions") from the "Redownload" option.

Regards,
Xavi M.

[saint2016]

hi, thanks for the update and pushing the version. Toggle worked, step functions didn't (neither brightness nor color). To be clear, I don't mean it didn't work smoothly, I mean it didn't work at all. I listened to the zha_event and they were firing OK.

Brightness worked 1 time randomly (it was when I had turned the bulb off, then did a step on the knob & probably an unknown thing, and then turned the bulb again) but I couldn't repeat the behavior.

[xaviml]

Thank you @saint2016 for the feedback. I am currently working on it since I saw there is a bug in the code. I will let you know again, so you can try it out. Are you okay I release another version or you can test it locally with the "CONTRIBUTING" guidelines?

Thanks!

[saint2016]

Very happy to test again, HACS re-download worked like a charm so it would be great if we could do it that way.

[xaviml]

Hi @saint2016 ,

I just released ControllerX v4.25.0b1 with the latest changes. Would you mind trying again? If it does not work, or works not as expected, could you please provide the AppDaemon logs related to the problem?

Regards,
Xavi M.

[saint2016]

This worked, thanks for making it happen!

There was just a behavioral issue: turning the knob to the left increased the brightness and turning it to the right decreased the brightness.

Standard dimmer behavior on analog dimmers is the opposite: turning the knob to the right should increase brightness and to the left decrease it. I'd assume people would expect that behavior (I for one certainly did expect things to be that way).

I also checked the appdaemon logs, all seem clear. So if you can fix the above this is all good to go.

[xaviml]

Hi @saint2016 ,

Sorry, I inverted the direction. I thought that 0 was down and 1 was up for brightness (the same for color temp). I will invert this and merge the PR. Did you find any other problems? Could you try the following scenarios (with the current version v4.25.0b1) with brightness and color temp?

• Turn the knob when the light is off. Expected: nothing should happen and no error in the logs should be shown.
• Turn the knob right when the light is on. Expected: attribute should go up.*
• Turn the knob left when the light is on. Expected: attribute should go down.*
• Turn the knob right when the light is already on maximum level (brightness/color temp). Expected: nothing should happen, but in the logs, you should see that the service call is done.
• Turn the knob left when the light is already on minimum level (brightness/color temp). Expected: nothing should happen, but in the logs, you should see that the service call is done.

*These cases are not working now, but they will be fixed.

Feel free to add more use cases and double check edge cases. I will be happy to help out in what I can to fix anything else you find.

Regards,
Xavi M.

[saint2016]

Great, no other problems I could see. On your scenarios:

• Turn the knob when the light is off. Expected: nothing should happen and no error in the logs should be shown.
  -- as expected
• Turn the knob right when the light is on. Expected: attribute should go up.*
  -- will work as expected after the invert
• Turn the knob left when the light is on. Expected: attribute should go down.*
  -- will work as expected after the invert
• Turn the knob right when the light is already on maximum level (brightness/color temp). Expected: nothing should happen, but in the logs, you should see that the service call is done.
  -- as expected
• Turn the knob left when the light is already on minimum level (brightness/color temp). Expected: nothing should happen, but in the logs, you should see that the service call is done.
  -- bulb goes off (on brightness, obviously). But I think this is because the bulb (IKEA TRADFRI) supports 0 brightness but keep itself on. My suggestion would be to prevent this if not too much effort. But equally that's how an analog dimmer works so shouldn't be too much trouble if the same behavior continues. The main challenge with a bulb at 0 brightness is when it's toggled there won't be a reaction from the bulb so some people will be confused by it.

[xaviml]

bulb goes off (on brightness, obviously). But I think this is because the bulb (IKEA TRADFRI) supports 0 brightness but keep itself on. My suggestion would be to prevent this if not too much effort. But equally that's how an analog dimmer works so shouldn't be too much trouble if the same behavior continues. The main challenge with a bulb at 0 brightness is when it's toggled there won't be a reaction from the bulb so some people will be confused by it.

Could you show the AppDaemon logs when the light is at minimum brightness and then you dim the light down? Theoretically, the brightness should stay at 1, and not show 0. If the light turns off with brightness 1, could you try following configuration:

tuya_app:
  module: controllerx
  class: TuYaERS10TZBVKAALightController
  integration: zha
  controller: 00:11:22:33:44:55:66:77:88
  light: light.livingroom_lamp
  min_brightness: 2  # Add this attribute

The min_brightness will tell ControllerX to not go more down than 2 for brightness.

I have also merged the PR, and released ControllerX v4.25.0b2. You can now try in there the latest changes.

Regards,
Xavi M.

[saint2016]

OK, tried v4.25.0b2 and all good.

On the minimum brightness, somehow the bulb still went off with the below log entry so I used your min_brightness and it prevented the bulb from going dark. This is a working solution.

--

2023-01-03 15:34:51.240418 INFO controller_knob: 🎮 Button event triggered: step_brightness
2023-01-03 15:34:51.247415 INFO controller_knob: 🏃 Running Predefined (brightness_from_controller_step) now
2023-01-03 15:34:51.267889 INFO controller_knob:
🤖 Service: light.turn_on

• entity_id: light.bulb
• transition: 1
• brightness: 1

the bulb went off at this point, somehow brightness of 1 is completely off

So overall things look good with the updates and this controller. Thanks again for implementing, please let me know if I can help further.

[xaviml]

Thank you @saint2016 for your active testing. There is nothing else I need from you :)

I will be closing the issue once I release v4.25.0.

Regards,
Xavi M.

[xaviml]

This device is now available on ControllerX v4.25.0. This issue can be now closed. If any bugs are found related to this issue, please open a new one.

[OliverDudgeon]

In ZHA only toggle, click_brightness_up and click_brightness_down seem supported. Is there something blocking allowing mapping other inputs?