Controllerx: [BUG] transition parameter not applied on hold action

[e9henrik]

Bug report

Description

Specifying transition parameter in light controller has no impact when holding controller buttons, only when clicking them. The impact of this is that the light transition when holding is not smooth.

Expected behaviour:
Transition parameter should be considered when brightness button is held down, or a configuration option for hold_transition should be added.

Additional information

• Devices involved:

  • Model: IKEA E1810 as Light

• Integration: deconz

• addon-AppDaemon version: [ 0.2.5 ] (Appdaemon 4)
• ControllerX version: [ v2.7.1 ]
• HACS version (if installed from there): [ 0.24.5 ]
• Home Assistant Core version: [ v0.109.6 ]

AppDaemon app configuration

light_controller_rgb:
  module: controllerx
  class: E1810Controller
  controller: light_remote
  integration: deconz
  light: light.lampa_rgb
  action_delta: 10
  add_transition_turn_toggle: false
  transition: 500
  actions:
    - 3002
    - 4002
    - 5002
    - 2001
    - 2003
    - 3001
    - 3003
    - 4001
    - 4003
    - 5001
    - 5003

Logs

2020-05-23 23:46:14.481760 INFO AppDaemon: Initializing app light_controller_rgb using class E1810Controller from module controllerx
2020-05-23 23:46:14.502827 INFO light_controller_rgb: 🎮 ControllerX v2.7.1
2020-05-23 23:47:56.426038 INFO light_controller_rgb: 🎮 Button event triggered: `3002`
2020-05-23 23:47:56.429433 INFO light_controller_rgb: 🏃 Running `click_brightness_down` now
2020-05-23 23:47:56.440364 INFO light_controller_rgb: 🤖 Service: light.turn_on
2020-05-23 23:47:56.445062 INFO light_controller_rgb:   - entity_id: light.lampa_rgb
2020-05-23 23:47:56.449613 INFO light_controller_rgb:   - brightness: 42.60
2020-05-23 23:47:56.454289 INFO light_controller_rgb:   - transition: 0.50
2020-05-23 23:47:56.455784 DEBUG AppDaemon: call_service: namespace=default domain=light service=turn_on data={'entity_id': 'light.lampa_rgb', 'brightness': 42.6, 'transition': 0.5, '__name': 'light_controller_rgb'}
2020-05-23 23:47:58.027674 INFO light_controller_rgb: 🎮 Button event triggered: `3002`
2020-05-23 23:47:58.032619 INFO light_controller_rgb: 🏃 Running `click_brightness_down` now
2020-05-23 23:47:58.042631 INFO light_controller_rgb: 🤖 Service: light.turn_on
2020-05-23 23:47:58.047571 INFO light_controller_rgb:   - entity_id: light.lampa_rgb
2020-05-23 23:47:58.052521 INFO light_controller_rgb:   - brightness: 16.60
2020-05-23 23:47:58.057275 INFO light_controller_rgb:   - transition: 0.50
2020-05-23 23:47:58.058913 DEBUG AppDaemon: call_service: namespace=default domain=light service=turn_on data={'entity_id': 'light.lampa_rgb', 'brightness': 16.6, 'transition': 0.5, '__name': 'light_controller_rgb'}
2020-05-23 23:47:59.766774 INFO light_controller_rgb: 🎮 Button event triggered: `2001`
2020-05-23 23:47:59.770650 INFO light_controller_rgb: 🏃 Running `hold_brightness_up` now
2020-05-23 23:47:59.798387 INFO light_controller_rgb: 🤖 Service: light.turn_on
2020-05-23 23:47:59.803734 INFO light_controller_rgb:   - entity_id: light.lampa_rgb
2020-05-23 23:47:59.808701 INFO light_controller_rgb:   - brightness: 41.40
2020-05-23 23:47:59.813942 INFO light_controller_rgb:   - transition: 0.35
2020-05-23 23:47:59.817628 DEBUG AppDaemon: call_service: namespace=default domain=light service=turn_on data={'entity_id': 'light.lampa_rgb', 'brightness': 41.4, 'transition': 0.35, '__name': 'light_controller_rgb'}

[htvekov]

Hi' @e9henrik

