Using the new action events in Zigbee2MQTT 2.0

[KennethLavrsen]

It may be a controversial oppinion but I generally do not these like blueprints that tries to do everything. Only the author understands what it is doing and it is super difficult to modify it unless you are really good at yaml and jinja. It keeps people stupid.

Bobby. It is easy to fix your automation. First step is to just accept that your trigger will only have one thing it triggers for with no to values and no trigger IDs.

The next two steps are.

1. Find out what your event entity is. It is called event.name_of_device_action

2. Go to developer tools → States and find your event entity. Look at the attributes in the right column. You should see event_types listing all the values that event_type can have. Also look for an optional button attribute. There is no list of buttons but if you press your remote buttons one by one you see the names.

Now you have the information you need. All you need now is to update your old automation with the super simple trigger exactly like my examples except for the event entity name.

And in your actions in the choose conditions you replace your conditions by the template conditions adjusting the values with the ones you found in step 2. And Bob’s your uncle.

[TimoJ]

I converted my triggers to use MQTT and it works fine and is simple. But maybe I’m missing something when I’m using this instead of this complicated action events way?

triggers:
  - trigger: mqtt
    topic: zigbee2mqtt/TuYa button/action
    payload: single
    id: single
  - trigger: mqtt
    topic: zigbee2mqtt/TuYa button/action
    payload: double
    id: double
  - trigger: mqtt
    topic: zigbee2mqtt/TuYa button/action
    payload: hold
    id: hold

[KennethLavrsen]

There are many ways to do things including the old legacy way which we can see on the Zigbee2MQTT github discussion probably will live for a long time, longer than communicated last week. Triggering directly on the MQTT messages is also a way. I’d it can quickly be complex if you have to combine multiple attributes.

The purpose of this forum thread is to share knowledge about how to use the new event triggers

[petro]

And what’s stopping you from using the event trigger and grabbing the step size from the sensor?

I get it’s not ideal, but direction=up was supplied which is not a standard attribute, it seems like they just forgot step size with it.

[123 (Taras)]

@TimoJ

maybe I’m missing something when I’m using this instead of this complicated action events way?

You’re not missing anything. You’re using one of several ways to interact with a device via Zigbee2MQTT.

MQTT Device Trigger and State Trigger (using an event entity or the deprecated sensor entity) communicate with the physical device (via Zigbee2MQTT) using concepts unique to Home Assistant (Device Triggers and entities).

These concepts provide additional features such an event entity’s history can be recorded and, when triggered, one can compare its previous state to its current state (i.e. previous button event to current one). They also serve as an additional layer of abstraction, meaning that the way you interact with an event entity is the same regardless of which integration (Zigbee2MQTT, ZHA, zwave, etc) represents the physical device.

In contrast, an MQTT Trigger directly references the physical device’s MQTT topic. Effectively, it bypasses the use of any “middleman” (such as Device Trigger or event/sensor entities) and uses the direct, raw feed from Zigbee2MQTT. It can’t take advantage of the middleman’s additional features but a given application might not need them.

---

FWIW, in the example you posted, containing one MQTT Trigger per button event, it can be reduced to a single trigger. A choose can separate which button event occurred based on trigger.payload.

alias: example
triggers:
  - trigger: mqtt
    topic: zigbee2mqtt/TuYa button/action
conditions: []
actions:
  - choose:
      - conditions: "{{ trigger.payload == 'single' }}"
        sequence:
           ... etc ...
      - conditions: "{{ trigger.payload == 'double' }}"
        sequence:
           ... etc ...
      - conditions: "{{ trigger.payload == 'hold' }}"
        sequence:
           ... etc ...
    default: []
mode: single

[bobby.kaucic (Bobby)]

Thank you @TimoJ

Because of your example, I have successfully upgraded and converted my automations

Everything works great now!

@KennethLavrsen
I will dig into your suggested method as well, as it will be good to learn. Thank you

