How to use Node-RED with MQTT device trigger from Zigbee2MQTT 2.0.0 breaking change?

[daviddesmet]

With all sensor.*_click entities removed from Zigbee2MQTT 2.0.0, it is suggested to use MQTT device trigger, but that article shows how to create an automation through HA.

How can I achieve the same with Node-RED?

I've all my automations in Node-RED and would like to keep all of them in there rather than having a couple in HA and having to switch between them.

[daviddesmet]

After poking around I found out that I need to manually connect to the MQTT Server and listen to a topic using the mqtt in node. I'm still looking to see if there's something more simpler.

[daviddesmet]

@Koenkk At the end I enabled that setting since it was more hassle-free when working with Node-RED. I'm just worried when it gets deprecated I would be facing the same situation.

@jimborr That's the node I was using before the breaking change from 2.0.0, The sensor.*_action entity is no longer listed and you can't select it from the Entity dropdown.

[Koenkk]

@daviddesmet it won't get deprecated until a proper solution is in place

[baloo2]

Same problem with MQTT device triggers in Node-red. Listened to all kind of HA events but the button action is not present. Had to enable legacy_action_sensor: true as it seems there is no simple solution in node-red right know. Well there is one solution but involves directly interacting with MQTT in node-red which I do not like (HA interacts with MQTT so why to interact with MQTT in node-red as well...?).

[lauri123]

I'm in the same boat. Found this discussion while searching for the neatest solution. Using NodeRED @ HA so I prefer that NodeRED communicates "over" HA, not directly with MQTT as much as possible. I'll enable the "legacy_action_sensor: true" also.

Note: Found "legacy_action_sensor: true" soultion also in the documentation, just hoped to find something better for the reason @daviddesmet mentioned - fear of being deprecated soon and need to re-redo again.

Solved for me (for now).

[sumasage]

@daviddesmet it won't get deprecated until a proper solution is in place

why was this changed in the first place? seem like it was working fine.

[YvoTuk]

I've enabled the legacy action sensor which solved some of the issues.

It seems like some devices just don't work anymore. I've got an Aquara WXKG03LM_rev2 toggle switch which says it exposes the action sensor, but when checking the device as such, it only shows Voltage, Battery and Linkquality. There's no mention of the action sensor.
I've tried a new interview, new config, but nothing happens.

Am I doing something wrong or is this some sort of bug?

[daviddesmet]

There must be something wrong on your side.
I just added the corresponding setting in zigbee2mqtt/configuration.yaml as follows:

homeassistant:
  enabled: true
  legacy_action_sensor: true # <--- this line

And then restarted the add-on.

[YvoTuk]

yup.. this is part of my configuration.yaml:
groups:

• groups.yaml
  homeassistant:
  enabled: true
  legacy_action_sensor: true

Strange... I assumed I could restart HA to restart the add-on, but I need to do that for the add-on itself.. hmm..

But.. entity is back now.. now have to see if I can get it back to work again :)
Thanks!

[kkuriata]

Enabling legacy_action_sensor works, but I believe it will disappear one day. I would prefer to solve the problem in "a new way" in NodeRED. I'm also looking for the solution other that mqtt in node. I tried device node and when I try to configure in for the first time, after selecting Aqara Switch, it detects actions like "single" and "double". However... After I deploy the changes, these action disappear and select field becomes disabled. Not sure if it is a bug or I'm just doing something wrong.

Before deploying:

After deploying and editting:

[daviddesmet]

Probably a bug since it is stated as beta. I would report that over here https://github.com/zachowj/node-red-contrib-home-assistant-websocket/issues
However, reading the description of the node "The Device node enables you to create device automations and call device actions within Home Assistant" doesn't seem like a good candidate since we don't want to call a device action, we would rather like to listen to them.

[Jens-Wymeersch]

Also in the same boat, but I'm not really worried about directly connected NR to the MQTT Broker. That said, struggling to find how to create the actions: single, double and long clicks. Anyone ?

[daviddesmet]

What I did was add the mqtt in node and set up something like this:

The topic is zigbee2mqtt/{device}/action

That goes to a switch node which then I split up into the corresponding actions:

You can add a debug node to find the action names.

It looks something like this (mine is still a work in progress since there are a lot of combinations for the Aqara's Magic Cube depending on the facing side):

My mqtt in node is disabled since I opted to enable the legacy_action_sensor setting.

[Jens-Wymeersch]

I've been trying to figure out the Topic for the whole day - did zigbee2mqtt/{device}/action work without the legacy_action_sensor ?
@Koenkk if you connect directly to the MQTT Broker like @daviddesmet will you be able in V2 and in the foreseeable future be able to get a state for the action.

[daviddesmet]

Yes, I came with that solution but didn't like it (because I didn't want to have another connection to the MQTT), hence why I enabled the legacy_action_sensor setting.

[Lusifeerus]

What I did was add the mqtt in node and set up something like this:

I did almost the same thing, but used the in node from node-red-contrib-zigbee2mqtt. It allows easy selection of device from dropdown and action as payload output.

[dnedeltchev]

Ah, there it is... I thought I was the only one with this issue...

[dnedeltchev]

OK, I got it working with a simple test flow but since I enabled legacy actions, I think I am still using those actions... I can't test what happens when I turn legacy actions now as the family is at home and if they can't turn on/off lights I will be in big trouble!

