ControllerX. Bring full functionality to light and media player controllers

[Bastian007]

I have been using ControllerX for more than 2 or 3 years successfully. And I am pleased about this useful and reliable framework! Thanks!

As I need to include further lights and switches, I wonder what kind of plans you have with that integration mid- or long-term? @xaviml
Having breaking changes such as Zigbee2MQTT in mind, are you going to support this solution in the future? Is there any further evolution planned (e.g. frontend maintenance without YAML)?
Or would you even recommend using HA onboard capabilities like automations/blueprints etc to connect controllers with lights?

I am really curious what you and maybe other ControllerX users think about the path forward.

[xaviml (Xavi Moreno)]

Hi @Bastian007 ,

ControllerX is still an active project, however, I had a hard time to put time on it. I still use ControllerX in my house with Zigbee2MQTT with MQTT integration (no action sensor from HA).

That in mind, I understand that the mqtt does not support the same capabilities as the regular Zigbee2mqtt integration (i.e. color loop), so I have the intention to update code to support the new event trigger from HA, instead of sensor.

Something that worries me for the future of ControllerX is the potential deprecation of the AppDaemon addon, since it is something it is out of my control and most of ControllerX users rely on.

Home Assistant Community add-on deprecation notice

With all this said, anyone is invited to create a PR to fix any bugs or improve any functionality in GitHub.

Thanks,
Xavi M.

[CoatsyJnr]

Is it still worth using this in 2025, or will automations do most of the work now. I am fairly new to HA and want to integrate buttons and dials/knobs

[stevevanhoyweghen]

Thanks for the tip!

[SeRiusRod (Sergio)]

@xaviml

They removed the sensors from Home Assistant, and recommend using events.

Hola @xaviml,
First excuse me if what I’m asking about is already talked before.

After upgrading Z2M I’m lately finding those messages in the log of Appdaemon:

WARNING hallway_sw2: There is no action in the MQTT topic payload

I’m wondering if it has something to do with that you where talking this past days. In my case, I always prefer to use independent control through mqtt:

hallway_sw2:
  module: controllerx
  class: WXKG07LMLightController
  integration:
    name: z2m
    listen_to: mqtt
  controller: hallway_sw2
  light: light.hallway_lights_ceiling
  manual_steps: 7
  mapping:
    single_left:
      action: toggle
      attributes:
        brightness: "{{ states('sensor.nr_circadian_pwm') }}"
        color_temp: "{{ states('sensor.nr_circadian_mireds') }}"
    double_left:
      action: toggle
      attributes:
        brightness: 255
        color_temp: 286
    single_right:
      action: toggle
      attributes:
        brightness: "{{ states('sensor.nr_circadian_pwm') }}"
        color_temp: "{{ states('sensor.nr_circadian_mireds') }}"
    double_right:
      action: toggle
      attributes:
        brightness: 255
        color_temp: 286

The above configuration seems to work, and I’ve got the action payload for the switch:

{"action":"single_left","battery":100,...}

I don’t know what the log message is referring to. That light.hallway_lights_ceiling is a HA group of 4 ceiling lights.
BTW, I calculate those circadian values in node-red and get them from HA entities.

ControllerX has proven to be much more reliable than HA on switching lights and stood online whereas HA was off.
Is there a good way to directly control my grouped lights without HA intervention?
Would you recommend in this case a migration to something else?

[xaviml (Xavi Moreno)]

Hi @SeRiusRod ,

Is the configuration working even with the warning in the logs? It seems odd that you get a warning, but then it shows the “action” in the payload.

In any case, you can also leverage the Z2MLightController which removes HA completely and relies only on Zigbee2MQTT:

https://controllerx.netlify.app/controllerx/controllers/wxkg07lm/#zigbee2mqtt-light

However, you would need to create the group within z2m if possible since that group is now created on HA as I understand.

Regards,

[SeRiusRod (Sergio)]

Thanks Xavi, for your help.
I remember trying to make a group with those lights in Z2M back in the day without success. But I’ll give it another go.

PD: Mostly is working. Only one room doesn’t work, and it has conventional lights driven by the zigbee wall switch instead of being zigbee lights themselves.

[carsten_h (Carsten Friehe)]

I have a very strange problem here.

Today Hacs told me that there is a new version 4.29.0b0 and I installed it. After I restarted AppDaemon, I see inside the AppDaemon log that I am running version 4.26.2.

I found that I have inside the folder /homeassistant/appdaemon/apps/controllerx the version 4.29.0b0 and inside the folder /addon_configs/a0d7b954_appdaemon/apps/controllerx the version 4.26.2 which is used by Home Assistant.

How is this possible? What have I done wrong in the past?

Can someone help me?

I have a Home Assistant OS Installation 2025.2.5 inside a Proxmox VM.

[xaviml (Xavi Moreno)]

Hi @carsten_h,

This is related to some changes that have happened in the past on the AppDaemon addon.

AppDaemon addon used to get configuration from /homeassistant/appdaemon, but now it gets it from /addon_configs/a0d7b954_appdaemon.

You would need to modify the appdaemon.yaml file from the addon folder to add the app_dir attribute.

I recommend you checking the installation page and go through it for your changes:

https://xaviml.github.io/controllerx/start/installation/

With these changes, it will get ControllerX from the /homeassistant/appdaemon folder which is where HACS installs it to.

Regards,

[carsten_h (Carsten Friehe)]

Yes, this works!

Thank you very much!

