This page is intended to rethink the current Automation Editor in Home Assistant. It's very much an early work in progress / brainstorming session at the moment. Going to gather feedback, refine these ideas, and then create mockups. This is a huge undertaking.

It would be extremely hard to fully satisfy both novice and advanced users at the same time, so it's important to pick a certain target audience to focus on (at least initially).

And it makes a lot more sense to focus on making things as simple as possible for novice users in my opinion. More experienced users already have a wide range of options to choose from like YAML, Node-RED, and AppDaemon among others. But for beginners there's a very steep learning curve and no good options.

Goal with this proposal is that anyone, regardless of skill level, will be able to open the automation editor and create automations without needing to look up documentation or ask for support. Everything should just feel 100% natural. It's about finding the right balance between accessible and capable.

With that said, despite the focus on simplicity, it will have some nice features for more advanced users too. Even for the more advanced users who prefer YAML, this could be used as a nice tool to quickly build the base of their automations and then get the raw YAML output and put the finishing touches on it in their text editor of choice.

I have gathered a lot of feedback, and also done actual testing with new users. Here are some of the most common issues:

1. It requires users to think in a way that just isn't natural. When somebody purchases a product that has "Motion Sensor" on the box, they expect that wording to be used when automating it. The logical way of thinking about the trigger would be "When motion detector detects motion" right? But the automation editor makes you think State > Binary Sensor > from off to on. Nobody is familiar with this term, it's not used in any other platform AFAIK. If you type "binary sensor" into BestBuy.com you'll get no results. Nobody thinks of their door being on/off, they think of it as opened/closed. And this is how automations should be built too. Device Class exists for this purpose and is used in the frontend, but not the Automation Editor for some reason.
2. The interface is overwhelming. The user sees triggers, conditions, actions all at once - there's a ton to process. It's intimidating. We have paragraphs of intro text on the left with three links to documentation where we send users down a rabbit hole of YAML examples despite this being a UI editor. We should remove a lot of this clutter and be smarter about things. Why are we showing a button to add a second trigger before the first one was even touched? Why are we showing the conditions & actions sections before the user has even added a trigger? Take it one step at a time.
3. The interface is very unclear. There's no descriptive text in the actual cards. Often you get a field to type things into, but it's never clear to the user what is expected from them. For example, if you create a "Time" trigger you might think of typing 4:45pm into the "At" field. Since there's no real-time validation you think it worked until you actually attempt to save the automation and then you'll receive some unclear error message at the very top of the screen: Message malformed: Invalid time specified: 4:45pm for dictionary value @ data['trigger'][0]['at']
4. Terrible error handling. There's no real-time error validation on anything. So the user could put in the wrong text input for 50 cards and only find out there's a problem when they go to save it. None of the error messages are user-friendly whatsoever. All of the error messages show up at the very TOP of your screen, so you won't even see them 99% of the time because you'll be scrolled further down.
5. Multiple ways of doing things. There's been some good attempts at solving some of these issues with Almond natural language and Device Automations, but to be honest, these haven't really been elegantly rolled into the automation editor, they feel a little tacked on. Every time you want to create an automation you get the Almond dialog first that must be skipped, every time you get in the editor you're defaulted to Device which often must be changed... These are good things but can be implemented better.
6. Much of the community doesn't use it. More advanced users have a number of reasons why they avoid the automation editor. In addition to some of the issues identified above, they also complain about more technical issues like their YAML code being rearranged, comments being stripped out on save, etc. But the problem here is if most of the prominent and active community members aren't using (and often despise and recommend against) the automation editor, newcomers have nobody to turn to for help. I'm not necessarily saying we should cater to advanced users. But if the reality is that advanced users aren't going to be using this, then we need to make it easy enough to where it doesn't require any hand-holding.

So this is an attempt at solving a lot of the issues I've found. Here's what this new Automation Editor would be like.

Simplicity is key

