[Feature request]: restore button action sensor

[devildant]

Is your feature request related to a problem? Please describe

Hi,

since version 2.0.0, the action sensors for the buttons have been deactivated, it is possible to reactivate them via legacy_action_sensor: true

but this is deprecated in the documentation, it will therefore be deleted in the future, my request is precisely not to delete them, here is why :

alternatives are problematic.

1. Use MQTT device trigger,
   this is based on the device ID which is not modifiable, using the device id is an abberation because it requires modifying all the uses of the device id when replacing a device, unlike the entity id which is modifiable and makes it easy to replace a device, just rename it like the old one and everything works again

2. HomeAssistant event:
   in automations the events are not re-emitted, this therefore requires catching all the events and adding conditions to determine the value, this makes the automation enormously complex for nothing, because you have to put conditions everywhere, and when you has an automation with several triggers it becomes a nameless quagmire

3. Use MQTT topic (best solution, but copy past necessary)

I admit that I absolutely do not understand the choice to remove the legacy action sensors, it is a simple, effective solution, supporting graphics management, removing them is in my opinion a regression and not an evolution.

I am open to explanation :)

Describe the solution you'd like

restore to default

Describe alternatives you've considered

no

Additional context

no

[SHxKM]

I don't quite understand number 2, but 1 is a strong argument in my opinion.

[devildant]

I don't quite understand number 2, but 1 is a strong argument in my opinion.

For exemple :

I have an ikea button for run a scene, with event, i click one time on the button, the event pass to on, the automation is trigger and run my scene, but if i click again on my button, the automation not trigger because the event is already « on »..

[devildant]

for this to work, the event trigger must be set to no value, then create a condition matcher with the event value. This will therefore unnecessarily complicate automations for nothing. to put it simply, events are not reset after the action

[SHxKM]

I don't quite understand number 2, but 1 is a strong argument in my opinion.

For exemple :

I have an ikea button for run a scene, with event, i click one time on the button, the event pass to on, the automation is trigger and run my scene, but if i click again on my button, the automation not trigger because the event is already « on »..

Haven't heard the advantages/other side of the coin, but this sounds like a nightmare.

[devildant]

I don't quite understand number 2, but 1 is a strong argument in my opinion.

For exemple :

I have an ikea button for run a scene, with event, i click one time on the button, the event pass to on, the automation is trigger and run my scene, but if i click again on my button, the automation not trigger because the event is already « on »..

Haven't heard the advantages/other side of the coin, but this sounds like a nightmare.

it's a nightmare, I have hundreds of automations that are already very complicated, I'm not going to add another layer... plus it's going to take me ages to modify everything if I don't forget some... and none of the solutions are practical, solution 1 on the device id is a no for me, solution 2 is the same, I'm not going to put conditions everywhere otherwise I'll be here for days. and solution 3 is going to be great for reading my automations, I don't validate the choice that was made at all

[sfox38]

I thankfully have only two automations affected by this change, so I updated one of my scene switch automations to use the new Device/Action method. Now everything triggers twice! I don't even know where to start now. Am I going to have to add some additional logic in there to prevent duplicate actions as well??

This is quite ridiculous. The whole point of Z2M, and HA for that matter, is to make incomprehensible and incompatible technologies (like Zigbee) usable by non-geeks, or even by just us lazy geeks who don't want to do a ton of scripting. I fail to see any benefit to anybody by removing this function. Please bring it back or else provide a well documented and 100% working replacement

[KennethLavrsen]

It is pretty easy to use the new events. Just use the example yaml from the documentation.

or better read this post I did on HA forum. https://community.home-assistant.io/t/using-the-new-action-events-in-zigbee2mqtt-2-0/821709

[After2702]

No, don't do that, keep the action method

[FuzzyMistborn]

Yeah I'm not a fan of this change. The MQTT device actions is an absolute nightmare for NodeRed. This is my current setup:

I have 1 node for all sensor.*_action entities that I can then filter and route depending on device and how many clicks. My reading of the docs for the MQTT device triggers is I'd had to create an individual setup for each button AND each click (single, double, hold, release).