[ganonderp]

thanks for making this! I’m a bit confused, I’m trying to set up this apparently supported remote -

TuYaERS10TZBVKAA

I’m using ZHA and I’m trying to set up the Light control TuYaERS10TZBVKAALightController

The device is in remote mode

smart_knob_controller:
  module: controllerx
  class: TuYaERS10TZBVKAALightController
  integration: zha
  controller: 00:11:22:33:44:55:66:77:88
  light: light.living_room

I’m guessing that controller: 00:11:22:33:44:55:66:77:88 needs to be changed to something, while listening to zhaevent in developer tools, I can see device_ieee: device_id and unique_id: but none of them seem to work, any ideas what I’m doing wrong here? thanks!

[xaviml (Xavi Moreno)]

Hi @ganonderp ,

It should be the device_ieee. What do you see in the AppDaemon logs when using the controller?

Regards,

[ganonderp]

That’s working now, I was on auto pilot and capitalised the device_ieee… I clearly need some sleep!

thanks so much for the rapid response!

[james7 (James)]

Any pointers on extending ControllerX with other AppDaemon apps?

I came across ControllerX, and then learned about AppDaemon, which solves a lot of the frustrations I have with overly complicated automations.

I’d like to set up an overly complicated control of lights which includes a lot of overcomplications, such as “revert” timers (e.g., turn the light to “default state” after x minutes), but where the behavior changes based on the time, and also you can’t turn on the light after a certain time (effectively the controller shouldn’t work after, e.g., midnight).

Not too hard in AppDaemon, but I would like to take advantage of controllerx’s code around zigbee controllers, especially the “hold to dim” feature. I’ve looked at the code and it’s pretty well architected – abstracts the controller codes, does an async loop, etc.

Any thoughts on how to re-use that? From looking at the code it doesn’t seem abstracted out enough for me to use it as a module. (E.g., it adds its own listeners and updates the lights directly, rather than having a dependency injection type of pattern.)

I’ve accepted that I’ll probably just have to copy out the code, but was hoping that someone might have a better way.

[xaviml (Xavi Moreno)]

Hi @james7 ,

I am glad you find ControllerX useful and you want to extend its functionality. It might be that some of the features you are looking for already exists in ControllerX, e.g. wait X amount of time to execute a service / action.

In any case, you are more than welcome to either:

• Create a PR with a new functionality that does not break existing one.
• Fork the project and add your own code in there.

If going for the latter, you can always install it manually through HACS through a custom repository.

Regards,
Xavi M.

[james7 (James)]

Thanks for the response.

My question was more along the lines of “any recommendations for ways that I might do something along the lines of import controllerx.light_controller_helpers to be able to re-use the modules”, though it seems like that isn’t feasible today, and would take a lot of refactoring.

I figured that my planned functionality would be so different that contributing back to ControllerX wouldn’t break it but would cause it to lose focus. However, as I think about it more, it is fundamentally a way to better control lights and “give the behaviour to the devices we lose when not having the original hub”.

Before I put too much effort into creating PRs, what would you think about accepting the following additional features:

1. Timed turn on & off:

• New parameters: “automatic on time” and “automatic off time” (e.g., turn on at sunset)
• Probably some additional configuration around initial on state (e.g., brightness & color)

2. Controller revert time:

• New parameter: Amount of time before the controller’s change reverts to the default state
• I probably want to hardcode in some behavior around this (which could be parameterized in the future). E.g., The revert time is only for “on” events, not for turning off the light. If you turn off the light it stays off until the next auto-on.

3. Controller lockout:

• New parameter for controller lockout time, during which the controller doesn’t work.

4. Turn on/up on motion

• Based on event from another device, turn the lights up for a period of time.

If you can’t guess, my usecase here is outdoor lights where I have guests over and don’t want to disrespect the neighbors. So:

1. Lights should come on at a dim setting (e.g., 10%) at sunset, and automatically turn off at dawn
2. Guests should be able to turn the lights up (or down, I guess). But if they turn the lights on super bright in the evening, I don’t want them staying bright through the early morning. That’s the “revert”
3. Additionally, I don’t want the guests to turn the lights on at 3am at all.
4. While (e.g. 10%) is the default state, the lights should automatically brighten to e.g., 50% if a motion sensor goes off or a gate opens, and then revert to the previous setting after a period of time (I have this built now in Automations, but it seems within the scope of ControllerX).

Additionally, while I’m at it, what do you think of accepting a feature for joint brightness + color temperature control? The use case is that many of my lights “default” state (especially at night) is dim and warm (e.g., 30% and 2200k). I have 4-button controls and I find that almost everytime I increase the brightness significantly, I also increase the color temperature. I think that the mental model is that the “brightness” button isn’t just # of lumens, but more like “make it easier to do things”. And vice-versa. I can’t think of a situation where you want 10% brightness at 5000k. So I built an automation that would scale both down at the same time… and think that this might be a sensible additional to ControllerX.

[Sagittarius]

Many thanks to the controllerX developer. It works well.

On the 5-button ikea remote, is there a way to press and hold the toggle button to set the lamp to warm white mode with maximum brightness, just like the behavior on the Ikea platform?

Finally, just made an automation:

alias: 'Always turn on table lights with default params'
trigger:
  - platform: state
    entity_id: light.table
    to: 'on'
condition: []
action:
  - service: light.turn_on
    data:
      entity_id: light.table
      brightness: 254
      color_temp: 370
mode: single