Using the new action events in Zigbee2MQTT 2.0

Busta999x · January 4, 2025, 7:48pm

Trying work out the extra config v2.0 needs

ynnor666 · January 4, 2025, 7:54pm

serial:
  port: tcp://ip.ip.ip.ip:6638
  adapter: zstack

The adapter thing is what you are missing now.

rama3124 · January 4, 2025, 7:58pm

Hi, I just tried updating my automations YAML config to suit Zigbee2MQTT 2.0 and the automations still don’t seem to work. Can someone help me work out what I’m doing wrong?

Old config:

- alias: Dining room light switch single
  trigger:
  - platform: state
    entity_id: sensor.dining_room_light_switch_action
    to: single
  action:
    service: light.toggle
    entity_id: light.dining_room
  id: 18cdee8f3f4aca34719087f8f3ec7e40

New config:

- alias: Dining room light switch single
  trigger:
  - platform: state
    entity_id: sensor.dining_room_light_switch_action
    to: ~
  conditions:
    - condition: template
      value_template: "{{trigger.from_state.state != 'unavailable'}}"
    - condition: template
      value_template: "{{trigger.to_state.attributes.event_type == 'single'}}"
  action:
    service: light.toggle
    entity_id: light.dining_room

KennethLavrsen · January 4, 2025, 8:00pm

You still use the old sensor. Change to event entity

rama3124 · January 4, 2025, 8:05pm

Very silly of me, thanks for the quick reply

Busta999x · January 4, 2025, 8:08pm

Ha! I should have known that!!

My mistake It had been a long day and I saw several updates and just clicked on the, I did not do a full check and got burnt by it.

Lesson learnt ! Only install updates one month after release, and read up on them before installing, noob error.

Many many thanks for the help, very much appreciated!

ynnor666 · January 4, 2025, 8:21pm

All good. No need to wait, simply check the changelog and perhaps wait a day or so. Most big issues are then known.

jchh · January 4, 2025, 8:30pm

do you have:

homeassistant:
  enabled: true
  experimental_event_entities: true

in your Z2M configuration? …you need experimental_event_entities ‘on’.

mundschenk-at · January 4, 2025, 8:38pm

It still kinda is, in that we haven’t hashed out some technical issues on how the final implementation should look like.

So event entities are definitely the future, but changes to the exposed values are a possibility. Right now, this is still the same implementation as in the last 1.x release. This means that a few “wildcard actions” (i.e. actions where the device converter only specifies something_*_somethingelse as an exposed action) don’t work at all, and there are a few open tickets where action handling is a bit inconsistent regarding which parts become attributes and not part of the event_type value.

For the time being, I’d suggest enabling the legacy action sensors and keeping your automation triggers as-is if you have used the sensor entities before (I didn’t, since my Z2M installation releatively new, I use Switch Manager, which uses MQTT triggers for its Z2M blueprints). You can then change your automations one by one to use the new event triggers, but if you have a lot, I’d hold off on converting everything for a month or two (to not have to touch things twice in short time).

ChirpyTurnip · January 4, 2025, 9:45pm

This is all a bit of a ball-ache!

I have 100+ Node Red automations triggering off sensor entities that will all need to be converted to ‘event’ entities. I thought my problem was limited to re-enabling the “Home Assistant experimental event entities” and “Home Assistant legacy action sensors” settings in Z2M, but now it seems there is a LOT more work to do just to retain existing functionality.

I use NodeRed as my logic is quite complex and NodeRed has typically been easier to use for complex flows that the default HA automations (though these have improved considerably of late).

Can someone please point me to a post that explains how to update NodeRed flows to go from using sensor.* to event.*?

I’ve had a google but there’s not much there…unless I’m searching for the wrong things…

Thanks!

jchh · January 4, 2025, 10:04pm

Enabling legacy (and restarting Z2M) is all you should need to do to retain v1,x functionality.

AldoQ · January 4, 2025, 11:53pm

This imho is really why IT and developers are not trusted by the public (I say this as a developer). Especially reading the feedback on github by developers when this is raised as an issue and thats its exceptionally user unfriendly. Its just being brushed off as ‘not our problem, complain to HA’.

