Make automation creation easier - Our plan as Home Assistant maintainers

[matthiasdebaat]

In the upcoming releases, we aim to make automation creation easier with @jenova70. Please let us know your thoughts on our proposed solution to the issues we want to address.

Issues

Home Assistant’s automation engine is one of the most powerful on the market, but this comes at a cost: It’s not the easiest to approach.

1. Triggers and conditions are hard to choose and configure

Entity and Numeric state triggers are powerful and flexible but can be challenging to understand, especially for those who are new to Home Assistant. Device triggers are easier to use, but these don’t let us fully use the power of the automation editor.

When we want to search on a common trigger, like motion or temperature, we won’t get any results. As these are part of the State or Numerical state trigger.

2. Common triggers and conditions are complex to achieve

In order to perform seemingly easy tasks, we must understand how data flows into the internal state machine and how it is represented. For example:

• “When the target temperature of my thermostat goes above 22 degrees”. Requires knowledge that this is an attribute, not a state.
• “When my front door opens”. We need to understand that it’s a binary_sensor, lock or cover.

3. Difficult to trigger something on a scope that is bigger than an entity

Automation is tightly coupled with the state machine. If something isn’t in the state machine, it’s difficult (or impossible) to automate. Currently, the only workaround is creating helpers to persist such data. For example:

• “When at least one light in the living room turns on”. We have to create a group helper.
• “When any of my switches labeled always_on turns off”. Labels are not available as trigger target. We can walk around that by creating some pretty advanced templates.
• “When presence is detected on the second floor”. Areas are not available as trigger target.

Our solution

We plan to unwrap the triggers and conditions, allowing integrations to provide them. This is similar to what we did for actions. Integrations will define available triggers, conditions, and actions, which Home Assistant will then display in the automation editor. This will result in:

1. Generic triggers and conditions such as light, climate and fan. And specific such as Sonos or LG Web OS.
2. The ability to target areas, devices, and labels. Not just entities.
3. A more intuitive “Add Trigger/Condition” dialog that only shows relevant options and supports search.

With these improvements, we will be able to create automations like:

• “When there is motion in the living room area, turn on all living room lights”
• “When a leak is detected, and if no-one is home, send a notification”
• “When lights labeled xmas turn on, start the Christmas playlist in living room”

Of course, we will still be able to use the State and Numerical state triggers for more complex use cases.

First results from user test are great. We feel like we are heading in the right direction, but want to continue getting feedback from the community. How do you feel about these improvements? Is there anything we may have missed here? We’re open for feedback!

Edit
Small clarification what we mean by allowing integrations to provide triggers and conditions, like it does with actions:

@jenova70

Basically, the triggers & conditions will be provided by light, climate, cover, etc.

Maybe, MAYBE, in some very rare case, sonos could also provide a vary specific crazy one like “When a timer ends” (I know Sonos has timers on their speaker, and they already have actions associated to it)

But the meat of the triggers will be what is today called “Entity components” … domain basically

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

How about not have the state actions buried a couple of clicks down from the main screen. After people learn automations in the UI, the next step is they want to do something that is not available in the UI,and often the device_id they are using in the existing action (because they didn’t know the state actions existed) cannot do the thing that want, and we spam this message to them so that they can get where they want to be.

Why and how to avoid device_ids in automations and scripts

This topic is part of the community-driven cookbook where you can find other topics you might be interested in or might like to contribute to. 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. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. Devi…

[Didgeridrew]

@matthiasdebaat

… unwrap the triggers and conditions

@matthiasdebaat

available triggers, conditions, and actions

@matthiasdebaat

Generic triggers and conditions

@matthiasdebaat

intuitive “Add Trigger/Condition"

Does this mean we can switch back to titles in the editors that make sense, are used everywhere in the docs, and are simple instead of the “When”, “And If”, “Then” nonsense?

[francisp (Francis)]

As long as existing automations using triggers continue to function. Some integrations haven’t been updated in a very long time.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

I see the need for the nonsense words, but make sure the old names are also clearly there in the header, maybe in parenthesis…

[daywalker03 (Matthew)]

That “nonsense” is more understandable to new folks than the older way was. Plus, it describes the flow of events fairly well.

[Edwin_D]

I think this is a good direction. However, I’m not quite clear on what you mean by integrations providing the triggers and conditions. The ZHA and ZWave integrations have tons of different devices, different kinds of devices too. Those can define lots of triggers and conditions.

People think in terms of devices. That is fine for “simple” devices. But if I take the MySkoda integration as an example: My car device has 7 things that can be considerd doors, 5 windows, lights, an odometer, a battery state, a climate entity, a driving range, dozens of sliders and toggles, sensors, … So triggers, conditions or actions per device is also a challenge to say the least.

