WhyTH is there not an options for smoothly dimming/brighten light and stopping the dimming/brighten effect?

Why is this not an option?

I know there is the set brightness service that can set the light to, let’s say 50% and set the transition time.
But why is there not an option to stop that transition time earlier if wanted.

Let’s say I have a button where I want to dim the light when it is clicked and stop at the dimming level it has reached when I click the button again.

When using ZigBee buttons, it sends an event when I hold down the button and an event when released. I want it to dim the light smoothly until I realise the button. (Read SMOOTHLY: not 5-10% every second, like the workaround with scripts, many has resolved to)

The only way I have found for it to gradually dim/brighten a light by holding until release, is by making scripts that is called by itself, until it is cancelled. This is not what I am looking for. Firstly because it’s in no way or shape a smooth transition to change a lights brightness by 5% every second, and second, that is a much too complicated way of making this happen, since I have tons of lights, I suddenly need many automations and many scripts, just to brighten/dim a single light source.

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. Home Assistant is not the one performing the transition and most, don’t support interruption or stopping a transition.

2 Likes

But I know there is a working solutions for DeConz, because I used it when I had DeConz.

This guy has some example automations that use DeConz data to do what I am looking for.

But since I switched to ZHA, because it supports more devices, this solution does not work.

I did find a hacky solutions, and that was to send a command to the ZigBee cluster of the lights, that interrupts the dimming transition. I can’t remember the automation code, and my HA instance is down at the moment, so can’t give example, I found it on the forums. But this solution is also bad, because it takes some time for HA to know the correct brightness value of the light after the interrupt.

But the example for DeConz works perfectly and never had a problem with it.

But that is exactly the issue, right? Some do work, others don’t. ZHA might be possible, but in the end, it will never be consistent with your description. As, for example, we don’t control the behavior of a Hue or Ikea hub.

But I don’t use the hubs, I use ZigBee dongle and ZHA.
And since DeConz has figured out how, why can ZHA not implement a similar command?

On a different take, could it not be handled by Home Assistant instead of the light.

If HA had an automation to keep sending light increase/decrease commands that changed the light brightness by x increments every x milliseconds, to a light either until it reached a specified brightness, max brightness or until another command was sent to HA that told HA to stop sending the increase/decrease commands?

2 Likes

That will also not work for a lot of devices, Hue for example only allows a X number of requests per second.

2 Likes

Fair enough. But I still can’t figure out why ZHA can’t get a function implemented like DeConz, since they have figured it out. So there is obviously a solution to get this function for at least the ZigBee lights. And isn’t ZHA native to Home Assistant? So it is in their ballpark to get this implementation made.

I cannot remember where I originally found the info about sending the brightness increase of 0.

But I remember that both the IKEA hub and the Philips Hue hub uses the same Zigbee method.

And it works on any Zigbee light device I have tried. Not only Philips and Hue bulbs but also some generic China Zigbee dimmer LED drivers. It seems very standard

I do not use ZHA but I encourage the dev of this integration to simply implement a command to send the increment message. Then you are flexible to use it with 0 or not zero. Now ZHA also support groups it makes sense. This is not really a hack. It is the way they all do it in practical.

1 Like

This exactly. And that is why I don’t understand why it hasn’t been implemented in ZHA.

Maybe it will work by using the brightness_step service that HA has implemented. So send turn_on with brightness_step 255 and when button is released, send a turn_on with brightness_step 0.
I have actually not tried that. I wish I had my instance up and running right now, so I could test it out.

I use a setup based on Event Sensor, see https://github.com/azogue/eventsensor

stue_dimmer and gang_dimmer are both entities of that sensor. My setup is a bit complex, I let each dimmer control several lights. Button 2 and 3 (up and down) are however the dimmer actions.

Here is my automation:

- id: dimmer
  alias: Dimmer
  description: ''
  trigger:
  - entity_id: sensor.stue_dimmer
    platform: state
    to: 2_hold
  - entity_id: sensor.stue_dimmer
    platform: state
    to: 3_hold
  - entity_id: sensor.gang_dimmer
    platform: state
    to: 2_hold
  - entity_id: sensor.gang_dimmer
    platform: state
    to: 3_hold
  condition: []
  action:
  - data_template:
      trigger_unit: '{{ trigger.to_state.entity_id }}'
      trigger_state: '{{ trigger.to_state.state }}'
      light: "{% if trigger.to_state.entity_id == 'sensor.stue_dimmer' %}\n  light.alle_stuen\n\
        {% else %}\n  light.alle_gangen\n{% endif %}\n"
    service: script.dimmer_script

and my script:

dimmer_script:
  sequence:
  - alias: Dim opp eller ned
    repeat:
      sequence:
      - service: light.turn_on
        data_template:
          entity_id: '{{ light }}'
          brightness: >
            {% set current = state_attr(light,'brightness')|default(0)|int %}
            {% set step = states('input_number.light_step')|int %}
            {% if trigger_state  == '2_hold' %}
              {% set next = current + step %}
              {% if next > states('input_number.light_maximum')|int %}
                {% set next = states('input_number.light_maximum')|int %}
              {% endif %}
            {% else %}
              {% set next = current - step %}
              {% if next < states('input_number.light_minimum')|int %}
                {% set next = states('input_number.light_minimum')|int %}
              {% endif %}
            {% endif %}
            {{ next }}
      - delay:
          milliseconds: 100
      until:
      - condition: template
        value_template: '{{ states(trigger_unit) != trigger_state }}'

