ControllerX. Bring full functionality to light and media player controllers

[thehijacker]

Hello.

That is very kind of you. I have a mqtt based cover (Shelly 2.5 with mqtt enabled). I can open it, close it and set exact position. Actually I have two of them close together, each on own Shelly 2.5 relay. I will call them left and right cover. My final goal is to manage them with this E1810 from Ikea.

Left Cover:

Pressing up to move left cover up until I release.
Pressing down to move left cover down until release.
Single up click to move left cover it all the way up.
Single down click to move left cover all the way down

Right Cover:

Pressing left to move right cover up until I release.
Pressing right to move right cover down until release.
Single left click to move right cover it all the way up.
Single right click to move right cover all the way down

Not yet sure how to use middle button.

[xaviml (Xavi Moreno)]

Hi @thehijacker,

This could be an start configuration that you can use once ControllerX is installed:

app_left_cover:
  module: controllerx
  class: CoverController
  controller: sensor.your_e1810_controller_action
  integration: z2m
  cover: cover.your_left_cover
  mapping:
    brightness_up_click: toggle_open
    brightness_down_click: toggle_close
    brightness_up_hold: open
    brightness_up_release: stop
    brightness_down_hold: close
    brightness_down_release: stop

app_right_cover:
  module: controllerx
  class: CoverController
  controller: sensor.your_e1810_controller_action
  integration: z2m
  cover: cover.your_right_cover
  mapping:
    arrow_right_click: toggle_open
    arrow_left_click: toggle_close
    arrow_right_hold: open
    arrow_right_release: stop
    arrow_left_hold: close
    arrow_left_release: stop

• The sensor.your_e1810_controller_action is the sensor that the controller exposes in HA
• The cover.your_{left, right}_cover are the covers that are integrated from HA. If you do not have them integrated in HA, I would recommend you doing so. However, if you do not want to integrate them with HA, then you will need to include in the configuration the calls to the MQTT throught the mqtt.publish call service from HA.

The toggle_open and toggle_close will open/close the cover if it’s not moving, and stop if it is moving. This way you have a way of stopping in case of wrongly pressing. If you have more actions you want to do with the controller you have the middle button as you said, and also multiple clicks (a feature from ControllerX), so your possibilities are endless.

For this configuration, I used:

• The device page
• The custom mapping page
• The predefined actions for the CoverController

I recommend you reading those pages, so you can explore yourself what are your options.

Happy to help further if you indicate your problem/questions

Regards,
Xavi M.

[simonf (Simon Frølich)]

Hi all,
I’m using the controllerX addon as the only script in Appdaemon. I’m experiencing high CPU usage from Appdaemon on my RPi 4. It runs at 10% load from the Appdaemon at all times.
Has anyone else experienced similar loads?

-Simon

[xaviml (Xavi Moreno)]

Hi @simonf,

I have a RPi 4 as well and the total CPU load is below 10%, and the add-on CPU usage is below 4%.

I would recommend you the following actions:

• Remove the configuration, restart the addon and see if the CPU usage goes down.
• Set production mode to “true” for AppDaemon in the appdaemon.yaml. See here. This will stop checking for changes in the configuration, so you will need to restart for changes.

How many ControllerX configuration (AppDaemon apps) you have running?

Regards,
Xavi M.

[simonf (Simon Frølich)]

Hi @xaviml

I already did the first check before I wrote the post. That did not fix the issue. However, setting the production mode flag seems to do the trick. Appdaemon is down to ~1 % now, which seems more resoanable.

Thanks for the quick reply!

[aixki]

Hi @xaviml

I’ve digged into the source code in order to improve the latency of my Hue Dimmer switch for brightness up/down. I’ve noticed there was a slight delay between the time I hold press the brightness button and the light changes. It seems it was due to the event configuration that reacts to the release event instead of the click event for the up/down buttons. Therefore, here is my configuration :

    def get_deconz_actions_mapping(self) -> DefaultActionsMapping:
        return {
            1000: Light.ON,
            1001: Light.HOLD_COLOR_UP,
            1003: Light.RELEASE,
            2000: Light.CLICK_BRIGHTNESS_UP,
            2001: Light.HOLD_BRIGHTNESS_UP,
            2003: Light.RELEASE,
            3000: Light.CLICK_BRIGHTNESS_DOWN,
            3001: Light.HOLD_BRIGHTNESS_DOWN,
            3003: Light.RELEASE,
            4000: Light.OFF,
            4001: Light.HOLD_COLOR_DOWN,
            4003: Light.RELEASE,
        }

