Home Assistant Blueprints: 3 Domains, Hundreds of Templates

Home Assistant Blueprints are reusable automation templates. They split the logic from the per-device bits. You define a pattern once, say a motion light with a timeout, then spin it up for every room by filling in a form. No YAML to copy. No ten near-twin automations to babysit. In Home Assistant 2026.4, blueprints span three domains: automation, script, and template. They ship dozens of selector types for clean input forms and tidy collapsible sections for bigger setups. They’re the fastest way to keep smart home behavior the same across many devices.

Why Blueprints Exist: The Copy-Paste Problem

A typical smart home has five to fifteen motion-activated lights. Without blueprints, each one needs its own automation. Same trigger logic, same conditions, same actions, only the entity IDs change. You copy the YAML, swap the entity names, and now you have fifteen near-identical blocks to maintain.

When you find a bug or want a new timeout rule, you edit all fifteen. Miss one and you get inconsistent behavior that’s painful to debug.

Blueprints fix this by turning the repeated pattern into a template with inputs you can change. If you’ve written code before, a blueprint is like a function. Each automation built from it is a function call. The blueprint sets the trigger, condition, and action shape with placeholder variables.

When you make an automation from that blueprint, you fill in the variables: which motion sensor, which light, what timeout. Home Assistant then builds a real automation. One blueprint can spawn many instances, and a change to the blueprint flows to every instance on the next reload.

This is different from scripts. Scripts are reusable action sequences. They don’t include triggers or conditions, only what to do, not when to do it. Blueprints define full automations: triggers, conditions, and actions. Since Home Assistant 2024.4, blueprints can also define reusable scripts (with domain: script). In 2024.x, template entity blueprints joined as a third domain.

When blueprints make sense:

• Any automation pattern you spin up three or more times
• Standard behavior across rooms (consistent motion lights , shared climate schedules)
• Repeated zone logic, like a Home Assistant smart irrigation system that runs the same watering rule across every garden zone
• Automations you want to share with the community or across many HA instances
• Templates for households where some folks prefer forms over YAML

When blueprints are overkill:

• One-off automations tied to a single room or use case
• Automations where each copy needs a different trigger or action shape
• Heavy branching logic that shifts per instance: Node-RED is often a better fit

The Blueprint Exchange

The Home Assistant community keeps a library of tested blueprints at the Blueprint Exchange . To import one, go to Settings > Automations & Scenes > Blueprints. Click Import Blueprint, paste the URL from the Exchange post, and click Preview. The blueprint lands in your /config/blueprints/ folder, and you can build automations from it right away.

A few community blueprints worth highlighting:

When you size up an Exchange blueprint, check the last update date. Blueprints from 2022-2023 may not support newer features like input sections or template domains. Read the comment thread for known issues. Test on a non-critical automation first. Prefer blueprints that define every input with a selector, not raw YAML templates, for full UI support.

Anatomy of a Blueprint YAML File

Custom blueprints live in /config/blueprints/automation/. Script blueprints go in /config/blueprints/script/. Imported blueprints from the Exchange land in /config/blueprints/automation/homeassistant/. Don’t edit those by hand, since a re-import would clobber your changes. If you run a big HA setup, pair blueprints with Home Assistant’s package system . That keeps custom blueprints next to the scripts and helpers they need, all in one version-controlled folder.

A blueprint file has two main parts: the metadata block and the automation (or script) body. Here’s a stripped-down example:

blueprint:
  name: "Motion-Activated Light"
  description: "Turn on a light when motion is detected, turn off after timeout."
  domain: automation
  author: "Your Name"
  homeassistant:
    min_version: "2024.6.0"
  input:
    motion_sensor:
      name: "Motion Sensor"
      description: "The binary sensor that detects motion."
      selector:
        entity:
          domain: binary_sensor
          device_class: motion
    target_light:
      name: "Light"
      description: "The light to control."
      selector:
        entity:
          domain: light
    timeout:
      name: "Timeout"
      description: "Seconds to wait after motion stops before turning off."
      default: 300
      selector:
        number:
          min: 30
          max: 3600
          unit_of_measurement: seconds

