That works great on one light or a few lights in a small installation.
It sucks when you have many Zigbee devices in a mesh and you try to dim many lights at the same time.
I did that initially. I have 98 Zigbee devices and half of them work like repeaters. The Zigbee network got flooded with messages and the practical experience was that not all the lights would dim at the same speed and it was a poor experience compared to how it was when I used the Philips Hue hub. If I tried to dim my living room I would end up with a couple of lamps at too high an intensity. After I changed to the better method it just works every time.
There is a reason why Philips Hue has implemented it this way
I tried doing it as you outline, but found myself deep into special cases of events/triggers that should stop the automation.
I eventually decided event sensor simplifies logic, that it should run the script as long as the dimmer is in the 2_hold or 3_hold position, and stop it when the dimmer changes state.
@KennethLavrsen You’re right, I might not have been specific enough. I was thinking making it a core HA integration. I just used the ZHA explanation, because almost all of my lights are ZigBee, the only wifi lights I have, is WLED.
But as you say, this will have to be implemented in each light integration, because of the reasons you describe. And that makes a lot of sense. So I see why this can’t be implemented easily.
But I would love to see the feature you are explaining with the brightness increase and transition time, implemented in ZHA. And my understanding is, that ZHA is a core HA integration, and not a third party.
For anyone interested, this is solved with ControllerX. It allows you to link controllers with HA entities (light, media player, switch, cover) and it works with Zigbee2MQTT, deCONZ, ZHA and MQTT.
This is awesome, but I am having a hard time understading how to actually make the hold action brighten and dim the light?
This is what I have, but only on/off works. Under supported controllers, it says that brighten and dimming is supported by this controller.
However, if you want different behaviour, then you can add a mapping attribute to override the default mapping. Read more about the mapping attribute here.
Oh okay, nice. That makes it a lot easier. This is some amazing work.
It’s not as smooth as if I was using the deconz method I was talking about earlier in the thread or if I had paired the controller directly with the bulb. But it’s a lot better then using automations.
It’s not as smooth as if I was using the deconz method
I agree, it is not a perfect solution because it does call HA service periodically, however, to make it smoother it calls the turn_on service with the transition attribute with the same delay as the delay that takes to send another request. If you add add_transition: false into the configuration and try to dim/brighten, you will see that the action will be less smooth.
You can also play around with delay (350ms default) and automatic_steps (10 by default). delay is the time between each request sent to HA while holding, and automatic_steps are the steps that are needed to go from minimum to max, so the bigger the step number is, the longer will be the time to go from minimum to maximum brightness.
But it’s a lot better then using automations.
Indeed, this was in the first place why I built this. I created a long HA YAML configuration for this + python script, and when I had to duplicate everything to just do the same thing with another controller was the moment that I realised that something was wrong, and it was then when I discovered AppDaemon and created ControllerX to just wrap everything up and allow from configuration to change what was really necessary: the controller and the light. This way I don’t have lots of YAML automations to just control a lightbulb with a controller, and leaving all the controller-based automations to ControllerX in a much cleaner and simpler way.
I tried implementing your solution with a HUE bulb and a HUE Dimmer switch, both connected to ZHA. For testing purposes I set the transition time to 10 seconds.
I call the turn_on service with {“brightness_step”:“254”,“transition”:“10”}
When I call turn_on with {“brightness_step”: “0”} The light instantly jumps to a 254 brightness percent, instead of stopping the dimming action.
This only works for deconz currently, and in deconz you don’t use the light.turn_on service, they have a special service deconz.configure that allows to do this and some other things.
I like the way you control the dimming/brightening of your lights. At the moment I’m looking at doing this in Zigbee2MQTT. But I’m not there yet. Could you tell me how Deconz handles the update on the individual lights in a group after setting them? Does it report the right brightness of all individual lights in the group or does it gets the brightness of just one light and assumes all lights in that group have the same brightness?
Setting brightness like this is very performance effective, but getting brightness after sending the stop command, is more performance consuming, because every device in the group has to send an update. Do you know how this is handled?
The updating from Deconz back to HA via rest API is not pretty. The intensity shown jumps a bit and some lights are reported 2-5 seconds later after you stop dimming. But eventually they are in sync. This does not have much negative practical effect. When you dim with a slider from HA they all jump to the set intensity. When you hold a dimming button on a remote on the wall or on the table you do not look at HA. Then it is more important that the dimming happens correctly to all the lights in the group. You look at the light while holding button until you reach the desired level. You do not see that there is a delay in the reporting back to HA in real life.
I have tried the same thing, as described by @KennethLavrsen, with ZHA and Zigbee2MQTT and a Zigbee light group (Philips Hue bulbs).
Interestingly, I see your result (light instantly jumps to full brightness instead of stopping the dimming) with Zigbee2MQTT, whereas with ZHA the dimming stops, albeit with a noticeable brightness drop that makes it look bad.
In addition, I observed erratic behaviour of the light group’s brightness slider in Lovelace with ZHA.
This is a pity, as Zigbee light groups in ZHA and Zigbee2MQTT otherwise work well in terms of synchronised brightness changes.
EDIT:
I have now also tried ControllerX by @xaviml and it works nicely. Thanks a lot for that.
In the spirit of keeping it simple and safe (KISS), I still think this should be supported in a more direct way in ZHA and Zigbee2MQTT, though. Should this be addressed somewhere else in order to bring this to the relevant developers’ attention?
Anyone knows if those brightness commands can be sent directly to Philips Hue bridge to archive same smooth dimming using other switches. For example I’m using Ikea dimmers from diconz but the lights are on the Hue bridge.
I am voting for this as well. That not all dimmable light would support it is no reason not to implement it.
E.g. Not all lights are captable of dimming and they are supported as well in the light integration.
So why can there be a “turn on” command with a parameter brightness and can’t be a “turn on” commant with the parameter dim_up/dim_down/dim_stop.
Integrations that support it, execute it while integrations that doesn’t support it can ignore it (same with brightness level).
This way, not Home Assistant is the restricting parameter, but the integration or the hardware is.
E.G. philips hue lights have a dim up command and z2m is implementing it, but ZHA isn’t.
Maybe integrations mantainers found already a good way to simulate it. Why not put this knowledge into the integration instead of people producing a lot of blueprints or other ways (controllerX - great by the way) to add this “commands” to Home Assistant?
Unfortunately, the answer in this case is: It’s because of the manufacturer of the lights/systems. Home Assistant sends a signal to e.g., Hue hub, Zigbee gateway, z-wave network, or some cloud for any of the hundreds of different lights Home Assistant supports.
That’s true, but there is hardware supporting it. And z2m has commands ( brightness_move) for those lights so that you can start moving the brightness with the specified speed and send a “stop” command at the end. This way you only need to send two commands from the light switch to the light (that does the dimming work) and it works the “analog way” most people are used to unsing their analog wall dimmer switches.
Home Assistant is not the one performing the transition and most, don’t support interruption or stopping a transition.
That’s the thing. Even a light.stop_transition command in Home assistant that integrations can implement would probably be enough as transitions are executed by the device.
Right now we only got turn_on/turn_off/toggle. So I can start the transition, but right now I don’t have any way to stop it.