Automations are one of the core features of Home Assistant, yet they require a fair amount of inspiration, technical knowledge and understanding to set up. Blueprints aim to make this easier, but finding a Blueprint for your situation is difficult, sure you can browse the Blueprint Exchange, but once you click into a Blueprint, you have no way of knowing if your instance of HA supports it. Does it rely on Z2M and you have ZHA? Does it require lightbulbs to have color_temp control and yours only have color control? Does it require device tracking - but you have no means to track devices yet? And so on.
A new user is likely to get lost and frustrated straight away.
Similarly it is probably annoying to have a “Motion Activated Light” blueprint if the user has no motion-detectors configured.
My Proposal
Each blueprint specifies requirements*, and these are specified as part of the yaml. These may be configured integrations e.g ZHA, entity attributes e.g at least one entity with supported_color_modes: color_temp or a particular device TRADFRI on/off switch by IKEA of Sweden. Once all the requirements are met, the Blueprint is “discovered” and suggested to the user in much the same way as the current default Home Assistant blueprints are.
Risks
Home Assistant may want to have some form of quality control before they suggest a blueprint to users, whilst still allowing discovery of new/up-and-coming blueprints via the forum.
*I wonder if it would be possible to programmatically determine these so this feature can be added retrospectively?
How clueless is this hypothetical user that they don’t know what they own (and looking at random blueprints)?
You do if you know what you bought and have read the blueprint’s description.
Your FR seems to be targeting a user who is unfamiliar with their own purchases and allergic to documentation. They have no plan beyond rummaging through blueprints in the hope something fits their system. Clueless and aimless is a bad combination for any endeavor. Catering to this demographic may prove the adage “No good deed goes unpunished”.
So why do you need it auto discovered then? After all, a wise man once said:
My proposal is just auto-discovering automations for those devices that users (1) may not have thought of, (2) may not have known was possible (3) may not have been able to create on their own or (4) may not want to spend the time to create the automation themselves.
Essentially this is just home assistant saying, “Oh you added a new device, did you know that you can automate it in a cool way with this other device you already own”.
With all due respect, HA is trying to move away from this approach to UX. A new, non-developer user should be able to use HA and it’s main features without having to spend hours perusing documentation (of variable quality).
In short, for users so profoundly unfamiliar with automating their home that they don’t know what they want to do with the things they bought and know little about them.
Don’t get me wrong, I understand the goal is effectively to “propose recipes for the available ingredients”.
Based on over 5 years of experience with Home Assistant, I feel that a user with such a profound lack of familiarity will not be well served by choosing Home Assistant. There are aspects of this project (that are unlikely to change in the near future, if ever) that will quickly push this hypothetical user out of their comfort zone and into completely unfamiliar territory.
With equal respect, the result so far has been a bit of a “bait and switch”. Home Assistant is so very easy to use … until it’s not and then you’re deep in the weeds. Why? Because despite the best of intentions, some concepts are resistant to being simplified to the extent it’s just a few clicks away.
This is the real problem with this FR. It’s not going to happen, any more than it does with HACS. Nor should it - users have to take some responsibility for researching and evaluating before they download.
I’m pretty sure auto-discovery usually happens after you’ve selected and downloaded an integration. So following that logic, users should be able to select and download a blueprint, and then the blueprint should discover available devices.
I don’t use them myself, but this sounds a bit like what I believe happens now…
Can blueprints auto-discover devices? I’ve no idea, but if not, that might be a good FR. But maybe something to suggest to blueprint authors, rather than HA.