Perhaps NodeRed could improve, but I don't understand why this change was made. And I 100% agree that putting in conditions is going to be a nightmare of automating to use HA events.

[SHxKM]

@devildant from what I understand, if we use HA events, then pt. 2 isn't really an issue. At least from what I read in the docs and from other discussions. But maybe I'm missing something (again).

[devildant]

@devildant from what I understand, if we use HA events, then pt. 2 isn't really an issue. At least from what I read in the docs and from other discussions. But maybe I'm missing something (again).

If you want use event in trigger, it's necessary to put an condition for check the value. If you don't create condition your action button will be not trigger in second click

It complicates automation for nothing

[devildant]

@devildant from what I understand, if we use HA events, then pt. 2 isn't really an issue. At least from what I read in the docs and from other discussions. But maybe I'm missing something (again).

This is what I found yesterday, while doing the test, do the test yourself

[SHxKM]

@devildant from what I understand, if we use HA events, then pt. 2 isn't really an issue. At least from what I read in the docs and from other discussions. But maybe I'm missing something (again).

This is what I found yesterday, while doing the test, do the test yourself

Yes, you were right. This is another regression in my opinion. Especially since Logbook will be filled with N * possible event_types if I want to handle events in separate automations.

[Mikescotland]

I would also like to see that change reverted.
Unnecessary complication in automations for scenarios that button is pressed second time. Nightmare.

[Koenkk]

We can always decide to not remove the legacy_action_sensor as it serves some use cases which are not covered by MQTT device trigger and event entities. However I would still keep it legacy as the MQTT device trigger and in the future event entities are better, the action sensor is a dirty hack which was needed because HA did not support MQTT device trigger/event entities back then.

[devildant]

We can always decide to not remove the legacy_action_sensor as it serves some use cases which are not covered by MQTT device trigger and event entities. However I would still keep it legacy as the MQTT device trigger and in the future event entities are better, the action sensor is a dirty hack which was needed because HA did not support MQTT device trigger/event entities back then.

Hi, thanks for your feedback, the events are still too young in ha, and I don't understand why the data from them remains persistent, it goes against a classic event system, their behavior should be similar to the legacy system with the z2m sensors. as for the use of the device id it remains just as problematic. for me as long as the legacy sensor action remains in place until the ha events are mature and functional with a self reset it's fine with me ^^ if I made this FR, it's to highlight the current shortcomings, and for the moment the legacy system remains the most reliable, efficient and easy to use

[ukmgranger]

For me, this is a bit of a 'WTH is it so hard to press a button and make it do something.'
I use Nodered for all automations. I do this for it's simplicity, and the fact that most things can be achieved without the need for coding (even relatively complex automations). Buttons were pretty simple - select the sensor action, then wire that to something. It has now become waaaay more complicated.
I also don't like living under the 'legacy' option as it feels like it could be removed at any point.

[KennethLavrsen]

The legacy label is important. I can personally say that I added Zigbee2MQTT to ny home several years ago motivated by the extensive support for various sensors, but I keps all my lights and all my 2 and 4 button switches on Deconz because of three reasons.

1. Deconz uses a nice event system where the events have human names.
2. Zigbee2MQTT however used the horrible HA device IDs which are random numbers. I still cannot acceot that a device cannot be read by me as a human.
3. Zigbee2MQTT marked the much more human friendly hack as legacy with a clear signal that it would be removed.

When Zigbee2MQTT announced the intend to implement the new events entities I was super excited. And with the December 2024 release I started planning moving almost 100 devices from Deconz to Zigbee2MQTT. I did the move the past 4 days. And I am very happy with the performance. Not so happy with the illuminance sensor changes but I managed.

I can live fine with the HA events as they are now. But I have been helping people in the HA forum the past days and people suffer. They suffer for the obvious reasons that is is a major change. They also suffer because the communication was too geeky with no complete examples.