Now, this script will dim up (2_hold) or down (3_hold) until the state of the dimmer sensor changes.

The automation sends the light to dim, the triggering unit (dimmer) and the trigger state to the script, and the script dims the light up/down according to the trigger state, until the triggering unit changes state again.

I am pretty satisfied with this. If you have one dimmer per light, you can of course do things simpler.

Completion of my setup: Button 1, short hold is toggle light on/off, and button 4, short hold is “cycle active light” (which rotates an input_select).

@vegardengen

This looks really promising actually. Still a lot of automations and scripts, but never come upon the “repeat until” function in the script.

I don’t really get why you need the event sensor though.
My ZigBee button sends an event on short click, another on hold and a third on release. Would I not just be able to use these events as the triggers?

Would I be able to set the until to listen for a ZHA event? Or how would go about going until the button is released?
Is that why you are using the event sensor, so it is an actual entity in HA, that the until will look at.
It’s been a couple of months since I messed with HA automations and scripts.

This WTH is not specific on the technology

I will like to emphasize that my “recipe” is specific to lights that use the Zigbee protocol.

The problem with a protocol like Zigbee (“Ooh the Zigbee”) is that it is a slow mesh network that easily gets saturated.

If you have a living room with say 7 Zigbee light bulbs and you implement a dim up or down automation by sending small increments to each bulb several times maybe 10 times per second then it means sending 70 messages per second. Some of these messages will be sent and retransmitted by devices that repeat the signal in the mesh.

The typical problem you will see is that some of the light bulbs will not dim as much as others.

What the Philips and Ikea hubs do are two things.

First you define a Zigbee group. You define a room called Living Room and you put your 7 bulbs in his group. These devices now react on messages sent to the group and you have already reduced the number of messages by a factor 7.

The second thing they so is to send an increment message. In Zigbee because of how things are implemented, the best is to increment the brightness by a value 254. Not the 255 you may think. It just does not work with 255 on many bulbs or Zigbee dimmers. And you send the command with a transition time which is defined so the dimming from minimum to maximum takes some seconds.

Most Zigbee light devices are implemented so they work on the grand father of all Zigbee hubs: Philips Hue, so they all seem to be implemented so when you send a message to increment the brightness by 0, while they are in the transition, they stop the transition.

So the Philips and Ikea dimmers on the hubs are implemented so when you press and hold the increase button, the hub sends an increment message to the bulb or the group of bulbs with a value of 254. And when you release the button, the same message is sent with the increase value of 0

When you press the decrement button, it sends a message to increase the brightness by -254.

The result is a smooth transition of brightness that lasts while you press the button and stop when you release it. And on the Zigbee network only two messages are sent.

This is a unique Zigbee thing. You cannot just implement it as a generic light feature in Home Assistant. So any implementation has to happen in the relevant integration. Zigbee2MQTT needs to implement it in their system and then Home Assistant can use it without any code changes to Home Assistant.

It is essential to note that Home Assistant alone cannot implement this.
It has to be the individual Zigbee software that needs to have the ability to both define Zigbee groups and make the lights know that they are members of this group, and it needs to implement the incremental change of brightness.

ZHA has groups added recently. All it needs is the ability to increase and decrease brightness (in addition to setting an absolute value) and it must be able to send the value 0 for the increase.

I cannot imagine how Home Assistant core can implement a generic feature for this that will fit any technology. It will always be something you have to implement specifically in an automation.
A Wifi based lightbulb may not have a command that is equivalent. I cannot see how you could add this to the genetic light commands.

One thing you can do with Home Assistant and Deconz and cannot do in Philips Hue is define the speed of the transition. By changing the transition time in my method you can decode how quickly you want the light to increase or decrease. You can even have different speed for the two.

8 Likes

See how I do it here. I think I’m doing it how you envision. I listen for the ZHA hold and release events and use these to start and stop a loop that uses the brightness step service to dim or brighten the light. The service is called four times a second and steps 5% each call, so full sweep in 5 seconds.

It works perfectly with an Ikea two button dimmer remote and a conbee ii coordinator.

That is the problem

You step the brightness several times per second.

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.

1 Like

Yeah I use this for single bulb lamps. I have the same logic on a four bulb group but the experience isn’t as nice.

@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.

I’d be interested in this being implemented too.

Maybe we need to add a feature request in their GitHub.

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.

You can find the community forum topic in here.

1 Like

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.

bedroom_light:
  module: controllerx
  class: E1743Controller
  controller: 14:b4:57:ff:fe:6c:5c:ac
  integration: zha
  light: light.light_basement_room
  actions:
    - "on"
    - "off"
    - "hold"
    - "release"

Okay I figured it out, I just had to scroll further down on the page. I was just skim reading to fast.

bedroom_light:
  module: controllerx
  class: E1743Controller
  controller: 14:b4:57:ff:fe:6c:5c:ac
  integration: zha
  light: light.light_basement_room
  actions:
    - "on"
    - "off"
    - "move_with_on_off_0_83"
    - "move_1_83"
    - "stop"
1 Like