when I was starting with hass, I was thinking about some exotic ways to set it up to make it small footprint etc, and then I had a quiet word with my self: “Men, just follow the default advised setup and all the equipment that they advise to not change it into a admin chore” - and I did … I followed every single guide to the letter, even the advised coordinator for z2m … works pretty well, but those trigger actions are a colossal miss.
This might help. It describes the three ways Zigbee2MQTT reports button clicks.
FWIW, I use the method that listens for state-changes to sensor.yourdevicename_action.
Yeah, that’s pretty much what lads before have suggested. It’s a shame that hass tries to box people into the “hey use our thing that will give you a headache in the future” approach. So far I’ve survived one upgrade with none of before mentioned issues.
So, I’m happy to report that suggested fix had solved my problem … with automation. Still when I upgrade hass, I now get all the lights not show up in the gui, since MQTT daemon is somehow messed up 
Requiring a VM reboot.
Thanks to peeps that helped !
1 Like
just if somebody is reading that in the future and / or is bothered about hass not doing updates properly on large installations, below is how an entity looks like after upgrade:
It’s right after performing an upgrade and waiting 3 minutes just in case. Reloading MQTT integration doesn’t help - just a full VM reboot restores stuff to rightfully state.
Soooo , don’t know whenever I should create a new topic for that, however I’ll drop this here as well. So I’ve managed to get a “after upgrade lockup of the HASS”, luckily reloading the mosquito seems to fix the problem.
Sequence of events:
Life goes as normal:
2024-05-17 18:27:18: New connection from 172.30.32.2:34946 on port 1883.
2024-05-17 18:27:18: Client <unknown> closed its connection.
2024-05-17 18:29:18: New connection from 172.30.32.2:42888 on port 1883.
2024-05-17 18:29:18: Client <unknown> closed its connection.
2024-05-17 18:31:18: New connection from 172.30.32.2:40758 on port 1883.
2024-05-17 18:31:18: Client <unknown> closed its connection.
2024-05-17 18:33:18: New connection from 172.30.32.2:34960 on port 1883.
2024-05-17 18:33:18: Client <unknown> closed its connection.
2024-05-17 18:35:18: New connection from 172.30.32.2:47782 on port 1883.
2024-05-17 18:35:18: Client <unknown> closed its connection.
2024-05-17 18:37:18: New connection from 172.30.32.2:41016 on port 1883.
2024-05-17 18:37:18: Client <unknown> closed its connection.
2024-05-17 18:39:18: New connection from 172.30.32.2:34172 on port 1883.
2024-05-17 18:39:18: Client <unknown> closed its connection.
2024-05-17 18:41:18: New connection from 172.30.32.2:57810 on port 1883.
2024-05-17 18:41:18: Client <unknown> closed its connection.
2024-05-17 18:43:18: New connection from 172.30.32.2:43650 on port 1883.
2024-05-17 18:43:18: Client <unknown> closed its connection.
Performing an upgrade about here:
2024-05-17 18:45:14: Client 0P4JAKn3X0TuxGouQh3L1T closed its connection.
2024-05-17 18:45:18: New connection from 172.30.32.2:56482 on port 1883.
2024-05-17 18:45:18: Client <unknown> closed its connection.
After an upgrade this show up:
2024-05-17 18:45:23: New connection from 172.30.32.1:37163 on port 1883.
2024-05-17 18:45:23: New client connected from 172.30.32.1:37163 as 776MRYuMXaPB1JDQMYJF7t (p2, c1, k60, u'homeassistant').
2024-05-17 18:45:23: Outgoing messages are being dropped for client 776MRYuMXaPB1JDQMYJF7t.
At this point nothing related to Z2M inside of HASS is “unknown”, while Z2M works perfectly fine. So I decided to perform a Mosquito plugin reload:
2024-05-17 18:47:10: New connection from 172.30.32.1:43891 on port 1883.
2024-05-17 18:47:10: New client connected from 172.30.32.1:43891 as 3TfHo1uZGSUZ9PiORppUmj (p2, c1, k60, u'homeassistant').
2024-05-17 18:47:18: New connection from 172.30.32.2:48274 on port 1883.
2024-05-17 18:47:18: Client <unknown> closed its connection.
2024-05-17 18:48:41: Client 776MRYuMXaPB1JDQMYJF7t has exceeded timeout, disconnecting.
2024-05-17 18:49:18: New connection from 172.30.32.2:37234 on port 1883.
2024-05-17 18:49:18: Client <unknown> closed its connection.
Here I though “Hey, maybe I should try whenever on simple inside of HASS reboot I’ll be able to replicate this” - so I did the reboot.
2024-05-17 18:50:32: Client 3TfHo1uZGSUZ9PiORppUmj closed its connection.
2024-05-17 18:50:38: New connection from 172.30.32.1:60363 on port 1883.
2024-05-17 18:50:38: New client connected from 172.30.32.1:60363 as 3cfGlRCCZMfwrgaiRW90LL (p2, c1, k60, u'homeassistant').
2024-05-17 18:51:18: New connection from 172.30.32.2:54866 on port 1883.
2024-05-17 18:51:18: Client <unknown> closed its connection.
2024-05-17 18:53:18: New connection from 172.30.32.2:51798 on port 1883.
2024-05-17 18:53:18: Client <unknown> closed its connection.
And everything works just perfectly fine … so a reboot =!= upgrade in terms of results.
Not that it solves anything, but it is one example on why to avoid using device ID’s instead of entities…
1 Like
I can confirm what @aceindy is saying, don’t use device ID’s but use entity ID’s. Requires a bit more hoop jumping but instead it’s rock solid.
It’s a shame that hass is pushing device ID’s on people when it’s not a finished product.