1 month in and I’m already highly impressed with Home Assistant. I’ve been giving some thought to how to get more users onto HA.
From my early perspective, HA seems to be missing what SmartThings had in the way of ready to use official automations (aka SmartApps). See the example below (although the categories were way better in their SmartThings Classic app).
Perhaps it would be worth having the most popular Blueprints available in a similar way, in easy to consume Blueprint Store – browsable categories eg. Official, Trending or by room (eg. Bedroom, Bathroom, Kitchen, Lounge) with tags against each.
The most elements of this would be:
Support: being official, they would be more likely to be trusted and to work better.
Curation: having the best Blueprints show first, new users are more likely to get going quicker.
(I do understand that the Blueprint system has just been released. I think that curation will make it a hit feature).
The blueprint concept is in its infancy. It’s still far from allowing anyone from building a proper ''app" because all it can currently do is compose an automation.
Packages let you combine different entities and that’s what’s needed for an “app”. However, a blueprint doesn’t support packages (not now but maybe in the future).
I think the best case would be the ability to import a repository of blueprints as a URL, similar to what exists today for HACS. Paste in the URL to some repo, and now you have a browseable list of blueprints than one can select from.
Also, being able to deploy packages with blueprints will be a game changer.
Please consider what you just suggested.
It may well be possible in the future. But as of now : -
I create a package blueprint for a (simplified) heating system
It contains : -
9 off template sensors
1 off device sensor
3 off binary sensors
1 off template switch
6 off input booleans
9 off input date times
6 off input numbers
2 off climate entities
11 off automations
2 off scripts
Can you imagine getting people to match what goes here and what goes there ?
I write my packages to contain uniquely named entities so the package in entire (and virtually self contained though some external referents may be required eg sensor.time, house occupied etc.)
So why couldnt I just give you the whole package, you then drop it in, change the names of your thermostat (sensor) and your boiler switch (I could even give you a page of lovelace yaml to give you a frontend user interface but cant afford the time or the space to give you two screen shots per entity for setting up helpers in the GUI editor or in the GUI lovelace editor (you’d need to do it in both for all of them))
2 mins of search and replace. a reboot and you are up and running
Why do you need a blueprint ?
Though I do think the store for Automation Blueprints is a good idea
But Curated by a Moderator at the minimum (to sort the wheat from the chaff)
In my case, the packages are getting very complex with a few thousand lines of code total. It’s a hell of a lot for a user to wade into to change one value. It works fine, and with a custom deployment script I’ve also automated the ability for the user to deploy the entire thing with some search/replace being done across the entire bundle but the moment you want to customize the functionality, the user is back to trying to figure out which of the several thousand lines needs to be modified.
Fine for me, I know how to do that because I wrote it. For someone that’s not me, it’s a huge hill to climb.
Additionally, a whole lot of what’s being done in my packages is “behind the scenes”, values which the user doesn’t really need to interact with but which are core to the overall functionality of the project. There would be no reason to expose these “helper” entities and automations to the user.
So, what I think would work best would be to continue to leverage packages for the base functionality, but then give the user the ability to paste in a repo link which would point to my list of available blueprints.
Then, they could select a specific function like “trigger a scene”. They’d be given the opportunity to select a button, enter the text to appear on that button, and then select the scene that would be triggered.
Nice and easy, and saves the user from having to figure out which of the 3000+ lines of YAML they need to change in order to modify a button on their device.
