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.
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.
I updated z2m yesterday to find out about this breaking change. Had to conclude the old system is way better. Especially since fixing this will most likely result in breaking changes.