Controllerx: [FEATURE REQUEST] Use move instead of stepping value with transition

[jeroenvansch]

Feature Request

Is your feature request related to a problem?

I noticed that the brightness hold funtion doesn't dim smoothly with my Tradfri lights. And also quite a lot of traffic on the zigbee network during Hold functions.

Describe the solution / feature you'd like

Instead of sending a new brightness value to the lights with a transition time every second you could just send the "brightness_move": [value] command upon the "Hold" action and the "brightness_move" : 0 command upon the "release" action.
this results in smooth dimming and less traffic.

I don't know if all lights support this, Tradfri and Hue do, but maybe offer it as an alternative in the config so the current way is still available.

Describe alternatives you've considered

Not using ControllerX, but thats not really a good alternative ;)

Additional context

[xaviml]

Hi @jeroenvansch,

Thank you for opening this issue. First of all, ControllerX was first created to do such behaviour, so it is able to support different integrations and different lights. What you are mentioning is related to Zigbee2MQTT, is that correct? deCONZ also has its way of doing so, but not ZHA as far as I know. So since each integration is different, I came up with a solution that would work for everyone - send requests periodically to HA and let HA handle the requests.

If you are having issues with your network, I would recommend you tweaking the delay parameter, so fewer requests are sent to HA.

Having said this, I love your idea, in fact, this is related to #118, which propose to send MQTT requests rather than sending call services to HA. However, this is not an easy change, to do, but it is something I will be adding, so ControllerX with Zigbee2MQTT can be used without the need of HA, therefore, improving the performance and the overall experience. What I did not consider is that Zigbee2MQTT has the brightness_move option, so thank you for pointing this out!

I will keep this ticket open, but it will be handle by #118.

Cheers,
Xavi M.

[jeroenvansch]

Hi @xaviml,

You are correct in assuming my setup uses Z2M. Being able to directly send commands to MQTT would indeed be a major improvement!
Would you like an example of the automations from HA that I use to get smooth dimming/CCT changes using the Brightness move/step commands?

regards,
Jeroen

[xaviml]

Hi @jeroenvansch,

An example of your current automation would be indeed helpful, thank you :)

Regards,
Xavi M.

[xaviml]

Hi @jeroenvansch,

I have been playing today with the current code of ControllerX to achieve what we aim for this ticket:

exampe_app:
  module: controllerx
  class: E1810Controller
  controller: livingroom_controller
  integration: 
    name: z2m
    listen_to: mqtt
  light: light.livingroom_lamp
  smooth_power_on: true
  multiple_click_delay: 250
  merge_mapping:
    brightness_up_hold:
      service: mqtt.publish
      data:
        topic: zigbee2mqtt/livingroom_light/set
        payload: '{"brightness_move": 60}'
    brightness_down_hold:
      service: mqtt.publish
      data:
        topic: zigbee2mqtt/livingroom_light/set
        payload: '{"brightness_move": -60}'
    brightness_up_release:
      service: mqtt.publish
      data:
        topic: zigbee2mqtt/livingroom_light/set
        payload: '{"brightness_move": 0}'
    brightness_down_release:
      service: mqtt.publish
      data:
        topic: zigbee2mqtt/livingroom_light/set
        payload: '{"brightness_move": 0}'

I overwrote the brightness hold and release actions to call MQTT topic you mentioned, and this works as expected. This is just a proof of concept for me to know it is viable, the idea now is do this calls internally and through the MQTT integration with AppDaemon, so without communicating to HA.

I will keep you updated with my advancements.

Regards,
Xavi M.

[htvekov]

Hi' @jeroenvansch & @xaviml

Just stumbled over this feature request by accident.

Have tested with completely default setting for an E1810 controller and only tweaked bringtness_move from 60 to 80.
This gave a 100% smooth transition in brightness from 0 to 255 and down again on an Ikea E14 White Spectrum bulb.
Never (as in NEVER !) experienced this before using z2m and HA / ControllerX with ANY settings of delay/automatic_steps.

This is as smooth as with proprietary Hue bridge and Hue dimmers.
Amazed I've never actually heard of brightness_move command before ?

We need this, Xavi !! 😁😆🎄🎁🎉😉
Well, if we could get this implemented along with ControllerX ->MQTT commands then my Hue Bridge will be obsolete for sure 😉
Then I'll be able to do perfect, smooth dimming, both single bulbs and zigbee groups, through ControllerX and z2m integration 😎👍

Merry Christmas guys and stay safe 🎄🎉🍻🍻

[xaviml]

Hey @htvekov,

I am glad it worked really well. I would love to implement this in ControllerX as you know, but it is not an easy task since ControllerX deeply depends on HA call services and calling it periodically with hold actions. I was thinking that the same way we have a integration attribute that indicates the integration of the controller (input), I would add an integration_output (name TBD) that would define the integration of the entity (light, media player, etc) which is the output. However, this is a very expensive solution since I will need to add support for all the integration and all the entities for it.

Another solution I thought was to ad a new attribute for light controller to define the strategy of the hold-release actions:

• default: What is currently doing
• z2m_mqtt: Implement connection directly with MQTT broker to change brightness or other attributes.
• z2m_ha: Same as the previous one, but calling the mqtt.publish service from HA (as the example above)
• deconz: deCONZ supports something similar to brightness_move

And more to come when needed. Probably this second option is cheaper in time, but it will still give the results we want.

Regards,
Xavi M.

[htvekov]

Hi' @xaviml

As ControllerX from the very beginning was build with HA as core integration, I wouldn't suggest to start all over and build yet another complete parallel MQTT integration from scratch.

Neither, I don't believe there's an actual need for a full MQTT integration (non HA dependant) now or in future ?
HA integration as is, is extremely powerfull and has virtually very few limitations.
But, as discussed in other threads, HA state machine calls/requests can be quite time consuming and for many commands through HA integration lag becomes notisable compared to eg. direct MQTT integration.

A MQTT 'light' light entity integration 😉 as you've scheduled, would in my opinion be sufficient and add great value to ControllerX.

On, off, toggle and use of move and step commands for color/brightness control directly from ControllerX as MQTT commands (single entitys or groups) would be awesome ! 😉😎

Ciao !

[xaviml]

Hi Henning,

Thank you for your input. I totally agree with you, it would be time-consuming to start all over again to add this functionality, so I will be adding the MQTT functionality to the light controller as I described earlier. This way we can define how we want the light controller to work.

Regards,
Xavi M.

[htvekov]

Awesome, Xavi 👍😊

Let me know when there's something to test and I'll gladly assist.