1. No code required. The user should never be asked to enter YAML, JSON, or Jinja templates - this is the job of the UI editor to solve. This is very different from saying no code allowed though. Code will still be supported through various ways like the overflow menu > edit as YAML and such. But it must be kept entirely optional like that, never a requirement.
2. No outside help required. You shouldn't be required to have the States panel open in another browser window to cross-reference entity ID's and available states and whatnot. The "Developer Tools" section in the sidebar should be exactly that, developer tools. To help make this work, integrations will make a list of all their possible states available to the automation editor, or we should leverage recorder to show recently used states (#4760).
3. No clutter allowed. Remove all of the introductory text and links to the docs, because a simple straightforward UI shouldn't need paragraphs of explanations.
4. (Almost) no text entry required. The most a user should ever have to type is a few characters before the auto-suggest kicks in. This makes for a much nicer mobile experience when the keyboard isn't covering half of your screen. And more importantly eliminating text entry eliminates any possibility of typos etc causing errors and misconfigurations. There's a lot of UI elements that can be used to reduce text input - checkboxes, toggles, radio buttons, sliders, etc.
5. No nerdy knowledge required. Simplify or de-emphasize technical jargon whenever possible. Avoid terms like geolocation and geofencing; describe things in less geeky terms like "when I arrive at this location." One of the reasons IFTTT became so successful is because literally everyone can understand the simple "if this, then that" terminology.
6. Optimize for users, not developers. We need to think about how users actually think, not how developers would think. It might be called certain things on the backend, but the frontend should always align with what the user expects.
7. No time required. We should aim for automations to take no longer than a minute to create, and strive for no more than ten taps.
8. No desktop required. Mobile first design, this is crucial. Mobile accounts for more usage than desktop and is constantly trending up.

• Thoughts

  • We must focus on showing the bare minimum only, remove any cruft or unnecessary text.
  • Not fully sure about this, but one thing to consider is not asking for a name or description until you actually hit save for the first time. Two reasons for this, it helps the user make their automation quicker, and another is that sometimes automations grow in scope as you're creating them, so the title you entered at the very start of the process might not match how it ultimately ended up.
  • Make it feel a bit smarter. Rather than a static "Add Trigger" button it could say "Add First Trigger" if there isn't one yet, and "Add Another Trigger" if one exists already. Minor tweaks like that make it feel both smarter and more user-friendly.
  • Move away from dropdowns which are often unpredictable and terrible. Sometimes they appear downwards, sometimes upwards, and they often expand behind UI elements like the bottom tab bars or top app header. That does not feel polished at all. Instead let's use more simple lists and radio buttons.
  • There will only be a single "Help" link placed in a consistent spot. It would relate to what's currently on-screen. Rather than a link to documentation, it would be better if it could be a highly polished video walkthrough.
  • More things can be shown if the user has Advanced Mode enabled.

• Design

  • More use of icons. Not just MDI, but implement brand icons and in the future, device icons too
  • All cards would have border radius, make the corners more rounded.
  • It would be structured a bit similar to the Lovelace card editors. The left side of the screen will be where the configuration part takes place and the right side will serve as more of a "preview" (high level overview).
  • Left side is where you pick which action / trigger / condition you want and set all the options. The configuration part basically.
    • There would be a search / filter box above the triggers and actions, you'd be able to type something in and it would filter the list of cards/buttons whatever that may be... So if you type "garage" or "blinds" it would show the Cover trigger/action for example. So each thing would have aliases kinda.
  • Right side of the screen will be a "Details" or "Summary" docked sidebar. Can be collapsed if wanted.
    • It would display more or less the same information shown today (automation name and optional description, triggers/conditions/actions, and save button) but in a significantly smaller/condensed format. Mini cards basically. It's intended as an outline / high-level summary.
    • Almond powered automations would be integrated into this sidebar, so it eliminates the dialog you must skip when creating a new automation. Pretty similar to the dialog but just better integrated imo.
    • You will not do any actual editing of things on the right, except for deleting or re-arranging the order of things. All of the triggers and conditions and actions will be shown using simple wording, just a text-based list. Clicking on it will update the view on the left where you perform the configuration. There will be an X icon to the right to delete.
    • There would be a little grab bar icon (mdi:drag-vertical) for drag and drop re-ordering of actions that replaces up/down arrows. On desktop, this would be hidden behind the icon.
    • Maybe swap placement of Conditions and Actions. Since conditions are completely optional and often won't be used, I think they should be underneath actions. Lets the user create things quicker.
    • Rather than the orange circular FAB with an outdated floppy disk icon reference, let's just have a button that says "Save Automation." When there's no unsaved changes the button would show in a gray disabled state, otherwise blue background.
      • Any steps that have errors would be shown in this sidebar with a red exclamation point over their icon. So you could easily see what needs addressing. Would not be able to save until fixing the errors. These errors would be user friendly such as "Your automation currently lacks an Action step. Add one now!"
  • On mobile devices the entire interface would be the sidebar described above. When you tap one of the list items, instead of showing it on the left, it would simply show the full card (with editing controls) underneath. So basically functions like an expansion panel / collapsible accordion menu type thing.

---

One of the friction points for beginners is that although they know exactly what they want to automate, it can be difficult to "translate" that into Home Assistant lingo. For example the user might know they want to turn on the lights when motion is detected but it's not immediately obvious that they should select the "State" dropdown, find the binary_sensor.living_room_motion entity, and type from: off to: on. And this is one of the more easier examples since it's just on/off - once you start getting into the various states of an entity, things become significantly harder.

So it would be very helpful if the triggers section focused more on common use cases. Not only does it eliminate a lot of confusion but it also provides some inspiration too.

Heading: When this happens...

• Weather Event
  • Temperature (less than, equal to, greater than). Slider for temperature with value listed in large font above it.
  • Wind Speed (less than, equal to, greater than). Slider for miles per hour with value listed in large font.
  • Humidity (Dry, Comfortable, Moist) - add percentages to these options
  • Weather State (Sunny, Cloudy, Rainy, Snowy, Hazy, Foggy)
  • Visibility and/or Air Pressure? Or is that too much.
• Location Event
  • Leaving or arriving at home
  • Leaving or arriving at a zone
• Time of Day
  • At sunrise or sunset
  • At time of day
• State
  • Motion detected
  • Door opened
  • Light turned on
  • Device turned on
  • Temperature is above or below
  • Battery falls below threshold
• System
  • Home Assistant startup or shutdown
• Integration
  • This will be a brand new thing where integrations can provide their own triggers. Kinda similar to Device Automations.

	Triggers - Time of Day
	At a certain time
	At sunrise or sunset

	Triggers - Location Event
	Arrive at Home
	Leave Home
	Leaving or arriving at Zone
	Proximity

UI: Display a small info icon next to the dropdown that will allow user to see more-info panel. This way they can determine whether it's the right entity they want, and see the available states to use in automation. Or better yet, if all available states can be retrieved (leverage recorder or something?).

Another idea here, that I'm kind of iffy about, is hiding things that the user doesn't have. If user doesn't have any motion sensors inside their HA instance, it wouldn't display the "Motion Detected" trigger for example. This would make the UI even more simpler, but on the other hand it might be useful to show the user that they can do certain things after buying the appropriate hardware. So it's sort of a tradeoff. Maybe display it but in a grayed out / disabled state or have a toggle or something so the user can see what's possible.

Heading: Under the condition... (optional)

At the very top would be a radio button to select ALL conditions (default) or ANY condition. If "Any condition" is selected, this would add "or" text between each card.

Also want to look at what the most common conditions are. Want to implement things that currently require templates to do. Like don't trigger this automation if it has ran in the past X minutes. Or don't run this automation until Home Assistant has been running for 2-3 minutes. Stuff like that should be easy to do in this editor.

• Time of Day
  • Specific Times (Start / End)
  • During the day
  • At night
• Presence (this will use person component)
  • I'm at home
  • I'm not at home
  • Somebody is at home
  • Nobody is home
• Weekday

Time is after X / Time is before X Sun elevation and such

Improve: Merge Sun and Time into one Time of Day condition.

Heading: Home Assistant should perform the following actions...

The problem:
Currently, the vast majority of automation actions are of the "Call Service" type. A huge dropdown list with dozens, potentially hundreds of choices. It's overwhelming. And it can be very confusing.

For example there's a media_player.play_media service and a media_player.media_play service - which one do I use? You might want to record a clip on your camera, so logically you'd type in camera but the service doesn't show up, because it's actually named stream.record. By the time you figure this stuff out, you might've forgotten what you were attempting to automate in the first place.

The solution:

1. First step is organizing and grouping related services in a logical way. Think of the reason we use folders on our computer, so that there's not hundreds of files strewn all over our desktop.
2. Create specialized UI for these common use cases.
3. Allow contributors to hook into this. Integrations like Discord and Telegram notifications would be listed under the "Notify" category for example. They would use the brand icons.

This proposal makes things significantly easier by grouping things in a logical way and optimizing the UI for these most common use cases. We use folders because having a ton of things in an unorganized way is hard to deal with. The ability to call any service will still remain, but it'll be listed at the very bottom as more of a "last resort." Most users will never have to use it.

We're going to organize and group related services together in a smart and logical way. Rather than seeing one massive dropdown list with an overwhelming number of services, it's going to be really user friendly and approachable.

Below are the categories everything would be grouped into. Each category has a relevant icon that makes it easy to quickly identify with minimal reading. If you don't have a relevant device, you won't see that category - users without a smart vacuum won't see the vacuum category for example.

Icon	Action Category	Services
	Quick Actions Import a previously saved set of actions to save time.	X
	Control a Light Turn on, off, or toggle a light.	3
	Control a Fan Turn on, off, or toggle a fan.	3
	Control an Input Boolean Turn on, off, or toggle an input boolean.	3
	Control a Media Player Turn on, off, play, pause, stop, adjust volume, mute.	7
	Control a Camera Play or record camera stream, take snapshot, enable or disable motion.	5
	Notify Someone Send a notification to you or a family member using any notify service.	?
	Say something Send a TTS (text to speech) message to a supported media_player.	1
	Trigger an Automation	1
	Run a script	1
	Set a scene	1
	Perform Home Assistant Task Restart, Shut down, Update Entity, Change Theme, Snapshot, etc...	X
	Call any service Advanced option that lets you run any Service not listed above.	1
	Change Alarm Status Arm, disarm, or trigger your alarm panel.	6
	Control Climate Set climate settings.	9
	Control a Water Heater Turn a water heater on or off, change temperature or operation mode.	5
	Control a Vacuum Turn a vacuum on or off, start or pause, etc.	12
	Control a Lock Lock, unlock, or open a lock.	3
	Control a Timer Start, stop, pause, or cancel a timer.	5
	Control a Counter Increment, decrement, or reset a counter.	3
	Control a Cover Open or close a cover, set position.	10
	Wait Until... (Wait Template) Wait until a certain condition is met before continuing running actions.	1
	Delay for Duration Waits for a set amount of time before continuing your Actions.	1
	Under These Conditions Any actions underneath this one will only run if conditions are met.	1

Feedback Requested:

• I'm probably missing a bunch of stuff, what would be important here? Remotes? What else? Switches obviously, but should Switch be merged with Input Boolean or is that too different?
• Could or should any of these categories be merged? TTS could maybe go under "Notify" for example since it's a voice notification. But maybe it's better at top level? Should the wait/delay/condition stuff go into a single category, and if so what should that be called?
• Maybe it is not a good idea to start everything with "Control a " cause now it makes it harder to parse the available actions quickly if they all start the same?

---

Integrations will be able to add their own custom triggers, conditions, and actions to the automation editor. For example the Logitech Harmony integration could add an action for "Change channel" that calls the harmony.change_channel service and the user would select which hub and enter in a channel number. Then they'd never have to touch YAML for any of that stuff. There would be a "Home Assistant" integration too which could provide conditions like Home Assistant was online for at least X minutes etc.. flesh this out more.

When sharing automations (more on that later), if the user who imports the automation does not have this integration on their system, it would help them install it. So you'd get a message that says "This action requires an integration to be installed" and then you click that and it launches the config flow to install it (or if not available via the UI it would be a link to the docs for that integration).

Alternative names: Rapid, Favorite, Fast Favorites, Saved Sets, Frequently Used, Common, Recent?

Often times you'll find yourself re-using the same conditions across many automations. For example any time I use Text to Speech I always have three conditions - don't play during night hours, don't play if the media player is already playing something, and don't play if the apartment is empty. This is trivial to do in YAML since you can just copy and paste the parts you want from one automation to another. But it's cumbersome to recreate these all the time in the GUI.

So the idea of this feature is once you add some triggers/conditions/actions, you'll have the option of saving those for later. In my above example I would save that as "TTS Conditions" and then every time I add conditions there will be a quick menu to simply import those. This would be indicated by a lightning bolt icon mdi:lightning-bolt

This menu could also have "Copy from recently created automation" and it'd show the last five or so. This way if you're creating five or six similar automations in a row, you could simply import what you want from the other one.

Need to think about this some more and figure out the best approach, but the basic gist is rather than having Almond be a separate dialog that you have to think about, you'd just enter the automation name as you normally do today. And then Almond would try to parse that and offer you suggestions. This could show up under your triggers/conditions/actions as "Suggested by Almond: Turn on light" and the user would just add it with one click but only if they wanted.

When you have an automation with conditions, that section will have a "Preview" button (or something in an overflow menu) that when clicked on will show either green checkmarks or red X's next to each condition. These would indicate whether the condition has been met or not. Clicking these icons will show either a tooltip or mini dialog with the current state.

Template support through the UI would be implemented where it makes sense in an easy and user-friendly way. Rather than making the user learn Jinja templates, wherever there is a text entry field, there'd be an "Insert Template" button with some of the more commonly used things like current time, current date, etc and you'd just pick from the list to insert it. There'd be an attribute one that you'd select an entity and then pick from the attributes which one you'd wanna show. I didn't think of this too much yet, other things have to get priority as one is a little more advanced.

Want to have an editor for creating if/else and service templates etc. Need to figure out the best way to accomplish this, just jotting down the idea for now. The other things have to get priority first but this is something to tackle later.

Sometimes you're creating an automation and you want to add a condition whose criteria does not exist yet. You can add input_boolean and such easy now from the UI under Helpers, but this suggestion would make it even more convenient and quicker.

Basically an "Add New" would be listed at the bottom of the dropdowns, and open up the dialog to create a new one. This is already done in certain spots like Areas. Once the user clicks add new it'll open the dialog to create an Input Boolean helper. When they hit save it's automatically added to the condition; no need to find out the entity ID or reload inputs or anything like that, it's all done for you in one convenient flow.

This idea could also be expanded to other areas - if you're creating a location based automation and need a new zone, just create one from the automation editor. It'd pop open the add new zone dialog and you can add it/save it without ever leaving automation editor.

One of the more tedious parts of creating automations, even for experienced users, is tweaking them to be just right. You might need to make very minor adjustments like tweaking the value of a delay command. But this involves saving, editing, reopening, reloading automations(?) etc.

There can be a much easier way. Would be a "Test Now" button and it would run your actions. So you'd be able to test an automation prior to saving it, then keep tweaking it on the fly until it works how you want. Hitting Test Now button could also activate the "Preview Conditions" button described above (though it's not necessary to match conditions for this to work, much like the Execute button).