Very disappointed to see Zigbee2MQTT do this. And how this is just brushed off with the usual ‘this is why normal humans hate IT people’ responses such as ‘its in the patch notes’, ‘it was experimental’ and ‘complain on the ha community forum’. Sigh…

kevmang · January 5, 2025, 12:08am

I just spent the last 30 minutes scratching my head trying to figure out why my Zigbee buttons stopped working, then I came across this thread.

I’m also using Node Red and turned on “Home Assistant legacy action sensors” in Zigbee2MQTT → Settings → Home Assistant integration

Thankfully everything works again!

KennethLavrsen · January 5, 2025, 12:15am

I just notice you have defined the action part of the automation with values for the “to”
You should avoid that for state triggers that use event entities as you may have problems when same button is pressed multiple times.
Either have no “to” or use the null or ~ which means ignore the to value. Also do not have attribute in the trigger. You must test for attributes in either the condition or action part of the automation. There is a lot of debate about this and a good WTH topic. Maybe it will change. For now only trigger on the event entity like I show in my examples

matthewcbyington · January 5, 2025, 12:16am

@KennethLavrsen (and others), I wanted to first thank you for this very useful thread. Just my $.02, FWIW, I’ve a slight preference towards something like this:

      - trigger: state
        entity_id: event.kitchen_button_action
        attribute: event_type
        to: "single"

The main benefit of doing it this way, for me at least, has been that the trigger itself is more clear. For single-button units (such as the Aqara Mini Button) you don’t need any additional Conditions in the Automation. For a multiple switch (like the Hue), I simply add the condition on the “button” attribute, in the Choose.

Hope this helps someone!
Matt

KennethLavrsen · January 5, 2025, 12:36am

I just follow the technical advice. Your button may send a release message also and then it works. But read this WTH are event entities not triggered a second time when using the attribute `event_type` in a state trigger? - #9 by Mincka

In short. You may run into trouble with your approach. It is not a matter of preference. There seems to be a real issue.

Also with race conditions. The attribute of an entity can change from a trigger to later when you test its valie in the actions. That is probably why the examples from the Zigbee2MQTT documentation uses the trigger.to_state.attributes.button and trigger.to_state.attributes.event_type to test for the values as they are the exact values that were caught when the event triggered.

ChirpyTurnip · January 5, 2025, 12:43am

Yup. But the eternal question is “For how long?”

I’m happy (begrudgingly) to re-do all my Node-Red flows etc because it is easier than being suddenly stuck with a broken system, but it really isn’t cool.

Today I have also had to re-do all of my smart speaker announcements as tts.cloud_say stopped working. So now everything has been moved to tts.speak which also means you need to put your target speakers into JSON rather than adding target entities - another big step backwards.

I get the need for continuous improvement, but the effort involved in eternally re-working what you have just to keep it running is not fun.

dinth · January 5, 2025, 6:51am

So it seems that for me, the migration from legacy actions (needed to enable legacy after 2.0 update to make them work) to new actions just means changing sensor. to event. in the automations. Or am i missing something?

ezhik · January 5, 2025, 7:42am

I could do with a little help please. I use Aqara sensors and with the update to v2.0 have lost the sensor for illuminance that I use in NodeRed ie sensor.aqara_hall_illuminance_lux.

I’ve enabled both the legacy options in Zigbee settings, and tried changing sensor.aqara_hall_illuminance_lux to event.aqara_hall_illuminance_lux but neither options work for me, and event.aqara_hall_illuminance_lux doesn’t exist.

Having read through the threads about this update I’ve been unable to find a fix, can anyone point me in the right direction?

PS For now I’ve gone back to v1.42 and enabled experimental entities, this should be the same as v2.0 I think but also keep things working for me whilst I prepare to update?

reste_narquois · January 5, 2025, 8:09am

This is a separate breaking change in version 2.0, nothing to do with legacy options.

The linked discussion on GitHub should give you the necessary solutions if you try the update again.