Smart Home Assistant

Home Assistant Natural Language Automations: What's New in 2026.7

SepehrBy Sepehr· 27 June 2026· Updated 27 June 2026· 6 min read
✓ Independent — no paid placements✓ UK-tested in real homes✓ Cited sources on every guide
Home Assistant Natural Language Automations: What's New in 2026.7
On this page[tap to expand]

Setting up a Home Assistant automation has always required you to think in the platform's terms: entity IDs, state values, condition blocks, trigger types. Even a simple rule — turn the heating on when the bedroom gets cold — meant navigating several dropdowns and knowing which entity to pick from a potentially long list. That process is about to become much more straightforward.

Home Assistant 2026.7, currently in release candidate and expected to ship in July 2026, graduates purpose-specific triggers and conditions — the feature that powers natural language automation — out of Labs and into the default experience for all users. If you have been putting off learning to write automations because the UI felt intimidating, now is the right time to revisit it.

What Changed in 2026.7

Natural language automation was previewed in Home Assistant 2026.6 as a Labs feature. Labs features require you to opt in under Settings → Experimental Features, and they carry no stability guarantee. The 2026.6 Labs preview let early adopters describe automation intent in plain language, but it also introduced a breaking change that caught some users out: the keywords any and last were renamed to each and all respectively, which broke existing YAML automations written against the Labs preview without warning.

Home Assistant 2026.7 resolves both of those concerns in one release. Purpose-specific triggers and conditions are no longer behind a Labs flag — they are now the default mode for the automation editor and the underlying engine for all users. At the same time, the renamed keywords (each and all) are now the stable, documented API. If you have YAML automations that still use any or last from the early Labs period, 2026.7 is your prompt to update them — see the migration section below.

Graduating a feature out of Labs signals that the Home Assistant team considers the API stable enough to rely on. For natural language automations, that is significant: you can now build automations using plain-language intent and expect them to keep working across future updates.

How Purpose-Specific Triggers Work

The core idea is that you describe what you want the automation to do, rather than configuring how it should detect each individual state change. The official blog example captures it well: instead of selecting a trigger type, picking a sensor entity, and specifying a numeric threshold condition, you write:

When the bedroom drops below 18°C, turn on the heating.

Home Assistant parses this intent and maps it to the correct trigger entity, condition type, and action — without requiring you to know the entity ID of your bedroom temperature sensor or the exact state format your heating switch expects.

Under the bonnet, the feature works through what the team calls purpose-specific matching. Rather than a generic entity picker, the UI presents contextually appropriate options based on what you are trying to do. If you are writing a trigger about temperature, it surfaces temperature sensors. If you are writing an action about lights, it surfaces light entities. The goal is to match the mental model most people already have — “when this situation occurs, do this thing” — to the Home Assistant data model.

This is complementary to, not a replacement for, the full automation system. Complex multi-condition automations, those that involve helper entities as intermediate state, or those that reference scenes as actions still use the same underlying YAML. Natural language automation is a better on-ramp and a better interface for simpler rules — it does not remove any of the existing power.

Writing Your First Natural Language Automation

With 2026.7 installed, creating a natural language automation requires no Labs opt-in and no YAML editing. Here is the basic workflow:

  1. Navigate to Settings → Automations & Scenes → Create Automation.
  2. Choose Create new automation from the prompt screen.
  3. In the trigger field, describe your trigger in plain language — for example, "When the bedroom temperature drops below 18°C". Home Assistant will suggest matching entities as you type.
  4. Confirm the suggested entity — in this case your bedroom temperature sensor. The threshold condition (below 18°C) is extracted automatically from your description.
  5. In the action field, describe what should happen — for example, "Turn on the bedroom heater". Again, Home Assistant surfaces matching entities.
  6. Give your automation a name and save. No YAML required.

Behind the scenes, Home Assistant generates valid YAML for the automation. You can inspect and edit that YAML at any time by switching to the YAML view in the editor — natural language and manual YAML editing are not mutually exclusive. This is useful when you want to add a second condition or copy part of an automation to a new one.

If you use input helpers — such as an input_number to hold a configurable temperature threshold — those helpers appear in the entity suggestions just as sensors do. Natural language automation is aware of the full entity registry, not just physical devices.

Migration Note for 2026.6 Labs Users

If you enabled the natural language automation Labs preview in 2026.6, you need to review your YAML before upgrading to 2026.7. The 2026.6 Labs preview renamed two keywords that affect how multi-trigger automations behave:

  • any → renamed to each — applies the condition to each trigger independently
  • last → renamed to all — requires all triggers to have fired before the action runs