There will be an "Initial State on Startup" option that you can toggle on or off. Right now there's no way of doing so through the Automation Editor. Advanced mode only.

User can set an icon in the Editor now. This would appear by the name field. Advanced mode only. Not too important though so this would be a low priority thing or could be scrapped altogether.

reword this a lot, just jotting down jumbled thoughts atm

One of the biggest features of this overhaul is that it will be built with sharing of automations in mind. Home Assistant has an amazing community that likes to help each other, and this feature will make it even easier to do so.

First, let's take a look at the two main problems with sharing code at the moment.

• Sharing Code - Not everyone understands how to properly format code when sharing it. Which is why...
  • Home Assistant's Community Forums has an obnoxiously large animated gif at the top of every page. And people still don't follow those instructions much of the time.
  • Home Assistant's Discord server has HassBot which tells people how to format code using backticks or that they pasted a message that was over 15 lines, and so forth.
• Using Shared Code - the other problem is importing code that someone shared into your setup.
  • Users have to figure out where to place those automations, how to indent them, etc.

And now, the solution to those problems.

Every automation would have a Share icon/button located at the top of the page just after the automations name. This would essentially create a link that other users can import directly into their Home Assistant instance with a single click.

Another cool thing that would be possible, is that when setting up an integration through the UI (Config Flow) you could have an option to automatically add some automations (do a mockup of this). So the developers of the integration could basically build.

