I just discovered another way of adding automations created by others to HA, packages. Packages seem to be a much better option as entities like helpers, sensors and scripts are created within the package rather than beings added by the user.
A search of the forums suggests there isn’t to many packages available. Curious to know why blueprints rather than packages have become, what appears to be, the norm?
Packages are for YAML entities. Not sure it even works for automations, but as YAML is slowly going away, so are packages, I guess.
Blueprints are automation templates.
Basically 2 totally different things…
I’ve heard this a lot. I, for one, would not be sad to see it leave.
That said, is it truly going away, or is it just that more and more functionality is being added to the UI, reducing the times a beginner would need to drill down to the YAML that the UI creates behind the scenes?
It seems like many things (automations, templates, etc.) either can’t be done in the UI, or there are so many options which the UI doesn’t support that it’s impractical. If not YAML, then what will be used to store all the complex parameters we’re currently (and in my case, painfully) using YAML for?
More or less that.
YAML is not “officially” deprecated, but the fact that you cannot change the interface of a YAML integration anymore, I take it as a “sneaky” depreciation 
Migrating the configuration of certain integrations from YAML to UI (“config flow”) is an architectural decision documented in ADR-010, almost two years ago. It was also announced in a much debated forum topic around the same time; users made dire predictions about YAML’s demise and, two years later, none have come true.
Blueprints don’t have much in common with packages. They’re designed to generate automations based on the user selecting options via the UI. Packages don’t do that but do offer more flexibility to provide a complete application encompassing a broader range of components. Blueprints were also designed to be easier to share compared to packages.
In theory, blueprints could be enhanced to provide all the functionality of packages (with greater convenience) but that depends on someone volunteering to implement it.
Well, yes, and the same ADR says “Changes to existing YAML configuration for these same existing integrations, will no longer be accepted”, which, practically and from experience means “move to UI or stop evolving”.
That’s what I mean by “sneaky”.
Packages were first long before blueprints cam along. I’ve used them forever. And I’ve never used a blueprint at all.
I doubt yaml will ever completely go away and I am one of the ones that would find doing everything thru the UI more than tedious (point-click-scroll-click, point-click-scroll-click, etc., etc., ad nauseum…).
And limiting…there is a reason why you don’t have an exclusively point-click-scroll-click word processor program. It’s way faster to just type it out (I have nothing against auto-complete tho. I’m not a total Luddite. 
)
Blueprints are made for one function - create an automation or scene with only the options provided in the blueprint. no more/no less.
If you need additional/less options then you need to manually edit the blueprint…which is written in…you guessed it…YAML.
Blueprints are OK if you have no idea what you are doing and only want to do exactly the same thing as the blueprint allows but they are completely limited beyond that unless you know how to edit them…in yaml. And have you actually LOOKED inside a blueprint to see all of the stuff that’s in there in order to “make it easy” for the next person to use? I understand yaml and even I fear to tread in there myself at times. And those are usually the simple blueprints. Bigger ones are just… 
The only thing that is officially “going away” in yaml are some built-in integrations.
For everything else yaml is likely here to stay because of those inherent UI limitations. And we are starting to see some of those limitations even in some integrations configured thru the UI. I think there were some options that were available in the yaml config and weren’t implemented in the UI because they were too complex to accomplish. But I can’t remember where I saw that tho so take that as hearsay.
I think you are mistaken.
the user still needs to manually create all of those things. the advantage to packages (as has been pointed out) is that all of the various bits for a logical “function” are all stored in the same location instead of you needing to open many different files to find all the related stuff.
Becauise packages are inherently non-singular use things. You can literally do anything you want in the package (that is supported by the HA infrastructure of course).
need 3 helpers, 2 switches, 15 sensors, 4 automations and 5 scenes? done…by you…in yaml.
it really only depends on how you want you HA structured.
Your points are well spoken. I agree with most. Like yourself, I find it easier to type several commands then to “point-n-click” my way to success. I’ll admit to using the UI editor but only when I can’t figure out how to write the appropriate yaml code.
I don’t think I am. I just installed a package that created two scripts and three helpers without my intervention. On the contrary, I’ve added several blueprints that, prior to being used, required creation of helpers and in one instance a LoveLace card.
I also find blueprints daunting! I’ve had problems with a few; those that don’t function as authors describes and those failing under certain situations as the designer failed to test all possible conditions prior to posting. I’ve also found it hard to keep installed blueprints updated. Seems the only way to update is to delete the previous version then D/L the new version. I’ve also noticed a few revised blueprints with completely change structures. A nightmare to reconfigure.
If blueprints are the direction HA is heading then some form of integrity check, versioning and cataloging needs to be added to the repository. Unlike HACS, which checks for updates then let’s me know, I find it very difficult to keep abreast of changes without searching through the Blueprints forum and reading tons of messages to see if there’s been changes.
It doesn’t seem furtive to me but quite overt; YAML was excluded as a means of configuring a fairly broad range (but not all) integrations.
The missing piece at the time (and arguably remains a deficiency) are UI widgets to make the configuration process less onerous (compared to YAML). Fortunately, the recent addition of number and select can help mitigate it (but a multi-select is still missing).
I agree YAML will play a smaller role going forward but I also agree with finity that it’s not likely to disappear because it remains well-suited for certain purposes.
Anyone wishing for YAML’s complete demise should contemplate the challenges this can cause (example: Hubitat). Got a problem with an automation? Be prepared to post long-winded screenshots of it because there’s no text-based method of sharing what you have created. Imagine having to input someone’s automation or Template Sensor this way (ugh).
Anyway, whatever our opinion on YAML, I’m pretty sure we can agree packages do not have a future…
Nope I don’t agree at all.
As a matter of fact the new “modern” style templates were recently modified so that they could be added to packages as well.
If packages were on the way out there is no way any developer would waste time on that modification just to have it soon be moot.
There is no way to “install” a package.
Where did the package you “installed” come from? Do you have a link?
If you mean you copied and pasted someone else’s complete yaml package into your config then yes, whatever was in the package will be created in your system.
That didn’t seem to be what you were describing. There is no “automatic creation” of those things aside from what someone coded into the package contents.
Sorry if I misunderstood what you were saying.
Not saying there are going away, just that, as less and less integrations will be configured in YAML, their usefulness as a way to manage those YAML will dwindle on its own…
Copy and paste or install? Isn’t this a matter of semantics!
Detail regarding the package I installed (or copied and pasted) is found in a message posted at Furnace Filer Life Sensor. Code for the package itself is found at https://github.com/Tediore/Furnace-filter-life-sensor-0.96-and-newer
Perhaps I used the wrong word here. Unlike some of the blueprints I’ve installed where there was a need for me to create a helper or add a script before the blueprint would function, the package code creates these things for me.
Regards, Robert
agreed.
Sorry again for misunderstanding.
I think package sharing is more of a convenience to show others what is possible and to be used as a starting point instead of them being a fully functional solution (tho obviously they can that too). I share my nws alerts package on github for that same reason.
I guess they could have been used like blueprints except the devs never fully promoted packages like they did blueprints. And I think that was because the “target audience” is totally different.
Another great use for packages is splitting up your configuration to make it much more readable and easy to deal with. Having started with HA long before there was UI editing, all of my config is YAML. I couldn’t function without this 
Integrations. Only integrations. I’m a stubborn YAML’er too. I don’t have a single script or automation done with the UI. That capability isn’t going anywhere.
Any integrations in the UI is actually pretty cool if they are written with async and all that fun stuff because they can be added/deleted/disabled and reloaded on the fly. For most people it only takes a minute to set an integration up and then its done. The only time it matters really is if you are constantly blowing up and/or redoing your configuration.
The one caveat is that you need to keep track of things like API secrets and/or configuration parameters somewhere just in case you want to reinstall an integration.
I’m actually waiting for a migration tool so I can import my hundreds of helpers into the UI
You don’t sound very stubborn to me.