Keep YAML!

It’s great that more and more things are being configured in GUI, I would have liked that 3/4 years ago… But it would be nice to keep the YAML option open now that we’re used to it… Yesterday ping goes away (easy to maintain in yaml, tedious in GUI), today proximity…

Just a thought, and I’m sure I’m not the only one :wink:

I voted because I agree. But there’s no way it’s going to happen. That decision was made a long time ago and they’re not going to change their minds.

2 Likes

Changing how an integration is configured, from YAML to the UI, was originally meant for certain categories of integrations. Refer to the following Architectural Design Decision (ADR)

Since that ADR was published, integrations that don’t fall into the original categories have been changed from YAML to UI. Therefore the evidence suggests that, contrary to what the ADR states, all integrations are subject to the policy of moving their configuration from YAML to UI (even it means losing functionality).

This has been thoroughly discussed in the past but the founder and his team aren’t willing to change their decision.

1 Like

I agree with keeping YAML and voted for it even though I know that the devs do not read these requests nor care how many people voted for it except perhaps anecdotally :slight_smile:

1 Like

Where can I down vote this request :grin:

When I started with HA, I was dumbfounded by configuration yaml… A conf file!!! Really? This is not 1995 when restarting an app was the norm

Burn the YAML file and burn it again just to be sure

It would be great if YAML and GUI for configurations could work like service calls, where you can choose to set up the service call in the GUI or YAML and switch back and forth between the two.

I guess this thread is nothing new and will eventually end up in trash.

But anyway… I’m all for GUI. I want my non–IT–educated brother to be able to install and use HA by himself. And my sister. And my mother. That would be great.

But I also chose HA myself, not because of GUI, but because of configurability, hackibility, YAML is a big part.

I want to version control with GIT. I want to set up a new instance by just running the config, not by configuring everything manually in the GUI. Etc. etc.

Where is the solution? Where is the compromise? I don’t know.

I’m on Nabu Casa trial, will most likely pay the subscription. If my voice was heard, I’d still choose YAML as a base. I feel like the base can always be extended to GUI, while choosing GUI first, makes nobody feel like keeping the YAML configurability.

So, my vote would be: keep YAML as base, extend to GUI. But KEEP yaml anyway.

1 Like

UI integration should work with yaml, and store config in yaml

1 Like

Any configuration that is not stored in a configuration file that can be version controlled through e.g. Git is terrible from a maintainability perspective.

Diving through menu’s to set things up might be more user friendly for less advanced users, and should absolutely be made available for HA to grow and gain larger user adoption. But that shouldn’t mean that on the backend of things options should disappear.

There’s a good reason that so many [blank] as Code models exist (Infrastructure as Code, Configuration as Code, Security as Code, etc.). That’s traceability. For advanced use-cases and complex setups this is an absolute must have!

I truly hope that more people would see the necessity of having a maintainable and traceable configuration and more people would stand up against the move away from YAML as a configuration storage backend.

2 Likes

Also, it’s not a problem to edit complex yaml in the era of neural networks. Yaml does not have to be edited in git or bitbucket; you can use your favorite text editor with hints.

He’s talking about using git in some form as a way to back up the yaml files.

As an option, you can also make an open source project for the yaml editor, to have auto-complete, know the home assistant structure and have built-in online validation.

It is a shame that the model used for automations, scenes and scripts was not extended to include integrations and helpers. The dashboards, which have raw mode, are not stored in a regular yaml file.

With three different ways of handling things, consistency lacking. This for instance also reflected in Watchman only finding broken entities in yaml.

As stated above, keeping config in GIT very useful, but currently way less evfective because it is only half the config. Searching yaml for usage of entities is now also less effective.

2 Likes