Update 2026.7: Home Assistant finally fixes one of its biggest flaws

Home Assistant 2026.7 is available, and this July update checks a box that many have been waiting for: making automations easier to create without sacrificing what makes Home Assistant interesting.

This is not just a moved button or a cosmetic touch-up. The big new feature is the introduction of “use-case oriented” triggers and conditions (those that have been in Labs for a while) which become the default behavior in the automation editor. In practical terms: instead of reasoning in terms of entities, states, and sometimes obscure attributes, Home Assistant finally moves closer to the way we conceptualize our scenarios.

Previously, to create an automation like “when motion is detected outside, turn on the outside lights,” you had to choose the right type of trigger, select one or more entities, know their exact state, and then check that the action targeted the right equipment. Not impossible, but it required a certain mental gymnastics. And when starting out, this gymnastics can feel like a major challenge.

With 2026.7, we start from what we want to do. “Motion detected outside.” “Temperature too low in the bedroom.” “Low battery.” “Door open.” “Sunset.” Home Assistant takes care of the rest.

It’s more intuitive, and more robust. The two often go hand in hand.

Automations that finally speak the language of the home

The most concrete change concerns the automation editor. Purpose-specific triggers and conditions become accessible to everyone.

The principle: instead of choosing a technical logic, you choose a real situation.

To turn on the heating when the temperature in a room drops below 18 °C, you no longer have to think “digital trigger,” “temperature attribute,” “value less than.” You select a trigger related to temperature, indicate your threshold, and it’s done.

The same goes for motion sensors. Previously, you sometimes had to know whether the sensor changed to “on,” “detected,” “occupancy,” “motion,” or other technicalities depending on the manufacturer. The editor now directly offers a trigger “motion detected.”

This is not trivial. Consistency in names is what makes an automation readable six months later – not just on the evening it is created.

Home Assistant announces over 200 new triggers and more than 200 new conditions. Motion, presence, battery, temperature, humidity, opening, media, volume, device state, position of a shutter, availability of an update, vacuum returning to its base, and robot mower returned to the dock: common scenarios are covered.

For someone experienced, this saves time. For a beginner, it removes a real barrier. And for an installer who needs to leave something understandable to their client, it’s great news.

Areas become truly useful in scenarios

The new triggers and conditions work with Home Assistant targets: room, area, floor, device, entity, or label. This is where it gets interesting.

Concrete example. You have three motion sensors in the garden: one in front of the front door, one near the garage, and one by the patio. Previously, you would have created a trigger with three entities, or three separate triggers. If you replaced one sensor, you had to go back to modify the automation.

Now, you target the area “Outside”: when motion is detected outside, turn on the outside lights. If you add a new sensor in this area in six months, the automation continues to work without touching anything.

The same logic applies to lights. You say “turn on the lights in the Outside area.” If you add a Zigbee wall light, a Shelly spotlight, or a Hue bulb in this area later, your scenario remains valid.

This is the difference between freezing a list of entities and describing an intention. The second approach ages much better.

Labels follow the same logic. Create a label “Christmas Decoration,” apply it to your smart plugs and garlands, then point to it in your automations. A single automation turns everything on at sunset, no matter where the garlands are in the house.

The new “first,” “each,” and “all” choices change the game

When an automation targets multiple devices, Home Assistant needs to know how to react. Version 2026.7 brings three distinct behaviors: first, each, and all.

The first mode triggers as soon as the first device matches. A window opens in the living room → we turn off the heating. No need to wait for all windows to be open.

The each mode triggers on every occurrence. Each time someone enters the house, we send a notification or update a presence log.

The all mode waits for all targeted elements to match. All shutters on the ground floor are closed → we activate night mode.

This type of logic already existed, but it required groups, templates, or well-crafted conditions manually. Here, it’s in the interface, readable, and designed to be understood without opening the toolbox of the perfect little YAMList.

Fewer technical traps in automations

Home Assistant is powerful, but it has its pitfalls. States like “unknown” or “unavailable,” for example, have caused hair loss for more than one.