I don’t know why you decided to react to the release event instead of the click? Maybe it’s to prevent to trigger the click AND the hold actions if they are different. In my configuration, these actions are the same so I’d rather get rid of this latency.

Anyway, the more I read your code, the more I think that it’s well designed, so congratulations!

[xaviml (Xavi Moreno)]

Hi @aixki,

This is interesting, are you saying that you changed XXX2 events for XXX0 ones? And by doing so, you got the controller still working the same, but it improved the latency problem you were having?

I initially chose XXX2 click release because I think the XXX0 is also released when holding (XXX1), isn’t this correct?

I do have a Hue Dimmer Switch integrated with deCONZ and I did not notice of this latency, bit I will do some tests with it, and see if I can see any differences.

Finally, if you prefer the XXX0 events than XXX2, I would recommend you to change it through YAML since if you upgrade ControllerX you will lose all your changes. You can use the mapping or merge_mapping for this.

Thanks!
Xavi M.

[xaviml (Xavi Moreno)]

Also, not sure how this solved your problem since the latency problem is only when you hold the button to change the brightness. How does your configuration look like? Does it contain any multiclickable action?

[aixki]

Hi !

My configuration is pretty simple:

dimmer_switch_bureau_anthony:
  module: controllerx
  class: HueDimmerController
  controller: dimmer_switch_bureau_anthony
  integration: deconz
  light: light.bureau_anthony
  action_delta: 0
  action_delay: 0
  transition: 1000

I initially chose XXX2 click release because I think the XXX0 is also released when holding (XXX1), isn’t this correct?

That is correct. The problem is that XXX2 is fired something like 1s after the click (XXX0) which introduces a slight delay before the smoothing takes place.

I’ve modified directly the source code because remapping requires some boilerplate that needs to be copy/pasted all over the place. Maybe there’s room for a new parameter that will specify if we want to react to click instead of release events, but if I’m the only guy interested in there’s no need

[Bobby_Nobble]

You only need to put any remapping in one place, couldn’t be simpler.

[aixki]

Really ? How could I do that ? With a template ?

[Bobby_Nobble]

Just add it on the end of your config like this example…

light1_controller:
  module: controllerx
  class: LightController
  controller: e1810_controller
  integration: deconz
  light: light.light1
  mapping:
    2002: "on"
    3002: "off"
    2001: hold_brightness_up
    2003: release
    3001: hold_brightness_down
    3003: release

[aixki]

Well, as I said, I have to repeat this config for each of my controllers, which kind of violates the DRY principle

[xaviml (Xavi Moreno)]

Hi @aixki,

I understand, and it totally makes sense. Does the XXX0 gets fired with XXX1 actions? If not, I will change the mapping.

@aixki

Well, as I said, I have to repeat this config for each of my controllers, which kind of violates the DRY principle

You could also leverage YAML anchors for this if you are using AppDaemon higher or equal than 4.0.6 (see here), so you do not have to copy the mapping over an over for each configuration:

.config_hue_dimmer: &config_hue_dimmer
  module: controllerx
  class: HueDimmerController
  integration: deconz
  excluded_actions: [1000, 2000, 3000, 4000]
  merge_mapping:
    1002: "on"
    2002: click_brightness_up
    3002: click_brightness_down
    4002: "off"

example_app_1:
  controller: your_controller
  light: light.light1
  <<: *config_hue_dimmer

example_app_2:
  controller: your_controller
  light: light.light1
  <<: *config_hue_dimmer

Regards,
Xavi M.

[aixki]

Thanks for the tip @xaviml !

Yes, the XXX0 gets fired with XXX1 actions. Therefore, be careful if you switch to XXX0 in order to start the brightness up process: it means we can’t have different actions bound to click and hold events, they will have to be the same - which is totally ok for me

I got another question: is that possible to cycle through xy color by click on the I button instead of holding it? Workflow would be:

• Click on I
• if lights are off: turn on
• else: go to the next xy color

I don’t like holding that I button for long as it starts to show the red led on my dimmer switch, meaning there’s a ZigBee problem (probably flood). I’d rather get it working as with my hue bridge: cycling through clicks.

[xaviml (Xavi Moreno)]

Hi @aixki,

@aixki

Yes, the XXX0 gets fired with XXX1 actions. Therefore, be careful if you switch to XXX0 in order to start the brightness up process: it means we can’t have different actions bound to click and hold events, they will have to be the same - which is totally ok for me

