ControllerX. Bring full functionality to light and media player controllers

Hi @Sylwester,

I have seen before that sending the transition attribute qhen turning on the light causes similar problems you are having. Could you try adding add_transition_turn_toggle to your configuration, like the following:

example_app:
  module: controllerx
  class: E1743Controller
  controller: XX:XX:XX:XX:XX:XX:XX
  integration: zha
  light: light.your_light
  add_transition_turn_toggle: false

This will remove the transition attribute when turning on the light. You can also try with true since I see that is not present when turning on the light in the logs.

If this doesn’t do anything, then I would recommend try another light and opening a tickrt to ZHA. They will be able to help you better with this issue I suppose.

Regards,
Xavi M.

Hi @xaviml ,
Thank for your help. add_transition_turn_toggle did not help. I have integrated that bulb back to IKEA hub and I was wrong. I have the same behaviour. If brightness is less then around 50% transition is nice slow visible but if is more then around 50% transition is too fast so I think we can blame bulb. Is what it is.
I am new to HA. I just started my journey. Before I found your solution I have tried to create dimming by my self but without success. Your solution is fantastic. Thank you for your work. I have another wireless switch similar to Tuya TS0044 but with 2 button. Your TS0044 controller works with my switch. This switch doesn’t have long press release action so only 1 step brightness available. Shame.
I tried to create automation. My idea was: 1 click - toggle (with condition - when input_boolean is off), 2 click - turn on dimming loop script and changing input_boolean to on (with condition - when bulb is on), 1 click - turn off dimming loop script and changing input_boolean to off (with condition - when input_boolean is on), long press - reset brightness to 100%, 2 click - turn light on 10% brightness (with condition - when bulb is off).
And also if you start dimming by double click and you do not stop by single click light will dim to 1% and stop dimming script itself to prevent turning light off.
That is my idea. Maybe you would like to use it :slight_smile:

1 Like

Hi @xaviml , what do you need from me to add ZHA integration for this unit:
E1812 (IKEA) | ControllerX (xaviml.github.io)?

Is it possible to reverse the button presses? I am using an Ikea E1743 button presser for a cover domain and noticed the open/close presses are reverse.

That is pressing the 0 opens the curtain and 1 closes. I want it to do the opposite.

apps.yaml

computer_room_curtains:
  module: controllerx
  class: E1743CoverController
  controller: sensor.cr_curtains_action
  integration: z2m
  cover: cover.computer_room_curtains

cover.yaml

  - platform: template
    covers:
      computer_room_curtains:
        device_class: curtain
        friendly_name: "Computer Room Curtains"
        value_template: >-
          {% if states('sensor.cr_curtain_left_position')|float < 90 %}
            open
          {% else %}
            closed
          {% endif %}
        open_cover:
          service: script.enable_cr_curtain_tpl
          data:
            modus: "open"
        close_cover:
          service: script.enable_cr_curtain_tpl
          data:
            modus: "close"
        stop_cover:
          service: script.enable_cr_curtain_tpl
          data:
            modus: "stop"
        set_cover_position:
          service: script.enable_cr_curtain_tpl
          data_template:
            position: "{{ position }}"
            modus: "position"
        icon_template: >-
          {% if is_state('cover.computer_room_curtains', 'open') %}
            mdi:blinds-open
          {% else %}
             mdi:blinds
          {% endif %}

script.yaml

  enable_cr_curtain_tpl:
    sequence:
      - repeat:
          until:
            - condition: or
              conditions:
                - condition: template
                  value_template: "{{ repeat.index % 10 == 0 }}"
                - condition: template
                  value_template: "{{ is_state('sensor.switchbot_status', 'ok') }}"
          sequence:
            - service: shell_command.computer_room_curtains_{{ modus }}
              data_template:
                position: "{{ position }}"
            - delay: 1

Hi @bjorn.sivertsen,

Could you please open a GitHub ticket with the following template.

This is an example of such ticket for ZHA integration: ZHA integration for WXCJKG12LM · Issue #202 · xaviml/controllerx · GitHub

Thank you,
Xavi M.

1 Like

Hi @duceduc,

I doubled check the code and the mapping seems to be correct, so “I” opens, and “O” closes. In fact, I have this controller with a cover and it works as expected. Could you confirm from HA calls (cover.open_cover and cover.close_cover) that they work as expected, maybe they are inverted.

However, you could fix that from ControllerX configuration:

computer_room_curtains:
  module: controllerx
  class: E1743CoverController
  controller: sensor.cr_curtains_action
  integration: z2m
  cover: cover.computer_room_curtains
  merge_mapping:
    "on": toggle_close
    "off": toggle_open
    brightness_move_up: close
    brightness_move_down: open

This inverts the commands of the default mapping.

Regards,
Xavi M.

1 Like

Hi @Sylwester,

