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
That was answered in the first post.
That should not be the case. Imagine all the non geeks which only option would be to use a cloud based solution?
Home assistant should focus on providing an home automation alternative for those who care about privacy and control.
1 Like
Hi @frenck . Unfortunately they donât, even after wasting an hour finding and listening to the entire podcast in the hopes of finding an answer. I canât find any justification as to why the project would refuse functional commits of code that address a need that an overwhelming number of people in the community have expressed. It seems blatantly incompatible with the claim that this is a community or volunteer project. Since Iâm getting the feeling at this point that I (we) are being jerked around, I am going to be direct:
What is the technical reason that Nabu Casa and the Home Assistant project cannot move forward with volunteer commitments of YAML code for sensors?
Community depends on dialog and dialog is two parties having a conversation. The moment people start saying âThis is our decision for us, and weâre going to enforce it for you too. Discussion over,â it stops being a community and becomes something else. Is it so wrong to let people continue to collaborate?
2 Likes
The problem with that approach is that itâs very similar to what we have today, super messy. YAML users would understandably complain when an integration dropped YAML config (see top reddit comment on 0.108 release notes for example).
But under your proposal youâre allowing an endless cycle where an integration gets rewritten and drops YAML, someone else re-adds YAML support, then another person drops it again, etc. Instead of being frustrated just one time youâre allowing them to be frustrated over and over again. Thatâs a large waste of time for everyone involved IMO, from the contributors and code reviewers and also the users who have to constantly update their configs.
Your proposal still wouldnât satisfy the vast majority of complaints in this thread. Most of the people complaining passionately about this want to have their setup 100% YAML, your proposal doesnât really solve that. Those complaining about certain integrations being UI-only would still be complaining. It doesnât solve the concerns some have that YAML is âgoing awayâ because now you would just be feeding into that even more by hiding YAML integrations or referring to them as âunofficial.â Etc etc.
IMO itâs better to just rip off the bandaid now and set clear expected guidelines on this stuff in order to keep a sane user experience.
4 Likes
as I said. itâs not about having a gated community. but one can expect the non geeks to be willing to learn. you know that saying: Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime.
HA should be all about teaching how to fish.
1 Like
Yeah thats true. One thing that might worry me is that most likely the non geek might also not have the same concerns about privacy. Just want things done no matter what.
However, I do not think that the HA could ever provide its full potential in UI mode. There are so many options. In the end every user need to learn how to create YAML for scripts/automations etc. But we should hook them up with easy integrations. After they see that the things work with HA they are less likely to walk away 
2 Likes
Maybe a bit off-topic, but since we are talking how to make it easy for new users. Didnt Nabu Casa for instance ever thought about selling pre-installed devices with HA?
This could hook more people in as they would have a starting point.