ESPHome 2026.11 adds a choose action, and an on_stop trigger cleans up after interrupted scripts

ESPHome automations are getting the kind of branching Home Assistant users already know. Pull request #20547 by Clyde Stubbs, merged into the development branch on 17 October 2026 at 10:23 UTC, makes four changes to scripts and actions. The documentation (esphome.io #7648) was merged later the same day. The code is in the dev tree, version 2026.11.0-dev, so it will reach users with the 2026.11 release. At the time, 2026.10.0 itself was still in beta (beta 4 came out on 13 October).

A choose action

Picking one of several paths has meant nesting an if inside an else. The new choose action takes a list of choices, each with if: and then:, and runs the actions of the first choice whose condition is true. An optional final else: runs when nothing matches. Internally it chains the existing if/else actions, so it changes how a configuration reads, not how it runs.

- choose:
    - if:
        lambda: 'return id(temperature).state < 20;'
      then:
        - switch.turn_off: fan
    - if:
        any:
          - lambda: 'return id(temperature).state < 25;'
          - binary_sensor.is_on: window_open
      then:
        - switch.turn_on: fan
        - delay: 5min
    - else:
        - switch.turn_on: fan

One condition straight under if

A single condition can now go directly under if: without a condition: wrapper. If you put more than one condition there, or mix one with condition:, all: or any:, validation stops with an error that tells you what to change.

script.stop without an id, and on_stop

Inside a script, a bare script.stop now stops that same script. Outside a script the id is still required.

The new on_stop trigger runs when a script is stopped before it finishes, either by script.stop or because a script in restart mode was started again. It does not run when the script reaches its end normally.

This closes a gap that bites simple automations. A script that turns a fan on, waits and turns it off again leaves the fan running if something calls script.stop during the wait. With on_stop, the cleanup lives in one place:

script:
  - id: fan_control
    mode: restart
    on_stop:
      - switch.turn_off: fan
    then:
      - switch.turn_on: fan
      - delay: 5min
      - switch.turn_off: fan

There is one behaviour change for C++ code: Script::stop() still does nothing when the script is not running, but in that case it no longer calls stop_action(). The pull request is labelled as a non-breaking new feature, so existing configurations keep working.