A sensor that becomes unavailable and then returns to its normal state can trigger an automation unexpectedly if it’s poorly built. The same issue occurs with certain events that do not change state in an obvious manner.

The new specialized triggers handle some of this complexity internally. Home Assistant knows better what should be ignored and what truly corresponds to the desired event.

This does not mean that advanced users lose control. Classic triggers, templates, complex conditions, and YAML remain available. But for common scenarios, the new model significantly reduces the risk of error.

In a real home, this matters. A light that doesn’t turn on at the right moment is annoying. A heating system that shuts off incorrectly or an alarm that misbehaves is another story.

YAML remains very much present

Home Assistant makes it clear: nothing breaks. Existing automations continue to work. No mandatory migration, no forced conversion.

Old triggers remain available. YAML stays at the heart of the functioning: the interface still generates it in the background.

These new triggers are designed to be clean in YAML. The names are more readable, closer to a sentence. You can understand what an automation does by reading its code, without remembering that a particular internal state corresponds to a particular physical event.

One point of attention, however: users who had enabled these functions in Labs before their official release may be affected by some key renaming.

• battery.low becomes battery.became_low,
• battery.not_low becomes battery.no_longer_low,
• vacuum.docked becomes vacuum.returned_to_dock,
• lawn_mower.docked becomes lawn_mower.returned_to_dock.

Nothing dramatic, but it’s worth checking the automations created with the old experimental version. For others, no problem.

A much more comprehensive documentation

Home Assistant has revamped its documentation. Dedicated pages now exist for triggers, conditions, and actions, with usage from the interface, YAML examples, and practical details for each element.

This is a real improvement. Many users still stumble upon examples from 2021 found on a forum or in an old YouTube video. With these new reference pages, Home Assistant sets a more solid and up-to-date foundation.

This will also help AI assistants, which still often rely on old YAML models to generate automations. More structured documentation should improve the reliability of these suggestions over time. Not magically (an AI can always invent an entity that doesn’t exist) but the foundation will be better.

The sun gains new, much more precise triggers

Sun-related automations are classic: open shutters at sunrise, turn on lights at sunset, close blinds when brightness decreases. Simple and widely used.

Until now, solar triggers were quite limited: sunrise, sunset, with possibly a time offset in minutes. The problem is that “30 minutes before sunset” does not yield the same result in June as it does in December, and even less so depending on the weather or your latitude.

Home Assistant 2026.7 adds finer concepts: civil, nautical, and astronomical dawn, twilight, solar elevation, ascending or descending sun. For fine-tuning enthusiasts, it’s a treat.

Concrete example: instead of turning on outdoor lamps 20 minutes before sunset – a fixed setting that works poorly in winter and arrives too early in summer – you trigger from a solar elevation level. The result matches better with the actual available light.

For conditions, it’s the same. “If the sun is set” or “if the sun is going down” can be written directly, without fiddling with a template.

The light turns on at the right moment, the shutters close more naturally, and no one wonders why the house is still living by winter time while the sun is shining brightly.

The activity log finally becomes readable

The Logbook adopts a new timeline format. And it’s a nice improvement.

The old format listed events line by line. Useful, but in a setup with dozens of sensors and automations, finding the cause of a specific event could quickly become tedious.

The new timeline groups events by day, with a vertical line, icons, and status colors. Most importantly, Home Assistant now displays the cause when known: the avatar of the user who turned on a light, the name of the responsible automation, the icon of the integration that triggered the action.

A lamp turns on by itself at 11:12 PM? We open the timeline, scroll up, and can see in seconds whether it’s an automation, a person, or an external integration that triggered the action.

The timeline appears in several places: Activity page, entity details, device page, zone page. During the presentation, the team showed a compact version directly in a light window, with state changes and their origin. It’s much more useful than a simple “on/off.”

The updates page becomes more practical

The updates page has been revamped. Honestly, it was about time.

When using Home Assistant with Core, Supervisor, OS, HACS, ESPHome, several modules, firmwares, and a few add-ons, the updates page looked like a mini laundry list on Sunday. Click, wait, click again, restart, repeat.

