the new menu is 2 tabs, left being the “new style triggers” and the right being “old style triggers”.
The new style triggers are much easier to use, you just need to select where you want to start from.
When you click options in the left, it will show you available options to use as a trigger.
Right. I guess it’ll just take time to use. And it needs to be finished first. The problem for now is that plenty of options are just missing there, so in my tries I was repeatedly in a situation where I was not able to find the trigger I was looking for.
Right, because it’s not complete. There’s still around 200 triggers to go, and even more conditions.
Oh no! I must apologize, I wrote this and it wasn’t the point I was trying to make:
The point is simply the UI then creates the automation or script using device IDs.
And if we, one of the support communities, can do anything to influence the devs to not use them when not 100% needed when generating the automation.
(My post above was also asking if there were common cases where device IDs had to be used and if the devs were aware of the concerns in this thread.)
You all know this. Abstraction is good:
Using fake code here, this is fine:
trigger: light.turn_on
target:
area: Living Room
But this isn’t:
trigger: light.turn_on
target:
area_id: 8db213f403c1d561435b62ac5badb031
Likewise, for the reasons we all know, this seems pointless, and can lead to trouble for unwary new users:
trigger: device
type: turned_on
device_id: 8db213f403c1d561435b62ac5badb031
entity_id: a739f8198dc99f1cc6e868e1a0802861
domain: light
It is simply about not having the UI build the automation in a way we know can cause trouble later for users.
I don’t really care if there’s “Device” in the UI as long as it uses the existing abstractions to build the automation.
The new “Purpose build” UI layout is much better, too. Device? Entity? that are those? I just want to turn on the living room light, or the lights in the kitchen. (I know the look I would get if I asked my wife to please turn on that “device” over there…)
On a side note: I’d be very curious how often you all use the UI verses using YAML. Personally, I use the UI for very basic automations. I use YAML most of the time because my automations get too complex for the UI to show it in a concise way. I assume that happens to a lot of people. TBH, I wish I there was a setting to default to YAML.
Maybe not “have to”, but I found it very convenient for a hue dimmer switch, that only published button clicks as events.
Hard to say, but I made a WTH topic about this in the last WTH and it barely got any votes, so I don’t think this is in general a big concern among the community.
It may be too late now, but I think it would be better if devices were simply a collection of entities, and that selecting a device would simple use the entities under it.
the device itself should not ‘do’ anything, the entities should do the work, and the ui/yaml should reflect that.
its like files and folders. You can certainly perform actions and stuff on a folder, but generally it is the files that contain the actual data or actions (programs). Folders don’t store data or execute actions.
Yeah, I’m sure it doesn’t rank high among other issues.