Question @ Erik - Dimming functionality on button holds?

[imbaimbaimba]

Hi @ebaauw

Thank you for your really amazing explanations of the deCONZ and huebridge functionality. I have been really struggling with one specific thing.l, that I thought you might be able to help me answer.

So I have Hue bulbs in the whole house that are currently connected to my deCONZ server, to ensure mesh for my Xiaomi sensors. Works great, and can call scenes like you explained me, at least from Home Assistant. My issue comes with my wall switches that are all Z-Wave. These wall switches gives events for clicks, holds, releases etc. Trying to use this in automation seems like a way more difficult task than I had ever imagined. It seems most automation examples flood the zigbee network with a gazillion commands to dim each little step, and does not work well at all. The result is the bulb continues to change brightness long after letting go, by means of the waiting commands.

I found that Hubitat has a function called StartLevelChange with a drop-down for up/down that will send the bulb slowly dimming towards 0 or 100. Along with this, they have a StopLevelChange button. I thought maybe something like this could be possible with deCONZ in some way? That would make it really easy to automate with button hold to start the transition and button release to stop it again - also this would only send those two zigbee commands to avoid flooding the network.

Now I don’t know how the Hue Dimmer switch functions, but the functionality of that is really what I am after. Maybe that functionality can be read out and replicated?

I’m really wondering why no one has solved this yet, as it seems like a very commonly needed feature set.

Do you have any insight on this, or could help me try to look at it? I’ll gladly donate you some tips for the trouble!

[ebaauw]

There are several Zigbee commands to change the level (brightness). If memory serves, when bound directly to a light (in standalone mode, without the Hue bridge) or group (using the associated group in deCONZ), the Hue dimmer switch sends Step on press, Move on hold, and Stop on long release. When bound to the Hue bridge or deCONZ, it sends events for press, hold (every second while holding), short release and long release. The Hue app creates rules to set state.bri_inc with some specific value and transitiontime on press and hold. The bridge (and I think deCONZ as well) translates this to a Step command. On release, the Hue app rules set state.bri_inc to 0, which is translated to a Stop command.

The values for the bri_inc seem chosen to make the transition look as natural as possible given the fixed timing of the Hue dimmer events. You would have to play around to find the suitable values for your Zwave switches (and any delays by HA).

Still I find the Move / Stop sent by the dimmer in standalone mode looks better. I use these instead of rules for the dim up/down buttons (also as a fallback, in case the gateway or my home network is down). This can only be done with ZigzBee switches, there is no REST API call that translates to Move. You might try rules setting state.bri to 254 or 0 with a longer transitiontime on hold and state.bri_inc to 0 on release. However setting state.bri translates to a Move to Level, causing the transition rate to depend on the starting level (it will take e.g. 2 seconds to move to level 254, both when starting at 1 as well as when starting at 127 - in the latter case, the brightness changes half as per second).

There’s no equivalent of state.bri_inc in HomeKit.

[imbaimbaimba]

Thank you so much for the valuable insight again.

It would be great if it was possible to implement a "translator" that could emulate Hue (the step/move/stop commands in this case) from Z-Wave events, or basically any other inputs. I assume that is not something that exists yet. I also thought a lot about how I could also implement wall switches to control deCONZ, maybe by wiring all wall switches to a central controller that "talks hue" - Like some diyhue? I never came u pwith anything good unfortunately.

Unfortunately, no ZigBee wallswitches exist that fit our Danish standard. The Logic Group switches are the only options we have, and are Z-Wave:
https://logic-group.com/products/matrix-switches/
https://logic-group.com/wp-content/uploads/2018/06/matrixd4-print_forfra-1200x1200.jpg
The rest of my switches have either a Fibaro Dimmer 2 (to dim a non-smart bulb) or Fibaro Double Switch 2 (without load).
So all my wall switches are based on Z-Wave events.

So in regards to the information you provided, I got some initial ideas to how it could possibly be done. This is assuming I use a system like Home Assistant to handle the automation between the Z-Wave switches and deCONZ setup. Then I could just run your homebridge platform in parallel for everything else basically. I would like to only do what is aboslutely necessary in the advanced platform, and keep the rest in HomeKit.

