Home Assistant 2026.7: Intent-Based Automations and the matter.js Overhaul, Explained

Home Assistant 2026.7 shipped on July 1, 2026. It makes purpose-built, area-aware automation triggers the default for everyone, and it changes the server that handles Matter devices. The release changes how automations are written more than any recent point release, so this guide covers what changed, what to check before upgrading, and where the caveats sit.

Home Assistant 2026.7 makes purpose-built, area-aware triggers the default, while a matter.js-based Matter Server rewrite is reported to improve Matter networking. Before upgrading, back up your configuration, review automations that count people in zones, and note which automations you may later rebuild as intent-based triggers.

This guide draws on Home Assistant’s official release notes and changelog, plus clearly labeled secondary coverage. See How This Guide Was Built at the end for details.

What Actually Changed in Home Assistant 2026.7

Home Assistant 2026.7 promotes purpose-specific triggers and conditions from the Labs experiment introduced in 2025.12 to the default for everyone. The same release brings a rebuilt Activity timeline, an “Update all” button, and ten new community integrations, according to the official release notes.

Activity replaces the Logbook with a timeline that groups entries by day. Infrared and radio frequency controls get dedicated panels, ZHA’s Zigbee device management is overhauled, a time format selection is added, and Raspberry Pi firmware updates can be managed from within Home Assistant (release notes). The 2026.7 line received four patch releases, 2026.7.1 through 2026.7.4, between July 3 and July 24 (changelog).

Intent-Based Automations, in Plain Language

Intent-based automation means you start from the outcome you want, such as “Temperature crossed threshold” or “Battery low”, instead of wiring raw entity states by hand. Home Assistant 2026.7 makes these purpose-built triggers and conditions the default for every installation.

The release notes’ own example reads like a sentence: “When the bedroom drops below 18°C, turn on the heating” (release notes). Instead of comparing one sensor’s numeric state against a threshold, you pick the named trigger and set the number. The release notes describe the new triggers and conditions as starting from what you want the home to do, rather than from Home Assistant’s internal state model.

Why Area Targeting Is the Real Upgrade

The most significant new capability is area targeting. Triggers and conditions can point at an area rather than a single device or entity. The release notes give the example of an automation that can “react to motion in the living room no matter how many motion sensors the room has” (release notes).

Because the automation targets the area, adding, replacing, or removing a sensor in that room does not require editing the automation. This is the practical benefit for mixed-hardware homes. It is the author’s inference that this also reduces dependence on a single vendor’s device, since the automation no longer names one specific device.

Build Your First Area-Based Automation

The release notes walk through the same steps this section follows. Here is the sequence, written from that example rather than from a hands-on test:

Start a new automation. Begin with a blank one rather than editing an existing automation, so you can compare the two before retiring anything. This is the author’s suggested practice.
Choose the purpose trigger. In the trigger picker, look for the named, purpose-specific triggers. “Temperature crossed threshold” is the one the release notes demonstrate (release notes).
Target the bedroom area. Target the trigger at the area, as the release notes describe, rather than a single thermostat or sensor entity.
Set the threshold. Enter 18°C, matching the release notes’ example.
Add the action. Turn on the heating. The release notes summarize the finished automation in one line: “When the bedroom drops below 18°C, turn on the heating” (release notes).
Consider conditions. Purpose-specific conditions ship alongside the triggers (release notes). Check the condition picker for the options available on your version.

Two caveats. First, this walkthrough follows the release notes’ example; we did not run it on hardware, so menu names may differ on your instance. Second, the release notes name only two example triggers and do not list the full set, so your trigger picker may offer more.

What Happens to Your Existing Automations and YAML

The release notes state “nothing breaks. All your existing automations keep working,” and that YAML remains supported (release notes). The new triggers and conditions are offered alongside the existing ones, so nothing is forced on you.

You can rewrite a fragile automation as an intent-based one and keep the original running while you test the replacement. That side-by-side approach is the author’s recommendation, not a documented migration path.

The Zone Entity Breaking Change: Check This Before Upgrading

One backward-incompatible change deserves attention before you upgrade. Zone entities now compute their person count and persons attribute from person entities’ in_zones attribute. One person can therefore count toward several zones at once (release notes).

Position-aware device trackers also change. Their state is now the smallest zone the device is in, where previously it was the zone whose center was closest (release notes). The release notes say automations, scripts, or templates that depend on zone person counts or tracker zone states may need adjusting.

If you have automations that count people in the home zone, or templates that read a tracker’s state as a zone name, test them after upgrading. Zone “entered” and “left” triggers were added during the 2026.7 cycle and then reverted within it, so they did not ship (changelog). The shipped feature is the area-based purpose trigger.

The matter.js Matter Server Overhaul, Explained for Owners

