What advantage does this (an automation with a blueprint) have implemented as a blueprint versus a traditional standalone automation?
If it were an automation, I just need to copy-paste it. Seems like that’s the same procedure for installing a blueprint, only less text is involved in the transaction.
Is that a blueprint’s advantage?
Everyone on Discord Beta is very excited about blueprints but I haven’t seen the light yet.
I don’t think it’s aimed at people with lots of experience writing automations. More for the newbs to get something up and running quickly.
I was quite looking forward to blueprints as I have a number of automations for lights on and off (all with different delays/colours depending on time, whether it’s dark and where the light is in the house) which currently is most efficient as one automation for each.
With blueprints I’ll be able to to define one blueprint and then reduce all the other automations to feeding it the light, colour, and delay template - which is a massive improvement.
I think it’s a shame that it’s already being diluted heavily. I’ve only seen 3 posted so far, and in 66% of them they are basically only any use replacing a single automation, which seems a bit pointless 
Maybe when this feature is actually released to the rest of us we’ll see some better examples of blueprints that will actually fulfil their purpose.
Thank you for adding the add-on links @tom_l, I was thinking about including these add-ons (some of them already has the auto snapshot creation feature), but I think a one for all solution would be very complicated and users usually need only one of them. So my idea was to create this, for now, maybe it can be useful for some users as it is currently.
Don’t be disappointed, this feature isn’t even released yet, and I’m still trying to figure out some things about Blueprints. People have to learn it first to come up with more complex blueprints, so give it a bit more time (you have only seen 3), and don’t expect world changing blueprints immadietly.
Also, I don’t think replacing a single automation is a bad idea, they can be convenient to newcomers.
If you copy-paste an automation, you will have to manually replace entites/device names to your ones so you have to look up the exact names. With blueprints, you can easily select them with selectors. For example, if the blueprint has an area selector, you will only see entites/devices that are in that area, and can easily select the one(s) that you want.
An other feature (which is not implemented yet), is the ability to update blueprints, based on the source url.
So a blueprint allows the automation’s designer to create a UI for selecting entities. This serves as a convenience for a user to adapt the automation to their environment (i.e. select entities that they have as opposed to editing the one’s the automation contains).
Effectively, a blueprint makes an automation into a black-box. The user only needs to adjust its inputs via a UI (without seeing/editing the automation’s internals).
I was going to ask mf_social “How do you create multiple different automations from one blueprint’s UI?” but I think you answered the question (that functionality doesn’t exist yet).
Thanks for the explanation. For the moment, I can’t see myself creating blueprints for my own usage (at least not the first incarnation of blueprints). It is geared towards distributing an automation to others, assuming the author doesn’t mind the additional work of creating the “blueprint” portion.
The future ability to update blueprints is interesting. That can be a double-edged sword (re: auto-updates) so I look forward to seeing how it will be implemented.
@123 this is actually available, you can click “Create automation” on the Blueprints dashboard multiple times, or when you add a new Automation on the Automations Dashboard, a Blueprint can be selected.
By saying “this feature isn’t even released yet” I meant that Blueprints are still in beta, and will be released in Home Assistant 1.0
My mistake; thanks for the clarification.
I don’t have a need to generate multiple, nearly identical automations for my own system but I see mf_social has an application for this capability. I honestly can’t think of a use for blueprints (for my personal use) but that might change after I experiment with them in the near future.
I still prefer using yaml rather than the UI to write automations, so it has little use for me.
I think this is targeted at experienced users who wish to distribute their automations to less experienced users. As I see it:
If you can compose an automation for your own use, you have less need to create a UI for it. If you need to modify the automation, well, you created it so you know how to edit it without the aid of a custom UI. I’m not saying you would never create a blueprint for your own use but (in my opinion) there’s less need for it.
If you can’t (for whatever reason) compose an automation, and simply want to use someone else’s (in the manner of a black-box) then you’ll benefit from having a UI to customize it for your environment. Instead of manually editing and replacing sensor.your_whatever with sensor.my_hallway_motion, you can select it from a dropdown via a UI (generated by the blueprint).
Of course, all this depends on the kindness of strangers willing to put the extra effort of creating blueprints for the automations they wish to share.
If blueprints are a convenience targeted for new users, would there be any value for the forum admins to add a “Copy this blueprint” button to forum topics tagged with ‘blueprint’? In other words, something to make it even easier for a new user to get the blueprint from the forum into Home Assistant?
Maybe a wilder idea would be to display all “blueprint” topics as a list within Home Assistant itself (Configuration > Blueprints). Click the topic’s “Get this blueprint” button and it is automatically added to Home Assistant (no need for copy/pasting URLs).
This discussion could have saved a lot of time from everyone involved if people took the time to either try the beta or at least read the blueprint documentation on the beta website: https://rc.home-assistant.io/docs/blueprint/ . I especially recommend the tutorial as it builds up the different aspects nicely.
Here is a very quick gist so you can help correct misconceptions when you see them in the forums:
!input placeholder that will be replaced at runtime, including a whole action block etc.action: in a blueprint, just write your own in the automation config.Here is a bare minimum blueprint you could store in <config>/blueprints/automation/example.yaml:
blueprint:
name: "Example BP"
domain: automation
input:
trigger_event:
action:
trigger:
platform: event
event_type: !input trigger_event
action: !input action
And an automation that uses it:
automation:
- use_blueprint:
path: example.yaml
input:
trigger_event: state_changed
action:
service: light.turn_on
entity_id: light.kitchen
If someone on this forum asks how to automate something I’d prefer to explain how the automation works with a yaml example rather than saying “here download and fill out this blueprint”. They will never learn anything that way and will have to be spoonfed a blueprint by someone else every time they want to do something.
It’s really unfortunate I can only give you one like per post… 
I can definitely see the benefits of this. I have quite some automations which have a high degree of similarity, or are even the same (e.g. for motion based lights with timers).
If I want to change the way it works now, I have to modify all the automations. With this, I would only have to change the blueprint.
I like it, no more copy/paste errors when changing entity ids !
Likewise. As I said earlier I think it’s going to be really powerful, I just think that the examples posted so far don’t do it justice.
As for
if people took the time to either try the beta…
Some of us don’t have the extra time for managing a second instance or handling potential breakages. It’s not our ‘fault’ that examples of as-yet-unreleased features are already appearing on the forums and we’re trying to make sense of it 
There’s a difference between trying to make sense of it and offering up suggestions. Suggestions for how it behaves, functions, how blueprints are imported…those would have been far more useful and would have more impact during beta.
Blueprints are shared via YAML code blocks inside forum posts just like typical automations, so they can still be explained exactly the same way as before. There’s also a blueprint description and each individual input can have a description too, so you can literally explain every step of the process.
And the user importing the blueprint can view the complete YAML before, during, and after import if they wish to learn how things work. Blueprints get stored in /config/blueprints/<filename>.yaml so they’re easily accessible and editable - they aren’t obfuscated in the hidden .storage folder like some might be thinking.
I’m fairly confident that Blueprints will teach people more about YAML-based automations than anything else before. By making it so easy to import and configure them, users of all skill levels are able to use and benefit from advanced automations, and then easily peek under the hood to learn how it was done and pick up some new tricks.
Everyone should try to keep an open mind until it’s officially revealed at the conference, it’s super cool and powerful stuff 