trigger:
  - platform: state
    entity_id: !input motion_sensor
    to: "on"

action:
  - service: light.turn_on
    target:
      entity_id: !input target_light
  - wait_for_trigger:
      - platform: state
        entity_id: !input motion_sensor
        to: "off"
  - delay:
      seconds: !input timeout
  - service: light.turn_off
    target:
      entity_id: !input target_light

The key pieces:

The metadata block (blueprint:) holds name, description, and domain (automation, script, or template). It also takes optional author, optional homeassistant.min_version, and optional source_url (links back to the Exchange post for update tracking). Then come the input blocks.

Each input has a selector that shapes how it shows up in the UI. Common selector types:

Input sections (added in Home Assistant 2024.8) group related inputs under collapsible blocks using input: sections:. They help a lot on blueprints with many inputs:

blueprint:
  name: "Advanced Motion Light"
  domain: automation
  input:
    sections:
      required_settings:
        name: "Required Settings"
        input:
          motion_sensor:
            name: "Motion Sensor"
            selector:
              entity:
                domain: binary_sensor
                device_class: motion
          target_light:
            name: "Light"
            selector:
              entity:
                domain: light
      optional_settings:
        name: "Optional Settings"
        collapsed: true
        input:
          timeout:
            name: "Timeout"
            default: 300
            selector:
              number:
                min: 30
                max: 3600
          brightness_pct:
            name: "Brightness"
            default: 80
            selector:
              number:
                min: 1
                max: 100

To use inputs in the automation body, reference them with !input input_name anywhere in triggers, conditions, or actions. When a user builds an automation from this blueprint, each !input reference resolves to the value they picked.

Building a Production-Quality Motion Light Blueprint

Start from a working concrete automation. Write it for one room, test it, then pull the variable parts out into blueprint inputs. Here’s a more complete motion light blueprint that adds an ambient light check and time-of-day limits:

blueprint:
  name: "Motion Light with Ambient and Schedule"
  description: >
    Turns on a light when motion is detected, with optional ambient light
    threshold and time-of-day restrictions. Turns off after configurable timeout.
  domain: automation
  input:
    sections:
      required_settings:
        name: "Required"
        input:
          motion_sensor:
            name: "Motion Sensor"
            selector:
              entity:
                domain: binary_sensor
                device_class: motion
          target_light:
            name: "Light to Control"
            selector:
              entity:
                domain: light
      timing:
        name: "Timing"
        input:
          timeout:
            name: "Motion Timeout (seconds)"
            default: 300
            selector:
              number:
                min: 30
                max: 3600
                unit_of_measurement: seconds
          brightness_pct:
            name: "Brightness (%)"
            default: 80
            selector:
              number:
                min: 1
                max: 100
                unit_of_measurement: "%"
      optional_conditions:
        name: "Optional Conditions"
        collapsed: true
        input:
          ambient_light_sensor:
            name: "Ambient Light Sensor (optional)"
            default: []
            selector:
              entity:
                domain: sensor
                device_class: illuminance
          ambient_threshold:
            name: "Ambient Light Threshold (lux)"
            default: 20
            selector:
              number:
                min: 1
                max: 500
                unit_of_measurement: lux
          start_time:
            name: "Start Time (optional)"
            default: "00:00:00"
            selector:
              time: {}
          end_time:
            name: "End Time (optional)"
            default: "23:59:59"
            selector:
              time: {}

trigger:
  - platform: state
    entity_id: !input motion_sensor
    to: "on"

condition:
  - condition: time
    after: !input start_time
    before: !input end_time

action:
  - service: light.turn_on
    target:
      entity_id: !input target_light
    data:
      brightness_pct: !input brightness_pct
  - wait_for_trigger:
      - platform: state
        entity_id: !input motion_sensor
        to: "off"
  - delay:
      seconds: !input timeout
  - service: light.turn_off
    target:
      entity_id: !input target_light

To test it, spin up the blueprint for two different rooms from the UI. Check that changing inputs in one instance doesn’t touch the other. Try the edge case where motion fires again during the timeout. The wait_for_trigger should handle that by resetting the wait. Open the traces under Settings > Automations > [your automation] > Traces to walk through each step and see how inputs were resolved.

