Thanks for the tip… you’ve found another place where I misunderstood the functionality based on the HA name. To me a “Blueprint” sounded like a “plan from which to build something”, in other words, I figured making a blueprint of an automation I wanted to repeat would help me with the “making multiple copies of this automation”, but I didn’t think it would work for handling the “making changes to the logic later”, which is why I went with Scripts, because to me those mean “reusable code snippets which can be called with dynamic parameters”.
Now that I understand that automations built using a blueprint aren’t just individual independent copies “based on the Blueprint at the time they are built”, but actual connected instances “inheriting from the Blueprint”, I’ll probably rework my logic into a Blueprint.
FWIW, “Blueprint” is a terrible name for this functionality. “Automation Template” would have been perfect, but I guess since the word “Template” was already being used to confusingly describe a computed value, here we are.
EDIT: And I can see why I was confused… even the Documentation for Blueprints makes it sound like they’re basically an “accelerator” to getting an automation set up with the same steps, not a common centralized automation definition that all instances of it will share.
Imagine you want to control lights based on motion. A blueprint provides the generic automation framework, while letting you select one specific motion sensor as a trigger, and the exact light to control. This blueprint makes it possible to create two automations. Each automation has their own configuration and act completely independently. Yet, they share some basic automation configuration so that you do not have to set this up every time.
I guess it’s time to figure out how to contribute edits to the documentation…
Good luck with this. I tried several times and never anything I added was accepted. Most of the time I was told that I had added to much or the example wasn’t needed. I was taught in an earlier life, that if the target reader can’t follow the document then the document is inadequate. Not that the reader of the document was. Most of the documents in HA (in my opinion) assumes way too much knowledge.
the level of required knowledge is mixed between neighborhood sentences.
Another issue I see is, that documentation is not well organized for newcomers. I found it closer to reference documentation, rather than user documentation.
And as reference one is very inconsistent in level of details.
From a new user perspective, there is no top-down structure, allowing to easily comprehend the architecture or structure of HA and its dependencies.
Let me give you a great example of what I mention. The main page of HA documentation. The first subject the reader can see is “Automation”. Second are dashboards and 3rd are Voice assistants. Two pretty advanced topics on the very top.
Maybe I opened the wrong page. But this is what Google proposed to me on “Home Assistant documentation” query
I don’t think it has ever been or ever will be a user manual where you can go from step 1.
That kind of documentation will be way to hard to build since each installation and devices will be different.
And even if it’s done then everything will need to be looked through on each release.
Now “only” the updated integrations need an update.
That’s been commented on quite a few times, not just here, and I know I’ve banged on about it to Missy (most recently, many others before this). They’re (well) aware of this, but it’s just one of a great many things on the list so I don’t know when it’ll get addressed.
Yeah, amen to that! It’s probably hard to find a worse combo than YAML/Jinja/{%%}. Maybe some esoteric programming languages like Befunge or Brainf*** could top that.
[*** It seems you can’t write the full name of Brainf*** without being caught by some automatic censorship algorithm.]