Given the issues that were highlighted in the December release you should not have turned off the legacy sensors. And what really makes me wonder is why does people report that the new events sensors were not even enabled in 2.0? Was that a HA addon silly decision? I had done the enable in the December release so my 2.0 was seemless with the event entities enabled from day one. Make sure the new events are default ON on next release.

For the future and success of the new events the key thing is to get the Home Assistant devs to fix the state triggers for event entities to retrigger for the same event values. People report problems with the new events because they want to use automations with trigger IDs and multiple To or Attribute values and that does not work well. Buttons cannot be pressed multiple times. That is a trap that people will fall into.

In the documentation for Zigbee2MQTT the example should not have the "To: ~" line in the trigger. People do not get the message.

see https://community.home-assistant.io/t/using-the-new-action-events-in-zigbee2mqtt-2-0 how I gave two good typical examples and note the problems people have. Until HA fixes the event triggers Zigbee2MQTT documentation should state clearly not to add any To or Attribute lines in the trigger. E.g. add the two comment lines from my examples.

[alepee35366]

This change makes life hell for anyone using NodeRed for their automations. I have just lost a couple of hours trying to find out why all my switches stopped working.

Considering the widespread aoption of NodeRed, a change like this should have been coordinated with the NodeRed teams so that a simple solution could have been implemented that would avoid having to heavily modify all existing flows. No one would be making such a fuss about this if it had been done that way.

I'm not going to argue for or against the new event entities, in the end, I don't really care as long as they work as they should and dont make me set up things in a convoluted and non natural way.

In my opinion, the legacy option should NOT be removed at least untill a solution has been implemented and thoroughly tested on NodeRed.

[Koenkk]

In my opinion, the legacy option should NOT be removed at least untill a solution has been implemented and thoroughly tested on NodeRed.

Given the feedback and the Node-Red use case, it will not be removed (at least anytime soon)

[sticilface]

I also agree. All my buttons just stopped working, all the button actions vanished from HA, I reenabled it via legacy action support, but I have probably 50 automations all working in NodeRed, and it is certainly not trivial for me to got through and change them all...

I'd appreciate it if they stayed... and I can take some time to get my head around HA actions.

[Mincka]

I personally think the issue is on HA side which lacks a proper trigger to handle the new "event" entities.

In the meantime, I am not sure the Z2M documentation should continue to state that "MQTT device trigger" is the "recommended" method for HA. This will continue to mislead people into implementing device triggers which are another HA flawed implementation.

I think it's right to say that Z2M actions for HA are from the past because they workaround the issue of handling repeated events with a state immediately reset to "", which is kind of ugly but it worked until now, and will continue to work.

The issue is that the pre-deprecation of Z2M actions left people in the middle of two things: the device triggers, a solution which was bad from the start, and the events, that are in the end experimental on both Z2M and HA sides. On HA side, there's obviously the issue related to repeated events, but also the poor implementation in logbook.