I don't believe it's a bug, but intentionally made by Xavi like this 🙂
I'm using z2m integration, but behaviour should be exactly identical.

When you hold the buttons to adjust brightness automatically, then transition has to 'keep up' with the delays between each call up/down in brightness. So delay also adjusts transition for these events, to keep transition period at same milliseconds as in between then calls.

So if you wish for 'smoother' transition when holding the buttons, you'll have to increase default delay (350 ms.) for E1810 like this:

office3_controller:
  module: controllerx
  class: E1810Controller
  controller: sensor.0xec1bbdfffe1b99e8_action #Ikea 5 button remote
  integration: z2m
  transition: 500
  delay: 1000
  add_transition_turn_toggle: false
  light: light.0x680ae2fffe924460_light # Office desk lamp

Here you'll have slow but real smooth automatic brightness and 500 ms. transition when clicking.

2020-05-24 01:59:42.152380 INFO office3_controller: 🎮 Button event triggered: `brightness_down_click`
2020-05-24 01:59:42.156361 INFO office3_controller: 🏃 Running `click_brightness_down` now
2020-05-24 01:59:42.165790 INFO office3_controller: 🤖 Service: light.turn_on
2020-05-24 01:59:42.170640 INFO office3_controller:   - entity_id: light.0x680ae2fffe924460_light
2020-05-24 01:59:42.178921 INFO office3_controller:   - brightness: 203.60
2020-05-24 01:59:42.184034 INFO office3_controller:   - transition: 0.50
2020-05-24 01:59:43.935179 INFO office3_controller: 🎮 Button event triggered: `brightness_down_hold`
2020-05-24 01:59:43.938781 INFO office3_controller: 🏃 Running `hold_brightness_down` now
2020-05-24 01:59:43.948163 INFO office3_controller: 🤖 Service: light.turn_on
2020-05-24 01:59:43.957378 INFO office3_controller:   - entity_id: light.0x680ae2fffe924460_light
2020-05-24 01:59:43.963690 INFO office3_controller:   - brightness: 177.60
2020-05-24 01:59:43.969350 INFO office3_controller:   - transition: 1.00
2020-05-24 01:59:45.063683 INFO office3_controller: 🤖 Service: light.turn_on
2020-05-24 01:59:45.068722 INFO office3_controller:   - entity_id: light.0x680ae2fffe924460_light
2020-05-24 01:59:45.073653 INFO office3_controller:   - brightness: 152.20
2020-05-24 01:59:45.078577 INFO office3_controller:   - transition: 1.00
2020-05-24 01:59:45.455218 INFO office3_controller: 🎮 Button event triggered: `brightness_down_release`
2020-05-24 01:59:45.459351 INFO office3_controller: 🏃 Running `release` now

Ciao !

[xaviml]

Hi @e9henrik,

As @htvekov said, this is done on purpose, the transition for the hold actions is computed from the delay attribute, which is the time between each HA call to increase or decrease the attribute (e.g. brightness or color temp). So the longer the delay is, the longer the transition should be. You can see in here and here that the transition is equal to delay / 1000 since delay is in milliseconds and transition must be in seconds.

However, there is something I do not agree with @htvekov, if you want a much smoother transition on the brightness or color temp, I recommend lowering down the delay attribute (default 350ms), but by doing this, you will send more requests per second and this might affect your network. Personally, I do not recommend lowering it down more than 100.

Therefore, if I change the code to use the transition attribute on the hold action, you will experience unexpected behaviour since the transition will be slow, but the brightness change will be quick. For this reason, I leave this issue as closed.

Let me know if you have any questions about it.
Thanks :)

[htvekov]

Hi' Xavi

Ok, not the best example I could have made. But it was just with random extreme numbers to show the difference from default settings 😉

I believe that the 'smoothness' of dimming experience could be somewhat bulb/manufacturer dependent. Ikea WS bulbs (especially high lumen output bulbs) do not dimm nicely (chunky) and do not support dimming to really low light levels like eg. Hue bulbs. But hey, they are very cheap, stable and delivers high lumen levels 🌞😎👍

