WTH can't integrations ship a set of blueprints?

There are lots of Blueprints that are useful for one specific integration. Eg. leveraging it’s more complex services or events.

Integration authors should be able to bundle selected blueprints with their integration so users already have a set of most useful tools when they installed the integration.

This would be awesome! But… it does require solving an different issue first: being able to provide upgrades for blueprints.

Otherwise integrations could never ship an update/change in the code.



As someone who likes the logical challenge of finding the best way to write my own automations I would be against the forced bloat of included blueprints that I would never use. Though I do acknowledge it would benefit a lot of people. So I just hope it would be an optional bundle.


Oh, is there no upgrade path for blueprints? That’s unfortunate.
The easy way would be to just provide links to files in a HA-blueprint repo. Once used the current version would be loaded. So some kind of blueprint-suggestions. But I guess it would be better solved with a proper upgrade path.

As for bloat: there are litterally over thousand integrations, and their code, shipped with a Core installation that I’m never going to use. If the shipped blueprints are only loaded when the integration is in use, and are in a separated in UI it should not be a problem. Its only couple of lines yaml / links anyway.

I have around 100 integrations used at this point and I never used any blueprints + deleted sample ones. So as a optional download, sure, but as mandatory, definitely no.


I personally wouldn’t like that, however as mentioned earlier it would be nice if the blueprints were featured on the integration’s page on home assistant. That would be an easy way to get going with a new integration.
And maybe updates could be handled by the new repairs page - “your blueprint is out of date. You should see if you need to update it…”

I was imagining something like it would install the blueprints along with the integration. So you saw the ones for the integrations you used but not for the many that you don’t.

I also like writing my own automations but I still think this would be handy. Idk if I’d actually use them but I’d look them over to get ideas for stuff I hadn’t thought of.

1 Like

I like the idea of adding them to the docs utilizing the existing method of adding a blueprint, because you do read the docs when adding an integration right :wink:

Or they could be linked like the documentation / issues are from the integration screen by just adding a Get blueprints link, which would pull in the default blueprints for that integration.

That way they could be updated / added etc. in the background, new users would get the latest version and there is no bloat added to the actual install.

1 Like

For me this feature should work like this:

  • Go to the device window
  • Click on “search blueprints”
  • Shows you the different compatible plans in two categories
    • By device type
    • Specific for integration

Thus, for example, there could be generic blueprints such as turning on the lights with any motion sensor, and specific blueprints such as performing actions with Xiaomi’s magic cube.

They are not installed by defaults, it simply allows you to quickly search for compatible blueprints.


They can be added to docs, nobody does :man_shrugging:


Documentation of eg. Knx is >1,8k lines raw markdown. Nobody would find it :face_with_monocle: even if anyone would ever try to read docs before posting in the forums :sob:

1 Like

How should they be added to docs?
You mean like this in zha-toolkit? If so, then I must be nobody*!

*Hence the joke: “My name is nobody. Nobody is perfect.”

+1 for shipping Blueprints with the Zigbee/ZHA integration for devices that need it to work out-of-the-box, like for example the Zigbee remote/switch controllers from the “Awesome HA Blueprint” repo:


I think this is a great idea for improving the Home Assistant UX.

Frenck’s answer also points out a number of the shortcoming with the current blueprint implementation that are in need of some attention like versioning, how to tell if a newer version exists, and finally as Frenck points out, what’s the upgrade process.