How do I abort/stop an active light transition?

Configuration
1

I have setup ZHA along with a simple ikea on/off switch alongside a few tradfri dimmable bulbs.

Clicking on the “1” button of the ikea switch I am able to increase the bulb brightness using a user defined transition.
My tradfri ikea bulbs increases the brightness just nicely.

I use appdaemon, in this case I call the service like this:
self.call_service(“light/turn_on”, entity_id = “mybulbs”, brightness_pct=100, transition=5)

But when I release the “1” of the ikea switch I want to be able so stop the ongoing transition.
I havent found a way to do this yet.

I have the ZHA events working just perfect for the various events for the ikea switch, this is not my problem.

I did try this:
self.call_service(“light/turn_on”, entity_id = “mybulbs”, transition=0)
it doesnt seem to do anything, the transition still completes till it reaches 100%

this seems to stop it:
self.call_service(“light/turn_on”, entity_id = “mybulbs”, brightness_pct=50, transition=0)
So it has to receive a brightness value in order to cancel the older transition. 50% used in this case.
obvioulsy Id have to get the actual bulb brightness that the transition it as.
Its getting ugly pretty soon, as the actual value is a fair bit behind the actual transition

2

You can’t. Transition is a hardware feature. Once the bulb has received the command, there is no zigbee command to stop the transition.

3

It is not possible as far as I know, but you could check out Controller X, which provides smooth dimming and more.

1 Like
4

Interesting. But how does the ikea gateway the do this perfectly?

It seems to stop the transition just fine.

5

Hi @gibman,

I encourage you to try ControllerX as @Burningstone recommended. It is a software solution to dim the light. It changes the brightness gradually and uses the transition attribute to make the change much smoother. In the documentation there is a section of links to Twitter where you can see the smoothness of the brightness. Maybe it is not the best video, but you might be able to appreciate in this one. I might record a better video showing this use case, however, I recommend you to try it out and see for yourself if it changes smoothly enough.

Let me know if you need any help with it if you are interested :slight_smile:

Thanks,
Xavi M.

1 Like
6

hi Xavi.

And thanks!!

I’ve installed your project and it works fine using this config:

bar_controller:
  module: controllerx
  class: E1743Controller
  controller: "84:2e:14:ff:fe:58:79:25"
  integration: zha
  light: light.ikea_bar1

although the dimming is rough and kinda slow.
Any way to tweak this ?

7

Hi @gibman,

You can always play with automatic_steps and delay. They are attributes that in the same level as light and integration.

automatic_steps: It is the steps that need to jump from minimum to max brightness. The higher the number the smoother the experience is, but it will get slower to get where you want to get. Default is 10

delay: It is the time in milliseconds between HA service calls. The lower the smoother the experience is, however, do not set it to 0 since you might overload the network and the experience will be rather unpleasant. Default is 350 in your case.

I recommend you to play around with those parameters. My current setup is automatic_steps: 15 and delay: 150.

Cheers,
Xavi M.

1 Like
8

Tried your values still sluggish and sometimes requires me to press the up or down dim button again as it seems to stop.
Rpi3 running hass /zha on a conbee 2 stick on an usb extension cable for best signal.

Im doing my trials in the same room as the conbee device. So signal should be nice.

I guess I should consider the deconz addon if I want to have smooth dimming instead of zha.

9

I do not use ZHA in my current setup, but I have tried ZHA with ControllerX and I have got the same performance on deCONZ and ZHA when it comes to speed by having the controller near the stick and a low load of devices in the network. If it is sluggish, then I would recommend you to not lower the delay too much since the lower it is the more calls to the network are requested.

10

I since moved from a rpi3 b+ to a SSD based AMD e-350 (NUCish) platform.
The dimming transition issues have now disappeared when using controllerX :slight_smile:
So the RPI might not be up to the task, atleast not in my case.

11

This is not a correct statement

The bri_inc command that increases or decreases brightness also works as stop when sending the value 0

That is how Philips Hue does it when you press and release the + or - buttons

Sending many small increase or decrease messages floods the narrow bandwidth zigbee channel. Correct way is to put lights in a zigbee group, start increase or decrease the full gang with one message to the group and send the stop when releasing button

I do not know the syntax for ZHA but for Deconz look here

1 Like
12

I think this functionality has not been implemented into ZHA and ZigBee2MQTT, otherwise the Controller X dimming functionality through async calls would be pointless right?

13

Maybe
But I replied to the statement that it is a HW feature and there is no zigbee command. There.
And I seeing how responsive the Zigbee2MQTT devs are maybe they will adds it if you know what to ask for.

2 Likes
14

You have to know it works as stop :slight_smile:

15

Did you know this? Maybe with this you could move away from your workaround for dimming of light brightness.

16

Hi @Burningstone,

Thanks for pointing this out. What ControllerX does is calling the turn_on with the incremented brightness (done within the code). The only change I could apply would be to call the bri_inc and remove the part that increments the brightness in ControllerX since it will be done in Home Assistant.

However, this funcitonality was added after ControllerX already existed and changing this would imply serious refactor that I am not willing to do. Furthermore, this same functionality is used for color temperature, brightness, volume from media players, etc which is more flexible than just having bri_inc.

Anyways, thanks for pointing this out to me :slight_smile:

Regards,
Xavi M.

17

Totally understand.

Maybe I’ll implement this dimming method in my app for non-deconz lights.
With this new information, I imagine it to look like this.

First Long press up/down → turn on light to max/min brightness with a transition
Release Long press up/down → turn on light with bri_inc = 0 to stop the transition

I’ll see if I find some time to test and implement this.

18

Good idea, if you need any help with it, just let me know. I am happy to help :slight_smile:

1 Like
19

I stumbled upon the same issue, and while I did give ControllerX a spin with some good results I wanted to see how hard it would be do something similar directly in Home Assistant.

I was unable to pass “brightness increase 0” to my light to stop the transition, so instead I send what I think the brightness should be at that point in time… sounds kinda hacky but works surprisingly well :smile:

If you want to try it out, check out this blueprint!

20

quite old topic, but I had the same issue and found a nice workaround, I’d like to share here.

Instead of guessing the brightness it should be at that time, the correct brightness can be received by publishing a get brightness via mqtt to the light bulb. After this, one just needs to wait for the light to respond and the correct brightness can be set. The last command will over-write the ongoing transition with the current brightness

  • service: mqtt.publish
    data:
    topic: zigbee2mqtt/lamp/get
    payload: “{"brightness":""}”
  • wait_for_trigger:
    • platform: mqtt
      topic: zigbee2mqtt/lamp
  • service: light.turn_on
    metadata: {}
    data:
    brightness: “{{ states.light.lamp.attributes.brightness }}”
    target:
    entity_id: light.lamp