I think that the event was conceived with good intentions because it fixes some of the limitations of using events (i.e. the kind you detect with an Event Trigger).
However, I think that its designer(s) may have overlooked to consider how it can be used to neatly detect two consecutive and identical button events. The current method requires more than what’s easily achieved by just pecking at things in the UI.
In contrast, it can all be done via the UI when using an MQTT Device Trigger.
Well that was known from day 1 and that was a compromise. But none of them thought about addressing it from the state trigger itself.
That’s the MQTT documentation, where you can’t control what comes on the event stream. So you’re forced to use extra attributes.
event entity docs → Event - Home Assistant
Those docs make it pretty clear what the intentions are without explicitly saying it.
Yes, but it’s also obvious the starting point when implementing event entities for an MQTT-based integration. Too bad I had already replaced my Hue Bridges with Z2M by the time event entities became a thing, otherwise I might have realized the underlying paradigm sooner.
That said, while we can to a certain extend change “the event stream” with Z2M, completely ripping out the existing exposed entities (called an expose in Z2M parlance) and replacing them with something much more fine-grained is a Very Big Task™, so I’m not sure it would have made a real difference. Thanks for the link though, I’ll give it a read.
I’m not at all facile with jinja, but I’m a ninja with the cut and paste.
I really like the idea of moving away from unique device IDs. Devices fail over time and solutions like this make it so much easier to swap them out. I hope event-based triggering for Z2M is here to stay and that it just gets simplified with a visual editor option for the triggers and conditions.