The script integration allows users to specify a sequence of actions to be executed by Home Assistant. These are run when you turn the script on. The script integration will create an entity for each script and allow them to be controlled via services.


The sequence of actions is specified using the Home Assistant Script Syntax.

# Example configuration.yaml entry
      # This is Home Assistant Script Syntax
      - service: notify.notify
          message: "Current temperature is {{ states('sensor.temperature') }}"

Script names (e.g., message_temperature in the example above) are not allowed to contain capital letters, or dash (minus) characters, i.e., -. The preferred way to separate words for better readability is to use underscore (_) characters.

Configuration Variables

alias string (Optional)

Friendly name for the script.

icon string (Optional)

Icon for the script.

description string (Optional)

A description of the script that will be displayed in the Services tab under Developer Tools.

variables map (Optional, default: {})

Variables that will be available inside your templates


The value of the variable. Any YAML is valid. Templates can also be used to pass a value to the variable.

fields map (Optional, default: {})

Information about the script field parameters; see the Passing variables to scripts section below. Please note: In order for this description to be displayed in the Services tab of the Developer Tools, the script description must be defined as well.


A parameter field used by this script. All sub-options are only used for creating a representation of this script in the UI.

name string

The name of this script parameter field.

description string

A description of this of this script parameter.

advanced boolean

Marks this field as an advanced parameter. This causes it only to be shown in the UI, when the user has advanced mode enabled.

required boolean

Mark if this field is required. This is a UI only feature.

example string

An example value. This will only be shown in table of options available in the Services tab of the Developer Tools.

default any

The default value for this field, as shown in the UI.

selector selector (Optional)

The selector to use for this input. A selector defines how the input is displayed in the frontend UI.

mode string (Optional, default: single)

Controls what happens when script is invoked while it is still running from one or more previous invocations. See Script Modes.

max integer (Optional, default: 10)

Controls maximum number of runs executing and/or queued up to run at a time. Only valid with modes queued and parallel.

max_exceeded string (Optional, default: warning)

When max is exceeded (which is effectively 1 for single mode) a log message will be emitted to indicate this has happened. This option controls the severity level of that log message. See Log Levels for a list of valid options. Or silent may be specified to suppress the message from being emitted.

sequence list Required

The sequence of actions to be performed in the script.

Script Modes

Mode Description
single Do not start a new run. Issue a warning.
restart Start a new run after first stopping previous run.
queued Start a new run after all previous runs complete. Runs are guaranteed to execute in the order they were queued.
parallel Start a new, independent run in parallel with previous runs.

Full Configuration

    alias: "Wake Up"
    icon: "mdi:party-popper"
    description: "Turns on the bedroom lights and then the living room lights after a delay"
      turn_on_entity: group.living_room
        name: Minutes
        description: "The amount of time to wait before turning on the living room lights"
            min: 0
            max: 60
            step: 1
            unit_of_measurement: minutes
            mode: slider
    # If called again while still running (probably in delay step), start over.
    mode: restart
      # This is Home Assistant Script Syntax
      - event: LOGBOOK_ENTRY
          name: Paulus
          message: is waking up
          entity_id: device_tracker.paulus
          domain: light
      - alias: "Bedroom lights on"
        service: light.turn_on
          entity_id: group.bedroom
          brightness: 100
      - delay:
          # supports seconds, milliseconds, minutes, hours
          minutes: "{{ minutes }}"
      - alias: "Living room lights on"
        service: light.turn_on
          entity_id: "{{ turn_on_entity }}"

Passing variables to scripts

As part of the service, variables can be passed along to a script so they become available within templates in that script.

There are two ways to achieve this. One way is using the generic script.turn_on service. To pass variables to the script with this service, call it with the desired variables:

# Example configuration.yaml entry
    platform: state
    entity_id: light.bedroom
    from: "off"
    to: "on"
    service: script.turn_on
      entity_id: script.notify_pushover
        title: "State change"
        message: "The light is on!"

The other way is calling the script as a service directly. In this case, all service data will be made available as variables. If we apply this approach on the script above, it would look like this:

# Example configuration.yaml entry
    platform: state
    entity_id: light.bedroom
    from: "off"
    to: "on"
    service: script.notify_pushover
      title: "State change"
      message: "The light is on!"

Using the variables in the script requires the use of templates:

# Example configuration.yaml entry
    description: "Send a pushover notification"
        description: "The title of the notification"
        example: "State change"
        description: "The message content"
        example: "The light is on!"
      - condition: state
        entity_id: switch.pushover_notifications
        state: "on"
      - service: notify.pushover
          title: "{{ title }}"
          message: "{{ message }}"

Waiting for Script to Complete

When calling a script “directly” (e.g., script.NAME) the calling script will wait for the called script to finish. If any errors occur that cause the called script to abort, the calling script will be aborted as well.

When calling a script (or multiple scripts) via the script.turn_on service the calling script does not wait. It starts the scripts, in the order listed, and continues as soon as the last script is started. Any errors that occur in the called scripts that cause them to abort will not affect the calling script.

Following is an example of the calling script not waiting. It performs some other operations while the called script runs “in the background.” Then it later waits for the called script to complete via a wait_template. This technique can also be used for the calling script to wait for the called script, but not be aborted if the called script aborts due to errors.

      - service: script.turn_on
          entity_id: script.script_2
      # Perform some other steps here while second script runs...
      # Now wait for called script to complete.
      - wait_template: "{{ is_state('script.script_2', 'off') }}"
      # Now do some other things...
      # Do some things at the same time as the first script...