Automations that still reference the old keywords (any, last) in their YAML will produce a warning in 2026.7 and may not behave as intended. The fix is straightforward: search your automations YAML (or the automation editor) for those keywords and replace them with the new names. In most home setups, the number of affected automations will be small — the rename only affects automations written specifically during the 2026.6 Labs opt-in period.

Users who never opted into Labs in 2026.6 are unaffected. The stable 2026.7 release uses each and all as the canonical names from the start.

Template Engine Speed Improvement

Alongside the natural language feature, Home Assistant 2026.7 includes a significant performance improvement to the template engine, credited to core developer @frenck. The template engine powers every Jinja2 expression in your automations — conditions that compute values, action fields that interpolate sensor readings, custom notification messages that include live data. In 2026.7, the engine renders templates up to 40% faster than in previous releases.

In practice, this improvement is most noticeable in installations with many automations that run frequently — for example, a home with dozens of sensor-driven rules evaluating every minute. It also benefits custom template sensors that update on every state change. The improvement is not something you need to configure; upgrading to 2026.7 is sufficient to benefit from it.

This is worth calling out because template performance has historically been the first bottleneck to appear as Home Assistant installations grow. A 40% throughput gain gives headroom to add more automations before needing to optimise template complexity.

What to Expect Next

Graduating natural language automations out of Labs is a statement of intent about the direction of the automation editor. The underlying architecture — purpose-specific matching of intent to entities — is now the stable foundation. Future releases are likely to build on it: more device types in the entity suggestions, support for more complex natural-language patterns, and potentially deeper integration with the voice assistant pipeline.

The each and all keywords introduced in 2026.6 and stabilised in 2026.7 are also worth understanding if you plan to write multi-trigger automations. They give you precise control over whether each trigger independently evaluates its conditions (each) or whether the automation waits for all configured triggers to have fired within a session (all) — a distinction that matters for things like "notify me when both the front door sensor and the motion sensor have triggered this evening".

For now, the most practical next step is to upgrade to 2026.7 once it reaches stable release (expected July 2026), explore the automation editor with a few simple rules, and confirm that any 2026.6 Labs YAML is updated. The community beta thread at the Home Assistant forums is a good place to watch for any RC-stage issues before the stable release lands.

Frequently asked questions

What are Home Assistant natural language automations?
Natural language automations in Home Assistant let you describe what you want an automation to do in plain English — for example, 'When the bedroom drops below 18°C, turn on the heating' — rather than manually configuring trigger types, entity IDs, and condition blocks. Home Assistant maps your description to the correct entities and generates the underlying YAML automatically. The feature, called purpose-specific triggers and conditions, becomes the default experience for all users in Home Assistant 2026.7 (currently in release candidate, expected July 2026).
Do I need to enable a Labs flag to use natural language automations in 2026.7?
No. Natural language automations were a Labs opt-in feature in Home Assistant 2026.6, but 2026.7 graduates them to the default experience. All users on 2026.7 will have access to purpose-specific triggers and conditions in the automation editor without changing any settings.
My automations broke after enabling the natural language Labs feature in 2026.6 — what happened?
The 2026.6 Labs preview renamed two keywords: 'any' became 'each' and 'last' became 'all'. This was a backward-incompatible change that broke YAML automations written against the earlier Labs preview. In 2026.7, 'each' and 'all' are the stable names. To fix broken automations, search your YAML for the old keywords and replace them with the new ones.
How much faster is the Home Assistant 2026.7 template engine?
The Home Assistant 2026.7 template engine renders Jinja2 templates up to 40% faster than previous releases, according to the official release notes. This improvement, credited to core developer @frenck, benefits all template-based automations, template sensors, and custom notification messages. No configuration is needed — upgrading to 2026.7 is sufficient.

Sources

Sources verified 2026-06-27

  1. Home Assistant — Home Assistant 2026.7 Release Candidate — Official Blog
  2. Home Assistant — Home Assistant 2026.6 Release Notes
  3. Home Assistant Community — 2026.7 Beta Week — Community Discussion
Sepehr

Written by

Sepehr

10+ years smart home experience · Runs Home Assistant locally · Tests every product reviewed

Smart home specialist with 10+ years running a self-hosted Home Assistant setup — Zigbee2MQTT, Frigate NVR, and local-first automations. Independent coverage for UK homes, no brand deals.

LinkedIn →

Related reading