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.
I attempted the @KennethLavrsen trick in ZHA as well, and saw the same ‘jump’ to max/min the others are observing.
Is it possible in HA/ZHA to synthesize something like that low level deconz.configure message instead of the light.turn_on?
For instance, there’s clearly a way to send special messages for configuring the devices in ZHA, through the “Manage Clusters” interface. Is there a cluster there that can be sent the step=0 message that would halt the dimming?
Using something like zha.issue_zigbee_cluster_command, do you know which step=0 command needs to be issued to halt the dim? A pointer to a deconz implementation might be helpful.
The only strange thing now is that the “on” level is not properly memorized, so turning on always goes to max brightness as opposed to where the dimming left off.
I guess what’s missing with this low level cluster command is the sync back to the HA state. A hack might be to use the low level cluster command to read the level attribute, and the generate a light.turn_on call that does not change the level, but updates HA.
I managed to dimm hue lights from a zwave Fibaro switch. But basically it can be any switch which fires event on short/long presses and releases of the buttons.
It starts dimming by setting the brightness to 255 with a transition time of 5 seconds. It stops the transition with a zigbee group command or cluster command, depending if you want to dimm a group of lights or a single bulb.
It dimms up or down depending on a boolean which is toggled on/off every long press of the button.
At the group command it’s important to fill in your zha group ID. When u want to dimm a single bulb it’s important to fill in the ieee address of the bulb. Also check the endpoint ID, beacause some vendors use ID 1 but hue for example uses endpoint ID 11.
The result is smooth dimming without the need of external implementations. It works with home assistant and zha and it doesn’t congest the zigbee network with brightness up/down commands every x milliseconds like some scripts do.
Rick, when you stop the transition using issue_zigbee_cluster_command (like your YAML example, or my Python example), does Home Assistant correctly update the brightness level in the UI?