Since I started using HA earlier this year, I’ve noticed that there appears to be a trend of removing support for YAML config and only supporting UI config.
I fully appreciate that for those who are less technical, UI config is the way to go… but for those of us who prefer to deal with code, YAML config is significantly better and allows for many benefits such as version control and quickly iterating ideas…
What the heck is behind this trend to remove support for YAML config? Why is it considered better?
If anything I would prefer more stuff to be editable in code that can be committed in git etc, not less. I want to put my dashboards into git etc.
To increase adoption, it needs to be significantly easier to configure and maintain a Home Assistant setup. This is the primary driver to the changes. It took me many months to get somewhat comfortable with YAML and for some things I am happy not to have to deal with it, but for others such as working on dashboards, I have grown to like it as the UI is still confusing (probably because I don’t use it since most of what I wanted was not feasible in it) and limiting.
I’ll vote for this mainly because I don’t want to lose the extra flexibility I get by editing the YAML but I also welcome the reduction of complexity. I just hope HA will never be “Applefied” (walled garden, uber limited so it just works, even for the least bright / tech savvy).
Supporting and maintaining multiple approaches to setting something up takes time. Assuming the code owner of the integration only has time to maintain one its very likely they are going to pick the one that makes the integration more approachable, discoverable and usable by the largest amount of users. Even if it means loss of the other things mentioned.
This is of course only for times when there is a choice. As the ADR about this states:
Integrations that communicate with devices and/or services are only configured via the UI. In rare cases, we can make an exception.
All other integrations are configured via YAML or via the UI.
So new integrations that communicate with devices and services must be UI-configured only. Ones that existed before this ADR aren’t forced to switch but are encouraged to do so if author is making enhancements. Only integrations that don’t communicate with devices and services have a choice as to how they are configured.
You can do this. Not sure where its documented but here’s a screenshot I found showing how:
You don’t have to use the lovelace_gen bit, that’s a separate custom component. You can just put this:
I understand the move to UI. But why is it not stored in yaml underneath. That would have enabled users to do both. Like the automations and scripts, that can be created by UI, but are stored in yaml
Yaml or json is irrelevant for the files in .storage. The UI stores it’s config in text files which have a no published schema. It does this intentionally, because that way it can completely change the schema and organization of these files in any release (major, minor or patch). Doing so isn’t a breaking change because there’s no support for humans making and modifying these files. Hence no published schema or documentation on them.
Given that, why in the world would they make them yaml? That would be taking a significant performance hit for no reason. Parsing json is much faster then parsing yaml.
If loading JSON really is that much faster (how much btw? and how often other than at startup?) than loading YAML, why don’t build bridges instead of walls?
Let the (power)users keep their YAML and convince the Newbies with a nice and barrier-free UI.
How?
Right now we have to save our .yaml file(s) and then reload that bit (or restart HA).
I would gladly insert a step where I’d have to hit a “transform to JSON” button or sth., if in exchange I could keep the flexibility and maintainability (git, comments) of YAML text files.
I’m no developer, so I have to hope that the main contributors (or the Nabu Casa folks) can point to good technical reasons for starving YAML.
The speed argument alone is a smokescreen.
To software engineering apply the same rules of decision making as in our everday life: ideology is the worst advisor.
The reasons for the changes are listed in the ADRs, they have been public for more than 2 years at this point. Dredging up this topic for debate again won’t help or change anything.
I’m aware of that.
HA is a bullet - once shot impossible change course? It’d better be a missile - able to be adjusted to moving targets or threats along the way. That’s been decided long ago is no argument by itself.
You conveniently glossed over my whole first point. There is no schema for these files since the only supported means of editing them is via the UI. Therefore they can freely change at any time.
Actually kind of a lot based on bdracos research which I believe is either linked in the post I linked or linked in the reply chain above.
But it doesn’t actually matter how much because of the first point. If it’s any faster at all then json should be selected since editing it directly isn’t supported anyway.
If you’re wondering we’ll why can’t they publish a schema and support direct editing? Well that takes more time. Lot of doc to publish, switching from json to yaml, moving it out of hidden folders, changing file names, adding new CI processes to ensure there’s standards and consistency in schema and changes are backeards compatible, etc. All this time to maintain a second mechanism of configuration, exactly counter that adr.
The reasons for the changes are listed in the ADRs, they have been public for more than 2 years at this point. Dredging up this topic for debate again won’t help or change anything.
I’m just following the various replies here. I’m learning as I go. But… your response reminds me a bit too much of the Vogons in The Hitchhiker’s Guide to the Galaxy.
“There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams.”
Sorry, but I thought that the month of “What the heck?!” was all about this sort of thing…
Seeing as I’ve only been using HA since April, I’m not even aware of what an ADR is.
But what I can tell you, is that when I’ve set things up on code-based configs I’ve had a much better experience than some of the UI-based configs I’ve been through. So this has 100% triggered the “What the heck were you thinking” moment for me.
You don’t have to know about the ADRs to read about it. There was a blog post, and thread covering all the reasons and it was quite public. Even mentions the ADR.
Yaml isn’t going away. That’s why the WTH doesn’t make sense. It’s also why many people including myself are annoyed with the same tired question. This topic comes up every few weeks with or without the month of WTH. Code owners have the choice to keep yaml and the UI when transitioning to the UI. If they choose to remove the yaml, then they can. It’s not complicated. They don’t even have to transition to the UI if they don’t want to.
Maybe the fact that this issue keeps coming back again and again for two years now, like a zombie that just won’t die, is a hint that something is fundamentally wrong with it.
As much as I hate YAML (and I really do) and as much as I agreed with the idea of moving things to the UI back then - in hindsight it was a mistake.
What we ended up with is a weird mishmash of a half finished UI with missing features and the dying remains of a text based config system awkwardly mixed together. We’re not getting the best of either world. We’re getting the worst of both.
Yeah, sometime everything will be in a nice polished UI. Maybe. Sometime. Or maybe not. Because however you turn it, maintaining a good intuitive and feature complete config UI for components with ever changing feature sets is a lot more work than maintaining an equivalent text based config system.
This ADR was a mistake. It was a bad decision. It should be revisited.
I am sorry. I appreciate that it must be frustrating for you if you’ve seen this topic come up again and again.
Maybe you can also understand that to a new user of Home Assistant, and a new member of this community (I only signed up this month) that I’m not aware of the history of this topic. I’ve not seen the other threads on this topic, and I hadn’t read the blog post until it was shared here.
