The state of an event entity is always the timestamp of the last event. The event itself can be found in the attribute event_type. That being said, I don’t know anything about how Node Red interfaces with HA.
Thanks. I will have to keep researching. I will ask in a Node-Red specific threat.
What I don’t really get is why I see everything ok in the entities list, but NR can’t read it:
Because the entity view has special magic for event entities.
Change the debug to “complete msg object”.
It will be at:
data.new_state.attributes.event_type
data.new_state.attributes.button
2 Likes
This was extremely helpful, thank you!
With the _action entity deprecation (I’m aware I can re-enable legacy support) my brain actually misfired for a moment where I thought “I guess device triggers are better?” 
Thankfully I regained my senses.
triggers:
- trigger: state
entity_id:
- event.knob_1_action
- event.knob_2_action
- event.knob_3_action
not_from: unavailable
actions:
- choose:
- conditions:
- "{{ trigger.to_state.attributes.event_type == 'stop_rotating' }}"
sequence:
- variables:
KNOB: "{{ trigger.entity_id.split('_')[1] }}"
ANGLE: "{{ states('sensor.knob_' ~ KNOB ~ '_action_rotation_angle') }}"
COUNT: "{{ (ANGLE / 12)|abs }}"
etc. works a treat again. 
(Aqara H1 Rotary Smart Dimmer … keywords in case someone is searching forum for this.)
Just finished converting one of my automations, that controls an IKEA E1743 device, from using the now deprecated sensor entity to an event entity. Here a few of my thoughts.
It’s not a significant difference unless you employ wait_for_trigger in which case it becomes a bit more verbose.
For example, here’s a snippet of the original automation that detects single and double presses of the device’s On button. A single press sets the light’s brightness to 128 whereas a double press sets it to 255. The wait_for_trigger uses a State Trigger to detect just one desired button event (to: 'on').
actions:
- choose:
- conditions: "{{ trigger.to_state.state == 'on' }}"
sequence:
- wait_for_trigger:
- platform: state
entity_id: sensor.office_dimmer_action
from: ''
to: 'on'
timeout: 1
- service: light.turn_on
target:
entity_id: light.office
data:
brightness: '{{ iif(wait.completed, 255, 128) }}'
The following does the same thing but with an event entity.
actions:
- choose:
- conditions: "{{ trigger.to_state.attributes.event_type == 'on' }}"
sequence:
- wait_for_trigger:
- platform: state
entity_id: event.office_dimmer_action
not_from: 'unavailable'
timeout: 1
- action: light.turn_on
target:
entity_id: light.office
data:
brightness: "{{ 255 if wait.completed and wait.trigger.to_state.attributes.event_type == 'on' else 128 }}"
The brightness template is ever so slightly more verbose because:
-
You can’t instruct the State Trigger to explicitly monitor the
event_typeattribute for a state-change toon. The reason is because it’s alreadyonand so it cannot change toon. Therefore the State Trigger will fire for any button press, possibly not anotheronevent as desired. So there’s a need to confirm that second button press was in fact the desiredonevent. -
If the
onbutton is NOT pressed a second time, thewait_for_triggertimes out and sowait.completedwill befalseand, more impactfully,wait.triggerwill benone. That meanswait.trigger.to_stateis undefined so your template cannot refer towait.trigger.to_state.attributes.event_typewithout first confirming thatwait.completedistrue(otherwise there will be an execution error).
Not quite as concise as using sensor.xxxx_action but I can live with it.
3 Likes
you need to be someone what a little bit more specific with this as I upgraded to 2.0 and it broke my opple switches and had to roll back, and before you say anything I am using events already, this is a shot from my mqtt screen after rollback from 2.0
In node-red, I changed from sensor to event, then instead of looking at payload, I changed that to data.new_state.attributes.event_type
Hope that helps
Example images:
3 Likes
Hello, I do apologies in advance if I missed an answer to my question, the topic is very very long 
In simple answer what should this be changed to in order to update to the MQTT v2.0.0-2
trigger:
- platform: state
entity_id:
- sensor.button01_action
to: single
id: Button1_Single_Press
The toggle likely turned off during the update. Verify the setting
Bobby. The thread is long but the original post I did is kept updated with the important info and the code you put is what I clearly warn against in the examples and in my text.
Do not - put to: or attribute: lines in the trigger.
1 Like
Thank you @KennethLavrsen , yes, this I have read but I am a bit confused regarding what should I put instead in order to differentiate the “single”, “double” or “long” press on the button?
Would it be for an example “event_type: single”?
triggers:
- trigger: state
entity_id: event.button01_action
event_type: single
id: Button1_Single_Press
It’s shown in the first post. If you haven’t read it yet, I suggest you start there.
The button event is in trigger.to_state.attributes.event_type.
The posted examples use choose to determine which button event occurred.
What part of my examples are not clear? The handing of the buttons pressed is in the action part of the automation.
To ensure you do not have race conditions (something has changed between trigger and test) you always use the trigger.to_state.attributes.event_type and often in combination with the trigger.to_state.attributes.button
It is different from device to device how it is implemented. But all I have seen is either event_type or both event_type and button attributes. When it is both the typical way is that the button indicates the physical button, and the event_type how it is pressed.
I think the entity described is a bit complicated for me to understand 
My automation that works on old MQTT version is something like this:
alias: "Zigbee Buttons automation"
description: "Zigbee Buttons automation"
mode: single
trigger:
- platform: state
entity_id:
- sensor.button01_action
to: single
id: Button1_Single_Press
- platform: state
entity_id:
- sensor.button02_action
to: single
id: Button2_Single_Press
- platform: state
entity_id:
- sensor.button03_action
to: single
id: Button3_Single_Press
action:
- choose:
- conditions:
- condition: trigger
id:
- Button1_Single_Press
sequence:
- type: toggle
device_id: 358987feee661a8a1409e8254a0ded34
entity_id: e861e434dfeee4122a1587009577409a
domain: switch
- service: notify.mobile_app_iphone
metadata: {}
data:
message: Open Gate by Button 1
- conditions:
- condition: trigger
id:
- Button2_Single_Press
sequence:
- type: toggle
device_id: 358987feee661a8a1409e8254a0ded34
entity_id: e861e434dfeee4122a1587009577409a
domain: switch
- service: notify.mobile_app_iphone
metadata: {}
data:
message: Open Gate by Button 2
- conditions:
- condition: trigger
id:
- Button3_Single_Press
sequence:
- type: toggle
device_id: 358987feee661a8a1409e8254a0ded34
entity_id: e861e434dfeee4122a1587009577409a
domain: switch
- service: notify.mobile_app_iphone
metadata: {}
data:
message: Open Gate by Button 3
- conditions:
- condition: trigger
id:
- Button1_Double_Press
sequence:
- service: alarm_control_panel.alarm_disarm
metadata: {}
data: {}
target:
entity_id: alarm_control_panel.outside_alarm
- conditions:
- condition: trigger
id:
- Button2_Double_Press
sequence:
- service: alarm_control_panel.alarm_disarm
metadata: {}
data: {}
target:
entity_id: alarm_control_panel.outside_alarm
- conditions:
- condition: trigger
id:
- Button3_Double_Press
sequence:
- service: alarm_control_panel.alarm_disarm
metadata: {}
data: {}
target:
entity_id: alarm_control_panel.outside_alarm
- conditions:
- condition: trigger
id:
- Button1_Long_Press
sequence:
- service: alarm_control_panel.alarm_arm_away
target:
entity_id:
- alarm_control_panel.outside_alarm
data: {}
- conditions:
- condition: trigger
id:
- Button2_Long_Press
sequence:
- service: alarm_control_panel.alarm_arm_away
target:
entity_id:
- alarm_control_panel.outside_alarm
data: {}
- conditions:
- condition: trigger
id:
- Button3_Long_Press
sequence:
- service: alarm_control_panel.alarm_arm_away
target:
entity_id:
- alarm_control_panel.outside_alarm
data: {}
I am failing to understand how to wrap this up into the new model 
If yaml is not you “thing” best to look for a blueprint for your remote.
Did you create that automation?
If you didn’t, ask the person who did. They’re probably facing the same situation and are converting it.
If you did, then you need to study the many posted examples. All of the required information is already posted in this topic.
it actually is 
I did all my automations via YAML and keyboard…I don’t like using the blueprints or ha automation wizards, hence I type all of it.
In the automation I noted, the only thing I extracted from HA is the device_id and entity_id…
Yes, I created it…
Ok, thank you …I’ll figure it out
1 Like
Oh… how broken that is…
I have Tuya ERS-10TZBVK-AA control via MQTT | Zigbee2MQTT
It sends simple payloads like:
payload '{"action":"brightness_step_up","action_rate":null,"action_step_size":97,"action_transition_time":0.03,"battery":94,"last_seen":"2025-01-07T17:58:41+01:00","linkquality":76,"operation_mode":"command","voltage":2900}'
Please note action and action_step_size.
In 1.x I could just trigger with action = brightness_step_up and get action_step_size from trigger.to_state.action_step_size in yaml.
Now getting to react for this with Z2M 2.0 is impossible, as I can get either (xor):
-
with legacy on, I can trigger *_action that can give me all info except for action_step_size:
trigger.to_state = <state event.przelacznik_sciemniacz_czarny_1_action=2025-01-07T17:03:04.917+00:00; event_types=['toggle', 'brightness_step', 'color_temperature_step_up', 'color_temperature_step_down', 'saturation_move', 'hue_move', 'hue_stop', 'single', 'double', 'hold', 'rotate_left', 'rotate_right'], event_type=brightness_step, direction=up, icon=mdi:gesture-double-tap, friendly_name=przelacznik-sciemniacz-czarny-1 Action @ 2025-01-07T18:03:04.917984+01:00>} -
use new, great
*action_step_sizetrigger, that gives me theaction_step_size, but does not say if this is up or down.
'to_state': <state sensor.przelacznik_sciemniacz_czarny_1_action_step_size=97; friendly_name=przelacznik-sciemniacz-czarny-1 Action step size @ 2025-01-07T18:13:34.792019+01:00>}
I’d appreciate if someone could enlighten me on how to use this “improved” way.
For now I’m reverting to pre-2.0 as it:
- brought me more bad than good,
- has edge cases where I just don’t know how to get data,
- bring unnecessary complications with breaking changes.