So if i understand you correctly, the challenge is the transition time, that will need to be dynamic depending on the difference in the initial brightness value, and the end point.
My immediate idea is to start by replicating a standard in dimming behaviour. I therefore just checked the Fibaro Dimmer 2 standard values:
Default step = 0,05s
Default size = 1%

So this means that Fibaro changes 20% or 51(out of 255) per second. Relating this to the initial value and differentiating it between dimming and brightening should give something like these two functions:
transitiontime.dimming [seconds] = InitialBrightness / 51
transitiontime.brightening [seconds] = (255-InitialBrightness) / 51

The ZHC5010 wall switches work with:
scene_id: 1-4 (button 1-4)
scene_data: (Single click = 0, Release = 1, Hold = 2, Double click = 3)

So, I have absolutely zero experience working with APIs, but I assume this is the kind of automation that would be needed?

• id: '0000000000004'
  alias: Hold - Brighten light
  trigger:
  • event_data:
    entity_id: zwave.logic_soft_zhc5010_wall_switch
    node_id: 1
    scene_data: 2
    scene_id: 1
    event_type: zwave.scene_activated
    platform: event
    condition: state
    entity_id: light.examplelight
    state: 'on'
    condition: numeric_state
    entity_id: light.examplelight
    value_template: states.light.examplelight.attributes.brightness
    below: 128
    action:
  • rest_command:
    climate_to_on:
    method: POST
    url: 'https://192.168.1.2:8080/api/apikey/lights/lightid/state'
    password: 'xxxxxx'
    content_type: application/json
    payload: '{
    "on": "true",
    "bri":255,
    "transitiontime": transitiontime.brightening
    }'

Now, I have no implement the calculation into it, but I can surely figure that part out.
What do you think?

On a side note, I have a question I want to ask you regarding ZHA and ZLL and using bulbs as ZigBee routers. Since I have been trying to solve this functionality I am looking for here for a while, I have gotten feedback and tips a lot of places. I keep hearing that it is asking for problems to use ZHA and ZLL on the same mesh, and I also keep hearing that bulbs in general are the worst type of ZigBee routers. Practically speaking, I like having my Hue lighting and Xiaomi sensors on the same ZigBee mesh, as the Hue covers the whole house with mesh for the sensors. Given your experience and knowledge, I would like to know your opinion on this. Is the setup I have going feasible long term, or should I consider splitting mesh, adding routers or anything like that?

[imbaimbaimba]

Made some progress.
What I got below actually works for clicking to toggle on/off, double-click to turn on at 100% and holding to dim either way on the same button. So if I set a value like 50 (1/10 seconds) in transitiontimevariable, it runs - that is where I put the ???????s below.

Now my problem is with the consistent speed of the transition, and what direction it goes in. It seems to me that the problem relates to the brightness value in Home Assistant is not being updated in deCONZ fast enough. So using states.light.light1.attributes.brightness does not seem viable.

What I see is that it does not always figure out that brightness is above or below 157, and then goes the wrong direction. Also trying to calculate a transitiontime from the brightness value in home assistant does not seem to be working.

