Home Assistant Blueprints: The Best Blueprint Collections and Hardware Compared (2026 Guide)

Home Assistant blueprints are the closest thing the platform has to an app store for automations. A blueprint is a pre-written automation with the specifics left blank: you import it, fill in a short form naming your own sensors and lights, and Home Assistant builds a working automation inside your configuration — no YAML indentation to get wrong, no triggers and conditions written from scratch. They solve Home Assistant’s steepest learning curve, which is why the community treats them as the standard first step for newcomers who want motion lighting, appliance notifications or bin-day reminders working tonight rather than next weekend. This guide compares the blueprint sources worth using in 2026, explains how to tell a maintained blueprint from an abandoned one, and covers the hardware that suits a blueprint-heavy setup.

Sourcing: this guide is built from the official Home Assistant Blueprints documentation at home-assistant.io, the Home Assistant Community Forum’s Blueprint Exchange, aggregated discussion on r/homeassistant, and EPMatt’s Awesome HA Blueprints repository on GitHub, plus manufacturer specifications for the hardware. Nothing here is based on hands-on lab testing or a reviewer’s test bench.

Quick picks

The fastest route for most people is Home Assistant Green plus a Zigbee radio if their sensors need one, then pull blueprints from Awesome HA Blueprints and the Community Exchange.

What is a Home Assistant blueprint?

A blueprint is an automation with the logic pre-written and the specifics left blank. Instead of assembling a trigger, a condition and an action block by hand, you import the blueprint and Home Assistant generates a form asking which motion sensor, which light, which brightness and which delay you want. What you end up with is an ordinary automation living in your own configuration — it has simply inherited its structure from someone else’s work.

The official documentation describes them as “automation templates with a set of inputs”, and that framing is accurate: the blueprint itself does nothing until you instantiate it. Blueprints arrived in late 2020, in the Home Assistant 2020.12 release, and have been the default on-ramp to automations ever since.

For standard inputs, no YAML is required at all — the form does the work. That’s not a universal guarantee: template-based blueprints, or those using nested selectors, may still require you to supply YAML for some fields. Check the blueprint’s own documentation rather than assuming every field will be a dropdown.

How blueprints differ from plain YAML automations

The practical differences matter when you’re deciding what to install:

• No code editing. Inputs are defined by the blueprint author and rendered as a UI form.
• Reusability. One blueprint can generate twenty automations across twenty rooms, each with its own entities.
• Portability. A blueprint URL can be shared, and anyone can import it through the My Home Assistant link.
• Shared maintenance. A widely used blueprint attracts bug reports and fixes far faster than a personal YAML file nobody else reads.

The trade-off is control. A blueprint exposes only the inputs its author chose to expose. If you want a condition the author never anticipated, you either fork the blueprint or convert the automation to YAML and edit it by hand — and once converted, it no longer follows the blueprint.

What a blueprint can’t do

Blueprints cannot add integrations, install Lovelace cards, or manage your Zigbee network. They are automation logic only. If a blueprint assumes a sensor exposes illuminance, power draw or battery level, that sensor has to exist in your instance first — which is why the hardware section below matters as much as the blueprint source you pick.

How to import a Home Assistant blueprint

The import path in the UI is Settings → Automations & Scenes → Blueprints → Import Blueprint. Paste the blueprint’s URL into the box, and Home Assistant validates the file before adding it.

The shareable link format many blueprint threads use is https://my.home-assistant.io/redirect/blueprint_import/?blueprint_url= followed by the raw URL of the blueprint file itself. The My Home Assistant redirect is what makes a blueprint shareable as a single click from a forum post: it hands the raw URL to your own instance rather than to a web page.

If validation fails, Home Assistant shows an inline error rather than importing a broken file. The most common cause is a mismatched blueprint: schema version — the blueprint was written for a different Home Assistant core version than the one you’re running. The step-by-step reference lives in the Home Assistant Blueprints docs.

The best Home Assistant blueprint sources in 2026

Community feedback consistently splits blueprint sources into two camps: curated libraries with review standards, and open exchanges where quality varies enormously. Both are useful, but for different reasons.

How to compare them: the four columns that matter

Whatever source you use, four data points do most of the work in telling a live blueprint from a dead one:

