You still use the old sensor. Change to event entity
1 Like
Very silly of me, thanks for the quick reply
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!
All good. No need to wait, simply check the changelog and perhaps wait a day or so. Most big issues are then known.
do you have:
homeassistant:
enabled: true
experimental_event_entities: true
in your Z2M configuration? …you need experimental_event_entities ‘on’.
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).
3 Likes
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!
5 Likes
Enabling legacy (and restarting Z2M) is all you should need to do to retain v1,x functionality.
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…
10 Likes
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!
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
1 Like
@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
1 Like
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.
2 Likes
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.
3 Likes
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?
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?
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.
The new event entities are only created for what you would consider stateless information. Pressing a button on a switch that bounces back is the classic example. Pressing a button that have “on” printed on it it does not leave the remote control in an on state. It just send a momentary message that is called “on”. You can press it multiple times and use it to toggle something on and off or you can increase the sound. Anything. These are events of transmitting the press, or the release, or the long hold etc of a button. This is what events are for.
Illumination is a sensor and it has a state which is a value with a unit lux. They are still good old sensors in Zigbee2MQTT. However 2.0 has a breaking change where the illuminance sensors were renamed so all your old sensors are gone and replaced by new. And to make matters worse they are by default disabled. You have to enable them first in Home Assistance. This takes 30 seconds from you enable them till they show up and another minute or two before the sensor sends a new value so be patient.
3 Likes
You can also stay on v2
- Enable experimental to keep the
event - Enable legacy to keep the
actionper v1
1 Like
I’v converted a automation for my ikea E1743 and E1744 from legacy to event based triggers. All works except the toggle trigger in the E1744. You can switch it off but can not switch it on, because then the event-state does not change (toggle → toggle). You can get it working bij dimming down and then press toggle. So i’m looking for a way to change or clear the state after a toggle. Does anybody has a sollution?
p.s.
Problem Solved
The problem was solved by @mekaneck on discord. I had to remove
attribute: event_type
in the trigger. All working now!
id: "1736018140368"
alias: kitchentable remote events
description: ""
variables:
command: "{{ trigger.to_state.attributes.event_type }}"
triggers:
- trigger: state
entity_id: event.kitchentable_remote_action
attribute: event_type
conditions:
- condition: template
value_template: "{{ command != ''}}"
actions:
- choose:
- conditions:
- "{{ command == 'on' }}"
sequence:
- data:
transition: 1
target:
entity_id: light.kitchentable
action: light.turn_on
- conditions:
- "{{ command == 'off' }}"
sequence:
- data:
transition: 1
target:
entity_id: light.kitchentable
action: light.turn_off
- conditions:
- "{{ command == 'toggle' }}"
sequence:
- data:
transition: 1
target:
entity_id: light.kitchentable
action: light.toggle
- conditions:
- "{{ command == 'brightness_move_up' }}"
sequence:
- repeat:
count: "20"
sequence:
- data:
transition: 0.5
brightness_step_pct: 5
target:
entity_id: light.kitchentable
action: light.turn_on
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
- conditions:
- "{{ command == 'brightness_move_down' }}"
sequence:
- repeat:
count: "20"
sequence:
- data:
transition: 0.5
brightness_step_pct: -5
target:
entity_id: light.kitchentable
action: light.turn_on
- delay:
hours: 0
minutes: 0
seconds: 0
milliseconds: 500
mode: restart
max_exceeded: silent
1 Like