It was not a question, just a conclusion. I do like to have a full backup in git that I can share and that is simply not possible anymore. I understand that the HA devs want also graphical configuration, but if this solution is the best way they can come up with then I think it’s best to go back to full yaml configuration and ditch the UI configuration.
Very sad… our IT industry is maturing with Infra as Code, pipelines, everything as code, moving away from repetitive GUI interfaces used to configure systems. Here HA is going the opposite way.
Before we had Google Assistant, Alexa, Mi Home, Philips Hue, and all Cloud Platforms, easy for non-technical persons, but indeed difficult if you value privacy. Otherwise… if you wanted to own your IoT, avoid the Cloud, and have everything working locally, you got to be tech-savvy anyway and went for HA. I relied on HA to replace all those apps, and now that I can’t simply copy & paste config with people or Git, it just got harder.
10 Likes
that’s a very good point with infrastructure as a code! that’s exactly where it should go. GUI never can be as easy on repetitive tasks as some code or task where you have to add more than just one integration.
And we still remember that ugly beast called Windows Registry. UI and some registry tweaks is not the direction we should go.
Now, I see news of integrations offering GUI-based configuration, like Logitech. I’m heading to the Logitech integration documentation, but only see the nice YAML-based options, nothing about the GUI.
Of course, this is a well-known issue, since the 90’s Microsoft had to make thousands of pages made of screenshot to explain all GUI options, while all modern Infra as Code or old Unix config files were taking a few nice manpages…
Maybe the next phase of HA is removing the documentation together with YAML and let user click-click everywhere like Windows users 
2 Likes
What are you talking about? The first section after “supported units” says:
The preferred way to setup the Harmony remote for your installation is via Configuration >> Integrations in the UI, click the button with
+sign and from the list of integrations select Logitech Harmony Hub .
2 Likes
First off I would like to apologize if I misinterpreted your comment. That is a fair concern, but historically it has never really played out like that. This is the first time that I’m aware of, and there’s a good reason for it.
Integrations are a bit of a different beast. There’s 1574 unique ones now, different code for each. It requires a lot of work and time to get an integration added initially because it goes through a (human) code review and approval process. And then it requires even more work to maintain that integration - lots of bug reports to address, some of which only occur on certain hardware or installation methods. Lots of time spent keeping up with changes to that integrations API and so forth. It’s easy to take these things for granted, but contributors often have to do lots of upkeep in order to keep integrations running smoothly for the users.
When you start adding extra burdens/requirements like maintaining two different configuration methods, it makes things a lot more complicated and time consuming than they already are. It’s adding complexity not just for the contributor but also the code reviewers I mentioned earlier. This is a bad thing, as a lot of integrations might never get off the ground in the first place. In other cases the contributor might abandon the integration due to stress / workload involved. Then users are stuck with something broken that’s not being actively maintained and not getting bug fixes.
So this solution puts all contributors on the same page, they have to support one method and not two. In theory it should be less stressful on them and reduce burnout, it will mean less bugs to fix, and should result in higher quality integrations across the board. Users will also be on the same page, they’ll have a consistent place to install integrations. And it’s easier and faster, and with no breaking changes or restarts. These benefits outweigh the minor inconveniences to power users who wish to still have 100% of their config in YAML.
I realize you’re probably still going to be upset with this change regardless of any reason for it. You had something working a certain way and wish for it to continue working that exact same way still, totally understandable. But hopefully this provides a little bit more context as to why things went in this direction. You don’t have to believe me, but I can assure you there wasn’t any ulterior motives behind this decision.
4 Likes
So we used to have an awesome documentation with all fields available and all. Now I can also get the example of Doorbird below, documentation is limited to a paragraph or two, no description of the list of elements to expect or anything, I guess we have to install and click to see, no way to know in advance features in advance. I mean, that ‘okay’ lot of software have limited documentation, but HA got us used to great extensive documentation for people who knew what they were doing.
" To add DoorBird to your installation, go to Configuration >> Integrations in the UI, click the button with + sign and from the list of integrations select DoorBird . After filling out UI prompts, click the gear icon to edit device settings. Enter device event names here to associate with a schedule in DoorBird app. See Schedules"
Where does it say the secrets file will be removed? 
2 Likes
This is only for integrations. And for the most part, you could never simply copy and paste integration config in YAML either and have it work right away, because values like your host IP, username, password, API key and tokens will ALWAYS be different from the persons config you copied it from.
If you’re going to have change most values anyway, what difference does it make if you’re typing them into a text editor and hitting save, or typing them into a web dialog and hitting save? It is pretty much the same amount of keystrokes/clicks.
So how exactly is it harder? In above example you can click a checkbox rather than typing out a full word “true” (easier and faster), and you can use the integration right away after hitting “Submit” button rather than waiting for a Home Assistant restart (again, easier and faster).
10 Likes
This is a good example thank you. How do I secure secret storage with the GUI? In the past I had control what went to secrets.yaml, and I could make sure it’s not part of my backups on Git.
Anyway, if you like to document your change management via screenshots, this is fine. But I used to be able to version my config via Git the right way: as any Infra of Code, I could commit the changes, and auto restart my podman container via a gitlab runner. All easy peasy, using best practices of IT. If a week later I notice a regression, I can easily see the history of changes.
About sharing online, I Google often pieces of config, which is not working that well with screenshots unless Google starts doing OCR.
It’s good to have choice, like Windows vs Linux. My point is that HA is now simply targeting the same user base as all Google Assistant, Mi Home, etc. I’m glad those platforms exists for non-ITers, but even Microservice started to recognize the limitations of GUI-only applications, and improve its command line again for power users.
2 Likes
If the config is not in yaml you can’t use the secrets file. When you put the .storage folder in git as they suggest all your passwords will be in plaintext in your git repository.
2 Likes
So put the auth files in gitignore…
1 Like
What are you talking about? There are no separate auth files, configuration and authorization are in the same file.
1 Like
But that only applies to integrations that are UI-exclusive. In some cases yaml-configs will remain available (at least for a while), and there the secrets-file should stay available. 
What#s the point in googeling how to configure an integration? It will only have so many options that will be documented if necessary. There’s just no reason to google that. Your point only applies to things that can come in different flavours, like scripts and automations. Which, as stated quite a few times now, will remain in yaml.
For now. If both YAML and UI were supported I would have no problem at all with this, but YAML configuration of integrations is actively discouraged, will receive no updates and already several integrations have dropped it.
1 Like
Great! Finally a GUI, so clear that people will never need to Google to find more information 
can’t wait to see it!
Alright then, I guess all I am missing then is to configure HA from my Ansible script using Selenium 
I just managed to configure fully my home server from Ansible scripts hosted on Git and applied from Gitlab Runner. No, more seriously, I will check what can be configured from the REST API, then I could still configure HA using a clean CI/CD pipeline by writing a few Ansible Roles.
1 Like
And how is someone supposed to commit code to address the issues if it has been stated in advance that such code will not be accepted?
“We will no longer accept any changes to the YAML configuration for existing integrations that communicate with devices and/or services.”
My main objection with this announcement is the refusal to let people address their needs for YAML through pull requests. Any of the following options would be OK:
- Only integrations that have a GUI configuration will be listed as official integrations.
- None of the people who signed the pledge to go GUI-only will contribute any more YAML code
- Any YAML code found for Integrations with GUI configurations will have the configuration greyed out and a message that YAML configuration was detected.
If nobody wants to support YAML for the integrations they need it for, that’s fine. But to tell them they cannot maintain or contribute that functionality moving forward, that’s something different, and it’s a bit disingenuous to call people out for not contributing code that will have been rejected in advance.
So what is the issue with refusing contributions for YAML configs? It seems like removing that bit from the ADR would address people’s concerns while still setting the priority to focus on the subset of users who prefer GUI.
3 Likes
Thanks for your view @templewood. 
Maybe it is an idea to listen to the latest Home Assistant Podcast where Paulus explains it a bit more.
Other than that, I think my previous comments cover a response on your matter.
…/Frenck
Why not keep YAML for the select few