Template trigger or Device Trigger? What is the better method

[Spartacus]

Hi all,

I’m currently thinking about which method is better for reacting to button presses in automations. Recently, my Shelly input entities are created as type event. With MQTT I can only use a device trigger. Alternatively, I can a template trigger. Device triggers have the disadvantage that you can’t identify the device anymore based on the ID. So what’s the better method for Homassistant here?

Version 1:

alias: UI_StudioLicht
description: ""
triggers:
  - domain: mqtt
    device_id: 3d6967049023b9e49fdab6cead078c41
    type: button_short_press
    subtype: button_1
    trigger: device
conditions: []
actions:
  - action: light.toggle
    metadata: {}
    target:
      entity_id: light.dg_st_l03
    data: {}
mode: single

Version 2:

alias: UI_Studio_Licht2
description: ""
triggers:
  - trigger: template
    value_template: |
      {{ state_attr('event.dg_st_i02_b01', 'event_type') == 'single_push' }}
actions:
  - action: light.toggle
    target:
      entity_id: light.dg_st_l03
    data: {}
mode: single

[Didgeridrew]

@Spartacus

With MQTT I can only use a device trigger.

There is a MQTT trigger and an Event trigger.

However, the best option is likely triggering off the state of the event entity, then using a condition to check that it has the desired type.

alias: UI_Studio_Licht2
description: ""
triggers:
  - trigger: state
    entity_id: event.dg_st_i02_b01
    to: ~
conditions:
  - condition: template
    value_template: "{{ trigger.to_state.attributes.event_type == 'single_push'}}"
actions:
  - action: light.toggle
    target:
      entity_id: light.dg_st_l03
    data: {}
mode: single

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Device trigger is ALMOST never the answer.
Besides the preferred MQTT triger mentioned, there is Automation Trigger - Home Assistant.

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [Screenshot from 2025-11-20 18-37-55] It works… but it is not a the best way to start because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. This topic is part of the community-driven cookbook where you can find other topics you might be interested in or might like to …

[123 (Taras)]

You also have this option:

alias: UI_Studio_Licht2
description: ""
triggers:
  - trigger: state
    entity_id: event.dg_st_i02_b01
    attribute: event_type
    to: single_push
actions:
  - action: light.toggle
    target:
      entity_id: light.dg_st_l03
    data: {}
mode: single

NOTE

Didgeridrew’s example employing a State Trigger is superior, especially if you need the ability to detect consecutive, identical button events (like two consecutive single-press events). The version I posted will detect the first single-press but not another one until it first detects some other button-event. EDIT It has the same drawback as the second example you posted employing a Template Trigger.

---

Which trigger type you choose (Device, Template, State, MQTT) depends on what you consider to be easier to maintain.

Device Triggers have the following drawback: if the device ever fails, when you replace it, the replacement will be registered with a new unique device_id value. As a consequence, the automation’s Device Trigger will no longer work because it still refers to the old device’s device_id.

When you replace the device, you are likely to maintain the same entity names. So automations using triggers that refer to an entity by its entity_id are more likely to continue to work without modification.

[dtrott (David Trott)]

@123

Which one you choose depends on what you consider to be easier to maintain.

If you have a large number of buttons (or many 4 gang switches) its easier to use MQTT “action” events - but the setup (code to process the events) for that is more significant, so it isn’t worth it for only one or two buttons.

triggers:
  - trigger: mqtt
    options:
      topic: zigbee2mqtt/Living Entry Scene/action
  - trigger: mqtt
    options:
      topic: zigbee2mqtt/Kitchen Entry Scene/action
...

[Spartacus]

Hi all,

many thanks for all your replies! I tried the event trigger without success , but I think I did an mistake. I will check again.

Thanks

[123 (Taras)]

@dtrott

the setup (code to process the events) for that is
more significant, so it isn’t worth it for only one or two buttons.

FWIW, I don’t find it “more significant” and employ it for all of my remotes (ranging from 2 to 4 buttons).

That’s why I suggested the OP choose what they feel is easier to maintain.

[dtrott (David Trott)]

@123

FWIW, I don’t find it “more significant” and employ it for all of my remotes (ranging from 2 to 4 buttons).

Are you even using MQTT “Action” events - i.e. directly listening to the action topic. I haven’t seen any reference to that in your previous posts in this thread.

[123 (Taras)]

@dtrott

Are you even using MQTT “Action” events

• If we are talking about the the kind of trigger used in Didgeridrew’s example, where a State Trigger is monitoring a remote’s event entity (ostensibly created via Zigbee2MQTT version 2.0+) then the answer is yes.

• If we are talking about an MQTT Trigger listening to the remote’s MQTT topic, like in your example, then no.

@dtrott

I haven’t seen any reference to that in your previous posts in this thread.

I didn’t explicitly indicate which trigger type I use until you quoted me and suggested MQTT “action” events require significant more “setup” therefore not worth it for one or two buttons. Had you not quoted my post, I wouldn’t have replied with my clarification.

My reply was the first indication (in this thread) that I use that type of trigger for all of my remotes, regardless of how many buttons they have. Originally, I used a State Trigger with a remote’s now-deprecated sensor entity. In my experience, it was a fairly simple transition to the event entity.

I need the ability to detect consecutive identical button events (like a double-press of on) and some of the triggers shown above are not fit for this purpose. Depending on the OP’s needs, it may influence which trigger they should consider using.

[dtrott (David Trott)]

Okay let me be clear
If you have hardware that manages the different types of button press for you - hence generates distinct MQTT events for:

• Single
• Double
• Hold

Then you have a choice of multiple methods for handling those events:

• You can use the device_id style trigger (OP Version 1)
• I haven’t used the OP’s “template” based approach, however it will assume it’s working for the OP.
• You can directly listen to the action topic (my approach)

I quoted your response:

@123

Which one you choose depends on what you consider to be easier to maintain.

Because I agree with it.

Simply put if, you only have one button in your house, don’t spend time trying to develop a generic approach.

However if you want to handle 72 (my case) events with a single automation then it’s worth putting in the time to figure out a clean way of handling that - and I would recommend listening to the action topics.

For me developing an approach to do that was “more significant”, I feel it was worth it - since ongoing maintenance is near zero, for example:

• Swapping out hardware doesn’t require any changes in HA - I just name the replacement device the same in Z2M.
• Duplicating a switch (adding a new switch that functions the same as an existing switch) is a few lines in HA

I realize that others may feel my design is overkill - which is what I was trying to acknowledge by quoting you.

[123 (Taras)]

Thanks for the clarification. I agree it would take effort and planning to develop a single automation to detect 72 events but the payoff is one clean centralized event handler. More work up front but easier maintenance afterwards.

---

FWIW, earlier I mentioned some types of triggers are not fit for the purpose of detecting consecutive identical button-events (like two on events). For anyone interested the types of trigger that can detect them are:

• Device
• MQTT
• State (listening to an event entity’s state)

The ones that cannot:

• Template
• State (listening to an event entity’s event_type attribute)