Home Assistant 2026.10 Beta Makes Multi-Trigger Automations Easier to Edit

Home Assistant’s October beta makes it easier to put the “on” and “off” halves of an automation in one place. The change I care about is how clearly the editor shows which trigger leads to which action.

In the 2026.10 beta notes, a Triggered by condition lets you select the triggers themselves instead of inventing and remembering their IDs. The editor manages those IDs, flags conditions pointing to removed triggers, and offers a repair for shared IDs. Existing manually assigned YAML IDs remain supported.

As of October 3, these are beta notes, with a stable release planned for October 7. The feature list can still change. This is an examination of the documented behavior, not a claim that I have installed the beta in my house.

The benefit is being able to read the whole job

Consider a hallway light. Motion should turn it on; the sensor remaining clear for a while should turn it off. Keeping those decisions together can make it easier to spot a mismatch when someone changes the sensor or the delay.

Home Assistant already supports this. Its trigger documentation explains that an automation starts when any of its triggers fires, and that trigger IDs can select the corresponding actions. The beta improves the editing experience rather than inventing multi-trigger automations.

I would organize the example as two triggers and two branches: motion detected selects the light-on action; motion clear for the chosen duration selects light-off. Labels should describe those events. A month later, “hallway motion cleared” tells me more than an unexplained number.

Combining automations can change the conditions

The part I would check most carefully is a condition that used to belong only to one half of the job.

Suppose the original light-on automation required the hallway to be dark. Move that condition to the top of a combined automation and it can also block the light-off branch. The light might then stay on when the room becomes bright. I would keep the darkness check inside the on branch unless it is genuinely required for both paths.

This is why I would not merge a working collection just to reduce the automation count. Two short automations can be easier to maintain than one with unrelated branches. Combining them earns its place when the reader can follow the complete behavior more easily.

For a first conversion, I would use an ordinary light and test both paths through real sensor changes. Then test the condition that should reject the on action. That last check matters: a successful run does not show whether the automation correctly refused the wrong one.

Check the timing assumptions too

Check the automation mode if either branch includes a delay or wait. In Single mode, another trigger cannot start a run while the first is still executing. Restart cancels the current run before starting again. Combining two previously independent automations can therefore change what happens when their events arrive close together.

The trigger documentation warns that waiting for a state duration with for does not survive a Home Assistant restart or an automation reload. A clearer editor does not make that wait persistent.

For a hallway light, losing an in-progress wait might be an acceptable tradeoff if another event restores the expected behavior. For something that must happen at a deadline, I would design around a stored deadline and explicitly handle startup rather than assume the pending wait comes back.

I like changes that make existing capabilities easier to inspect. When the stable release arrives, I would try this on one paired automation, keep a copy of the original, and check its branches and timing before converting the next one.