• Import/download count. A high count means many people are running the same logic. More users means more bug reports, and bug reports are what get blueprints fixed. A count of a handful is a warning sign, not a disqualification.
• Last updated. A blueprint untouched for years still works if Home Assistant hasn’t changed the services it calls — but an actively updated one is far more likely to survive the next core release.
• Minimum HA version. Blueprint YAML declares the core version it needs. Check it against your own version before importing, or you’ll meet the schema-version error described above.
• Moderated? Yes or No. Curated libraries have someone other than the author looking at submissions. Open exchanges do not, which is not a criticism so much as a description: you are the reviewer.

Awesome HA Blueprints (EPMatt, GitHub)

Awesome HA Blueprints is the standout curated option, and its verifiable differentiator is architectural rather than cosmetic: it uses a hook/controller pairing design, where a thin hook automation chains into a central controller rather than every automation carrying its own version of the logic. In practice that means one place to update when something changes, instead of twelve automations each holding their own copy. Being moderated, it also filters submissions before publication. Best for anyone who wants a small, dependable set of blueprints rather than a firehose. Caveat: a curated library is by definition narrower than an open exchange, so niche use cases may simply not be there yet. Verdict: start here, then widen your search if your use case is missing.

Home Assistant Community Blueprint Exchange

The Blueprint Exchange is an official forum category, unmoderated and searchable by tag. That combination makes it the widest pool of blueprints anywhere — thousands of imports are recorded across the threads — and the best place to find the odd, specific thing you actually need, from appliance notifications to presence logic. Best for buyers who know exactly what they want and are willing to do the vetting themselves. Caveat: because nothing is checked before publication, the four columns above are not optional reading. Verdict: the widest choice on the platform, with the widest quality range too.

SmartHomeJunkie

SmartHomeJunkie is worth naming for a different reason: it is a tutorial site that also publishes blueprints, not a blueprint library. Its value is the explanation wrapped around the code — you get the walkthrough and the importable file from the same page, which suits anyone still learning what the inputs do. Best for beginners who’d rather understand the automation than simply install it. Caveat: it is not a searchable library, so don’t treat it as a catalogue. Verdict: a teaching resource first, a source second.

Six named blueprints to start with

These six are the recurring names in community recommendations, spanning lighting, notifications, appliances and reminders.

Motion-activated Light is the archetypal community blueprint — the one that turns a hallway or utility-room sensor into an automation rather than a project. As the name implies, you supply the motion sensor and the light entities, and the blueprint handles the trigger and the switch-off logic. Best for a first automation, because the form is short enough to fill in during a coffee break. Standout strength: it’s the most widely discussed lighting blueprint on the Exchange, so other people’s experience is easy to find when something behaves unexpectedly. Caveat: because so many lighting blueprints overlap, it’s generally wise to pick one approach per light rather than layering several on the same fixture. Verdict: the sensible first import.

Adaptive Lighting (basnijholt, GitHub) is the opposite end of the lighting spectrum: rather than switching a light on at fixed moments, it aims to keep brightness and colour temperature in step with the time of day. Best for whole-home lighting you want to feel natural without writing schedules. Standout strength: it lives on GitHub with public versioning, so download figures and commit dates let you judge maintenance at a glance — the clearest of any option here. Caveat: it’s a bigger piece of logic than a simple trigger, so read the repository’s own notes and confirm the declared minimum HA version before you rely on it across the house. Verdict: the one to choose when lighting quality matters more than setup speed.

Sensor Light sits in the same Lighting category as Motion-activated Light but is the more input-heavy option, aimed at people who want to tune behaviour rather than accept one behaviour. Best for users who have already run a simple sensor automation and want more control over it. Standout strength: it occupies the middle ground between a one-screen form and a full GitHub project. Caveat: more inputs means more to misconfigure, and a longer form to work through — start with one room, not eight. Verdict: the step up once the basics work.

Z2M Device Availability Alert covers notifications, and it’s aimed specifically at Zigbee users running Zigbee2MQTT — Z2M being the common shorthand for that software. Best for anyone who wants to know when a sensor quietly drops off the network, which is otherwise the kind of failure you notice weeks later when a light stops responding. Standout strength: it addresses a real blind spot in Zigbee setups, where a device can go unreachable without announcing itself. Caveat: it assumes Zigbee2MQTT is already installed and publishing availability information, because blueprints cannot manage Zigbee themselves. Verdict: essential housekeeping for a Z2M household.

Washing Machine Finished is the appliance-notification blueprint — the one that tells you the cycle is done instead of leaving you to check the drum. Best for anyone who has already smartened up the laundry area and wants the notification rather than another app to open. Standout strength: it’s a small, single-purpose automation, which makes it a good demonstration of what a blueprint does well. Caveat: the blueprint only supplies the logic. Something in your instance has to be able to tell Home Assistant the cycle has ended, so sort that sensor out first. Verdict: a tidy, low-risk first appliance automation.

