I thought about chucking comments all over the place, but I didn’t like it. It messed with my OCD.
It’s not all about username and password, it’s about configuration options. My telegram codes require using the bot with parse_mode html. How will readers of the repo know that I selected that when I set up via UI? They won’t unless I put it in a comment, when it’s configured in yaml on the same page as the automation it’s there for all to see.
It may only be small things but lots of small things add up to a lot of time to keep on top of, and I couldn’t think of a decent way to cater for it all and also keep the repo ‘tidy’.
Before these changes I didn’t have to spend any extra time writing comments or whatever, I just pushed my changes and they explained themselves really.
So mark the yaml-dropping Components just like cloud-polling / local-polling are marked. Let us see which components are dropping Yaml. Shoot, let us filter the list so we’re not even distracted by those for whom yaml is sigh oh so burdensome.
One thing I don’t like is when you setup an integration only to find out the configuration has failed even if you followed the documented configuration and have to restart Home Assistant 3 more times to get it working right.
It makes my zwave network very unhappy. So I welcome anything that causes me to have to restart Home Assistant.
You want to grow this nice thing because if you don’t it tends to stagnate and die.
Understandable.
Pissing off a large section of your loyal user-base to grow the nice thing?
Unfortunately that has to be done sometimes simply due to practicalities.
You have to be very careful about choosing your new target demographic though. For example:
By dumbing down the nice thing you are going to attract a lot more dummies. And the situation shown in that comic is going to become more common, not less.
Ask yourself, do you really want Home Assistant to be used by people who would have trouble setting a clock on a microwave oven?
This is all a bit rambling and I do have to admit that so far the shift away from YAML has not affected me adversely. I can only remember one or two occasions where I had to delve into the undocumented .storage black box to fix things that were not fixable via the UI. That was in the early days though and I have not had to do this lately. I do actually like discovery and the way my commercial and DIY devices seamlessly integrate into Home Assistant.
One thing that has become slightly more difficult is community support. Rather than asking for correctly formatted configuration code so it can be easily cut/pasted/corrected I find I have to post more screenshots edited to show a button press procedure. This is time consuming and tedious but I’m not forced to do it. So I may just end up doing less.
Also I learned YAML and it was surprisingly easy. So new users should have to learn it as well. Now get the hell off my lawn. ~ Wanders away yelling at clouds ~ /jk
But seriously, I find it more efficient to define automations and scripts in YAML and JINJA than the UI and if the current ADR ever changes to exclude that I would have to re-evaluate my use of Home Assistant. It is good to hear there are currently no plans to remove this.
Same even though I use Lovelace in Storage mode and I maintain lovelace in yaml and use cut/paste so I kinda get the best of both methods. I have pretty much switched to everything via GUI except scripts/automations and when GUI adds new support for integrations I switch to use them. I don’t see a good reason not to use the GUI where possible for that kind of stuff.
A few weeks ago after an update/restart my frontend wouldn’t load (of course I did a config check first just like every other time!) and I started getting errors in my log about the HACS component (along with a lot of other related/unrelated things). And of course we all know that the first recommended troubleshooting step is to remove the offending custom component (it says so right there in the first lines of the log).
The problem was that I had HACS configured via the UI at some point and because I didn’t have access to the front end I couldn’t remove it via the UI. I was then pretty much stuck. It literally took several hours of troubleshooting/editing the .storage files to purge them of anything HACS related/etc. until it was all back up and running again. I even eventually had to create an entirely different virgin HA docker container and added things back a bit at a time from my original config until I “found” the issue.
So…without being able to edit those mostly not-easily-readable JSON files and then knowing how things were supposed to work in the first place because I usually configure (mostly…) everything in yaml I would have ended up needing to completely restart my main config from scratch. And even with my experience with things HA related I was still unsure about where all the bits of the HACS integration were spread out in the .storage files.
I still don’t know why things got broken like they did but I’m fairly confident in saying that if I was one of the newly-targeted “non-tech savvy” users I would have been completely lost on how to proceed to fix things. And having everything configured in the “black-box” of the hidden .storage files only adds to that.
And since there is no “customer service” that the non-tech savvy user can reach out to for help they will come here. Then we are supposed to try to help them fix their broken systems by telling them…what exactly? To use SSH/SAMBA (which they probably don’t know how to use and haven’t ever got it set up) and go into their .storage files and edit those un-editable files that are written in unreadable JSON and to delete every reference to some UI configured integration that might be spread across several files? But "oh, yeah…make sure you don’t mess up the syntax of those mysterious files because if you do all hope is lost for ever fixing it without starting completely from scratch. But, hey, no pressure. “Wait, you didn’t make a backup?” Of course not. And why would they since the new target user is not tech savvy…
It would be interesting to see where HA would end up if all of the “power users” stopped interacting on the forums trying to help out all of the new target “non-tech savvy” users when things break and they weren’t here to hold the new users hands thru fixing it.
I much prefer using YAML for as many things as possible being that is how I learnt how to use HA. I find it simple now, and mostly easy to troubleshoot.
I can see how for new users having an idiot-proof setup via integration makes life easy getting things to work…until it doesn’t.
My 2 cents: sure, it’s not my preferred solution. But I want my family to use HA as well and they can absolutely not be trusted with YAML files. I want HA to grow, I accept the devs decision and I’ll make the integration that I help maintain ready for UI.
(edit: must have pressed the wrong button, this was not meant as a reply to @kanga_who)
Wanders away yelling at clouds