That’s a good summary. The only thing I’d add is to make sure you have the new adapter: option set under serial: before updating or you may have issues connecting to your adapter.
2 Likes
Same here with Ikea switches. Works again after set the flag in Z2M
Thanks! Worked for me.
I’m in the same situation as you in that the action states are deeply ingrained throughout my config and custom sensors. When I updated to 2.0.0-1 a ton of things broke and after a few hours debugging I restored to a backup of 1.40.2-1 at least get the house working again until I can figure out what to do.
I’m stuck trying to get the experimental event entities to show up in 1.40.2-1 so that I can start updating my automations, scripts and custom sensors. These event entities were neither there when I updated to 2.0.0-1 nor now since I’ve restored the add-on to a backup of 1.40.2-1 and added experimental_event_entities: true into my config. Maybe I have added this setting in the wrong place, or perhaps it is just not available in 1.40.2-1? Little trick I did’t know was that I needed homeassistant: true under socat in order for that part of the config to not just disappear on restart.
If you’re using the home assistant addon then you can change that setting in the Z2M GUI - go to Settings → Home Assistant Integration and enable Event Entities from there. After a restart of Z2M the new setting should then appear in the YAML. On my setup it seems like it might have taken 10 minutes or more for these “event.xyz” entities to appear in my list of entities in Home Assistant.
FYI I’ve been down a rabbit hole since my last post; my initial solution of swapping out sensor.xyz for event.xyz in my automations did not entirely work because this method would not detect repeat events from the same button. ie everything works fine if you have a 4-button remote and you press ON, then BRIGHTNESS UP, then BRIGHTNESS DOWN etc. But if you try to press BRIGHTNESS DOWN x 5 times then it only recognises the first press. This was the case with battery-powered Xiaomi wall switches, Xiaomi square buttons, and Xiaomi magic cubes. However the issue doesn’t seem to occur with Hue remotes or Xiaomi round buttons. Very odd.
So to solve this I refactored some automations using the Event trigger steps outlined here: Event - Home Assistant - using the event as a trigger and using conditions to detect the button / single / hold / shake etc. in this case it correctly performs an action on every button press, even repeated presses of the same button.
However over the course of this afternoon I found that ghost events were toggling lights and scenes and causing general hassle… no idea how, but ghost events like this never happened before with the old triggers. So I’ve removed those new event triggers and “gone native” with MQTT triggers such as below:
trigger:
- trigger: mqtt
topic: "zigbee2mqtt/Kitchen Xiaomi Cube White/action"
payload: "tap"
I won’t be updating to the 2.0 version for a few days until I’m sure everything is stable. I don’t think I’ve ever had to put so much research and work into a pre-migration.
2 Likes
I have this problem with several devices. I upgraded Z2M to 2.0.0 but am still on HA2024.12.5, so it is the Z2M upgrade that caused the problem. The MQTT action messages are there but the associated entities in HA are either missing or show no action.
Did you remember this: Zigbee2MQTT 2.0.0 breaking changes · Koenkk/zigbee2mqtt · Discussion #24198 · GitHub
Took me a while to get to this point on the page (Home Assistant):
- By default, Zigbee2MQTT does not listen to the
hass/statusHome Assistant status topic anymore,homeassistant/statusis used instead (ifhomeassistant.status_topicis not set in your Z2Mconfiguration.yaml). Double check that Home Assistant is using this status topic by going to: HA → Settings → Devices & services → MQTT → Configure → Re-configure MQTT → Next; the Birth message topic should behomeassistant/status.
2 Likes
I have corrected the problem by activating in the Zigbee2MQTT settings : Home Assistant experimental event entities.
A new entity has appeared in the MQTT device of type Event
Example:
event.0x00158d0001050e0f_action
The state of the event is the timestamp. Each time an action is performed, the date changes.
There are 2 interesting attributes:
- event_types → with the list of all actions.
- event_type → represents the action performed
Example on my Xiaomi Cube
event_types: shake, throw, wakeup, fall, tap, slide, flip180, flip90, rotate_left, rotate_right
event_type: flip90
Next, create a single automation rule. It must be triggered by each change in status (timestamp). You then need to create a ‘Choose’ action with the action (event-type) as a condition.
Example :
triggers:
- entity_id:
- event.0x00158d0001050e0f_action
trigger: state
conditions: []
actions:
- choose:
- conditions:
- condition: state
entity_id: event.0x00158d0001050e0f_action
attribute: event_type
state: flip90
sequence:
YOUR ACTION
- condition: state
entity_id: event.0x00158d0001050e0f_action
attribute: event_type
state: flip180
sequence:
YOUR ACTION
The big advantage of this operating mode is that the state of the entities is retained. It is simpler to consolidate all the actions in a single automation rule.
Michael, thanks, I would never have found that. I thought I had worked through the recommended changes for 2.0.0, but I missed that one. Gradually seem to be getting back to normal now with this help and others here.
1 Like
The problem with the action triggers is that the dropdowns under From and To don’t populate with the actions that the device sends. This is unlike using a device trigger under Zigbee2MQTT 1.14.
I really don’t want to have to maintain lists of supported actions for each device and then type them in each time, like an animal — and nor do I want to edit YAML directly :(
Are you sure you have the correct attribute selected? It should be event_type. The values do populate in the UI.
why are you all using the legacy or experimental options and not the recommended MQTT device trigger?
Advantages of experimental entities event :
- No need to go through the MQTT discovery phase to select the action
- All available actions are listed in the
event_typesattribute. - All actions can be consolidated in a single automation rule
Disadvantages of MQTT triggers:
- Can’t be used in a condition (e.g.
holdaction with condition repeat until actionrelease) - Device identifiers are not as reliable as entity identifiers. If you need to replace or re-associate a device for any reason, you have to correct every automation.
I’ve been experiencing unwanted triggers after restarting the Zigbee2MQTT service. I backtracked with MQTT triggers as recommended
Thank you!
I lost actions since the update. I made this, check “Home Assistant legacy action sensors”, but my automations doesn’t work.
Zigbee2MQTT and Home Assistant restarted two times.
The action shows and is functional on the device page, but none of the automation are firing when action changes…
Here we can see at right that the action changes:
My automations are well configured:
But:
…
Someone has a solution ?
Can you expand your trigger? It looks like your are looking for an attribute instead of the state.