Hello, working on combining four separate automations for Hue Dimmer Button press actions and need some assistance.
I have seen several posts answered on this topic using custom implementations or ZHA (whatever that is).
I’m thinking it should be possible to have a single trigger on the state of the dimmer (which I think would allow to not have 4 triggers, one for each button press)
And the with a “Choice” action somehow detect which button was pushed and take the appropriate action.
But when I configure in this way, there don’t seem to be good choices for the choose condition. Whereas for a device action one can just pick the hue device and then select the button up. In the condition field there are no button choices, just the battery sensor.
I actually made a blueprint to do this in zigbee2mqtt as an experiment (to see how blueprints worked when they first came out) if that’s any good? I haven’t posted it anywhere yet but it’s fully functional if anyone wants it. Will just have to wait until the next time I’m at a laptop.
Not quite sure what you mean. The only sensor I can see related to the dimmer is regarding the battery.
WRT the device, there are a bunch of triggers related to the buttons. For a single automation it’s trivial to set the device trigger to e.g. “On button release” and call whatever service in response.
But the conditions available to test seem like nothing except the battery state.
I think you are asking me back the same question I am posting to ask…
If I use an action driven by a device then all of the buttons have their own triggers and it is trivial to react to a certain button press, pick the service call or whatever that is to happen when that button is pushed on the dimmer.
But that requires 4 automations, one for each button.
To combine to one automation I believe this is to be done via the “choose” action. The choose action does not have “triggers” (for which the button detection is built-in) instead, it has “conditions” and the selectable “stuff” is exclusively a sensor, specifically the battery one.
If I must use “conditions”, how can I have them “see” what can be “seen” from the “trigger”. Are the triggers from the hue dimmer also accessible via the state change of something? What?
Honestly it’s not clear why triggers and conditions are not the same thing anyway, since they all seem to ultimately boil down to a state change of something (as you suggest). Why not just make everything a state and make them all show up in a searchable list of states?
I’m sure some of this just related to what has been exposed and in what way from a given integration, as the first responder asked. Perhaps that’s why alternate integrations have been implemented for Hue - can any of those be used i.e. ZHA without the zwave stuff ( I had a bunch of zwave for years and it was a huge pita! Now all in the drawer) but still expose triggers as states?
Just replying to my post to bring this issue forward. Very curious if others have figured how to create a single automation with the UI that handles all 4 buttons of the hue dimmer using the basic Hue Integration.
As I told you before, I have, and I’ve made a blueprint, but the states for that blueprint are based on the entity domains and states generated by the zigbee2mqtt integration and I don’t know what the equivalents are for the Hue integration that you’re using.
Since posting this thread you’ve had 6 days to look in your states list, find that information out and post it here so that I can adapt my blueprint for you and you can use it to generate the automations you need.
If you’re not going to bother doing that, I don’t know how either me or anyone else is going to be able to help you.
Thanks for the replies, I do appreciate the effort. You reference a states list. Does that exist? If so where should one look to find it? I searched the forum and it seems multiple people have asked and the answer seems to be that there is no states list.
Also, per the original question, the UI seems to attempt to display a state list, in this case the only states displayed are for the battery. That may mean that the hue dimmer just isn’t supported in that way by the integration.
Somewhere in there will be either an entity_id that refers to the switch as a whole (all four buttons) or an entity_id for each button. Then when you press a button, double click a button, press-and-hold a button you will get some kind of state change.
Automations work by seeing this state change and reacting to it, but I need to know what the entity_id is to monitor and the what the state changes to that indicates the button has been pressed.
As described above, in zigbee2mqtt it is represented as one entity_id (sensor.xxxxxxxxx) and a press of each button on the remote (from top to bottom) yeilds the states ‘on-press’, ‘up-press’, ‘down-press’ and ‘off-press’. Using these I have created a blueprint that turns on the light when the state changes to ‘on-press’, turns it off for ‘off-press’ and increases/decreases the brightness by 10% for the up/down presses as appropriate.
For each room in which I have a hue 4 button switch, I just have to create an automation from the blueprint and tell it which sensor.xxxxxxxx to react to, and which light.xxxxxxxxxxx to control.
OK, the problem is that what you are saying does not appear to be true. Those states just don’t exist. On more searching for “hue dimmer states” I came across this thread:
Apparently there is debate amongst devs if a remote switch like the hue dimmer is stateless or not. The current implementation of the hue integration doesn’t seem to have states for the buttons at all, which is what I have been saying all along. If there were states, they should appear in the choose>condition menu of the automation builder.
The hue dimmer does have events, which is why it’s trivial to handle the buttons in a single automation, but when you try to use the choose option, the conditions only allow to “choose” based on states, which the dimmer doesn’t seem to have.
That thread makes reference to something called an “eventsensor”, maybe there are other “things”/entities/devices/objects/constructs that do indeed imbue the button presses of the hue dimmer with states that could be used instead in the automation.
I need the actual events, not a ‘friendly’ UI representation.
If you’re determined to use UI based automations and device triggers, then I can’t really see why it matters to have 4 separate automations as you’ll never see the code anyway.
If, on the other hand, you want efficient code - you need to use an event trigger (I’m guessing based on what you’re telling me) and a template that resolves to the correct action based on which event.
Your suggestion to look into the states list did help with at least identifying that this is a known limitation of the hue integration. See another long thread about hue and hue dimmers here:
You’re right about the UI. I resisted it for years, and after adopting it partially found that the UI often conflicts with direct yaml manipulation. So, now that the UI actually seems to offer strong abilities for others in the family to “do things” I now try to prefer it wherever possible and make sure that I’m not missing some way to do what I need via the UI. The reason for wanting a single automation is again a limitation of the UI. Automations are just one long list, and I now have to page down to find the automation I’m looking for - because there are no folders one must use super long names. So any way to combine automations into fewer helps with organization.
Based on the links I have posted it seems like really an unsolvable problem in the UI. So again you are probably right that it just needs to be done in code, which I can do.