[123 (Taras)]

Here’s your automation converted and simplified; one State Trigger and three choose options.

alias: "Zigbee Buttons automation"
description: "Zigbee Buttons automation"
mode: single
trigger:
  - platform: state
    entity_id:
      - event.button01_action
      - event.button02_action
      - event.button03_action
    not_from: 'unavailable'
conditions: []
actions:
  - variables:
      event: "{{ trigger.to_state.attributes.event_type }}"
  - choose:
      - conditions: "{{ event == 'single_press' }}"
        sequence:
          - type: toggle
            device_id: 358987feee661a8a1409e8254a0ded34
            entity_id: e861e434dfeee4122a1587009577409a
            domain: switch
          - service: notify.mobile_app_iphone
            data:
              message: "Open Gate by Button {{ trigger.to_state.object_id[7:8] }}"
      - conditions: "{{ event == 'double_press' }}"
        sequence:
          - service: alarm_control_panel.alarm_disarm
            target:
              entity_id: alarm_control_panel.outside_alarm
      - conditions: "{{ event == 'long_press' }}"
        sequence:
          - service: alarm_control_panel.alarm_arm_away
            target:
              entity_id:
                - alarm_control_panel.outside_alarm
    default: []
mode: single

If your device does not have a separate event entity for each button, let me know and I’ll show you how to modify the automation.

[mundschenk-at (Der Mundschenk & Compagnie)]

The underlying issue is that some devices have pretty idiosyncratic exposes (i.e. some like this Tuya device have additional payload keys that are related to the action but technically separate). The current event implementation does not handle these “extra” data points at all (that’s one of the reasons why it is labelled “experimental”). There is an ongoing discussion on how to best handle these things in the future (mostly on a technical level - e.g. will there be a new JSON object in state collecting all the relevant attributes).

[petro]

I understand, but for the time being, they can use the sensor for that additional information if they want to transition to the event entity. Otherwise they can stay with the legacy sensor entity.

[mundschenk-at (Der Mundschenk & Compagnie)]

Sure. I just wanted to explain that it was not an oversight, but rather a minimal implementation that was intended to be extended in future iterations (before 2.0.0), but got stuck in an architecture discussion.

For now, personally I’d probably stay with the legacy sensors if I had been using those before on a large scale, and only transition a few of my less complex automations to get the feel for event entities. I hope something happens for the WTH you created, it’s really detracting from the ease of use for event entities. Since I was using Hue dimmer switches for testing, I didn’t even notice that the event_type was not updating for repeated presses (because those have separate actions for press, hold, and release, so the attribute always updates during a cycle).

[ajeden]

It’s not there.
Depending on how you trigger the automation you get either direction, xor step size.
I also miss the point of having event brightness_step + direction while device sends brightness_step_up or brightness_step_down as actions.

[petro]

It is, you posted an entity for it…

@ajeden

‘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>}

[ajeden]

I appreciate your help, petro.

Ok, but which direction did the knob turn?
This is triggered by event *action_step_size - no indication of up/down. Just the number of ticks registered by the knob.
Or am I missing something?

[petro]

You trigger off the event which has the event_type and direction, and you use the sensor separately to get the number of ticks.

This can be done with variables, which resolve directly after the trigger and before conditions.

e.g.

triggers:
- trigger: state
  entity_id: event.przelacznik_sciemniacz_czarny_1_action
variables:
  type: "{{ trigger.to_state.attributes.event_type }}"
  direction: "{{ trigger.to_state.attributes.direction }}"
  step_size: "{{ states('sensor.przelacznik_sciemniacz_czarny_1_action_step_size') }}"
condition:
...
action:
...

[ajeden]

I was missing this:
states('sensor.przelacznik_sciemniacz_czarny_1_action_step_size')
Thanks a lot. I’ll try it later, as for now I just moved back to 1.42.

[KennethLavrsen]

@mundschenk-at here is a working automation for the Aqara Opple 6 button switch

