OK, so I’ve finished with automations and all are shifted from devices to entities for triggers - let’s see how it holds up after few months 
But… running for 4 years, never had issues either 
1 Like
OK, maybe somebody can explain to me, why hass seem to have an amnesia and forget the actions ? when I navigate to the device and try to add automation, the list of available triggers has no actions i it:
I may add that this button was in hass for maybe 2 years ? it’s not like it was never pressed or something. It always works, but after update hass has a problem with it since it’s a button and actions from it have a STD
Apparently the device only has controls no sensors or attributes…
Hard to say thought without seeing the device…
If you look at services, they don’t have much available either:
Weird starting point though, i always start with ‘create new automation’ from automation view…
It’s a philips hue button. it does have some actions like press, hold, release etc …
Here are exactly the same two buttons:
Note that printer button magically forgot the “hold” action
EVEN thou the action does show up in the logbook. For some reason actions are disconnecting from the device.
I know it’s weird starting point hence I don’t use - BUT I’ve managed to find a commonality that if actions don’t show up in this menu → they don’t show up in automation “device” “trigger” dropdown → they stop working as a trigger.
i would look into my devices….
What integrations does hue use anyway ?
zha, zigbee2mqtt, hue bridge?
Z2M
I might add that ALL zigbee devices are connected via Z2M - there are roughly 160. there are couple of networked devices like pfsense senor etc but those are dime a dozen
And if you looks at the device, does it have all controls, sensors, diagnostics??
Or only missing at the +automation screen ?
example of test equipment button:
Everything seems to be in order / same as other buttons.
Please note that side notebook DOES understand that there are actions being triggered for it, yet when I navigate to navigations, hass is unaware or any existence of actions.
Beats me man…don’t have a clue what the issue is 
I’m running Zigbee2MQTT too, at first on a different machine, now ass add-on to HAOS.
And I use a ConbeeII coordinator…
always rocksteady with or without automation for the last 4 years…
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.