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 does 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.