I want to control an Ikea Synfonisk speaker using the Synfonisk remote. I am using ConbeeII/Deconz (no Ikea gateway) and this is my configuration so far:
If I click once on it it does start playing (after 7 seconds delay), one more click and nothing happens, it is not pausing. Rotating the controller has erratic behaviour, only can increase volume one step and rotating anticlockwise sometimes increases the volume any ideas what could be the reason?
I am trying also to use an Ikea Switch to control TV volume. The switch is already configured to switch on/of a light (In Phoscon), I would like to use hold-down to control TV volume from the same switch. Is that possible?
If I click once on it it does start playing (after 7 seconds delay), one more click and nothing happens, it is not pausing. Rotating the controller has erratic behaviour, only can increase volume one step and rotating anticlockwise sometimes increases the volume any ideas what could be the reason?
If you have a 7 seconds delay, I would say you have a problem in the network or the device is overloaded. Here are some things to check:
Which hardware is controlling the system? I currently have z2m, deconz, appdaemon, mqtt broker, and HA in a raspi4, but I know this same setup works well in raspi3. I would recommend you to check the CPU usage and free memory of your device.
Is the controller far from the coordinator (ConBee II)? If the controller is far away, then it might cause unexpected delays.
If you disconnect AppDaemon for a second, and check the deconz_event in the Developer Tools, do you see the delay in there too? Could you try to do the same with AppDaemon and ControllerX up and running?
Could you share the AppDaemon logs when using the controller with ControllerX?
I would like to use hold-down to control TV volume from the same switch. Is that possible?
You said you want this behaviour with an “Ikea Switch”, the same symfonisk controller or another one? If the Controller supports hold and release action (symfonisk doesn’t), then yes, it is possible to do so. If you share the already working configuration I can help you to modify it to do so.
For the first issue with the Symfonisk controller it is then most probably a hardware issue as I am testing with one of the early RPis I had over. I was actually surprised it worked so well with a few lamps, switches, Combee stick, a few automations. I guess Appdaemon and the symfonisk controller was too match for it . Have ordered a Rpi4.
Regarding the other point. I have an Ikea on/off switch/dimmer (not the symfonisk) that I have configured in Phoscon to switch on/off a lamp. And want to use hold-down to increase/decrease TV volume. The below configuration doesn’t work, so I must be doing something wrong.
It will work much better with it. I have the raspi4 with z2m, deconz, appdaemon, MariaDB, MQTT, NGINX, DuckDNS, Samba, and more. I also have ~10 devices and >120 entities, and I haven’t had any issues with it.
Regarding the other point. I have an Ikea on/off switch/dimmer (not the symfonisk) that I have configured in Phoscon to switch on/off a lamp. And want to use hold-down to increase/decrease TV volume.
You have the configuration almost correct, but you will need to add the mapping attribute like:
If you remove the mapping part, then the controller will do the following:
Click “I” → Play/Pause
Click “O” → Next track
Hold “I” → Volume up
Hold “O” → Volume down
However, if you already using the click for something else, then I recommend you having the above configuration since click (1002 and 2002) are omitted.
@xaviml, many thanks for creating this, I’ve just moved over to ZHA from Z2M and thought there must be an easier way of doing things than the loads of automations I did have but didn’t realise it could be this simple, obviously at the expense of all your hard work.
Few quick questions that I haven’t found the answers to, probably there but just can’t see them so apologies if it looks like laziness.
First, is there a quick way to reload the config rather than having to restart HA each time I tweak it?
In the config I set up below, it would only work if I added an entity to the top part of the code, in this case another light: light.sams_bedroom at line 6, despite every button having an entity specified for it, is this just how it is or am I missing something?
Lastly, how would I set a button up to cycle through some specific settings on each press like it does for brightness below from a different app-daemon app, I’m thinking a selection of specific colours rather than using ‘click_xycolor_up’ which would go through the lot? …
I’m glad you find ControllerX useful. I have been in the same place as you, where I had long HA YAML automations to just make a remote control the lights. I will answer you questions one by one.
If you have the standard and default configuration for AppDaemon, every time you save the /config/appdaemon/apps/apps.yaml file, it will reload the configuration. So you don’t need to restart HA every time you change something. The only time you need to reload something is AppDaemon and is when you upgrade or downgrade the ControllerX version.
ControllerX has a base class called Controller where all other controllers inherit from. Under the Controller class you have the type controller (LightController, MediaPlayerController, SwitchController, and CoverController) that the device controllers inherit from. In the case of HueDimmerController is a LightController (check here). This means that this controller is tight to functionality related to lights, and therefore a light attribute is mandatory, otherwise it will not work. Having said this, the advantage of separating the different type of controllers is that you have predefine actions that act to the entities (light, media player, etc). You can see the predefined actions in here. This means that the configuration you placed can be reduced by using the predefined actions:
sams_wall_remote:
module: controllerx
class: HueDimmerController
controller: xx:xx:xx:xx:xx:xx:xx:xx
integration: zha
light: light.sams_bedroom
mapping:
on_short_release: "on" # This is the default behaviour
off_short_release: "off" # This is the default behaviour
on_short_release$2:
- service: light.turn_on
data:
entity_id: light.ice_block
off_short_release$2:
- service: light.turn_off
data:
entity_id: light.ice_block
off_long_release: # Not sure why you want the lights to be off when releasing after a long hold
- service: light.turn_off
data:
entity_id: light.sams_bedroom
- service: light.turn_off
data:
entity_id: light.ice_block
up_short_release: click_brightness_up # This is the default behaviour
down_short_release: click_brightness_down # This is the default behaviour
up_hold: hold_brightness_up # This is the default behaviour
down_hold: hold_brightness_down # This is the default behaviour
on_short_release$3:
- service: scene.turn_on
data:
entity_id: scene.sam_morning
I recommend you checking the comments I left in the configuration since there are some things that don’t make sense. If what you want is to have the Phillips Hue Dimmer switch work with the default mapping (check the device page I linked before), but turn on/off another light when double clicking, then this is what you would need:
Well, this is not 100% configurable, but you can set a color palette yourself and every time you press, it will cycle through that palette instead of the default one. You can read more about it in here (color_wheel attribute). The configuration would look like:
I hope you find all these answers useful. You also made me realised that the ZHA mapping from Hue Dimmer device page from the documentation is outdated, and needs to be updated. The correct mapping is the one you posted in the configuration (the same as the code). So thank you
Thank you so much for the more than full explanation, all makes perfect sense now.
Didn’t think of just trying it after editing, so used to having to reload automations etc to make them active.
The reason for the off_long_release is it seemed the easiest way for him to remember an all off function, it only has a couple of things in the example but will have 6 or so devices when complete, or did you mean why that instead of off_hold, in which case I just used that because I used release for everything else and didn’t think about it further.
The color_wheel solution is perfect for what I wanted thanks
Was confused by the ZHA mapping in the documentation, probably why I ended up specifying a lot of things that are defaults
After all the help you’ve already given it seems a bit rude to ask but do you think there’s potential to support these…
if so, I’m happy to do any leg work that might help?
Thank you so much! adding “mapping:” made the trick
Now I can use the same switch to control a ligth and also lower the TV volume (with hold down) from the kitchen when my kids have it too loud
Didn’t think of just trying it after editing, so used to having to reload automations etc to make them active.
This is the magic of AppDaemon, pretty amazing, indeed.
The reason for the off_long_release is it seemed the easiest way for him to remember an all off function, it only has a couple of things in the example but will have 6 or so devices when complete, or did you mean why that instead of off_hold , in which case I just used that because I used release for everything else and didn’t think about it further.
I was concerned because the off_long_release gets called when the hold action is released, so it would make more sense when the hold action is fired (off_hold). In case of the short click, there is an event for when is clicked and for when is released, so time difference is negligible.
The color_wheel solution is perfect for what I wanted thanks
Perfect! I am glad
Was confused by the ZHA mapping in the documentation, probably why I ended up specifying a lot of things that are defaults
That probably didn’t help, indeed. I will change this now, thanks!
After all the help you’ve already given it seems a bit rude to ask but do you think there’s potential to support these…
Yes, supporting controllers is easier, you can fill out this ticket stating the events that are fired and which button fires them.
After amending the rest of the set up along the lines of your recommendation I found out the hard way about merge_mapping also calling the off_hold function as it triggered a colour loop that I could only stop by cutting the power to the bulbs. Now it uses off_hold
The colour wheel works fine using the default on_hold, but so the bulbs could get back to a proper dimmable white I set on_short_release to activate a scene that specifies colour temp. Works well and gives the best of both worlds whilst simple to remember for my lad.
Great news on the new controller, will sort out the necessary.
Setting this up for the first time, and having trouble with extracting the controller ID. I’m using ZHA and have a E1810 and E1743. When I go to listen for events, I’m not seeing any events come up when I press buttons. I’m sure I’m missing something simple. Any assistance you could provide would be most appreciated!
Assuming you have paired them with ZHA you go to Configuration>Integrations>click on ‘Devices’ within the ZHA panel>click on the device and under ‘Zigbee info’ you’ll see ‘IEEE:’, that’s the controller ID.
You can check the IEEE following @Bobby_Nobble’s instructions, however, when listening for the zha_event and interacting with your controller, you should see the event messages in there. If you don’t see them, ControllerX will not work since it listens to that event to know the buttons that were pressed or held for example. Have you added your controller successfully with ZHA?
Seems you are having the same problem as @Hoekeren had recently. The problem was that you are probably using the E1744 controller without the legacy: false option in the devices.yaml. You can see his first post regarding this in here, and then you can follow down the thread to see how to fix the problem and also which tips I gave to him.