Writing Your First Home Assistant Automation: A Step-by-Step UI Editor Guide

Once you’ve got a dashboard showing your devices, automations are where Home Assistant actually starts saving you effort - things happening on their own rather than you tapping a toggle every time. The built-in UI automation editor covers the vast majority of what most households actually need, and you don’t need to touch YAML to use it.

The Three Parts of Every Automation

• Trigger - the thing that starts the automation (a time, a sensor changing, a button press)
• Condition (optional) - a check that must also be true for the automation to continue (e.g. “only if it’s after sunset”)
• Action - what actually happens (turn on a light, send a notification, lock a door)

Every automation, no matter how complex, is built from these three building blocks. Once that clicks, most of what looks complicated in someone else’s automation is just more of the same three things stacked together.

Building a Real Automation: Porch Light at Sunset

Rather than a toy example, here’s a genuinely useful first automation - turning on the porch light automatically at sunset and off at a fixed time.

1. Go to Settings → Automations & Scenes → Create Automation → Start with an empty automation
2. Under Add Trigger, choose Sun, then Sunset. You can add an offset here too (e.g. 15 minutes after sunset) if you don’t want it triggering the instant the sun technically sets
3. Under Add Action, choose Device, select your porch light, and choose Turn on
4. Save and name the automation clearly (e.g. “Porch light on at sunset”) - vague names become a real problem once you have thirty automations

Now add a second automation for turning it off, using a Time trigger (e.g. 11:30pm) instead of Sun, with the same action set to Turn off. Two simple automations rather than one complex one is often easier to build, read, and fix later than trying to cram both directions into a single automation with multiple triggers.

Adding a Condition: Only If Nobody’s Already Handled It

A common next step is adding a condition so the automation doesn’t override something you’ve deliberately changed. For example, add a State condition checking the porch light is currently off before the sunset trigger turns it on - this avoids the automation doing something redundant (and potentially confusing) if you’d already turned it on manually for some reason.

Testing Before You Trust It

Don’t wait for the next sunset to find out if it works. Every automation has a Run actions button (the play icon) in the automation editor that fires the action immediately, skipping the trigger and condition - this tests your action logic in seconds rather than waiting hours for a real trigger. For testing the trigger itself, Home Assistant’s trace feature (accessible from the automation’s three-dot menu) shows exactly what happened the last time it actually fired, which is invaluable once things get more complex.

A More Advanced Example: Combining Multiple Conditions

Once the sunset example feels easy, a good next step is an automation that combines several conditions with AND logic - this is where most of the real value in home automation actually lives, since a single-trigger automation is really just a fancy timer. Try building: turn on the hallway light when motion is detected, but only if it’s after sunset AND the light isn’t already on.

1. Trigger: your motion sensor’s state changing to detected
2. Condition 1: a Sun condition set to “after sunset”
3. Condition 2: a State condition checking the hallway light is currently off
4. Action: turn the hallway light on

By default, multiple conditions in the standard editor are combined with AND - all of them have to be true for the action to run. If you need OR logic instead (e.g. “if motion in the hallway OR motion in the landing”), that’s a job for multiple triggers on the same automation rather than multiple conditions, since triggers already work as OR - any one of them firing starts the automation. Conditions and triggers solve different problems and mixing them up is a common source of confusion early on.

Useful Second and Third Automations to Build

• Notification on a specific sensor - a water leak sensor or door sensor triggering a mobile app notification, using the Notify action and the Home Assistant Companion App
• “Everyone’s left” trigger - using the Zone trigger tied to phone locations (via the Companion App) rather than a single person’s phone, so the automation only fires once the whole household is genuinely out
• Time-and-day scheduling - a Time trigger with a day-of-week condition, useful for anything that should only run on weekdays or weekends

Common Mistakes When Starting Out

• Building one giant automation instead of several small ones - simpler automations are easier to debug when something doesn’t fire as expected
• Forgetting conditions apply at trigger time, not continuously - a condition is checked once, the moment the trigger fires; it doesn’t keep watching afterwards
• Not using the trace/history tools when something doesn’t work - guessing why an automation didn’t fire wastes far more time than checking its trace

Reading a Trace Properly When an Automation Won’t Fire

The trace tool mentioned above is worth understanding properly, not just knowing it exists. Open an automation, click the three-dot menu, choose Traces, and pick the run you want to inspect (or the most recent one if it just failed to do what you expected). The trace shows every step the automation actually went through as a small flowchart: which trigger fired, whether each condition evaluated true or false, and which action(s) ran as a result.

The single most useful thing to check first is whether the automation triggered at all. If there’s no trace for the time you expected it to run, the trigger itself never fired - which usually means the underlying entity (the sensor, the sun state, the time) didn’t actually change the way you assumed, not a bug in the automation logic. If a trace exists but stops at a condition step shown in red, that condition evaluated false and blocked the action - click that step and the trace shows the exact state value it was checking against, which is almost always more informative than re-reading the automation’s YAML by eye.

A related tool worth knowing: Developer Tools → States lets you look up the live current value of any entity - useful for confirming what a sensor’s state actually is right now, before assuming an automation’s condition is broken when the real issue is that the entity itself isn’t reporting what you think it is.

Frequently Asked Questions

What’s the difference between an automation and a script in Home Assistant?

A script is just a sequence of actions with no trigger of its own - useful when you want to reuse the same set of actions from multiple different automations, or trigger it manually from a dashboard button. An automation always needs a trigger; a script is called by something else (an automation, a dashboard button, or manually).

Do I need Node-RED instead of the built-in editor?

Not for anything covered here - the built-in editor handles triggers, conditions and actions perfectly well for the majority of household automations. Node-RED becomes worth learning once you need genuinely complex branching logic that’s hard to express in the standard editor’s condition blocks.

Once you’re comfortable building simple automations, our guide to building a real presence-detection automation covers a genuinely useful step up from single-trigger examples like the one above.