So I do hope it is entity based to keep the list of possible things you can do with it acceptable. But even then, what would a wled light have in the list of conditions? And how much consistency will there be amond devices if all integrations define in their own words what can trigger an action?

But that does not sit well with doing something with a label or an area. The list of things you can do will get huge. Even if all media players can do the same, why would a Sonos be different? Believe me, integrations will think they are more equal than others.

So in order for this to work, there need to be strict rules on what integrations should offer and how, if it is to stay usable for people with many devices. I also hope those triggers, conditions and actions will remain working when I switch a ZHA light for a ZWave one. Because if ZHA names things differently…

[Didgeridrew]

@daywalker03

That “nonsense” is more understandable to new folks than the older way was

I don’t think that is the case…

In order for the current version to be as understandable as it is, it apparently requires an explanatory sentence and a link to the documentation. That same explanatory sentence and link could be matched with a heading “Triggers”, which

1. Would match the current YAML key.
2. Makes syntactic sense with the “Add Trigger” button.
3. Matches, or nearly matches, the majority of available examples past and present.

[CaptTom (Tom)]

Sounds like a good direction.

That said, I’d like to reiterate what @francisp mentioned, above: Don’t break existing functionality.

I’ll go one step further and say don’t forget about the folks who use YAML instead of the UI.

I often use the UI to make the first iteration of an automation, but after that I tend to work in YAML only. I move the new automation from the automations.yaml file to my own included file, where I can add meaningful IDs, comments and names, and format it in a way which makes sense to me. I can also copy and paste from my own existing automations or from those others have posted.

Please don’t make that any harder when making the UI easier! Thank you!

[petro]

@matthiasdebaat

The ability to target areas, devices, and labels. Not just entities.

Please add the ability to trigger off entities inside a group. Many people build complex template entities to overcome this. They want to have a single group they maintain and trigger off entities inside the group, not the groups state.

This has been an 8+ year sore point in HA.

[matthiasdebaat]

@Sir_Goodenough

After people learn automations in the UI, the next step is they want to do something that is not available in the UI,and often the device_id they are using in the existing action (because they didn’t know the state actions existed) cannot do the thing that want

I agree this is annoying, we have this issue on our radar. With this solution, we hope to lay a foundation to fix this as a second step. More on that later.

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Just pulling that

add actions - other actions - perform action -

thing up to the same level as a device_id action would help a lot. (in the mean time). Especially with some of those on the bottom of the list in the menu…

IE Entity next after Device …

[matthiasdebaat]

@francisp

As long as existing automations using triggers continue to function.

With this solution we would add functionality without removing support of created automations. Same as we did with the action “call_service”.

[Didgeridrew]

@matthiasdebaat

First results from user test are great… How do you feel about these improvements?

Is the test version publicly accessible? If so, then a link should be provided. If that’s not feasible, it would probably help a number of people if there were, at minimum, some sort of video walk-through of the test version… so we can share opinions based on something other than a kind-of-vague, written description.

[matthiasdebaat]

Thanks for pointing this out. Triggers and conditions would basically get the same pattern as actions. Where we group them per integration. There are no ZHA and Z-Wave actions, but there are light actions. We’re going to use the same strict rules as for actions. Making sure that there are no slightly different trigger and conditions.

Right now you can’t select your car, but can select the climate of your car. Our idea is also that you get the same “target selector”. This means you can keep selecting entities, but also group of entities based on device, area or labels. You can only select relevant targets based on the trigger or condition. For example, if you select a motion trigger, but you don’t have a motion sensor in your Kitchen area, that area wouldn’t be listed.

[matthiasdebaat]

@Didgeridrew

In order for the current version to be as understandable as it is, it apparently requires an explanatory sentence and a link to the documentation.

The description is added to make it easier for new users to start with Home Assistant. I agree we could drop the description if you’ve created a couple of automations. We didn’t make time to implement this.

[matthiasdebaat]

@CaptTom

I’ll go one step further and say don’t forget about the folks who use YAML instead of the UI.
…
Please don’t make that any harder when making the UI easier! Thank you!

Our solution is not UI only, and includes YAML.

[matthiasdebaat]

Like your action example, this would be the same for triggers and conditions. I have the wish to improve these dialogs, but that would be another step after improving the listed issues.

[matthiasdebaat]

If I understand correctly. If someone created, for example, a light group of 4 lights. This solution lets you pick the light group, or one of these lights.

Bonus to this, you can select an area and you don’t need a helper group anymore.

[frenck (Franck Nijhof)]

Or label… That would work too…