I do not doubt that your controllers work perfectly. And my WXKG01 (using ‘click’ iso ‘action’ - of course) works as ‘good’ as my Hue Dimmers, but suffers from the exact same problem.
But the fact remains that ‘my’ Z2M publishes topics strictly according to the official docs - and yours (and Xavi’s) does not quite, as Xavi admitted freely and as you can easily check for yourself. But no worries, as it’s rather easy to solve this discrepancy, and I’m sure Xavi is on top of it.
It took some time to actually ‘filter out’ the answer I was looking for, but evetually I DID find it.
Both yours and mine (and Xavi’s) setup and MQTT commands are actually as expected and documented. But I must admit, that it was very hard to find some documentation on the specific Home Assistant legacy entity state implementation commands.
Please check this issue and especially check out Koenkk’s replies April 22nd, 2020
With homeassistant: true set in configuration.yaml you’ll get the extra MQTT command that clears state, in order to be able to trigger directly on state change in HA. Otherwise it would be impossible (as you’ve experienced) to detect multiple state changes on same entity_id. Makes perfect sense for all z2m click devices.
If you only use MQTT device triggers, it’s possible to completely disabe the HA entity integration with homeassistant_legacy_triggers: false
Recommended method is still using MQTT device triggers
Can’t test the above as I’m at work, but I’m quite sure that’s why we experience different MQTT commands in the logs.
Do you have the homeassistant: true set in your configuration.yaml, @pav ?
Thanks for finding this! I really tried to find why this was happening, but I could not. However, the documentation does not say what the homeassistant: true fully does. I did just try to set homeassistant to false in the configuration and indeed, I do not receive the /action and /click topic in the MQTT.
Anyway, I will give full support to the other topic in ControllerX since it is the official topic from Z2M.
Actually I’ve never given it ANY thought, that there were multiple MQTT calls for my click devices. Just used the easiest approach for automations - before you came up with ControllerX
For HA’s state machine it also makes perfect sense and more consistant that states for click devices don’t ‘live’ forever. You pressed a button - and now it’s done… Next ! As I’ve mentioned previously, I really dislike my Hue core (or custom ??) remote integration, which actually leaves states to live ‘forever’. No, state is not ‘1_click_up’. I pressed that button like 10 hours ago
It’s also much easier for newcomers to understand how to build easy automations, without the need to understand how to parse JSON objects.
But documentation really lacks - quite a bit! Now I know what it’s about, I can understand the vague sentences about HA legacy integration. But if I’ve read it two days ago, I wouldn’t have a clue about what Koenkk actually meant with that Home Assistant legacy paragraph
While you at it (MQTT integration in ControllerX), Xavi. Could you briefly check if there’s some potential code optimizing hidden somewhere in order to speed up MQTT integration ? I’m still using HA for toggling lights and let ControllerX do the rest. With a MQTT automation in HA, toggle is some estimated 150-200 ms. faster than same with MQTT integration in ControllerX. If not, I might raise an issue (more like a question) and ask Frenck if something could be done in Appdeamon code ?
Everything related to configuration seems right to me. What I think is happening is that the events that the Hue Dimmer switch fire are different from what ControllerX is expecting. ZHA is the most complicated integration to maintain since the events change from time to time and I am the only one maintaining all the controllers to be up-to-date. So if you want to help, could you please raise an issue (bug) on the GitHub repository and report the different ZHA JSON events for each action (clicks, holds and releases). Then I will update the code to integrate again that Controller for the ZHA integration.
Could you share the YAML automation from HA to have an idea of what the flow is and compare it to ControllerX? There is no much to optimize on the MQTT integration, it just listens to the topic that is been set and then calls HA services. Just to clarify, the MQTT integration (and any other) is to get the actions from the controllers, when dealing with devices/entities (lights, media players, switches, etc) ControllerX communicates through HA call services. This means that if you have a controller and a light with Z2M, the communication with the controller will be done with MQTT directly to AppDaemon/ControllerX, but when toggling the light, ControllerX sends a HA call service and not a MQTT topic.
I’ve been trying many different setup’s to toggle lights as fast as possible from my in wall Tasmota switchmode 11/12 Shelly’s. As you know, these use MQTT commands for the different click and hold situations.
Fastest setup so far for ‘toggle’, is using HA automation which listens to identical topic as used in ControllerX and uses standard HA light.toggle service calls to toggle the light. This setup is really close to instant action.
With Appdeamon, identical setup is notisable slower. On first tests, I had an active contrain_input_boolean in YAML. Disabling that actually makes ControllerX quite a bit faster. Perhaps almost halfes the ‘lag’ experienced with constrain_input_boolean. But still HA automation with MQTT trigger and even HA state trigger is faster than ControllerX with MQTT trigger… ?
On second thought, this leads me to think that MQTT integration is perhaps not the culprit here, but more likely that appdeamon <–> HA state integration has speed issues. Appdeamon uses many milliseconds more than HA itself to check states (condition using contrain_input_boolean) and/or changing states with same service calls as HA uses. Either that or HA automations are more closely linked to HA core than appdeamon (or any other external app) is. And hence can access state machine much faster than any external app ?
Don’t get me wrong - Both Appdeamon and ControllerX are excellent and makes life SO much easier But it triggers my OCD that I can’t gather all tidy and neatly in ControllerX. Instead I’m forced to breakup my automations in both HA and ControllerX.
Probably just the way it is I’m afraid. And I’ll, without any doubt, survive this ‘luxury’ problem
Below my test automation in HA and appdeamon.
Ciao !
# *** HA AUTOMATION ***
# Toggle lights through HA using MQTT trigger. Quicker responce than using platform state or directly in appdeamon ControllerX app
- id: kontor_loftlys_cstm_mqtt_toggle
alias: kontor_loftlys_cstm_mqtt_toggle
trigger:
platform: mqtt
topic: zigbee2mqtt/office_cmnd
payload: "toggle"
#trigger:
#- entity_id: sensor.tasmotest
# platform: state
# to: 'toggle'
action:
- service: light.toggle
data:
entity_id:
- light.0xec1bbdfffed45c3b_light
then I could use those zigbee switches as normal button entities in other usecases, the benefit is that the consumer case would not need to know if its a zigbee button or something else.
so pressing the button on my xiaomi switch would just flip the value of the defined virtual binary sensor.
Not sure if I understood you fully, but you can toggle any type of sensor using CallServiceController (about to be deprecated and Controller can be used, but behaviour is the same). You can overwrite an attribute called mapping where you can define the event/action as a key and the service to call as value. Configuration would look like:
This configuration allows you then to switch the value of your input_boolean when pressing the WXKG11LM Aqara switch. It goes without saying that the input_boolean.your_input_boolean should exist in your HA setup, either via UI r configuration.yaml.
Not sure if this is what you are looking for, otherwise, could you specify more in detail what is what you are looking for and see if it is something worth to implement or it’s there already a way of achieving it.
Cheers and thanks for the feature request!
Xavi M.
Hi, do you think you can add support for this controller?
I have it working using deCONZ. It doesn’t show there, but it is listed under integrations/entities in HA. Also I can listen to event and have written an automation with it succesfully toggling lights using event_type: deconz_event. ControllerX support would be amazing!
I can help you out with finding out all the events that are paired to button presses and test this
Adding support to new device is simple. I will just need all the actions fired from each of the buttons (presses, holds, releases). You can create a new device in here.
Awesome! I noticed some buttons have a hold option (firing a new event every 1-2 seconds) while others have a press-hold-release event and don’t keep firing.
I will test extensively tomorrow and share it there!
Is is possible for custom controller to release an action if it repeated, for example, if I long press it do hold_xycolor_up and long press again it release the action ?
There is a new added attribute called hold_release_toggle. If true , a hold action will work as a release when another hold is running. This is useful when you have a button with just one action event and you want to use the hold-release feature, then you just need to map that event to a hold action. Otherwise, it will work as always, when a hold action is called while another one is called, then it will be ignored. Default is false. Configuration would look like the following:
The important things in the config are the hold_release_toggle: true and that you can just use the toggle: hold_brightness_toggle without a release action. With this, every time you click the toggle button, it will bright up/down the light and stop when it is click again if it is still changing the brightness.
This minor change does not contain breaking changes. Note: Remember to restart the AppDaemon addon/server after updating to a new version.
Features
Add the mapping attribute to the Controller base code, so the attribute can be used in any controller class. Custom controllers have been deprecated, they can still be in use, but a warning will be shown in the console [ #98 ]
Add attribute parameter to the state integration to listen to state attributes. Default is to listen to the state as it already was [ #106 ]
Allow input_boolean and binary_sensor entities to be used in switch controllers
Add listen_to attribute to choose between listening to HA state or MQTT [ #109 ]
Add hold_release_toggle attribute. If true, a hold action will work as a release when another hold is running. This is useful when you have a button with just one action event and you want to use the hold-release feature, then you just need to map that event to a hold action. Otherwise, it will work as always, when a hold action is called while another one is called, then it will be ignored. Default is false.
Fixes
Raise an error when a group has no entities [ #102 ]
Fix brightness transition only works once after a controller is started [ #100 ]
Fix ZHA mapping for HueDimmerController [ #110 ]
Fix Toggle direction requires the button to be held twice [ #113 ]
deCONZ supports this controller as well (I have received one today and paired it succesfully). Or can I just edit some files and tie in the deconz events myself?
I’ve been using ControllerX for half a year now and just thought about the incredible development you’ve done with ControllerX in only six months time. Wow !!
Your dedication, time spent with us end users and the countless hours you’ve spent debugging issues / enhancing code is simply amazing…
Go have a beer (or two), mate!
You definitely deserve it !
I’m still using HA for toggling lights and let ControllerX do the rest. With a MQTT automation in HA, toggle is some estimated 150-200 ms. faster than same with MQTT integration in ControllerX. If not, I might raise an issue (more like a question) and ask Frenck if something could be done in Appdeamon code ?
that I can’t gather all tidy and neatly in ControllerX. Instead I’m forced to breakup my automations in both HA and ControllerX.
Features
Fixes
Docs