According to secondary analysis, Matter Server v9.0 replaces the Python-based server with one built on matter.js, the TypeScript implementation of Matter, and reaches Matter 1.5.1 compliance. The same analysis describes a redesigned networking stack aimed at more reliable discovery and reconnection. Those details cross-reference Home Assistant’s June preview post, The Matter upgrade you’ve been waiting for. Treat them as reported, not independently verified.

For owners, the practical takeaway is narrower than the word “overhaul” suggests. What is being reworked is discovery and reconnection. After upgrading, watch how reliably Matter devices reappear after a server or network restart.

New Matter Sensors and Diagnostics

The official changelog confirms two additions to the Matter integration: GeneralDiagnostics sensors with fault binary sensors (PR #169830), and a Matter soil moisture sensor (PR #172372). Both are recorded as merged in the 2026.7 cycle.

Secondary coverage additionally reports Reboot Count, Uptime, Boot Reason, and Hardware, Radio, and Network Fault sensors, plus a Thread network visualization tab, and new Matter 1.5.1 device categories: cameras, doorbells, and closures such as blinds, curtains, and garage doors. These come from a single secondary source, so treat them as reported rather than confirmed.

Your Pre-Upgrade and Post-Upgrade Checklist

Take a full backup before updating. Secondary coverage recommends including the Matter store and ZHA databases.

Before upgrading

Take a full backup, including the Matter store and ZHA databases (secondary analysis). The 2026.7 cycle also hardened backup tar extraction with Python’s tar_filter (PR #172252) (changelog).
Check Z-Wave JS versions: zwave-js-server 3.9.0 or newer (schema 49), the Z-Wave JS app at 1.4.0 or newer, and the Z-Wave JS UI container at 11.19.1 or newer (release notes).
List the automations and templates that reference zone person counts or position-aware tracker states, so you know what to audit afterward.

After upgrading

Confirm you are on the latest patch. The 2026.7 line includes 2026.7.1 (July 3), 2026.7.2 (July 10), 2026.7.3 (July 21), and 2026.7.4 (July 24) (changelog).
Audit the zone-dependent automations from step 3 and adjust any that behave differently (release notes).
Rebuild one fragile automation as an area-targeted, intent-based trigger, and run it alongside the original before retiring anything.

Automation Creation, Before vs After 2026.7

The table condenses the release into the comparison that matters for daily use: how you write triggers, what you can target, and what happens to automations you already built.

Aspect	Before 2026.7	After 2026.7
Trigger style	Raw entity state triggers; purpose-specific triggers only in Labs (introduced in 2025.12)	Default for everyone (release notes)
Trigger examples	Numeric thresholds and battery states wired by hand	Named triggers such as “Temperature crossed threshold” and “Battery low” (release notes)
Targeting	A single device or entity	Areas, so one automation covers every sensor in a room (release notes)
Zone entered/left triggers	Not available	Not shipped in 2026.7; added then reverted (changelog)
Existing automations	Unchanged	Keep working; YAML remains supported (release notes)

FAQ

Do my existing automations stop working after upgrading to 2026.7?

No. The official release notes state that existing automations keep working and that YAML remains supported. The exception is automations that depend on zone person counts or tracker zone states, which may need adjusting because those values are now computed differently.

Were zone entered/left triggers shipped in 2026.7?

No. Zone “entered” and “left” triggers were added during the development cycle and then reverted within it, so they did not ship in 2026.7 (changelog). The shipped feature is the area-based purpose trigger (release notes).

Do I need to update anything else for Z-Wave JS?

Yes, if you use Z-Wave JS. The release notes require zwave-js-server 3.9.0 or newer (schema 49), the Z-Wave JS app at 1.4.0 or newer, and the Z-Wave JS UI container at 11.19.1 or newer (release notes). Check all three so the server, add-on, and container versions match the core update.

The Bottom Line

Upgrade, after a backup. Area-targeted, purpose-specific triggers make automations easier to describe and easier to keep working when a sensor is swapped, which is the author’s assessment based on the release notes. Existing automations keep working and YAML remains supported (release notes), so nothing forces a migration. The main risk is the zone person-count and tracker-state change, which can quietly alter automations that count people or read tracker zones. Back up first, including the Matter store and ZHA databases per secondary coverage. Then audit zone-dependent automations.

How This Guide Was Built

This guide is based on Home Assistant’s official 2026.7 release notes and core changelog, both fetched on 2026-10-17, plus secondary coverage. We did not run this release on a test system. No screenshots, timings, or test results in this post come from our own testing.

Facts sourced only from secondary analysis are labeled as such in the text: the Matter Server v9.0 implementation details, the Thread network visualization tab, and the Matter 1.5.1 device categories. The author’s walkthroughs and recommendations are inference from the release notes, not documented procedures. The changelog was checked through patch releases 2026.7.1 through 2026.7.4, dated July 3 through July 24, 2026.

ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from SmartHome Field Guide.

← Back to guides