Home Assistant Automations in 2026: The New Trigger Model and Why Yours Didn't Run

On 1 July 2026, Home Assistant changed the way automations are built. Purpose-specific triggers left Home Assistant Labs and became the default for everyone, and the release notes called it one of the biggest changes in years.

Almost nothing written about Home Assistant automations reflects that yet. Guides published in June 2026 still teach you to pick a trigger type called "state" and then hunt for the right entity, which is the exact workflow the new model was built to replace.

So this guide starts with what the editor does now, then spends most of its time on the part the tutorials skip: why an automation that looks correct quietly does nothing.

What is a Home Assistant automation?

A Home Assistant automation is a rule that runs by itself when something happens in your home. Motion is detected, so a light turns on. The temperature drops, so the heating starts. Everyone leaves, so the plugs switch off.

Every automation has the same three parts:

• A trigger. The event that starts it. Something has to happen.
• A condition. An optional check. Should this actually continue right now?
• An action. What Home Assistant does.

The difference between the first two trips up nearly everyone, and Home Assistant's own documentation flags it directly: "Triggers require an event to happen for the conditions to be evaluated using current state information."

The practical version: a trigger is a moment, a condition is a fact. Motion starting is a moment. The sun already being down is a fact. You can't build an automation that triggers on "the sun is down" because that isn't an event, it's a state that's just true for twelve hours.

What changed in Home Assistant 2026.7?

Home Assistant 2026.7 made purpose-specific triggers and conditions the default, so you now choose the event you care about rather than the internal mechanism that detects it.

The old flow started from Home Assistant's architecture. Franck Nijhof, a Home Assistant core developer, described the problem in his write-up of the change: you had to work out "which entity represents that? Which state does it use?" before you could build anything.

That sounds minor until you hit it. You want an automation for a low phone battery. First you have to know whether your phone reports battery as a percentage sensor or a binary "low" flag, then whether the value you're comparing is a number or a string, then what happens when the phone is off and the sensor reports unavailable instead of a number.

The new model gives you a trigger called "battery became low" and the integration works out the rest.

The second change matters more over time. Triggers can point at an area instead of a list of devices. Home Assistant's release notes put it plainly: "The trigger points at the outside area, the action points at the outside lights. Change which sensors or lights live there later, and the automation follows along."

That's the difference between an automation you edit every time you buy a sensor and one you don't.

Nothing breaks, either. Existing automations keep running, YAML is untouched, and generic triggers still exist for anything the new ones don't cover. It's a better starting point, not a migration.

The three triggers you have to fix by hand

Three trigger keys were renamed in 2026.7, and Home Assistant does not update them for you:

• battery.low became battery.became_low
• lawn_mower.docked became lawn_mower.returned_to_dock
• update.update_became_available became update.became_available

If you built automations with these during the Labs preview, they need updating manually, either by re-selecting the trigger in the editor or editing the YAML key directly. This is listed in the 2026.7 backward-incompatible changes, and it's the kind of thing that turns into a month of wondering why the mower never comes home.

Building your first automation

Go to Settings, then Automations & scenes, then Create automation, then Create new automation.

Home Assistant's own getting-started guide uses lights at sunset as its example, and it's a good first one because it needs no sensors at all. Add a trigger, type Sun, pick Sunset, then set an offset of -00:30:00 so it fires half an hour early while there's still some light. Add an action to turn on the light you want. Save.

That's a complete automation. No code, no entity IDs.

The instinct after that first one is to build something clever. Resist it for a week. The community's most-referenced automation guide makes the same point from the other direction, listing over-complex single automations as a top beginner mistake because they're miserable to debug when one part misbehaves.

Why your automation didn't run

Start with the trace, not the automation. Home Assistant records the last five runs of every automation, and a trace is "a step-by-step timeline of what was triggered, which conditions were checked, and what each action did."

Open it from Settings, then Automations & scenes, then the three-dot menu on the automation.

What you find there splits the problem in two:

No trace at all means the trigger never fired. The actions are irrelevant; don't touch them. The problem is upstream.

A trace that stops partway means a condition blocked it. The trace shows you which one.

Then there's the third case, the one that makes people reinstall Home Assistant: the trigger fires, the trace looks fine, and the automation still doesn't do anything on the second, third, or fourth try.

That's the run mode.

The run mode nobody mentions

Every automation has a mode, and the default is single. Home Assistant's documentation describes what single mode does when the automation is triggered while already running: "Do not start a new run. Issue a warning."

It doesn't queue. It doesn't restart. It drops the trigger and writes a line to a log you aren't reading.

