Home Assistant YAML vs UI Automations: Which to Use

One of the first questions new Home Assistant users ask is whether they should build automations in the visual UI editor or write them in YAML. The community is weirdly tribal about this. YAML purists act like the UI is for amateurs. UI fans act like YAML is needlessly masochistic. Both are wrong. Each approach has specific strengths, and the best setup uses both.

Let me give you the practical breakdown so you can make an informed choice instead of picking a side based on forum arguments.

The UI Automation Editor

The visual editor in Home Assistant lets you build automations by clicking through dropdown menus. You select triggers, conditions, and actions from lists, and HA generates the underlying YAML for you. Everything is stored in automations.yaml behind the scenes.

When the UI Is Better

• Simple automations: "When motion is detected, turn on the light" takes 30 seconds in the UI. Writing YAML for this is slower and adds no value.
• Exploring available options: The UI shows you every available trigger type, condition, and action. When you are learning what HA can do, browsing these menus is faster than reading documentation.
• Device-specific triggers: The UI surfaces device-specific triggers (like "Aqara button double-pressed") that are hard to discover in YAML without knowing the exact event type strings.
• Non-technical household members: If your partner or roommate wants to create or modify automations, the UI is accessible without learning YAML syntax.

YAML Automations

YAML automations are written directly in configuration files. You can put them in automations.yaml (same file the UI uses) or in separate files using the !include directive.

When YAML Is Better

• Templates: If your automation needs dynamic values, like adjusting brightness based on time of day, or sending a notification with sensor data, YAML templates are far more powerful than the UI template editor. Jinja2 templating in YAML lets you do math, string formatting, and conditional logic inline.
• Complex conditions: Nested AND/OR/NOT conditions with multiple variables are easier to read and maintain in YAML than in the nested UI dropdown interface.
• Version control: If you keep your HA configuration in Git (and you should), YAML files give you proper diffs, commit history, and the ability to roll back changes. The UI editor modifies automations.yaml which works with Git, but the formatting can shift between edits.
• Bulk operations: Need to create 10 similar automations for 10 rooms? Copy-paste and find-replace in YAML takes 2 minutes. Building each one individually in the UI takes 20 minutes.
• Advanced features: Some features like choose (conditional branching), repeat (loops), and parallel (concurrent actions) are available in the UI but much easier to structure and read in YAML.

My Recommendation: Use Both

Here is what works well in practice. Use the UI for:

• Quick, simple automations (motion lights, door alerts, time-based triggers).
• Prototyping. Build it in the UI first, test it, then convert to YAML if it gets complex.
• Anything your non-technical household members need to modify.

Use YAML for:

• Anything with templates (dynamic brightness, calculated values, conditional notifications).
• Complex multi-step automations with branching logic.
• Automations you want in version control with clean diffs.
• Blueprints (reusable automation templates you share or apply to multiple rooms).

Converting Between UI and YAML

Converting a UI automation to YAML: open the automation in the UI editor, click the three dots menu, and select "Edit in YAML." Copy that YAML into your configuration file.

Converting YAML to UI: paste YAML into the visual editor's YAML view. If the YAML uses features the UI supports, it will render in visual mode. If it uses advanced features (like complex templates), the UI will show it in YAML-only mode but still manage it.

One caveat: if you edit an automation in the UI that was originally written in a separate YAML file (not automations.yaml), the UI will move it to automations.yaml. This can cause duplicates if you are not careful. To avoid this, either manage all automations through the UI (in automations.yaml) or keep YAML-managed automations in separate included files that the UI does not touch.