This is my first attempt at a Blueprint. I adapted it from another Blueprint to use the experimental events in Z2M 2.0. It’s working great for me so I thought I’d share. I will keep it up to date if I can.
Note that Zigbee2MQTT Events (experimental) will need to be enabled since it is not enabled by default. It seems like events will replace the action sensor which is now depreciated.
Background:
Editing Z2M configuration:
My Blueprint with changes as per title:
Hey,
I have been using this since you released it - thank you.
As i have recently moved from one zigbee stick to another i ended up rebooted quite a lot and noticed that the current blueprint does not differentiate between an old press (after a reboot) and a new press.
So I updated the template Zigbee2MQTT 2.0 Tuya/LoraTap remotes with experimental event entities · GitHub
and added a condition to ignore when the previous state is unavailable and this stops the false positives I was getting.
Great original work btw 
- works prefectly, it just happens that I do alot of my computer work when the kids are in bed and keep getting shouts of “why has my light turned on” due to the restart issue this halts.
Hey, sorry 1 more update - I noticed that on a zigbee2mqtt reboot (as I use that over ZHA) I got a weird warning in the logs –
'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'button' when rendering '{{ trigger.to_state.attributes.button }}'
Template variable warning: 'homeassistant.util.read_only_dict.ReadOnlyDict object' has no attribute 'event_type' when rendering '{{ trigger.to_state.attributes.event_type }}'
I looked into it and modified my gist to only process if not unknown / unavailable and also a slightly differnt way to get the button so that if that is not fully setup it does not fail / error.
You’re welcome! I’m glad you’re getting use of the script.
Thank you for noting your changes. I hope you don’t mind that I took your changes and incorporated the changes into “my” version. I also manually merged in some other edits I noticed someone else made (to have up to 6 buttons).
Hey, no worries at all, if gists allowed PR’s I would have gone down that route 
I see code and open and people should contribute to a common goal, your template saved me when zigbee2mqtt V2 came out, so I’m glad to be able to give a small amount back
Hey,
Thanks for importing all the other changes, as an fyi I have made one more change, and tested it on my local system: the addition of ignoring where the the state is coming from unavailable.
I don’t know what has changed in zigbee2mqtt, but with the latest version what is sent on a reboot seems to have changed, I believe the previous order was:
Before went : unknown → unavailable (reboot) → unknown
However now it goes :
Unknown → unavailable (reboot) → null → unknown
Since we are watching the events, and that always has the attribute event_type this was causing the action to happen on each reboot.
So I have added an extra condition to ignore when the previous state was unavailable, so ignoring the first null record.
The alternative, and would value your views, is to ensure legacy sensor is used? And perhaps only pickup the actual none null state from
sensor.{{ name of switch }}_action
As from what I can see that is either
Unknown, null, unavailable, or the actual action
And on a reboot that actual action is not pushed.
But it is in the event attributes, which is how I think it is currently captured.