The new page groups updates by categories. Home Assistant Core, the OS, and the Supervisor remain separate: these are the core components that one wants to update deliberately. Other updates are grouped by type: integrations, apps, ESPHome, HACS, firmwares, etc. And a “Update all” button allows launching all updates of a group at once.

The OS is not mixed with the rest, to avoid a restart in the middle of other updates. Home Assistant stays composed on this matter.

For installations with many ESPHome devices, this is a relief. No need to select everything manually one by one.

Raspberry Pi can update their firmware more easily

With Home Assistant OS 18 or newer, Home Assistant can display an update entity for the Raspberry Pi firmware: the EEPROM, also known as bootloader firmware.

This low-level firmware manages booting, USB or NVMe storage, and some hardware functions. Keeping it up to date on Raspberry Pi 4 and especially Pi 5 improves compatibility and stability.

Previously, updating this firmware was not a pleasant task. It sometimes required a dedicated SD card, a screen, a keyboard, or command-line access. Now, it can be done from Settings > Updates, like the rest.

There are a few limits to know. Home Assistant OS 18 is required. The Raspberry Pi 4 that boots from USB storage cannot always take advantage of it. The Home Assistant Yellow with Compute Module 4 is not affected. However, Pi 4, Pi 5, and the Yellow with Compute Module 5 are included.

After application, Home Assistant requests a restart: like a PC BIOS, the new version is not active until a reboot.

ZHA benefits from a real Zigbee management page

The advanced management of Zigbee devices via ZHA leaves the small compact window for a dedicated page.

The tools were there but cramped: clusters, bindings, signatures, neighbors, technical details. All in an interface that lacked space to breathe.

Version 2026.7 reorganizes all this with tabs. The information remains the same, but it’s more readable.

For basic everyday use, it doesn’t change much. You can very well use ZHA without ever digging into Zigbee clusters. But to understand your mesh, check the neighbors of a device, or create direct bindings between devices, it’s much more pleasant. And for diagnosing a sensor that is unresponsive, a tricky bulb, or a flaky mesh network, a clear interface saves time.

Infrared and radio frequency now have their dedicated panels

After Zigbee, Z-Wave, Thread, and Matter, Home Assistant 2026.7 adds dedicated panels for infrared and radio frequency devices.

These panels only appear in settings if you have the relevant equipment: configured IR/RF emitters, proxies, or gateways.

This concerns ESPHome solutions, infrared blasters, RF 433 MHz bridges, or integrations that can control equipment without state feedback: air conditioning, audio amplifier, fan, old radio blinds, 433 MHz sockets. This whole little ecosystem now has its corner in the interface.

Infrared and 433 MHz have an old-school feel, but they remain very present in real installations. Finding them neatly organized is a good thing.

Matter.js becomes the new default Matter engine

This point was the subject of a separate announcement, but the official presentation of this update revisits it: Home Assistant’s Matter server now uses Matter.js as the default backend.

The old server relied on the official Matter implementation in C/C++, with a Python layer that was not really designed for production. Matter.js, developed in JavaScript/TypeScript and supported by the Open Home Foundation, is a clean and independent implementation, easier to evolve.

For the user, the migration is meant to be seamless. Matter devices remain paired. The first migration may take slightly longer (data is converted in the background) but the goal is to break nothing.

The interest is primarily medium-term: better support for new Matter features, more mastered behaviors, and an independent implementation that helps pinpoint ambiguities in the spec itself. Matter is promising, but still young, and there are still vague areas in the standard.

Performance increases in the interface and templates

Some discreet but useful optimizations.

The frontend loads faster, especially the graphics. This is noticeable on energy dashboards or long histories.

The device and zone pages adapt better to different screen sizes, with a cleaner column layout. On wall tablets, mini PCs, or smartphones, these kinds of details matter.

Most importantly: templates are reported to be about 40% faster. Templates are everywhere in advanced installations (calculated sensors, conditions, custom messages, dashboards). A gain at this level has a real impact on large configurations.

