Yes, but the blueprint would still require one entity selector for each button, because there would be no enforced naming of the event entity ids, so you couldn’t just use a device selector and figure out the event entity ids based on that…?
Well, yeah as long as the devs don’t kill that feature I guess. But why introduce event entities at all if the intent is not that these are what should be used going forward and the old methods eventually be deprecated…
They aren’t going to kill that feature, the only thing that has changed is event entities were added 1 year and 4 months ago. Nothing was removed.
Maybe you’re confusing Z2M’s transition from sensors to event entities.
Not correct. All my remotes from hue, Aqara, IKEA, and some noname chinese ones currently all have this in common
There is ONE event entity per physical remote control (sometimes called a switch) no matter how many buttons it has.
Once triggered one or two attributes are received that you need to build your conditions on in the actions
event_type (using trigger.to_state.attributes.event_type)
And optionally button (using trigger.to_state.attributes.button)
All examples I have using the attribute button it is a combination of button and event_type.
For example the good old 4 button Philips Hue Dimmer has 4 button values: on, up, down, off
And the event_type values are: press, press_release, hold, hold_release
That is pretty logical for this device.
For others all the combinations are in event_type. Like the IKEA round 5 button. For that event_type can be one of: toggle, brightness_up_click, brightness_down_click, brightness_up_hold, brightness_up_release, brightness_down_hold, brightness_down_release, hold, arrow_left_click, arrow_left_hold, arrow_left_release, arrow_right_click, arrow_right_hold, arrow_right_release
So pretty confusing.
And then there is the 6 button Opple where the event_type can be: hold, button_1_release, button_1_single, button_1_double, button_1_triple, button_2_release, button_2_single, button_2_double, button_2_triple, button_3_release, button_3_single, button_3_double, button_3_triple, button_4_release, button_4_single, button_4_double, button_4_triple, button_5_release, button_5_single, button_5_double, button_5_triple, button_6_release, button_6_single, button_6_double, button_6_triple
Note the hold value. For hold you also need to look at the button attribute to see which button. That one is a total trainwreck. And confirmed to be a bug because some regexes on the Zigbee2MQTT side are not really fully implemented. In other words. That will all break.
I do not mind so much the solution I just wish that
Home Assistant fixes the trigger for event so it can retrigger when you press the same button multiple times.
And Zigbee2MQTT gets a more consistant implementation of the event_types and the button attribute
well that’s on Z2M to make that right then. Because that’s not the intention of event entities.
When event entities were added to HA, they were meant to represent an event stream from a single device. It’s on the developers of the integration to split them properly.
Also, old-school events still exist as well.
There’s entirely too many ways to deal with events and they are all here to stay.
You say “When event entities were added to HA, they were meant to represent an event stream from a single device.”
Isn’t that was Zigbee2MQTT has done?
For my 4-button Philips Hue remote all events are received on one single event entity.
For example for my “Bed Right Switch” I get in HA the entiry event.bed_right_switch_action. Only that one
When you press a button the event.bed_right_switch_action itself gets a value which you trigger on but do not use for anything.
And then you test for the attributes that came with the trigger.
odd, but that wasn’t the original intention to be built that way. If you had 4 buttons, I’d expect 4 entities. Regardless, if that’s the case, then you have to work with what they gave you unfortunately.
Z2M’s events are subject to change - if somebody wants to chip in with what HA intended then I’m sure they’ll listen.
Well, I’m hoping they’ll listen.
I wish I had the convo saved, it was with one the devs somewhere on discord.
are you using ZHA?
No. This is for Zigbee2MQTT! The new event way that was introduced in December (though more relevant in January release where the default legavy action sensor hack was disabled by default)
No matter how Zigbee2MQTT do things - an event should be able to trigger multiple times with the same event value. Pressing the same button multiple times is not exotic. It is quite normal. Think inclease light intensity. Or think toggle light on and off. And it would be really silly if Zigbee2MQTT would have to send double events. One for the action and one for “undefined”. That is just moving the action sensor hack where they do exactly that to the event domain.
But should it be the state trigger that is enhanced to accept retrigger on same value?
Or a new event entity trigger? There are ideas in this thread and I have no oppinion how. But as it is now - people are confused.
Yes, but event entities, when they were originally made (august 2023), there was a defined approach to them that seems to have been lost in translation.
FWIW my experience with the Philips Hue Dimmer (I have the V2) matches @KennethLavrsen 's (one entity, 4 physical buttons on the device): (using Z2M)
Exactly.
There is also a logbook thing that could be better. Showing the actual event_type would be very helpful when you are building your first automation with a device you do not know. Clicking the buttons to see what happens. You have to go to developer tools → states now to see what is going on with the attributes. But that is not the subject of this WTH. The issue in the WTH is that we cannot retrigger with same button if we add any “to: something” or “attribute: something”. It has to be an open catch all state trigger.
+10000. “Detected an event” isn’t that useful. I will see if I can raise a FR in Z2M for this.
After reading over @KennethLavrsen’s explanations and examples, I’ve got all my Z2M automations working again. I’m a simple end-user, so if I can do it, anyone can. Yeah, it was really disruptive on my Sunday to have to figure it all out and then change my automations, but now that it’s done, I like it. The trigger section is cleaner, especially with multiple devices - 1 trigger per device. And, it’s not a big deal to add the conditions.
Well duh, my Philips Hue Dimmer Switches are still using the Philips Hue integration. That’s why each button has a separate event entity. 
I’ll see myself out …
I guess that might mean Z2M may not have implemented event entities as Paulus intended, seeing that he and marcelveldt are code owners of the Hue integration.
Well, event entities are currently considered to be “experimental” in Z2M.
Like you, I found the new event model in Z2M mostly allowed simplification. I had one thing that tripped me up, but that was my own fault for being an idiot.
For everything else it’s a simple any state change trigger and a trivial template.
I also live happily with the simple open trigger for my Zigbee2MQTT
But. We also have to think about the less experienced and not set up a “trap for young players”. And when I look at several threads both on the HA forum and in the Zigbee2MQTT github, people have trouble with it because they are used to seeing multiple trigger values and trigger IDs.
It is also a bit problematic with the GUI automation editor. Every choice in the action section is a template jinja geek thing. If you have trigger IDs to work with your conditions can be made from pure UI. That is an important aspect. But I am happy with my jinja stuff.