Since everyones entities are going to be unique, it would replace the entity ID's with a variable type thing. When clicked on you select your own entity_id to be there.

Why this is awesome:

• In the documentation you could have clickable buttons/links that beginners can add the automations to their setup.
• Every link that gets shared is also promoting Home Assistant, and the Home Assistant apps.

Maybe experiment with a handful of pre-made automation templates where the automation is more or less done and the user just fills in some fields MadLibs style? Use Chips?

Each thing would have a number, so it's clear which order things run in.

Chips?

Here's an example of how it would look (OLD MOCKUP FROM OVER A YEAR AGO...REDO):

The example mockup above combines eighteen different services into a very clean and organized list of just four items.

• There are nice icons that allow you to quickly scan the list and find what you're looking for. These icons would use theme primary-color as the background color. In this example it's using the default theme which is blue, but here's some more examples of various colors.
• Not only is it more readable in plain english, but also solves some discoverability issues. For example camera.play_stream and stream.record are related services, but they're on far opposite ends of the Services list. This UI combines them into a relevant group.

Step 2: After selecting the category, you then select the entity from a dropdown list. This will be filtered to only show relevant entities - for example if you select "Control a Light" it would only show entities prefixed with light.* and so forth.

Step 3: Lastly you select the specific action to perform. These would be radio selects or something similar, really simple layout. Print the "Friendly Name" inside here if there is one.

Below is a table of some commonly created automations and the amount of steps (clicks or taps) it requires to create. Besides just pitting the current editor against this proposal, I am also comparing it to some of the larger platforms out there. I want to get it on par with those.

Automation	HA Current	HA Proposal	Alexa	Google	HomeKit
Turn on light when motion detected	TBD	TBD	TBD	TBD	TBD
	TBD	TBD	TBD	TBD	TBD
	TBD	TBD	TBD	TBD	TBD
	TBD	TBD	TBD	TBD	TBD

Note: Intentionally not using Almond or Device Automations for the current figures, always the full-fledged editor.