HA should replace yaml with Json; it’s too complex to copy&paste with all the “white spaces” in front… that’s the reason people prefer UI… you take a snapshot and that’s all… but I’m not surprised that python people are in love with yaml…
JSON and yaml are interchangeable. You can write your entire config in json if you want.
2 Likes
For sure!!!
Just checked my telegram_bot yaml configuration against json version of updated UI setup. It was 6 lines, became 42 with a lot of unnesasary stuff.
I find YAML configuration far more convenient for making changes, duplicating parts of the config with small modifications, and for copying entire setups to other servers.
UI configuration is great for end-users who have no technical background — for people who just want a simple way to set things up without touching code. But for those of us who do have technical skills, and especially for contributors who build and maintain Home Assistant setups for multiple users, YAML is much more efficient.
With YAML, you can instantly duplicate a configuration block, tweak a couple of lines, and be done. You can keep everything in one file, easily share it between instances, and version-control it. In the UI, achieving the same often requires clicking through multiple pages, sometimes filling in part of the configuration on one screen, clicking “Next,” then another part on another screen, and so on.
Even worse — if you want to recreate or slightly modify such a configuration, you can’t simply copy-paste it. You can’t even see the entire setup in one place without navigating through those pages. For some integrations, you’d literally have to take screenshots of every step and then manually redo it. That’s just painful compared to editing a YAML file directly.
By removing YAML options from integrations, Home Assistant is making it harder to build reusable, portable configurations. It feels like the project is moving toward “set it up once and never touch it again” scenarios, instead of encouraging modular, shareable setups that advanced users can adapt and improve over time.
10 Likes
Sounds like it’s moving in the right direction. To becoming a stable platform that anyone can rely on for long term deployment.
It’s pretty clear that editing YAML directly is still possible and quite easy for anyone that wants to do so. What’s going away is YAML as a requirement or pre-requisite.
Now we need LTS releases of HASS as the update situation is still very much untenable for off-site customer deployment and maintenance.
That’s not entirely true. Most of the integrations don’t support YAML, and it’s being removed from more and more old integrations. While we can still use YAML for automations and UI config, which is arguably the most important, but managing many devices is still painful through the UI and these are not possible to configure via YAML.
I would say - “absolutely not true” instead of “not entirely true”.
2 Likes
Yeah, I would also prefer UI-first config for new users or quick edits, but I would absolutely love an “edit as YAML” button on the integrations page (I know it’s not really possible technically) similar to what we have for automations or dashboard cards…
Wow, there’s so much to be learned for a new user in this topic. Organisation structure, process, history, community politics, characters, settings storage, different kinds of configuration, oh and the different uses of JSON and YAML in HA.
I recommend reading from the top for anyone wanting to get deeper into this project in a few minutes rather than by spending months just on topics relevant to their interests.
I can see why this is a tricky issue and don’t think there’s a way to satisfy the different wants being raised. Some like YAML. Eeek. I don’t. I’ve only used it for a few months for CI and I hate it, but only a little more than I hate editing JSON.
I imagine YAML was designed to be human writable and failed. And that JSON was designed to be human readable and also failed.
There are better ways for both IMO but this is where we are. I’ve been around long enough to know these discussions are necessary (>700 replies) even if they don’t bring much change because those in charge have already invested the time and made decisions, so at this point it’s not going to be undone.
It is possible but costly in time to involve a community in decisions to help arrive at a more consensual way forward. Perhaps ADRs are an approach to that, but to formal and techy for many newer HA users (if ADRs are what I imagine).
One way is to begin with a proposal post where it’s easy for anyone to comment (ie here) and iterate between that and the more formal process.
I think that a fairer way to describe this would be to say that the community is attracting a lot of people who aren’t coders, and who understand the technology in tetms of usage and opertunity, but who are either unfamiliar with the coding concept involved or unable to devote the personal resources nessesary to build a system this way.
We’re living in a society that’s often split between technology users and technology builders. People can be tech savvy, but never go under the hood, so so to speak.
2 Likes
I have to admit, I despite being a coder, I often pass by things that do not have ui based setup.
It can sometimes be a pain to figure out if something isn’t doing what you want because it’s not able to do it that way, or because you’ve missed or misread something in the documentation and are trying to do it the wrong way.
ui set up takes a lot of that out.
I struggle old for an hour to get something running a while back because I missed one sentence buried in a long set of instructions that a mounted to using a single quote instead of the usual double in yaml.
That might be another YAML fail, although given the subtleties of quotes in codeland I won’t assume that.
I agree with your more refined definitions of techy/coder. As for text UI v GUI I don’t think it’s simple because in both cases a lot depends on how savvy the creator is and whether time has been put into usability.
I love a good UI whether it is GUI (you meant GUI BTW 
) or text. I think YAML and JSON are both poor ways to do config using text and that people tend to choose them because they are what they know rather than because they are suitable.
or documentation, as the case may be.
2 Likes
One thing that bugs me is that automations.yaml, if you use !secrets, then (in my case anyway) that crashes the UI editor for ALL automations, so I am forced to have an automations.yaml for UI editable automations but then also an automations_non_ui.yaml for the others. That seems a little silly to me!
2 Likes
try to move executors that likely require mentioned passwords to a script. then call the script from the automation
2 Likes