Advanced Patterns

Beyond simple entity swaps, blueprints support patterns that show up in the better community blueprints.

Multi-trigger blueprints use the id field on each trigger and check trigger.id in conditions or actions to tell which event fired. A hallway light blueprint might have one trigger for motion and another for a door opening, with a different brightness level for each.

Action selectors let the user define their own action sequence as a blueprint input. A “doorbell notification” blueprint can take an action input where the user wires up any alert: push, TTS, a chime, or a mix. Reference it with action: !input notification_action. The blueprint stays plug-and-play, and the author doesn’t have to guess every alert platform up front.

Target selectors (selector: target:) let users pick any mix of entities, devices, and areas. That’s more flexible than a single entity selector when the blueprint should hit a group, like “turn off all lights in the selected area.”

Template conditions with inputs blend Jinja2 templates with !input values for richer logic. For example, checking if an ambient light reading is below a user-picked threshold:

condition:
  - condition: template
    value_template: >
      {{ states(ambient_sensor) | float(0) < (threshold | float) }}

This lets the blueprint take user-set thresholds while still doing the comparison live.

Versioning is worth a thought for shared blueprints. Put a version number in the description or as a comment. When you ship an update, bump the version. Users who imported from the Exchange can re-import to pull the new one. Existing automations keep the old logic until the file is updated and automations reload. Home Assistant 2026.x added update alerts in the UI to make this smoother.

Debugging Blueprint-Generated Automations

Blueprint automations produce traces like any other automation. Go to Settings > Automations & Scenes, find the instance, and click Traces. The trace shows an interactive graph of the run: which trigger fired, which conditions passed or failed, which actions ran, and any errors. Expand a node to see the resolved input values, timestamps, and state changes.

Common debugging scenarios:

If the automation never fires, check the trigger entity in Developer Tools > States. Make sure the entity ID matches what you picked in the blueprint form. If the blueprint uses to: "on", check that your sensor actually moves to that state. Some sensors use detected instead.

If a condition blocks the run, expand the condition node in the trace. You’ll see the template or state check that was evaluated and whether it returned true or false. For time conditions, double-check your HA instance timezone.

If the timeout doesn’t work as expected, look at the wait_for_trigger plus delay pattern. If motion fires again during the delay, the automation may not restart based on the mode setting. Set mode: restart on the automation so a new trigger resets the countdown.

On speed, blueprint-built automations run just like hand-written ones. Home Assistant resolves the !input refs when the automation loads, not on every trigger. Fifty automations from one blueprint cost the same as fifty hand-written ones. The startup cost scales with the total number of automations, not the number of blueprints.

Migrating Existing Automations to Blueprints

If you already have five copy-pasted motion light automations, turning them into blueprint instances is simple:

1. Pick the most complete automation as your template
2. Spot which values differ between copies. Those become your blueprint inputs
3. Swap those values for !input references and add the matching input definitions
4. Save the file in /config/blueprints/automation/custom/
5. Build new automations from the blueprint, filling in the per-room values
6. Disable or delete the old standalone automations
7. Test each new instance by triggering it and checking the trace

You don’t have to migrate everything at once. Start with the most duplicated pattern, build the blueprint, and grow from there.

Blueprint Limitations

Blueprints shine for automations that share one shape with different parameters. They’re not the right tool for every job.

Blueprints can’t build triggers on the fly from inputs. You can’t say “create a trigger for each entity in this list.” The trigger shape is fixed in the blueprint. Only the entity IDs and values inside that shape are configurable.

Heavy branching that differs between copies also fits poorly. If room A needs three conditional branches and room B needs five different ones, jamming them into one blueprint gets tangled fast. Reach for Node-RED for visual flow programming, or write separate YAML automations.

Blueprints also can’t call other blueprints. There’s no composition or inheritance. Each blueprint is self-contained. If you find yourself wanting to nest blueprints, the use case has probably outgrown the model.

Finally, when you “take control” of a blueprint-built automation, you convert it to a standalone automation for hand editing, and you can’t convert it back. The link to the blueprint is broken for good. Be sure you need to break away before you do.