Device triggers in automations - why?

Configuration
1

More and more people posting in the forum seem to be using device triggers and conditions in their automations - is there any advantage to this? I can only find two examples in my own system - both for Hue buttons.

Device triggers seem so much more complicated than state/numeric state. Am I missing something?

2 Likes
2

It’s all about the UI editor. They’re less complicated from that view point…

  1. Device is selected by default, you don’t need to even click on the trigger/condition/action types drop-down.
  2. Most of the time the options are automatically populated based on the integration. You don’t have know beforehand, or to go to the States tool to figure out, that “Wet” is really “on”. You just chose “Wet” from the drop-down.
2 Likes
3

I see what you mean. Can’t help thinking it’s leading to problems, though - it’s always popping up in questions.

4

Devices are simpler, and require less understanding.

They’re also more limited, not supporting templates and generally being harder to troubleshoot.

5

6-in-one… Before the Device options were instituted there were posts daily from new users who needed help because their binary sensor trigger wasn’t working when it turned “Wet”.

6

IMO they are a crutch that creates cripples.

6 Likes
7

These are the problems I have seen:

  1. The user attempts to manually modify the Device Trigger/Condition/Action’s auto-generated YAML, typically by adding a template to one of its options. Templates are not supported by Device Trigger/Condition/Action.

  2. User replaces a failed device with a new one and the replacement device gets a new device_id value. All existing Device Triggers/Conditions/Actions referring to the previous device_id value are rendered inoperative.

The first problem is avoidable (don’t modify the auto-generated YAML) but the second one isn’t … unless you avoid using Device Triggers/Conditions/Actions entirely in favor of traditional triggers, conditions, and service calls that reference the entity via its entity_id.

1 Like
8

Also when they get more confident in creating automations some users attempt to use (unsupported) templates with them.

9

“State” would seem to lead to a better understanding of the way HA works. The options seem to be in alphabetical order at the moment, which is no use to anybody - could “state” not go at the top…?

10

I’ve chatted with one of the mods before about this annoyance. I really dislike this and don’t agree that they’re simpler if you understand the simple concept of an entity ID.

You need to pick way more things when setting up e.g. a device trigger compared to a state trigger.

A simple UI change to pick a more sensible default will go a long way.

Many tears will still be shed and my empathy on this front is low.

EDIT: I get the point on state values. That’s really a UX deficiency that has been reported several times. Making the UI for device triggers easier than state triggers were just baffling.

1 Like
11

Hang on… Is this still true?

If I don’t click on the drop-down, I get

trigger: []

And if I do use the drop-down list, “Calendar” is the first item. People must be deliberately selecting “Device”.

12

Looks like you’re right. I guess that goes to show how much I use the UI editor.

I don’t know that “deliberately” is the right word, more like subtly “pushed” by the UI design. As you mentioned earlier, the alphabetical ordering of the types means that State and Numeric state are not immediately visible. If a new user starts their first automation and is presented with:

image

They can likely rule out that they don’t want to use Calendar and Device is the next option. Once they get that first automation done with a Device trigger, they just keep using it.

2 Likes
13

Feature request here.

14

Exactly. Very well said.

15

Precisely. Here’s a great verbatim from someone I helped recently:

image
image738Ă—109 10.7 KB

1 Like
16

Um… vote for the feature request, then? :thinking:

1 Like