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

Archive Month of "What the heck?!" (2020)
9

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
10

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.

11

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

12

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

13

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.

9 Likes
14

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.

15

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

16

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
17

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.

18

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

19

I’d be interested in this being implemented too.

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

20

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
21

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
22

Hi @AnthonMS,

Each controller fires different actions for each integration (z2m, deconz and zha). In your case, the actions for ZHA for this controller are:

  • on → Click “I”
  • off → Click “O”
  • move_with_on_off_0_83 → Hold “I”
  • move_1_83 → Hold “O”
  • stop → Release “I” or “O”

Since this is something that ControllerX already knows, it gives a default mapping to the controller:

  • Click “I” → Turn on
  • Click “O” → Turn off
  • Hold “I” → Brighten up
  • Hold “O” → Brighten down

So you just need to add the minimum configuration if you want to use the default mapping:

bedroom_light:
  module: controllerx
  class: E1743Controller
  controller: 14:b4:57:ff:fe:6c:5c:ac
  integration: zha
  light: light.light_basement_room

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.

Cheers,
Xavi M.

23

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.

1 Like
24

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.

Regards,
Xavi M.

25

Hi @KennethLavrsen,

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.

1 Like
26

Maybe it is not implemented in ZHA. I only know it works in Deconz

27

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.

1 Like
29

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?