This Aqara WXCJKG13LM control via MQTT | Zigbee2MQTT

Note the odd way that the hold function requires to AND the event_type and the button. The rest are nice and simple event_types. How did it end up like that?
When you look at the raw MQTT the message are simple button_6_hold. I do not even understand how it ends up like that in HA. It must be a bug. And when you fix it you break things again and people will be grumpy. Can you explain why it is like that? It cannot be intentional?

alias: Cloud Control Opple
triggers:
  - trigger: state
    entity_id: event.cloud_control_action
    not_from: unavailable
actions:
  - choose:
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_2_single'}}"
        sequence:
          - data:
              topic: living-room-curtain/set
              payload: open
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_1_single'}}"
        sequence:
          - data:
              topic: living-room-curtain/set
              payload: close
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_2_double'}}"
        sequence:
          - data:
              topic: living-room-curtain/calibrate
              payload: open
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_1_double'}}"
        sequence:
          - data:
              topic: living-room-curtain/calibrate
              payload: close
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_4_single'}}"
        sequence:
          - data:
              topic: smallwindow/set
              payload: open
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_3_single'}}"
        sequence:
          - data:
              topic: smallwindow/set
              payload: close
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_6_single'}}"
        sequence:
          - data:
              topic: cloud/step
              payload: "5"
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'button_5_single'}}"
        sequence:
          - data:
              topic: cloud/step
              payload: "-5"
            action: mqtt.publish
      - conditions:
          - "{{trigger.to_state.attributes.event_type == 'hold'}}"
          - "{{trigger.to_state.attributes.button == 'button_6'}}"
        sequence:
          - data:
              topic: cloud/step
              payload: "100"
            action: mqtt.publish
      - conditions:
          - condition: template
            value_template: "{{trigger.to_state.attributes.event_type == 'hold'}}"
          - condition: template
            value_template: "{{trigger.to_state.attributes.button == 'button_5'}}"
        sequence:
          - data:
              topic: cloud/step
              payload: "-100"
            action: mqtt.publish
      - conditions:
          - condition: template
            value_template: "{{trigger.to_state.attributes.event_type == 'button_6_double'}}"
        sequence:
          - data:
              topic: cloud/automove
              payload: "on"
            action: mqtt.publish
      - conditions:
          - condition: template
            value_template: "{{trigger.to_state.attributes.event_type == 'button_5_double'}}"
        sequence:
          - data:
              topic: cloud/automove
              payload: "off"
            action: mqtt.publish
initial_state: "on"
mode: queued
max_exceeded: silent

[mundschenk-at (Der Mundschenk & Compagnie)]

It is intentional in that the raw action strings are parsed and broken up into the actual action (the event_type) and other attributes (like button). It is not intentional in that of course all actions of a device should be treated consistently.

The reason why things come out weirdly for this specific device is that the initial experimental/poc implementation (for 1.42.0, this is not a new feature in 2.0.0!) has a bunch of regular expressions to try and parse the action payload strings that were designed by looking at zigbee-herdsman-converters/src/devices at master · Koenkk/zigbee-herdsman-converters · GitHub but of course not tested with all of them. It happens that button_<x>_hold matches the regex intended to showcase the features of HA event entities with the Hue dimmer while button_<x>_single does not.

PS: A benefit of short “generic” event_types is HA’s frontend translation could localize them.

[KennethLavrsen]

I am fine with either. It was the inconsistancy that concerned me. Now I understand the regex discussion I read earlier on the Z2M github. Thanks for taking the time to explain it @mundschenk-at

[MrPardal]

Guys, just turn ON legacy actions in Z2M > Settings > Home Assistant integration

[123 (Taras)]

Sure, but this topic isn’t about continuing to use a deprecated method that will eventually be eliminated.

The event entity was designed to be integration agnostic. Once you learn how to work with it, you can manage button events regardless of the device’s integration.