1. 
2. 
3. 
4. 

[Jens-Wymeersch]

You can take both MQTT node and your switch node in one and use the MQTT node with topic zigbee2mqtt/{device}/action as @daviddesmet suggested. The question is if you disable the legacy actions, you still find this topic in MQTT.

[dnedeltchev]

I will try to disable the legacy over the next few days and test.

[daviddesmet]

It works without the legacy_action_sensor enabled. I tested that before going back to the original way.

[dnedeltchev]

Thank you for this. I wonder when the legacy actions will be removed. But I think I would keep them for now as I have loads of flows that use the actions.

…

On Thu, 9 Jan 2025, 19:01 David De Smet, ***@***.***> wrote: It works without the legacy_action_sensor enabled. I tested that before going back to the original way. — Reply to this email directly, view it on GitHub <#25579 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AONHCL37KRRGXGIMIJQQNT32J3BRXAVCNFSM6AAAAABUUJYPNKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZZGAYTGNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[daviddesmet]

Yep, I'm in the same boat hence why I didn't want to go with the mqtt in node route.

[Jens-Wymeersch]

I've just moved mine to mqtt in. It's only 1 node per ... (in my case it was 15)
Potentially, looking if I want to do a mqtt out to make some of the flows (lights) fully independent of HA

[Jens-Wymeersch]

@Koenkk This is different as what you have suggested in the doc.

[manuelkue]

The really nice thing with subscribing to MQTT topics is that it allows for "generic" topics with wildcards like this:

zigbee2mqtt/+/switch/+/action/#

+ stands for a single level, # stands for multiple levels (or none) and must be placed last.
This way you can reduce the trigger nodes' count really well and don't have to create an automation for every device.

Read more about that here: https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

For this to work your devices should follow a name scheme that represents nested levels like office/switch/wall_4gang_1. I follow this scheme for my switches, sensors and thermostats and can then simply subscribe to the correct generic topic.

Afterwards their actions will be available under the topic zigbee2mqtt/<DEVICE_NAME_WITH_LEVEL_NESTING> and can be subscribed for as seen above.

In my case I then extract the device data in a following js node and evaluate the logic in a switch node. To find all mqtt messages initially you can simply put a mqtt in node that listens for all zigbee2mqtt-messages via subscribing to zigbee2mqtt/#:

(You should disable the subscription to every message after testing)

Extracting the data:

Reacting to the subscription in a switch node:

(The payload is the data the device emits to the mqtt topic, in this case the button press of my 4-gang wall switch like 1_single, representing a single click on the button top left)

[daviddesmet]

Fascinating share!
I wish I should have used that naming convention before 😅

[aru089]

I'm using mqtt in node. The strange thing is, I get three identical events by one single press.

The settings of the mqtt in node is following

Can anybody help?

[aru089]

I fixed it by deactivating and activating Z2M. Now, there is only a single message by one click of the button.

[nzagorac]

[edit 20250118] Per @Koenkk, the recommendation is to rely on Legacy, rather than "Experimental" mode. So the approach below is potentially subject to additional refactoring in the future.

---

After having spent a few hours, I found a way to avoid "Legacy" setting (life is too short to keep coming back and fixing reliance upon legacy stuff) and make it work with node red. Hope someone finds this useful.

My setup:

In Zigbee2MQTT settings, Home Assistant integration tab, I have enabled experimental features, so that I receive the "new" behavior. (they removed the old behavior with a breaking change, but they didn't introduce any new behavior unless it is explicitly configured):

Notice that I did NOT turn on legacy mode here.

Then, in Node RED, I am able to read the event state using entities (further reading here), like so:

$entity().attributes.event_type='on'

Obviously, your event types may differ from mine, depending on the zigbee device itself and what it's sending. The above is for an Ikea Tradfri button. Another button (random stuff from Aliexpress) I am testing like this:

$entity().attributes.event_type='single'

With this, I restored by Z2M pre-2.0.0 behavior, and I am not dependent on legacy any more. I hope the "experimental" thing becomes permanent so that I don't have to revisit this...

[dnedeltchev]

Hm, interesting... But I'm not sure whether relying on experimental features is better than legacy features 😁

[nzagorac]

It is a risk. But in my perspective:
Legacy = "it's guaranteed to go away at some point"
Experimental = "we believe this is the new direction" (based on the fact that they rolled out a breaking change of this scale, I hope they have a sense of the experimental alternative being the way to go)

[baloo2]

koenkk: legacy triggers won't get deprecated until a proper solution is in place

what that means is legacy triggers will not go away and will work without changes until (most probably) experimental events entity is finalized (koenkk: until the implementation becomes finalized, the event types and additional attributes are subject to change)

@nzagorac so what do you think is more stable solution for now...?

[Koenkk]

Personally I would keep using the legacy for now, the experimental stuff may break again in the future requiring you to refactor twice.

[nzagorac]

That's a clear recommendation from the maintainer (thanks for very prescriptive recommendation, Koenkk). I'll go ahead and edit my post above to reflect this input, to avoid any confusion.

Unfortunately, as I already refactored mine, to save time, I'll probably stick with current setup based on experimental and fix further breaking changes if they come.