I’m pretty sure the documentation for the new event entities just introduced in Zigbee2MQTT has got this wrong because they haven’t followed the process you describe here.
Good spot - I’ve submitted a PR to the Z2M docs to change that.
4 Likes
This is my WTH as well but I didn’t find this topic (stupid search…). So my arguent for it:
I do like the switch to events for a lot of things. The event-entity is a nice addition for that. The only thing I find a big WTH is the fact that you still have to use a state-trigger to use it while it is a “stateless” entity.
Now I get it that an event-entity does have a state, the datetime it fired. But it doesn’t feel correct.
This WTH get’s bigger because of the use of event_type as attribute which has nothing to do with the event_type of real events. Because a HA event of an event-entity is still just state_changed.
So in order to do a trigger on an event-entity with a specific event_type you have to make a state-trigger without a to/from-state. And add a condition to check the state of the attribute of the event-entity. This is even what the documentation suggests. To me, three things are wrong with this:
- You have to make a trigger and a condition to make it work. Double work.
- You do both a state-trigger and a state-condition on an item that’s introduced as state-less.
- You have to hope the event-entity does not get events too fast because the trigger and the check of the attribute are two separate steps. Especially if you do other actions before checking the attribute, it might already have changed.
So I think an event-entity-trigger is the missing piece here. Or, what I would suggest to get it more in line with real events, extend the event-trigger to accept the entity id of event-entities. Although yes, there is still a huge difference between a HA event and an event-entity, I think it would be much cleaner if it is possible to just do:
trigger:
- platform: event
entity_id: event.hue_remote_control
event_type: short_release
Especially if this would be something you could setup in the UI. And this would be way less confusing than a state-trigger and the confusion on how to check the event_type (which in reality is just an attribute…). Which also makes sure the attribute is checked when the event fired.
3 Likes
The only downside to your suggestion is there’s already an event trigger, so we’d need to come up with another name or alter the existing state trigger. I’m not sure what route is better. Either way, it’s definitely needed.
1 Like
You are right it exists but this is not the only time a block can do entirely different tings depending on the keys used in it. In this case, once you supply an entity id of an event-entity it should not look for a real HA event but for a state change (+ optional the event_type as attribute). Without entity id, it should check for a real event aka stay the same as it is now. This way it would be fully backwards compatible.
Yes, this is a bit of a stretch for the event-trigger. But I think the whole root cause is the choice to basically name an entity to something that already exists in HA. Even though the term event is logical, because it already existed it is confusing as hell now…
The other option would be to pick a different name for the trigger. But than I would also clearly label the event-entity as such. But even then I think it would cause quite the confusion between real events and event-entities with their different event_modes. So that’s why I would propose to stretch the event trigger to bring event-entities closer to the feeling of a real event.
Third option would be to let event-entities trigger a complete new type of event (event-event?) and make a GUI element for that. But still will be confusing and will probably need quite some changes under the hood.
I was quite enthusiast with that implementation on the Z2M side and I was eager to make the switch from “state / _action” to events with version 2.0. However, it’s way too convoluted to implement it in HA.
This kind of automation where I can intuitively map different button presses, as different triggers, to one or more actions with choice become overly complicated with templates with this system.
triggers:
- entity_id:
- sensor.entree_bouton_aqara_gache_portillon_et_garage_action
to: single
id: portillon
trigger: state
- entity_id:
- sensor.entree_bouton_aqara_gache_portillon_et_garage_action
to: double
id: portillon
trigger: state
- entity_id:
- sensor.entree_bouton_aqara_gache_portillon_et_garage_action
to: hold
id: garage
trigger: state
With to: ~ / null, you also have the issue of having your automation seen as triggered even when it will not match anything in the end (and it could happen when coming back from unavailable also).
The implementation of Deconz with events sent on the bus was more intuitive than that.
trigger:
- platform: event
event_type: deconz_event
event_data:
unique_id: 00:17:88:01:06:06:81:5c # Stable ID that does not change like the HA device ID
event: 1002 # Click (xxx2) on left button (1xxx)
Why not sending the “button events” (“button” for disambiguation) on the event bus with a event event_type that would contain the “button event” in the event_data ?
trigger:
- platform: event
event_type: event
event_data:
entity_id: event.entree_bouton_aqara_gache_portillon_et_garage_action
event_type: "click"
I don’t think that would be worse than the official solution which has “state” for a stateless thing 3 times:
triggers:
- trigger: state
entity_id: event.hue_remote_control
actions:
- alias: "Choose an action based on the type of event"
choose:
- conditions:
- alias: "Normal evening scene if the button was pressed"
condition: state
entity_id: event.hue_remote_control_on_button
attribute: "event_type"
state: "short_release"
sequence:
- scene: scene.living_room_evening
And worse, this does not handle the race condition issue that requires an ugly template (again) to capture the attribute in the context of this specific trigger run.
There is also the lacking implementation of the event details in the logbook discussed here.
Edit:
Actually, maybe it could be already possible to do that with the event bus with something like that (I need to test).
trigger:
- platform: event
event_type: state_changed
event_data:
new_state:
entity_id: event.bureau_julien_bouton_hue_tap_dial_volet_et_lumieres_action
attributes:
event_type: press_release
button: button_1
Edit 2: Not possible because of this (8 years ago).
Yes, logbook spamming may not be the major issue with how the event entity works, but it’s definitely one of them.
An alternative good name was brought up in this post:
state_reported
I think this can also be done in a non-breaking manner.
state_reported is the name of the event that exists in HA today that is fired in large volumes. There was a PR specifically created to disallow triggering on it. The path the devs seem to want to take instead is to expand the state trigger to allow triggering on a report. Something like adding a configuration like fire_on_state_reported: true. The name of that setting I came up with myself and maybe isn’t great, but if I read between the lines that behavior is what the devs would agree to for a PR.
Edit: here is the PR I mentioned, for reference.
1 Like
I didn’t know that. For this to work for the use case discussed here, I guess it should only be for state that is reported as a side-effect of an action. Otherwise, state that is reported not in response to an action may lead to unnecessary invocations.
FWIW: I was not happy about this change at first, but I think I’ve been converted. It took a fair amount of work to update my automations, but they are cleaner now. Each device has one trigger instead of multiple triggers for each action. So, the triggers section is a lot less cluttered. Not a big deal to add the specified event as a condition.
1 Like
Shouldnt event entities be specialcased to NOT dedup state reports?
Yikes. This seems completely awful, and the documentation is sure confusing. Take a Zigbee dimmer remote for example. Is the intention to have one event entity that covers all buttons, or does each button have its own event entity? Because if one looks at the example in the documentation, the trigger uses entity id event.hue_remote_control while the conditions uses entity id event.hue_remote_control_on_button. Is this intentional or a gaffe?
If the intent is to have one event entity per button, how are blueprint developers supposed to deal with that? If any user can change the event entity id of any button, and I find entity ids to often be incorrectly or not at all renamed when renaming their containing device, it will be impossible to make blueprints where the user only selects one device and it makes use of all buttons.
This seems to happen regularly with HASS. I mean, how many different things are called a template now?! Confusing.
it’s really not that bad, you just transfer the the yaml from the trigger to a condition. For my automations, it was a literal 2 yaml line change.
And, yes, it’s each event entity represents a button, they are not all funneled to a single event entity.
Well as already mentioned what is bad is that the entity ids could be literally anything. If making a blueprint, you cannot take event entity ids for granted, like you can with say a device trigger type and subtype for a given ZHA device. In the blueprint you would need to explicitly ask the user “what is the event entity id for button X?”, “what is the event entity id for button Y?”, etc. Or am I completely misunderstanding something here…? If all you are doing is manually writing automations for your own use, then sure it is no big difference.
… you can filter entity selectors to integration and domain and device
Keep in mind, you can still use device triggers as well, just as you describe. With or without the event entities.
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