And now, because of this, HA people are advised to use overly complicated workarounds to support events which create other issues (e.g. automations appear as triggered but it's not relevant because event filtering is done inside).

Hopefully, this move from Z2M will help to gain traction and visibility by HA dev so they can propose a proper trigger to handle events. Please vote for this WTH: 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/804428

[huperaisan]

I'm unable to follow the technical discussions, but would appreciate a layman's explanation of how to replicate what used to be the "action" field in something like this: https://www.zigbee2mqtt.io/devices/SH-SC07.html

The only entities remaining are "Battery" and "Link quality".

[Mincka]

Just use legacy_action_sensor: true in /homeassistant/zigbee2mqtt/configuration.yaml for now to restore the _action state of sensor entity:

homeassistant:
  enabled: true
  legacy_action_sensor: true

[huperaisan]

Just use legacy_action_sensor: true in /homeassistant/zigbee2mqtt/configuration.yaml for now to restore the _action state of sensor entity:

homeassistant:
  enabled: true
  legacy_action_sensor: true

Okay, so this has restored the _action state in Z2M, but is there an additional step to restore it as an HA entity? I've restarted HA and reloaded the MQTT integration, and it's not showing up in either the HA devices page for the button nor in Node Red. Thanks for your help!

[Koenkk]

In the meantime, I am not sure the Z2M documentation should continue to state that "MQTT device trigger" is the "recommended" method for HA. This will continue to mislead people into implementing device triggers which are another HA flawed implementation.

Out of curiosity, why is the MQTT device trigger a flawed implementation? In my opinion it is really simple and it works very well, I use it for years already without issues. Example: #25677 (comment)

[Mikescotland]

In the meantime, I am not sure the Z2M documentation should continue to state that "MQTT device trigger" is the "recommended" method for HA. This will continue to mislead people into implementing device triggers which are another HA flawed implementation.

Out of curiosity, why is the MQTT device trigger a flawed implementation? In my opinion it is really simple and it works very well, I use it for years already without issues. Example: #25677 (comment)

As it is now in the HA? Very simple. Simplicity. It's a big regress from being a user friendly thing.
With mqtt trigger I need to know the topic and payload. For each trigger from the device. So my 4 button scene switch can have 12 payloads. And I need to know them and not to make a mistake.
I'm used to (and so is majority of HA users) to chose a device, get a state from the drop down and set target action. Voila!

If this is to be for masses, not for programmers or geeks, in the current state of HA, mqtt payloads / topics are black magic for majority of HA users.
I've just set up HA for my grown up niece who's quite tech girl. She can do simple automations herself. She's not able to check topics / payloads. And she doesn't want to know or simply, she doesn't need to know.

[SHxKM]

In the meantime, I am not sure the Z2M documentation should continue to state that "MQTT device trigger" is the "recommended" method for HA. This will continue to mislead people into implementing device triggers which are another HA flawed implementation.

Out of curiosity, why is the MQTT device trigger a flawed implementation? In my opinion it is really simple and it works very well, I use it for years already without issues. Example: #25677 (comment)

To add to what others have said: it creates coupling to physical devices. For my kitchen light the entity will always be light.kitchen_light, but devices will be replaced eventually.

[KennethLavrsen]

@Mikescotland you mix up trigger by MQTT messages and device trigger which are presented in the GUI of the automations editor.

@Koenkk As SHxKM says. The flaw in the HA device trigger implementation is that the device is stored under its long hexadecimal device code in automations and scripts. When a bulb or switch breaks or just gets replaced and removed from HA you are left with broken automations and scripts and the detective work can begin finding them all. If your automation has a lot of yaml and jinja the GUI gives up and you can most only edit yaml. And there you have these horrible device IDs that our human brains cannot relate to.
When you use triggers that are related to an entity then the names are human. And better. If I give my new device the same Friendly Name like "Kitchen Window Sensor" then all my automations and scripts and dashboards etc will work without having to do anything.
That is why both the old sensors and the new events are so "sexy". We just need the HA guys to fix the event retrigger with same value problem to make them perfect

[Mikescotland]

@Mikescotland you mix up trigger by MQTT messages and device trigger which are presented in the GUI of the automations editor.

@Koenkk As SHxKM says. The flaw in the HA device trigger implementation is that the device is stored under its long hexadecimal device code in automations and scripts. When a bulb or switch breaks or just gets replaced and removed from HA you are left with broken automations and scripts and the detective work can begin finding them all. If your automation has a lot of yaml and jinja the GUI gives up and you can most only edit yaml. And there you have these horrible device IDs that our human brains cannot relate to. When you use triggers that are related to an entity then the names are human. And better. If I give my new device the same Friendly Name like "Kitchen Window Sensor" then all my automations and scripts and dashboards etc will work without having to do anything. That is why both the old sensors and the new events are so "sexy". We just need the HA guys to fix the event retrigger with same value problem to make them perfect

Omg.. Switched off the legacy. Seems I have been using even without realising it was mqqt trigger, I'm sorry for the confusion!
One of my switches didn't work as it was set up by a blueprint, so I created "ordinary" automation.