The future of YAML

[chickenandporn (Allan Clark)]

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.

[firstof9]

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.

[tom_l]

So you have this nice thing.

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:

@danielperna84

But my everyday job is being a developer, and I constantly have to deal with situations like the once shown in this comic:

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.

[DavidFW1960 (David)]

@tom_l

I find it more efficient to define automations and scripts in YAML and JINJA

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.

[tom_l]

@DavidFW1960

I use Lovelace in Storage mode and I maintain lovelace in yaml

I forgot about the the front end. Yes this is the best of both worlds.

[finity]

@danielperna84

What reason do you have to read and, more importantly, edit this?

I have an example of needing to do this…

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…

[finity]

@tom_l

So I may just end up doing less.

TBH, that’s kind of where I’m headed right now.

EDIT:

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.

[kanga_who (Jason)]

@finity

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.

absolutely

[kanga_who (Jason)]

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.

[francisp (Francis)]

@anon3881519

MQTT devices account for 95% of my devices and I suspect similar for the majority of users. Yet, we still have to add them through yaml edits.

Well, I try to get as much of them out of yaml. It sometimes needs some json crafting to create discovery messages, but it is doable.

[YarmoM (Yarmo Mackenbach)]

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)

[Thewho]

Is it the time for a new fork?
There have been more and more changes recently that do not sit well with current users.

Do I smell something similar to emby/jellyfin?

[tom_l]

Hopefully not. We’re mostly users, not developers.

[kanga_who (Jason)]

@YarmoM

But I want my family to use HA as well and they can absolutely not be trusted with YAML files.

So don’t give them access. Pretty simple. I don’t trust my wife with any admin functions, hence why her account is a user account.

[decairn (Keith Hudson)]

I’m sorry all the cobol programmers are busy fixing the US unemployment systems for the foreseeable future.

[nickrout]

Yeah but IBM are doing lessons to bring the workforce up to speed.

[YarmoM (Yarmo Mackenbach)]

I mean, I want them to use it in their place, I don’t live with them . Biggest threat is that they’ll move to some closed solution.

[SeanM]

@anon43302295

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’.

You don’t have to chuck comments all over the place though. Where you used to put your integration config, you’d simply replace it with something like this (most likely saving lines in fact):

# Set up this integration via Configuration -> Integrations 
  # Enable the following options: HTML Parser, X, Y, Z

I think this approach is much simpler overall - clear instructions for users browsing your repo, no confusion over secrets.yaml stuff, no possibility of breaking their config by improperly pasting YAML, no missed options, no need to restart afterwards, no breaking changes during upgrades since the config gets migrated, etc.

If you can accept needing to do things a slightly different way, I think this change is beneficial for the most part.

[AndiH]

I see the reasoning in moving to a more UI-oriented configuration; but having everything tidy and machine-readible in one configuration file was for me always a key feature of Home Assistant. (I’m not saying I haven’t browsed this board hour-long to find the right combination of single-double-quotes to make the config work…)

Isn’t the obvious solution to keep both – that is, UI-based configuration and YAML-based configuration – and make a two-way converter as part of Home Assistant core? That would keep the good and proven flexibility and sharability of YAML but would enable Home Assistant to a broader audience. It would also lift the burden from integration developers; they simply integrate abstract read_config methods which deliver data defined either via UI oder YAML.