Hi @xaviml - I have a bit of a weird issue with a symfonisk controller. When rotating the controller slightly to increase the volume the action will continue after I have stopped physically turning the controller and the volume will turn up to full
It is as if controllerx doesn’t recognise that the symfonisk has stopped being turned and carries on responding to the clockwise command. Is this behaviour that you’ve seen before and related to a parameter, or do you think it is more likely to be an issue with my symfonisk link to HA/Deconz?
I see you have stated in the integration to use z2m, but you have the MQTT broker configured in the appdaemon.yaml. If you want to use z2m with MQTT directly, then your configuration will need to be different. You can read more about it in here.
Even so, the default z2m integration should also work, although I have experienced some delays. This is why I created the MQTT option. Could you let me know what you are trying to achieve and also past the relevant AppDaemon logs related to this problem? Otherwise, I am not able to see what the problem is.
which version of zigbee2mqtt are you currently using? There has been a change in the action mapping for this controller from zigbee2mqtt, this is why the mapping does not match. I only maintain the mapping of the latest version on the integration and the firmware. If you want to keep using the legacy mapping, then I recommend you to override the mapping on the yaml configuration and not the Python code, since the Python code will be overridden when you upgrade ControllerX. You will need to add the mapping attribute with the desired mapping, like:
As you mentioned, this controller fires a rotation start event and a stop event. The same as other switches when holding and releasing. This is why I created ControllerX mainly because I wanted to gradually change the brightness of a light gradually between the starting event and the stop event.
So ControllerX calls HA to change the brightness (or volume, or other attributes) periodically when the start event is fired (“hold”), and stops calling HA when the stop is fired (“release”). This means that is the release action is missed (i.e. not fired), then the loop won’t stop unless:
It reached the top or bottom(if any)
Or, it reached a maximum number of loops (max_loops; default is 50)
Knowing this then, there are few things that can be happening:
The release event is not captured by ControllerX.
The release event is not released from the integration.
A hold event is released after the release event.
The first one is just unlikely, specially if this happens to you sometimes and not always. It is more likely to face the 2nd or the 3rd, and to know better about it I would need to see the AppDaemon logs and the deconz events.
I have faced something like this before some times, and it was because I was testing the controller in a hard mode, going up and down quickly. This confused the events that were fired by mixing hold and release altogether. But if used normal, I did not see this behaviour.
As an action point for you, I would recommend you to check the deCONZ events on HA developer tools and see if the release event is fired at all and if so, is it fired after the rotation is stopped?
Let me know about it, I am happy to help you further.
Chances are I’m a complete idiot, but I can’t find this wonderful piece of software anywhere in Hacs. What Am I doing wrong? I looked in alle 3 categories (even frontend - as if) , tried the + sign and tried adding a custom repository.
ControllerX is in the “Automation” tab. To activate this, you will need to enable AppDaemon on HACS integration options. So you can go to Configuration > Integrations > HACS > Options and click Enable AppDaemon apps discovery & tracking. Then you should be able to see the new “Automation” tab.
Thank you very much! I had Hacs installed before it was available as an integration. It showed up in integrations, but there was no ‘options’ option. Uninstalled - reinstalled. And hey presto! Installing now.
Just for clarity, you just need to add legacy: false in the devices.yaml from zigbee2mqtt. If you are running zigbee2mqtt as addon, then you will find it on /share/zigbee2mqtt/devices.yaml. Mine looks like:
The name of the action is called brightness, but that is not related to what the controller will be used for. It is just the name of the action that z2m gave to that controller. What is that you what to achieve? Control a light or a media player? I use the symfonisk for media player and the configuration is like:
If you want to use if for a light, it could be something like this if you have the MQTT broker configured in the appdaemon.yaml, which I recommend if you want to use this controller. You can read in here how to set it up.
Thx Got it, it’s not related to what the controller will be used for but it is related to legacy: false, when I edited that file, now I can restore the python file ikea.py and my device does not call the old action mapping Controlling a media player and want to make the controller “smoth” and not laggy but I will play around with the delay thx for the help and take care
Got my E1743 connected and controlling my mi-lights Gu10 bulbs which are controlled through MQTT. On and off work, but hold - brightness up and down doesn’t. Do I need to configure anything additionally?