What do you think of what I got till now? And do you have any ideas how maybe the transitiontime calculation could be carried out in the API calls? Or a different approach for it?

 rest_command:
  light1stop:
    url: 'http://myip:port/api/XXXXXXXXXX/lights/1/state'
    method: PUT
    headers:
      content-type: application/json
    payload: '{"bri_inc":0}'
  light1startup:
    url: 'http://myip:port/api/XXXXXXXXXX/lights/1/state'
    method: PUT
    headers:
      content-type: application/json
    payload: '{"on": true,
              "bri": 255,
              "transitiontime": "{{ transitiontimevariable }}"}'
  light1startdown:
    url: 'http://myip:port/api/XXXXXXXXXX/lights/1/state'
    method: PUT
    headers:
      content-type: application/json
    payload: '{"on": true,
              "bri": 1,
              "transitiontime": "{{ transitiontimevariable }}"}'
 
 automation:
    - alias: 'light1 - brighten'
    trigger:
    - event_data:
        entity_id: zwave.fibaro_system_fgs223_double_relay
        node_id: 24
        scene_id: 2
        scene_data: 2
        event_type: zwave.scene_activated
        platform: event
    condition:
        condition: or
        conditions:
        - condition: template
            value_template: '{{ states.light.light1.attributes.brightness < 157 }}'
    action:
      - service: rest_command.light1startup
        data:
          transitiontimevariable: !?!?!?!?!?

    - alias: 'light1 - dim'
    trigger:
    - event_data:
        entity_id: zwave.fibaro_system_fgs223_double_relay
        node_id: 24
        scene_id: 2
        scene_data: 2
        event_type: zwave.scene_activated
        platform: event
    condition:
        condition: or
        conditions:
        - condition: template
            value_template: '{{ states.light.light1.attributes.brightness > 157 }}'
    action:
      - service: rest_command.light1startdown
        data:
          transitiontimevariable: ???????????????????

    - alias: 'light1 - brighten'
    trigger:
    - event_data:
        entity_id: zwave.fibaro_system_fgs223_double_relay
        node_id: 24
        scene_id: 2
        scene_data: 1
        event_type: zwave.scene_activated
        platform: event
    condition: []
    action:
      - service: rest_command.light1stop

    - alias: 'light1 - toggle'
    trigger:
    - event_data:
        entity_id: zwave.fibaro_system_fgs223_double_relay
        node_id: 24
        scene_id: 2
        scene_data: 0
        event_type: zwave.scene_activated
        platform: event
    condition: []
    action:
        service: light.toggle
        entity_id: light.light1

    - alias: 'light1 - on full'
    trigger:
    - event_data:
        entity_id: zwave.fibaro_system_fgs223_double_relay
        node_id: 24
        scene_id: 2
        scene_data: 3
        event_type: zwave.scene_activated
        platform: event
    condition: []
    action:
        service: light.turn_on
        entity_id: light.light1
        data_template:
        brightness: 255

[ebaauw]

This looks like the right approach, at least in theory. In practice there might be some issues:

• The deCONZ REST API plugin keeps a cache of the light state, when you GET it through the API, it returns the cached value, instead of retrieving the actual value from the light. The cache is updated perodically, when polling the light, and on each command sent to the light (where the API tries to predict the new value). This prediction works fine on “regular” PUTs of state.bri, but tends to fail on state.bri_inc and/or longer transition times.
• Most Zigbee switches that support dim up/down using a single button either change direction on each press/hold, or on the light reaching maximum or minimum brightness. By adopting the first approach, you could eliminate the dependency on the correct brightness for the direction.
• Then there’s the question how frequently HA updates the value in the light attributes, after deCONZ has updated its cache. I don’t know HA, but if they’re listening to deCONZ’ websocket notifications, this should be OK. If not, you might want to implement the logic in deCONZ rules instead of in HA. In that case, you would create a CLIPGenericStatus sensor to reflect the event from the ZWave switch, and update that sensor from HA. The deCONZ rule would have a triggering condition in the CLIP sensor and an additional condition on the light’s brightness (hoping that’s supported, I’m not really sure),
• It is definitely not possible to do the transitiontime calculation in deCONZ REST API rules. If would be possible to create a series of rules, each for a different range of brightness values with a different, hardcoded, transitiontime. Ugly, but effective. I’d use a script to create and/or update the rules.

[ebaauw]

I keep hearing that it is asking for problems to use ZHA and ZLL on the same mesh

Fake news. ZHA vs ZLL are at a higher level in the Zigbee stack, meshing is at a lower level.

and I also keep hearing that bulbs in general are the worst type of ZigBee routers.

Also fake news. The Hue bulbs tend to be the most reliable routers.

Having said that, the Zigbee standard leaves a lot open to interpretation, and different vendors implement the standard differently. While most of these differences are at the application (ZHA vs ZLL) level, some also apply to the meshing. deCONZ seems to be one of the few gateways/hubs/bridges that actually builds a map of the Zigbee network. It does so by polling the routers for their neighbours and routing tables - not all routers appreciate that. Also, there seem to be multiple ways to discover routes (I don't know the technical details), notably between deCONZ/Philips vs IKEA.

Practically speaking, I like having my Hue lighting and Xiaomi sensors on the same ZigBee mesh, as the Hue covers the whole house with mesh for the sensors.

Same here. Note that Xiaomi sensors stick to the router they connected to on pairing, and, unlike other sensors, don't switch to a new parent when the parent is unavailable or out of reach. Make sure to pair them at their target location and don't use traditional wall switches to power down routers.