Did you get this configuration to work? I could help you out to configure such behaviour with ControllerX if you are interested.

However, if you already have the ControllerX working, you could share it with the community.

Thank you,
Xavi M.

It’s quite strange really. When I first setup using the same Ikea controller, it was working as it should. Then a few weeks after, I have change the codes and noticed it was doing the opposite. Not sure what had happen and maybe by posting the code, someone could spot it.

I just test with HA developer tool and it does what the image below suggest. I think the motor (switchbot curtains) I am using the control the curtains the positioning numbers are opposite of HA. However, why was it working during my initial setup?

From developer tool:

From my frontend UI:
2021-06-16_5-28-58

This is an awesome add-on to Home Assistant. I’ve struggled with various IKEA controllers making them work as on the IKEA bridge. It took me a while to figure out that I needed the AppDeamon installed and operating correctly. Furthermore I spent some time setting up the Symfonisk Controller as it should apparently be added as an “Other” controller.
Once these issues were identified and corrected (and the HACS-komponent reinstalled) the controllers has been working without problems. Thank You for a great tool.
The IKEA bridge is about to retire - and dependent on my interest in keeping the HUE-lights at current version they may go the same way.

1 Like

Hi everyone :slight_smile:

I hope everything is well for all of you and that you are safe. I am here to announce that I released a beta version Release v4.14.0b0 · xaviml/controllerx · GitHub.

This update contains changes about grouped entities. Up until now, ControlerX only officially supported Group Integration, however, it was not very convenient for people using Light Group Integration for example, which is way more common for lights. The latter should work flawlessly if Home Assistant would consistently show the right attribute for those entities. This made the Light Group integration not work properly with ControllerX.

I have updated the code to take into account all type of groups by reading the entity_id attribute from the entities, this way I can detect which entities are group or not. Before ControllerX detected this through the name of the entity (e.g. group.all_lights). For this reason, I would you to download the latest beta version and see if any errors popup for your use cases. Everything is fully tested with automated tests and manual tests in my local environment, and I was not able to find any issues with it. I have never had problems with Light Groups, but if anyone did, you can now try if it is working properly with the new beta version.

TL;DR: There is a new ControllerX beta version, and I would really appreciate if you try it out and report if you have any issues. If you install ControllerX through HACS, you should be able to rollback version in case of something breaking.

Thank you,
Xavi M.

1 Like

How is it possible to install the beta through HACS. I seem to be too blind to find it.

Hi @carsten_h,

Once you are in the Automation tab from HACS, you will see the ControllerX card. Then, you can click in the 3 vertical dots, and select “Reinstall”. You will be prompted with a dialog where you will be able to see a toggle button with the following text “Show beta versions”. Once toggled, you will be able to select in the dropdown beta versions as well as stable ones.

Regards,
Xavi M.

I saw that, but didn’t chose it. Oh No. So simply can it be.

Thank you very much!

And the result is:
I have a light group with four tasmota LED and they can be controlled without a problem with the Ikea E1810 (brightness and colour).

1 Like

Thank you @carsten_h for confirming!

I saw that, but didn’t chose it. Oh No. So simply can it be.

When I do big changes, I sometimes release beta versions and wait some days to make sure some people tried it. If you leave the “Show beta versions” on, you will get notified in HACS when a new version (beta or no) of ControllerX is out. Although I have a fair amount of automated tests, it is impossible to cover all the use cases, this is why beta versions are important to me.

Regards and thanks!

I read it and I am impressed. Your home will blink and look like a Disco. :slight_smile:
I clearly don’t know how much works this is for your software. I only knew automated tests when I was working for a company which develops navigation systems for cars (OEM) more than ten years ago. And that automated tests are really extensive and complicated and included also “drunken monkey” test for all the menus. They run a whole weekend for a new version.

That is impressive @carsten_h, I which I could reach that level of automation! The automated tests I ran with ControllerX are all mocked, so I don’t need AppDaemon running or HA. I assume they exist and mock their behaviour. This is why before releasing a version I always test it manually with my environment to make sure I didn’t miss anything, but most of the time I don’t need to fix anything if all automated tests are passing.

Yes, that was great. I only got the results and had to fix the errors. :slight_smile:

1 Like

One totally other thing.

Did you ever thought about a GUI for ControllerX configuration?

Hi @carsten_h,

It did cross my mind, however, ControllerX already relies on AppDaemon, and it would be complicated to build something around that.

Maybe one day I will start working on it, but there are other priorities in the list right like dim lights through MQTT rather than through HA (for zigbee2mqtt), or convert it in a HA integration if possible. The latter would allow me to build a GUI the same way that HACS works for example.

Regards,
Xavi M.

That is totally OK.
It just came to my mind. Maybe it is something possible that just reads/writes the apps.yaml file in the end.

1 Like