First, thanks to the developers and community–this is intended as constructive feedback from a new homeowner and smart-device user who wants Home Assistant to be more approachable.
As a newcomer, it confuses me that Home Assistant sets up nothing by default besides Overview dashboard statuses. Many device have “obvious” behaviors, yet require manual work for automation.
Two big advantages of good defaults seem clear:
It’s easier to delete or disable something than create it from scratch.
Experienced smart-home-owners likely have better ideas than me for good baseline behavior.
Defaults may annoy power users–so let them opt out, assuming they don’t find them useful as learning examples.
To summarize, I’d like to see more automation for Home Assistant’s own setup. No single device is a major problem, but my cumulative setup effort is adding up quickly. AI Assist may eventually help, but even then stronger defaults should help teach AI Assist, too.
Examples from my experience:
Washer/Dryer laundry: With Samsung SmartThings, connecting the devices to our account automatically enabled cycle-complete notifications. Adding the SmartThings integration to Home Assistant, by default I get no notifications and a third of my dashboard filled with useless statuses. Moreover as a new user it me months to realize organizing those statuses was wasted time, and all I really need is a notification. The only laundry Blueprint I found requires me to buy a smart plug for that monitoring.
Safety alarms (water leaks, smoke, CO, etc): These usually do nothing, but notifications are critical. Shouldn’t all safety sensors automatically get notifications for offline status, battery status, and danger detected? Ikea Klippbok water leak sensor just came out, yet apparently this warrants reinventing the wheel with a new Blueprint.
Thermostats: I got the Z-Wave Honeywell T6 which has scheduling and Home/Away modes built in. Yet those disable once added to Home Assistant, and Home Assistant doesn’t provide defaults or guidance to replace them. I spent a long time creating calendar helpers and several different automation triggers to set the temp, but it’s not very user-friendly. I eventually found forums recommending GitHub - nielsfaber/scheduler-component: Custom component for HA that enables the creation of scheduler entities, but I see it was last updated 2 years ago. If it’s truly great, shouldn’t it be listed with Bronze or better status at Integrations - Home Assistant ?
This is just a difference of philosophy and options. Most of the time, HA follows a philosophy that users should not be automatically be opted into things. While a new user may think…
It’s easier to delete or disable something than create it from scratch.
… for existing users, automations appearing out of nowhere sounds like chaos and the kind of prescriptive control that caused them to leave other platforms.
When you were using the SmartThings app on your phone, it notified you on your phone. But, HA has something like 40 core notification integrations and dozens of custom notification integrations. If it existed, which one or ones would your proposed Washer notification target?
But, I’m skeptical of the concept. I’ve been helping other users on this forum for 4 years, and I have been consistently surprised by what many users consider “obvious” or “necessary” automations.
That blueprint has nothing in it that is specific to the Klippbok… it will literally work with any moisture sensor. And it looks like it’s at least partially AI slop, relying on a generic action that is unreliable once you have more than one notifier… so it’s setting up anyone who uses it for eventual failure and frustration.
It’s not a core integration so, no, it shouldn’t be listed in the core integrations list with any quality scale designation. Custom integrations only move into core when their code owner request/allow it, and they meet minimum requirements, and the core team thinks it’s appropriate.
Just because the base code didn’t need an update in 2 years doesn’t mean it’s unmaintained.
The accompanying scheduler card gets more frequently updated, as recently as last week.
I strongly suggest you check out both the integration & the card. They’ve got some pretty impressive features & have been rock solid for me for over 4 years.
I see the timeline is measured in years, so this is a long term plan and I look forward to what’s coming next. I already see the automation improvements that just came out and can see they’re more user friendly. So it feels like good ideas already.
Does this relate to my comment, “Experienced smart-home-owners likely have better ideas than me for good baseline behavior”? Ie new users sometimes have silly ideas? Or are you saying new users are expecting the moon, stuff that will never happen automatically and will always require an AI assistant or even a dedicated developer?
So clearly some community stuff is good and some is not good.
How am I supposed to tell? I am leery of what’s not an official Home Assistant integration, because like you described it sets some kind of minimum bar and includes a basic rating system. Github has stars and download counts which appear in HACS. But the scheduler-component apparently only has 656 downloads and 840 stars, which doesn’t feel like much to me. For comparison the Playstation Network official integration has bronze quality with 6500 active users and probably tens of thousands of installations. Then again the Altruist official integration has bronze quality with only 3 active users.
And look at this guy, he didn’t realize this particular HACS integration existed and creating his own totally separate code to do the same thing. It’s a different interface which is fun to see, but the backend is likely very similar.
Assuming this scheduling component and accompanying card are good defaults, Home Assistant providing them as defaults for new thermostat devices seems like a great way to ensure a good baseline experience and to reduce developer effort fragmentation.
Search these forums. You’ll generally always find a thread (or 10) about custom components. Be aware that forum posts usually skew negative because people aren’t in the habit of posting when things do go right.
Next, I would focus on the issues tab in Github. You can see the dev’s response to genuine issues and the manner and speed they handle them.
What I would not do is base my perception of the quality of an integration based on the number of installs, github stars or integration quality scales.
First, because you’re comparing apples to oranges (an official integration with wiser out-of-the-box reach & ease of install, vs a custom integrations which requires HACS & 2 separate components).
Secondly, because github stars mean nothing. Speaking for myself, I have never heard of that feature before today, let alone handed out stars for integrations.
Finally, I wouldn’t base my decision to install based on the quality scale. That mostly means that an integration is easy to integrate and follows HA’s standards (for better or worse). There have been a few cases in the recent past where actual functionality was removed from integrations in order to climb up the quality scale.
That is up to the dev responsible to decide whether to attempt to integrate with HA Core. There are good reasons why some devs decide against this, the primary one being that they would rather push updates at their own pace rather than be constrained by HA’s release cycle.
I meant it more as an allusion to how unique and personalized home automation actually is in practice. Each instance of HA has a unique collection of devices, in a unique physical environment, inhabited by a unique group of humans with their own personal preferences.
Because of that, blueprints or “starter automations” often fall into one of the following categories:
Those that don’t account for that diversity and end up being too basic or too specific to be useful.
Those that only account for it partially and end up with a narrow scope. From what I’ve seen, this is where the majority of community blueprints fall. This is not meant as a knock on any of the blueprint authors out there. Writing good blueprints is hard.
Those that account for the diversity and the end product has too many options. Feature creep is real, and an extremely flexible blueprint may eventually become nearly as complicated as creating the automation yourself.
Users can take control of automations and scripts created by blueprints and edit them to better meet their needs and preferences. But, the automations generated this way are often quite complicated and the users are facing a deep knowledge debt because they skipped learning the basics.
ShadowFist has provided some guidance, but IMO the only real answer is “Try it”. If it works for you, great… if not, try something else.
I absolutely love documentation that has examples and pulls them apart to explain why certain parts are the way they are, going back to the actual parameters in the documentation.
This can make documentation quite lengthy, but can save a lot of head scratching.
Reading these forums can often be most enlightening, seeing what can go wrong, and how it is fixed. ‘Users’ can be quite creative in setting up things the original developer never envisaged. You learn best when you have to understand how it is supposed to work, and then go back and make your attempt to match this.
Glaringly embarrassing is when AI enters the picture, offering outdated (and often wrong) slop. An incredible waste of time and resources to go back and try and work out where the garbage came from. I believe it comes back to a fundamental misunderstanding that the current crop of LLMs, marketed as AI, are not actually intelligent, just careful searchers that repackage whatever they find, carefully formatted to look convincing, and are based mainly on outdated documentation and snippets of wrong code in forums such as these, where often the corrected solution doesn’t appear, the poster happy they have stumbled over a fix, but it not being documented to close off the thread. Home Automation is such a fast moving field, and the relentless grind of frequent HomeAssistant changes, that the LLM learning models cannot keep up.
Having templates for common situations might sound like a handy thing. How do you narrow down the endless possible combinations that the inbuilt flexibility of HomeAssistant offers to a few, and then maintain it?
Go back, read the actual documentation carefully would seem to be the best way to improve your understanding. Taking shortcuts often brings perplexing grief.
Thanks for the thoughts y’all. I think the summary is:
Improvements are the roadmap (and not just relying on AI Assist)
A general solution for defaults is not nearly as obvious as I might think based on my experience in my home
For now the best that’s available is scouring the forums, reading the documentation, and investing the time to try stuff out and see what does/doesn’t work for me and my home. For some people and some desired automations, it probably makes sense to wait a few years. It’s a spectrum of effort-vs-reward, and the answer will vary for each person and their scenario.
Never intended it to be a KLIPPBOK specific blueprint, it was only to keep all my IKEA matter related blueprints together and share. When I wrote it I was going out of town and had no way to group moisture sensors together and set a behavior that if ANY in the group activate then the whole group should trigger a persistent notification that needs to be dismissed. That way when I am away from home I can still see that there was a point in time when a sensor activated.
If you have improvements to keep the behavior consistent going forward I would like to incorporate them.
To the OP’s point there isn’t even a logical grouping in the Matter integration so you can’t call something a button, sensor, etc, and then assign group like behaviors to things of the same time that really should record at least a record (moisture group detected wet @ sensor) to persist across logs and not just when I’m looking at my dashboard or in close enough proximity to hear the siren.
Other things should logically be simple to assign since Matter in particular is about simple sensors first and foremost. Like a CO2 alarm should always produce a persistent notification unless you disable it at the time you add it to HAOS.
You also can’t just “duplicate” a button without the blueprint hack as well. See my BILRESA blueprint for an example. Every button device and every variation (quick press, release, long press, etc) is a whole separate automation to tie it to an action, UNLESS you make a blueprint that logically puts the whole thing together as a button.
There is a similar headache for Zigbee like devices which send all kinds of control codes, which can’t be handled as cleanly as a matter button press.
It’s much simpler than that. Bookmark the Blueprints Exchange section of the forum & search through it whenever you need an automation. The search allows you to filter by that specific section only.
If it’s half as common as you think, then someone will have surely written up a blueprint which you can just download, fill in and use. Beats having to go on a wild goose chase when someone else has done all the heavy lifting for you.
(By the way, the above does not absolve you of reading the official docs. Do that…frequently)
I did create an automation for “When dryer changes from any state to Stopped, Then do Notifications ‘Send a notification’”. So I guess whatever is the default choice for notifications for automations, that seems to me like a reasonable default.
Realistically at best I will evaluate 2 or 3 integrations before choosing something. I am certainly not going to evaluate 40 (plus dozens more). Likely I’d be satisfied with whatever is most maintained.
Idk, sounds to me like your description matches my summary…
I said scour the forums in general, you said scour Blueprints Exchange specifically.
I said read the docs, you agree to “do that… frequently.”
I said try stuff out and see what works/doesn’t work for me. I suppose your thought is that the first thing find in Blueprints Exchange will always work for me first time. Well, that didn’t work in my one example of washer notifications. The first Blueprint I found turned out to be for washers using a separate energy monitor to trigger cycle notifications. Not suitable for my system.