If I decrease default delay without adjusting automatic_steps as well, the dimming of an Ikea WS bulb on z2m will be notisable 'chunky'. I can 'smooth it out' increasing the automatic steps. But my personal best experience is with some 450 ms. delay (transition) and some 8 automatic_steps or so. Bulbs firmware is somewhat better at doing the transition than increased amount of calls with smaller steps. But no way near as smooth and perfect 'fluid' dimming as Hue bulbs.

Ciao ! 🙂🙋‍♂️

[xaviml]

Hi Henning,

That is true, firmware can affect on this and also the integration. As a matter of fact, I have tried ControllerX with deconz and I experienced a much better smoothness with delay: 100 and automatic_steps: 20. Something that I could not achieve with z2m. So yes, depending on the setup it will change, but you made the point, the two parameters to change the smoothness are delay and automatic_delay, they go together in the configuration.

Thanks for clarifying this! :)

[htvekov]

Hi' Xavi.

Yep. I believe that this can only be improved by skipping need for HA state detection -> MQTT -> Zigbee with direct MQTT implementation in ControllerX 😉😁

With my newest Tasmota/switchmode 'project', I also experience a very slight toggle delay using HA state and ControllerX. If I use HA automation with MQTT platform instead (only for toggle of lights), toggle is simply some (estimated) 100-150 ms. faster (very near instant). Doesn't sound like much I know, but the difference is really notisable IRL.

I've actually just upgraded my HA hw from a RPi 3+ to a NUC, and experience is still exactly the same. No experienced speed improvement there. It simply takes some extra time when HA state machine is part of the equation.

[xaviml]

Hey Henning!

I believe that this can only be improved by skipping need for HA state detection -> MQTT -> Zigbee with direct MQTT implementation in ControllerX

You are totally right with this and I was planning to add compatibility to integrate z2m with matt directly. I now it is possible, I just need some time for it. I will let you know if I get down to this for testing :)

I've actually just upgraded my HA hw from a RPi 3+ to a NUC

Nice! Is it better in general?

[htvekov]

Hi' Xavi.

No rush ! 😉
Summer is almost here, covid-19 is on slow retreat in Europe and you also have to enjoy life with a 🍻 with friends/family - OUTSIDE ! 🌞😎

Everything works perfectly as it is now. But I'm quite convinced that there will be a notisable difference in responsiveness for ControllerX apps, cutting out HA's state machine from the equation and communicating directly with the MQTT server 🚀🚀😎 I have the general feeling that MQTT servers in general are really really fast. But I've no idea how to do some real tests with precise timing. Can z2m deliver logs with milliseconds ?

I'll be glad to test when/if you get the time for implementing MQTT directly in ControllerX 👍

The basic 'core' things in HA (state machine, MQTT, automations in general etc. seems to be about the same speed as with my RPi3+ Didn't really expect a rapid improvement, as my RPi actually was doing fine and CPU was not heavily loaded. I had already months ago switched from SD card to SSD disc on the RPi. SD cards are simply not fast or stable enough for a production environment running 24/7.
But viewing logs and history, frontend in general + rebooting is much much faster on the NUC 🚀🚀
I also wanted a more 'stable' production environment, without spending a large amount of money on a brand new NUC set-up. Ended up buying a second hand NUC5PPYH with 8GB ram for some 65 Euro. All it needed was a SSD from the drawer and a HA image. Cheap upgrade and the Pentium N3700 1,6GHz processor can easily do the task. It's running almost idle around 5% CPU use most of the time 😁

Any progress on the 'dimming direction' code improvement we discussed earlier ? 😃

Ciao !

[xaviml]

Hi Henning,

Any progress on the 'dimming direction' code improvement we discussed earlier?

I remember we discussed this in another issue and here is my comment about it. I am just attaching it, so I do not lose track of it. However, I will create an issue about it and try to tackle it as soon as I can! Thanks for the reminder @htvekov . I will also create an issue for the MQTT compatibility to z2m integration.

Ended up buying a second hand NUC5PPYH with 8GB ram for some 65 Euro

That is a good bargain! I would have bought it if I were you as well, that is for sure.

Cheers!

[htvekov]

Sounds great, Xavi 👍

Wish you a lovely weekend 🌞😎🍻