Trash Collection Reminder does the same job for bin day. Best for houses where collection day moves around because of bank holidays. Standout strength: reminders are the purest example of a blueprint paying for itself — the automation is trivial, remembering to write it is not. Caveat: as with the washing machine blueprint, the collection schedule has to exist in your instance somewhere Home Assistant can read it; the blueprint cannot know your council’s calendar. Verdict: five minutes of setup, permanent benefit.

Practical limits and gotchas

Blueprints cannot add integrations, install Lovelace cards, or manage Zigbee devices — that’s the ceiling on what any of the six above can do for you. Everything they reference has to exist already.

The bigger long-term risk is what the community calls orphan risk. If the source blueprint is deleted, or broken by a Home Assistant update, the automations you derived from it keep running — but they lose their blueprint linkage. You’re left with working automations that no longer receive the author’s fixes and no longer show a form when you open them. Community forum threads on the subject are consistent on the practical consequence: nothing breaks immediately, but your maintenance story gets worse. The habit that avoids it is checking the last-update date before you commit, which is exactly what the four comparison columns are for.

Before you import: reading the YAML

A blueprint is third-party automation logic that executes services already configured on your instance. It cannot grant itself new permissions, but it can call what you’ve already connected — which is why the recurring community recommendation is blunt: read the YAML before importing. Blueprint files are plain text, and the trigger, condition and action blocks are short enough to scan in a minute or two. Guidance on this comes from the Home Assistant community forum rather than from any vendor. Preferring moderated sources such as Awesome HA Blueprints reduces the workload; it doesn’t remove the practice.

Hardware to run a blueprint-heavy setup

Home Assistant Green is the straightforward option: it arrives pre-flashed with Home Assistant OS, so the instance is running before you think about blueprints at all. It draws approximately 8–10 W according to the manufacturer’s specification, which is low enough to leave on continuously without thinking about it. Home Assistant Green is typically around £99 at UK stockists including Pimoroni and The Pi Hut — check stock, as availability moves through 2026. Its real advantage is official Nabu Casa support, not any blueprint-specific feature: blueprints behave identically on any properly configured instance, so the hub choice is about how much maintenance you want to do yourself.

Home Assistant Yellow is the alternative for Zigbee- and Thread-heavy setups, because the built-in radio means those devices don’t need a separate coordinator. A PoE variant exists. Availability, however, is the catch: Yellow has been supply-constrained as of 2026, so verify current stock at nabu.casa or Pimoroni before recommending it to anyone. Where it is in stock, expect it to land somewhere around £140–£220 depending on variant. If it isn’t available, Green covers the same blueprint workload — the radio is the only meaningful difference for this use case.

FAQ

Do Home Assistant blueprints need HACS? No. HACS exists to install custom integrations and Lovelace cards, and blueprints can’t install either of those anyway — they’re automation logic. A blueprint goes into your configuration’s blueprints folder and is imported through Settings, with no third-party store involved.

What happens when a blueprint is updated? Home Assistant generally applies the blueprint author’s updated logic to the automations you created from it, while keeping the inputs you chose. Behaviour changes, then, can appear without you editing anything. If a widely used blueprint is about to change in a breaking way, the author usually flags it on the source thread — worth watching if you rely on the automation daily.

Can blueprint-derived automations be edited? You can always change the inputs through the form, but the underlying logic isn’t editable while the automation remains linked to the blueprint. The escape hatch is converting the automation to YAML and editing it manually; after that it behaves like any hand-written automation and stops following blueprint updates.

Do blueprints work on HA OS, Container and Core? Yes — blueprint support is a core feature, not a function of the installation type, so OS, Container and Core installs all handle them the same way. What differs between installations is the set of integrations and entities available, and a blueprint can only use what you’ve already set up.

Why did my blueprint break after a Home Assistant update? Two usual causes: a blueprint: schema version mismatch, which shows up as an inline error at import, or a change to the services and entities the blueprint calls. If the automation still runs but its blueprint linkage is gone, you’ve hit the orphan scenario described above — the derived automations survive, the connection to the author doesn’t.

Are blueprints safe to import? They can’t add integrations or escalate their own access, so the realistic risk is a blueprint calling services you’ve already exposed in a way you didn’t intend. Read the YAML before importing, prefer moderated sources, and check that the thread is active. That combination is the community’s standard advice, and it’s sound.