Please stop move integration configuration from .yaml system to the current implementation UI web-browser based system

Configuration
1

First of all really thanks for the all the developer bringing us Home Assistant.

Here is my problem:
I really don’t understand why the developer are porting all the configuration for integration from the .yaml to the UI web-interface. I get that configure something from the UI is more simple. At what cost? The UI is good for basic operation, but when you have to custom config things it really don’t fit the purpose.

For example HomeAssistant with update 2022.02 moved AndroidTV integration configuration to the UI. Very simple to configure for the basic operation (put the IP address, port and hit ok), a nightmare if you have to make some more deep custom configiguration.

I really don’t get how do you think that this

Screenshot 2022-02-07 at 15.32.46
Screenshot 2022-02-07 at 15.32.46398×621 23.9 KB

and this only one very long line configuration experience
Screenshot 2022-02-07 at 15.32.55

could be better, simple and user intuitive than a propper .yaml configuration file.
Screenshot 2022-02-07 at 15.41.59

Another thing to consider is that transfer a configuration with a .yaml file is so simple like transfer a file from an instance to another of HomeAssistant. Whit the UI Configuration system you have to reconfigure all clicking an copy/pasting on the UI web-interface.

I really hope the developer stop this porting to UI web-browser based configuration until they don’t find a way to let coexist UI web-based configuration and .yaml based configuration system.
In the same way when you configure an automation in the web-browser home assistant write these information in a .yaml file that you can then manually modify or eventually transfer to another HomeAssistant istance.

7 Likes
2

Hi there,

I can’t say anything about that example.
But:
Homeassistant is intended to be accessible to a wide audience and many have problems with the YAML configuration.
Me too.
So I’m happy about any change towards the user interface.

Of course 20 years ago everything was programmed by code.
But the development continues.

Greetings Werner

3

It was a design decision made a long time ago. There’s a long thread elsewhere in the forum that discusses the pros and cons of the decision (I suggest you read it at your leisure). What you are seeing is part of an on-going conversion process.

Highly unlikely. It’s an ADR that is approaching 2 years old:

4

I tend to think that going from a nice “configuration-as-code” way to a pure UI one is a bit going against the flow as well, but for sure there will be no going back.

What I end up doing most of the time is editing .storage/core.config_entries directly, which is basically the YAML equivalent. In most case, I actually have no choice because the UI don’t support such basics as changing an IP or a key.

(Before anyone tells me I’m not supposed to do that, I don’t care :slight_smile: )

2 Likes
5

Ditto.

I’ve also found the need to edit .storage files but the reason I don’t normally suggest it to others is because, while it’s easy to explain what to edit, it can be challenging to explain how to fix a system borked by a bad edit. Any explanation that begins with “At the command prompt, type …” is going to be an adventure for the uninitiated.

6

Hahaha. Same.
There are so many different “command prompts” ending up somewhere different in HAOS that I wouldn’t know how to start explaining :smiley:

7

Hurdles for helping someone to recover from a bad edit:

  1. Cannot recall the installation method.
  2. Using HAOS but the SSH Add-on was never installed.
  3. No recent backup or last backup is an older release.
  4. No familiarity with a command prompt.
  5. Responses limited to “It still doesn’t work.”
2 Likes
8

Moving toward GUI is nice looking initiative… until devs figure out how much work it costs to cover all those configs to details.

1 Like
9

Big issue I can see for Tech-People is that we like to work with a VCS. Having those config files on yaml allows us to properly versioned our changes and be able to detect when/which change affects the current behavior.
The files into .storage folder are supposed to not be included on the VCS, so maybe what UI-Integration should try to do is move this configuration outside of .storage folder.
Keep configuration on yaml or json style shouldn’t be a problem, both could be good to be stored on VCS. If json is the final decision, would be good to have some mechanism to split those configs “per entity” to allow a better organization.

Maybe an interesting configuration for the UI part would be to add a button on any integration that was initialized from the UI to allow migrate this configuration to an external ysml/json file, then we would be able to edit/version this config

1 Like
10

While I can see that having a UI has its benefits so does having a yaml config file. Combined with VCS configuration as code is just the way to go for complex configs. This really feels like we are going backwards in time and I think at some point ppl will see this as a big mistake.

Also configuration as code and config through UI are not mutually exclusive. Why not make them work nicely together? The UI could just edit the yaml files for you. That way even for non technical ppl its easy to get into and when they have a need for configuration as code its easy to apply that as well.

5 Likes