Easier-to-customize time formats

Cards displaying dates or durations gain a formatting option directly in the interface.

Before, modifying the display of a timestamp required YAML or a template sensor. Now, the editor offers several formats: date, date and time, relative, long, or short.

For uptime of a server, the last update of a sensor, or the date of the last synchronization of a device, you get a readable output without fiddling.

New integrations for water, energy, ventilation, and more

Ten new integrations for this version: Aqvify (water level in a well or tank), Chef iQ (Bluetooth cooking probes), Dropbox (backups), Edifier Infrared, energieleser (energy, water, gas, heat meters), Envertech EVT800 (solar micro-inverters), Greencell (charging stations via MQTT), Helty Flow (decentralized ventilation units), KlikAanKlikUit (433 MHz radio equipment), and MELCloud Home (Mitsubishi Electric systems).

Several deserve attention.

Dropbox as a backup destination is a simple option for those who want to externalize their backups without a complicated infrastructure. Home Assistant backups are precious: when an SD card fails or a mini PC decides to go on an indefinite vacation, a recent backup can save the day.

On the energy side, Envertech EVT800, Greencell, energieleser, and Hypontech Cloud further bolster Home Assistant’s position as an energy monitoring hub. Solar, electric vehicle charging, consumption, battery, grid: the building blocks are accumulating.

Helty Flow is interesting for decentralized ventilation, a recurring topic in well-insulated homes. Being able to control that locally, without a constant dependency on the cloud, is the kind of detail that matters.

Existing integrations are also making progress

The new features are not limited to new integrations.

Alexa Devices can now manage Alexa task and shopping lists in Home Assistant and adds switches to control announcements and communications on Echo devices.

SMTP gains modern notification entities to send emails from Home Assistant – useful for important alerts: water leak, power outage, alarm, critical low battery, excessive consumption.

Overkiz supports Rexel Energeasy Connect via cloud and local API, an interesting point for French installations. Tesla Powerwall supports Powerwall 3 and adds sensors related to operating mode as well as maximum charge and discharge powers.

Yoto makes significant progress: media browser, new sensors, binary sensors, time entity, screen brightness and maximum volume settings. Parents using these little audio readers for children will appreciate.

On the pool side, Vistapool gains many additional entities for more precise scenarios around treatment, lighting, and control. And since the connected pool is a fun playground in summer, we won’t complain.

Finally, we note the addition of the ability to send images to the SwitchBot AI Art Frame that we tested some time ago, which will enable much more enjoyable interactions with this beautiful frame :)

A major cleanup of abandoned integrations

Home Assistant 2026.7 also removes a series of integrations that have become unusable: broken for years, dependent on closed services, abandoned libraries, or discontinued hardware.

Acer Projector, Ampio Smog, Avi-on, BeeWi SmartClim, Clementine, Dovado, ELIQ Online, Microsoft Face, MS Teams, Mycroft, UniFi LED, Watson TTS, and others are removed.

This kind of cleanup may seem abrupt. But a broken integration since 2019 helps no one. It complicates maintenance, weighs down the project, and gives false hope to those trying to use it.

Should you install Home Assistant 2026.7?

Yes. This is one of the important updates of the year.

The new automations make Home Assistant more accessible without sacrificing the power that appeals to advanced users. The activity log is finally readable. The updates page is less tedious. ZHA is improving. Raspberry Pis gain firmware management directly in the interface. Integrations continue to grow. And performance improves bit by bit.

This is a version that enhances the substance rather than stacking compatible devices.

For beginners, it’s a better entry point: creating an automation becomes more logical, closer to the way we think. For regulars, it’s an opportunity to revisit some old automations: not an obligation, but the new model is cleaner and more maintainable. For installers, it’s another step towards setups that the client can understand, or even modify themselves without calling for help.

Home automation has never been so powerful. It also becomes a bit less intimidating. This wasn’t the most urgent point five years ago. Today, it’s probably what matters most for it to truly settle in homes.