I want to initiate a discussion on this subject. Recently looking various subjects I fell on not one posts by @tom_l (and not only him) stating that it is much better to use entities from devices, ex: Automation actions, calling service vs triggering a device. Which is better?, which I found that suggestion has some logic. In the same time Zigbee2mqtt states that the recommended way is device triggers based on Home Assistant documentation (MQTT Device Trigger - Home Assistant). So I’m wondering… what in the end is the correct way?
They are both "correct’ in that they will work as intended and device automations appear simpler to new users, however using only entity ids has some major advantages, particularly in the long term. See:
I understand (I actually agree with the entities) but I just feel little confused. Koenkk recommends the usage of device triggers not because he wake up one day and say I don’t like entities, they are legacy but because the official documentation state this as recommended way for MQTT. And for sure Z2M is a big integration (perhaps a competitor to ZHA ). Perhaps it will be nice if the team officially provide some guidance with some blog post or even in documentation on what is recommend in general (not just on MQTT). The post is good but still in the end for the buttons (a usual case for the MQTT cases) is still recommends the entity which goes in contradiction with the official documentation.
btw: sorry for the tagging, it was mostly to open a broader discussion not only with you.
There is no official recommended way. Device triggers, actions, and conditions are extremely limited. The community recommends against them for many reasons described in the post Tom linked.
Device triggers are evil IMO. Easy to start, hard to live with. The need for device_id and the fact automations break when a device is replaced are the big disadvantages for me. System behavior when a device goes away absolutely sucks (see above).
Other than the simplified automation GUI, I can’t think of any advantages to device triggers, only negatives.
Link?
I have to wonder if it was an example of convenience.
None of that really speaks to how to use the device/entity in automations. It’s more about how to define an mqtt device.
For automations, outside of the simplified GUI, I can’t think of any advantage to using device triggers in automations, for buttons, binary sensors or anything else exposed by zigbee2mqtt.
I don’t think that it needs explicit mention automations. The phrase '“An MQTT device trigger is a better option than a binary sensor for buttons, remote controls etc.” is clear without need explicit mention about automations or dashboards or something else or GUI or not. I agree in all cases Device trigger has the same disadvantage so what the reason behind.
That’s specifically talking about event based z2m stuff, which historically people made momentary binary sensors. That’s a niche scenario and has nothing to do with best practices with mqtt, z2m, or HA.
I don’t but also I don’t want to have something marked as legacy (from the Z2M side). Legacy means something old, potentially unsupported and in one point be in our beloved memory
I don’t think “action” or its equivalent will ever go away, too many people use it. I can’t see Koenkk removing tried and true code for theoretical elegance. The most I can ever see happening is changing the z2m default for legacy triggers, and maybe not allowing it for new devices.
Device triggers would be my absolute last choice in HA. Mqtt triggers would be the middle ground. You still lose convenience and abstraction at the HA layer, but at least it’s possible to replace devices.
I can see why from the z2m perspective device trggers seem more elegant, z2m doesn’t have to do the “action” housekeeping. From HA’s persepctive, device triggers are evil IMO, and that is trying to be polite.
I have just read this thread after struggling with the z2m docs on “responding to a button click” with the three options. Am I correct in understanding it as follows;
mqtt device triggers = not good due device-id gibberage
HA entity = ok, not going to be phased out any time soon
mqtt topic = ok, ?
I’m now experimenting with the mqtt-topic which allows me to use the whole trigger event data in a variable. Isn’t that an advantage over the second method? I also think it therefore allows for much shorter code when using for instance a HUE tap-dial button.
Can someone comfirm or deny this?
It’s all personal preference, the only bullet that has a drawback is device triggers. If you replace the device, your automation will be disabled and non-functional until you fix it. Secondly the functionality of the new device may not match the old device, so you’ll likely have to replace the entire trigger instead of making a small update. Thirdly, if the device is not discovered for some reason, your automation will fail and be disabled.
HA entity or MQTT Topic are hands down better than a device trigger. However they are both harder to add to an automation because they do not “guide you” along the way like a device trigger does.
I can’t think of anything in the mqtt event for z2m that isn’t exposed as an attribute in the entity state trigger.to_state. With the state trigger you also get trigger.from_state, which I’ve found useful.
Thanks Petro and Jerrm for the clarifications and some more insight. Indeed the trigger/from_state is available so not much difference there.
I will try both solutions (HA entity and Mqtt-topic) and see what is the easiest for me.
to ZHA ). Perhaps it will be nice if the team officially provide some guidance with some blog post or even in documentation on what is recommend in general (not just on MQTT). The post is good but still in the end for the buttons (a usual case for the MQTT cases) is still recommends the entity which goes in contradiction with the official documentation.