mmmh I see… then I will not do that change in the default mapping. Thank you for the input!

@aixki

I got another question: is that possible to cycle through xy color by click on the I button instead of holding it?

Yes, the default mapping uses the click to turn on only, so you could leverage constrain_input_boolean to define different behaviour depending on the light state:

.config_hue_dimmer: &config_hue_dimmer
  module: controllerx
  class: HueDimmerController
  integration: deconz
  excluded_actions: [1002, 2002, 3002, 4002]

example_app_on:
  light: light.light1
  controller: your_controller
  <<: *config_hue_dimmer
  merge_mapping:
    1000: click_color_up
    2000: click_brightness_up
    3000: click_brightness_down
    4000: "off"
  constrain_input_boolean: light.light1,on

example_app_off:
  light: light.light1
  controller: your_controller
  <<: *config_hue_dimmer
  merge_mapping:
    1000: "on"
    2000: click_brightness_up
    3000: click_brightness_down
    4000: "off"
  constrain_input_boolean: light.light1,off

However, if this is too cumbersome for you, you could use multiple clicks and reduce it to one app. Then, you could define double click in “I” and “O” for color click changes:

.config_hue_dimmer: &config_hue_dimmer
  module: controllerx
  class: HueDimmerController
  integration: deconz
  excluded_actions: [1002, 2002, 3002, 4002]

example_app_on:
  light: light.light1
  controller: your_controller
  <<: *config_hue_dimmer
  merge_mapping:
    1000: "on"
    1000$2: click_color_up
    2000: click_brightness_up
    3000: click_brightness_down
    4000: "off"
    4000$2: click_color_down

You can see the predefined actions like click_color_up/down here.

Regards,
Xavi M.

[carsten_h (Carsten Friehe)]

Hello!

Since today I am owning an Aqara Opple button with six buttons.
The first thing has nothing to do with ControllerX.
After connecting it to the ConBee II and deCONZ it took a while to let the double and triple events working. In the first five minutes only single presses are possible. But after a few presses suddenly the double, triple and hold presses are sending events. Does that happen to someone else here?

I found a few little errors in the documentation for the button:
" * 1005 → Double triple top left button"
I think that has to be:
" * 1005 → Triple top left button"
This is also wrong for the other triple presses.

It is also wrong for ZigBee2MQTT. But these are only small errors.

Is it enough to write it here or do you want to have an entry in github?

[xaviml (Xavi Moreno)]

Hi @carsten_h,

Thank you for pointing this out. I will change this asap

Cheers,

[aixki]

Hi @xaviml
I’ve bought in some ikea devices, and it seems that the mapping configuration for the W2049 is wrong.

Here’s the fix that I had to do to make it work:

  class W2049LightController(LightController):
    def get_z2m_actions_mapping(self) -> DefaultActionsMapping:
      return {
            "on": Light.ON,
            "off": Light.OFF,
            "brightness_down_click": Light.CLICK_BRIGHTNESS_DOWN,
            "arrow_left_click": Light.CLICK_COLOR_DOWN,
            "arrow_right_click": Light.CLICK_COLOR_UP,
            "brightness_move_up": Light.HOLD_BRIGHTNESS_UP,
            "brightness_stop": Light.RELEASE,
            "brightness_move_down": Light.HOLD_BRIGHTNESS_DOWN,
            "brightness_stop": Light.RELEASE,
            "arrow_left_hold": Light.HOLD_COLOR_DOWN,
            "arrow_left_release": Light.RELEASE,
            "arrow_right_hold": Light.HOLD_COLOR_UP,
            "arrow_right_release": Light.RELEASE,
        }

I didn’t want to open an issue as there could be something wrong with my z2m setup as I’m quite new to it. But this mapping is working perfectly fine for me!

Here’s a screenshot of the z2m logs for each buttons press/hold:

Weirdly, an arrow long press trigger the on event.

[sentur]

I’m trying to setup a couple of IKEA ICTCG1 rotating dimmers, but without much look. Have a I missed something from the confit below? I’m able to see ZHA events when using the Developer Console > Event listening and using the dimmer, but I’m not seeing ControllerX make any changes to the lights I’m wanting to control.

$/config/appsdeamon/app/apps.yaml >

#Controller X setup
living_room_light_controller:
  module: controllerx
  class: ICTCG1Controller
  controller: "00:0b:57:ff:fe:13:8b:65"
  integration: zha
  light: light.living_room_lights