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:
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.
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
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.
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
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?
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.
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.
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.
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).
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.
I read it and I am impressed. Your home will blink and look like a Disco.
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.
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.
