The future of YAML

I agree with that.

But unfortunately that doesn’t seem to be the direction things are going.

Doesn’t it really seem strange that most of the “older” users who are here are simply asking for their ability to continue to configure their system using yaml? It’s not like there hasn’t been substantial use cases provided to support that desire. And it’s not like we are asking to completely change how things are done. I honestly really don’t care if there is a GUI added for every single function.

All *most" of us are asking is just to keep the existing paradigm and not force us into using the UI to configure our systems because “it’s hard for new users to figure out yaml”. So what? Let them use the UI along with it’s inherent limitations in functionality.

But to shift the focus to cater to “grandpa” (which I am one of several times over…) while alienating your existing user base just doesn’t seem like a winning strategy to me.

Literally the only thing that the majority of people who have issues with this are asking is to just keep the promises made and keep the ability to configure things in yaml along with the UI config if desired.

13 Likes

Well said! Bravo!

3 Likes

As someone who contributes mostly small PRs but also a code owner. The clarification on configuration is great. We were always operating under always changing and unwritten rules. The config flow process also greatly increases the flexibility of the configuration process. Personally, I hate YAML configuration as a user and I like the change.

I will agree that the way this had been rolled out gives off a smell of being pushed through rather hastily in the back room, so to speak. The ADR 0010 was posted and then published in less than a day. Further, it was published only 8 days after ADR 0007, which it significantly superseded. What happened in those 8 days? It is possible this was prediscussed over a period time internally, but this doesn’t help the optics either.

4 Likes

I think your speaking for a smaller subset of veterans than you think.

That is always a distinct possibility…

1 Like

Interestingly there is a brand new thread that highlights the issue with some of the things we are discussing here.

For those who think that the UI editor is the way to go I suggest you go to this thread:

and help that user solve their problem without using any of the yaml that they have provided in their post.

Do it completely using examples from the UI editors and screenshots. But even then it will be easier since they already provided a yaml version for you to better understand what they are actually somewhat trying to do.

I’ll watch the thread to see how it works out.

2 Likes

There’s actually been a couple of those today. With no replies.

1 Like

the automation editor is not the same thing as config flow, they are completely separate in this respect and many of the power users that like config flow do not use those editors. They have their own issues. That level of complexity is not there for configuring an integration.

3 Likes

Literally said umpteen times in this thread that yaml for automations scripts etc is staying. The option for yaml is only for new configurations.

5 Likes

I don’t believe for one moment that neither you nor the poster above you understood the point he was making. :man_facepalming:

3 Likes

Apples and oranges. Adding an IP address and a port via the UI verses yaml is the same. Automations is another story. Using the automation editor as a baseline is unfair and you know it.

5 Likes

Not at all - the question is ‘how do we support people when they dump screenshots instead of posting code?’

The answer, apparently, is to create an animated gif. Seeing as I spend most of my time on my phone it’ll be unlikely I’ll be able to provide such support.

Your responses won’t be code… you’ll say things like “next click ok, then click in the upper left corner”.

I can see it now.

1 Like

2 Likes

I said clock, with an L :laughing:

9 Likes

Hah, sometimes you need to walk away from support when that happens

2 Likes

I agree with Brian here.

I find Home Assistant to be unacceptably fragile. I agree with the couple of posters I’ve seen who commented that HA is not reliable across upgrades, or even reboots. Moving more eggs into that basket, and eroding our ability to sidestep it when necessary is not a step in the right direction, in this user’s opinion.

When an open-source developer tells you that the project is run by volunteers, and implies that you, the user, should be grateful and to hold your criticisms of the project’s direction, they are doing you the unintended favor of revealing their opinion of users’ place in “their” community. Take notice.

So I guess I’ll take the condescendingly-offered advice to move on to some other solution.

1 Like

Do you have a link to a dev saying that?

Check twitter :slightly_smiling_face: