event entities didn’t exist in HA 6 years ago, they are about a year and a half old. So Z2M is just taking advantage of the new system HA built to support events as an entity.
There are some good reading in a WTH topic
https://community.home-assistant.io/t/wth-are-event-entities-not-triggered-a-second-time-when-using-the-attribute-event-type-in-a-state-trigger/ submitted by our favorite petro
In fact, if state triggers, as an exception would retrigger with same value, the new Zigbee2MQTT events would work great with trigger IDs so go and vote for that WTF
Also the topic has a good technical discussion
3 Likes
Yeah I created that to give me an reason to potentially update state triggers without push back from the devs.
Still not sure if that’s the “best” way to handle this.
I think the simple solution to allow retrigger with same value if the source is an event entity would be simple and elegant and backward compatible. And it would require one line of documentation to be added in the description of state triggers
I haven’t found a work around yet that allows me to keep ‘legacy’ off and still use node red for the actions, however: having an mqtt-in node configured to listen to the device/action topic seems to work. Now I would only need to replace all button ‘event-state’ nodes for this one.
Too much work for today, but maybe in the future.
Using the mqtt in node is exactly what I’ve done. Works no problem although I only had a few to change.
Moved my blueprints to event entity with Z2M 1.42.0 and it works faster than with legacy action sensors.
Remember to ignore the unavailable state transition in your triggers/conditions, otherwise your house will take its destiny into its own hands.
I opted for this instead of templates:
triggers:
- id: action
trigger: state
entity_id: !input remote
not_from: unavailable
5 Likes
That is elegant.
You can replace the condition 3 lines by adding the not_from: unavailable
I verified that this works.
1 Like
On a side note, I have an Ikea two-button E1766 button. How can I tell if it’s short pressed or long pressed?
E.g., for a short press, only one event is fired.
For a long press, a stop event is fired when it’s released. So theoretically by looking at just the first event, there’s no way to tell if the button is short pressed, or if it’s being long-pressed and not yet released. Any thought? Thanks!
You do not show all the information the switch is sending and I do not have this type.
We need to see the event_type attributes. Read my entire initial post in its entirety including looking at the attributes values, They should tell you all the values.
For some switches it is a combination of multiple attributes. Often a button attribute.
Another 2-button IKEA that I have can be caught with this
- "{{trigger.to_state.attributes.event_type == 'brightness_move_up'}}"
Sorry my post was a little irrelevant. The event trigger works fine in my setup and I can perform any action when the button is pressed. It’s just that I’m looking for a way to tell if it’s being short-pressed or long-pressed.
It is not off topic. The purpose of this post is to give working examples.
My IKEA two button - different model lists these attribute vales in Developer Tools → States.
event_types: on, off, brightness_move_up, brightness_move_down, brightness_stop
event_type: off
icon: mdi:gesture-double-tap
friendly_name: Office Blinds Switch Action
The events attribute is a value that never chages but lists all the event_type values.
The event_type is the last value received
What does it say for your IKEA switch? Please share so we can give people a solution
Detect the initial open or close event then use a wait_for_trigger (or wait_template) to detect a potential stop event. Use a timeout value of 1-2 seconds. Then use an if to decide what should happen next (based on whether or not a stop was received).
I have used the same technique for detecting long press events and double-press events (specifically for devices that don’t explicitly report a double-press event).
Funny that this variant only has those 3 values.
The E1743 - the one with 0 and 1 - has the additional values for long press and then you can use the one liner I posted. I think the other one came with IKEA shades or blinds.
But what happens if I hold the button longer than 2 seconds?
How long should I wait for the stop event?
(And how long will it take for my wife to file for divorce, when every short press of a button causes a wait time of > 10s until the light switches on. 
)
You should read the documentation for wait_for_trigger and timeout and then you can answer your question.
The alternative, if feasible for your particular situation, is to buy a device that explicitly reports a long-press event.
That’s the ones I have and use the technique I suggested above (to Thyraz) for detecting double-press events (which aren’t explicitly reported by an E1743).
E1743 Actions
The possible values are:
on,off,brightness_move_up,brightness_move_down,brightness_stop.
Well. I’m aware of the documentation, it was more a rhetorical question. But I thought that it’s not possible anymore to identify the single click because of Z2M 2.0.
Then I would avoid updating or enable legacy features before buying new hardware.
(In hope that a future update will bring possibilities to fix this, as this is most likely not the only sensor with problems in the large Zigbee world).
But it sounds now, like this sensor never had the possibility to distinguish between long and short presses quickly? (Without timeout hacks.)
I will assume you’re still posting rhetorical questions.
Hi there! Sorry for bumping in like this on the topic. I have read all posts here, but I still don’t know how to get Node-Red to work. My setup:
- As mentioned here before, I have checked this set of options:
When I press the Xiaomi button, I see the topic and the “action” parameter reporting proper values:
But Node-Red picks up only the timestamp:
Can anyone please shed some light?
Thank you