This bites hardest with motion lighting, because the usual pattern is: motion detected, turn light on, wait five minutes, turn light off. That automation is running for the whole five minutes, including the wait. Walk past the sensor at minute two and nothing happens. The light goes off at minute five while you're standing under it.

Nothing about that looks broken from the outside. The run started, it just refused the ones behind it.

Motion lighting wants restart. Change it under the automation's three-dot menu, and the timer resets every time you walk past. Queued and parallel cap at 10 waiting or simultaneous runs by default.

The reason this matters more than any list of automation ideas: it's not a bug you can see. The automation is written correctly. It just declines to run and tells nobody.

Testing without waiting for the trigger

Waiting until sunset to find out whether your sunset automation works is a bad way to spend an evening. There are three faster routes.

Run actions from the three-dot menu executes the whole action sequence "while skipping all triggers and conditions." It answers one question only: do the actions work? If the light comes on, your actions are fine and any remaining problem is the trigger or a condition.

Test a single condition from that condition's own three-dot menu. It reports back "Condition passes" or "Condition did not pass" immediately.

Live condition badges, added in 2026.6, are the quiet upgrade here. Every condition row now carries a small badge on its icon showing whether it currently passes, updating in real time as your home changes. Green check, red circle, or a neutral state if it can't be evaluated. You can set a temperature threshold and watch the badge flip without saving, running, or opening a single trace.

If you've been debugging Home Assistant conditions by trial and error, that badge is worth updating for on its own.

One inconsistency worth knowing about

Home Assistant's documentation currently disagrees with itself, and it's worth knowing if you're following along in two tabs.

The getting-started automation guide walks through the new purpose-specific flow. The understanding automations page still describes the older generic model, where all triggers are state transitions and the example is a person's presence changing from not_home to home.

Both are live and both are official, checked on 19 July 2026. The release was eighteen days ago and the documentation is still catching up, which is normal for a project shipping monthly, but confusing if you assume every page was updated together. Trust the getting-started guide and the release notes for anything about how triggers work now.

Automations that fit an Indian home

Most automation lists are written for houses with central heating and a garage. A few of the situations that actually recur in Indian homes are worth naming, because they're genuinely different problems.

Geyser scheduling is the clearest win. A water heater left on all day is one of the largest avoidable loads in the house. A time trigger that switches a smart plug or switch on 30 minutes before people usually bathe, and off after, does the whole job with no sensors. It's also the automation people notice on the bill, which is a related topic covered in where automation actually cuts energy use.

AC control through an IR blaster. Most air conditioners here aren't smart, but a Broadlink-style IR blaster brings them into Home Assistant, after which a temperature-crossed-threshold trigger works exactly as it would on a smart thermostat.

Power cuts. Home Assistant on a Raspberry Pi with no UPS will do an unclean shutdown every time the power goes, and the corruption risk is on the SD card. This is a hardware decision more than an automation one, but it changes what your automations can be trusted to do.

Monsoon humidity. A humidity sensor plus a dehumidifier or exhaust fan is a straightforward threshold automation, and it runs for three months a year rather than all of it.

Water tank levels. An ultrasonic or float sensor with a notification action is a common project here and almost unheard of in guides written elsewhere.

None of these need the new trigger model. They're just the automations that don't appear on the lists.

When a blueprint saves you the work

A blueprint is a pre-built automation template where someone else wrote the logic and you fill in the devices. Motion lighting is the classic case: the good blueprints handle the timer reset, the "don't turn on if it's already bright" check, and the manual-override problem that trips up hand-rolled versions.

Import one from Settings, then Automations & scenes, then the Blueprints tab.

Worth doing when the logic is fiddly and well-solved. Worth skipping when the automation is three lines, because a blueprint you can't read is harder to fix later than an automation you wrote.

What this post does not cover

This is about building and debugging automations in the current editor. It doesn't cover writing automations in YAML beyond what the editor generates, Jinja2 templating, scripts and scenes as separate concepts, node-based alternatives like Node-RED, or local voice control.

It also assumes Home Assistant is already running. If it isn't, start with getting Home Assistant installed, and how dashboards changed this year covers the screen these automations will show up on. For the hardware layer underneath, Matter hubs compared is the place to start.

Nothing here is a recommendation to buy a specific device.

Sources

• Home Assistant 2026.7 release notes: Automations that speak your language, Home Assistant, 1 July 2026
• Home Assistant 2026.6 release notes, Home Assistant, 3 June 2026
• Understanding automations, Home Assistant documentation
• Automating Home Assistant: getting started, Home Assistant documentation
• Testing and troubleshooting automations, Home Assistant documentation
• Automation modes, Home Assistant documentation
• More power, less complexity in Home Assistant automations, Franck Nijhof, Home Assistant core developer