Home Assistant Automation YAML Generator

What this generator does

Writing automation YAML by hand is mostly a memory test: which key holds the trigger platform, where a duration goes, whether a list of conditions means AND or OR. This page turns the decisions into a form and prints the YAML those decisions describe:

• Builds the three blocks. Triggers, conditions and actions are added as rows and emitted in order, with the indentation Home Assistant expects.
• Writes valid scalars. State names such as"on" and "off" are quoted, numbers stay numbers, and templates go into a block scalar instead of a quoted one-liner.
• Nests conditions correctly. Two conditions with AND selected are wrapped in condition: and, because a bare list would be read as OR.
• Says what it built. Every generated automation comes back with a plain-English summary and a note per field you chose, so you can catch a wrong entity before you save it.
• Copies or downloads the result. Paste it intoautomations.yaml, or keep the file next to your backups.

How the blocks fit together

Triggers are OR-ed: any one of them fires the automation. Conditions are where the AND/OR choice lives, and actions are a queue — the next one starts when the previous one returns, unless you usemode: parallel.

Worked example

With the Zigbee plug preset loaded and everything else left at the defaults, the generator produces:

alias: Zigbee plug drawing too much power
description: Watches a Zigbee smart plug through a power sensor and warns when the load stays high.
mode: single
triggers:
  - trigger: numeric_state
    entity_id: sensor.living_room_plug_power
    above: 2000
    for:
      minutes: 5
conditions:
  - condition: state
    entity_id: person.owner
    state: home
actions:
  - action: notify.mobile_app_phone
    data:
      title: Plug overload
      message: The living room plug has been above 2000 W for five minutes.
  - action: switch.turn_off
    target:
      entity_id: switch.living_room_plug

In words: When sensor.living_room_plug_power goes above 2000 and stays there for 5 minutes — but only if person.owner is “home”, call notify.mobile_app_phone with 2 data fields, then call switch.turn_off on switch.living_room_plug. Thefor: block is what stops a one-second spike from firing the automation, and the notification action appears before the switch-off action because actions keep the order you gave them.

What the generator checks before it writes anything

• The alias is filled in, so the automation has a name in Settings → Automations.
• There is at least one trigger and at least one action — otherwise the automation could never fire or would do nothing.
• Entity IDs look like domain.object_id in lower case; a value with spaces or capitals is flagged instead of being pasted in broken.
• Numeric thresholds are numbers, and durations are whole seconds, minutes, hours or days.
• Clock times are HH:MM or HH:MM:SS, and time patterns are a number, * or /N.
• Service names look like domain.service, and mode: queued or parallel comes with a max.
• Nothing here reaches your instance: entity IDs, services and thresholds still have to exist in your Home Assistant.

These are syntax and shape checks, not a validator for your home. Whether sensor.living_room_plug_power exists, and whether the service you named accepts the data you gave it, can only be answered by your own instance.

Limitations

• Nothing is tested against a live instance. The page wrote YAML from your selections. Rename every placeholder entity ID, and reload the automation through Developer tools → YAML before you rely on it.
• Modern keys need Home Assistant 2024.10 or newer.The classic option (trigger:, platform:,service:) is accepted by every release that reads YAML automations.
• A limited trigger and action set. Seven trigger types, five condition types and four action types are covered — no device triggers, no blueprints, no choose: orrepeat: blocks. Nested logic is a hand edit away in a text editor.
• No scripting beyond services. Named scripts, scenes and helpers are referenced by name and are not created for you.
• Comments are plain text. When you ask for explanatory comments, they are added as # lines that Home Assistant ignores; they are a reading aid, not documentation that survives a UI edit.
• Everything stays in the page. No upload, no storage, no analytics event carrying your entity IDs. Close the tab and the draft is gone.

FAQ

Is my automation uploaded anywhere?

No. The form is read by JavaScript in this page and the YAML is assembled in memory. There is no upload, no account and no request to any server, so your entity IDs and thresholds stay on your device. You can load the page, generate an automation, then disconnect from the internet and the result is identical.

Should I choose modern or classic YAML keys?

Modern keys write triggers, conditions and actions with a trigger key on each trigger and an action key with a target block. They need Home Assistant 2024.10 or newer. Classic keys (trigger, condition, action, platform and service) are accepted by every release that reads YAML automations, so pick classic if your instance is older or if you are following a tutorial written before 2024.

Why did it wrap my conditions in condition: and?

Because a plain list of conditions in Home Assistant is read as OR. When you have two or more conditions and AND is selected, the generator nests them under condition: and so the YAML says what you meant. Choose OR and the conditions stay flat, which is the same thing to Home Assistant and easier to read.

Will this YAML work with my entity IDs?

Only after you rename them. The generator writes exactly the entity IDs you typed and never contacts your instance, so it cannot know whether sensor.living_room_plug_power exists in your home. The examples are placeholders drawn from a Zigbee setup; copy real IDs from Developer tools → States, then reload the YAML through Developer tools → YAML before you rely on the automation.

Where do I put the generated YAML?

Either paste it under the automations: key of configuration.yaml, or add it to automations.yaml when you edit that file directly. If you use the automation editor in YAML mode, the entry can go in as a single list item. Check the configuration before restarting, and remember that a UI edit will rewrite comments the generator added.

Does it cover blueprints, choose blocks or device triggers?

No. It covers seven trigger types, five condition types and four action types — service calls, delays, wait_template and stop — which is the shape of most hand-written automations. Anything past that, such as choose, repeat, blueprints or device triggers, is a hand edit in a text editor afterwards.