Home Assistant 2026.10 Makes Multi-Trigger Automations Easier to Edit

In the 2026.10 release, 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 an optional way to separate shared IDs. Sharing an ID remains valid; the suggestion does not mean the automation is broken. Existing manually assigned YAML IDs remain supported.

Updated October 10: This article originally covered the beta on October 3. The stable release shipped October 7 with the trigger-editor changes described here. This is analysis of the documented behavior, not a report of testing it 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 new editor 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.

Check both branches before replacing the originals

For a first conversion, use an ordinary light, save the original automations, and disable them during the test so they cannot mask a mistake in the replacement. These are suggested checks, not results from a household test.

Use sensor transitions and inspect the automation trace for the trigger and branch taken. Also exercise overlapping events if either branch waits. If the replacement behaves differently, disable it before restoring the originals; leaving both enabled makes the next result ambiguous.

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 would convert one pair first and keep it only if the branches and timing are easier to follow. A smaller automation count is not worth changing when a light turns off.