I understand the Reason to take this way. A lot of user there are not geek don t use hass because need to modify text file. But a good compromise will be to could modify configuration in yaml directly in the UI as same way than Lovelace yaml edit but with a better editor 
. what do you think of that?
1 Like
What are you talking about? I can copy paste that and all that I have to do is add my credentials on my secret file, which is clearly declared on this same piece of yaml you pasted. This answer in favour of the UI doesn’t make sense. I don’t want to manually setup things on the UI every time I upgrade my hardware
3 Likes
There comes a time in any project where everyone will have had their say but ultimately a decision has been made. At that point the whole team HAS to accept the decision and align with it. In the years to come, if it doesn’t end up as planned, you can have the smug moment of thinking “I told you so” but it doesn’t change the inevitable. To constantly spend a huge amount of time and effort telling everyone why the decision is wrong will just cause bad feeling in that team. We are the Home Assistant team and the decisions have been made and there’s at least be some effort to explain those decisions.
We’ve all seen comments from developers saying how demoralising it can be to have their hard work slated for not conforming to an individuals desires. Requesting changes is fine but trying to change the way in which they want to work isn’t fair. Surely we need to get on board with what is happening? We’re massively lucky to have Home Assistant. Remember trying to write python scripts on RPi’s connected to various components and then finding Cayene and thinking it was amazing? I can’t live without Home Assistant but if you can’t live WITH it, you have to find an alternative solution.
6 Likes
I think this is a bad decision. It is OK to go with UI, but UI will never replace YAML (/JSON) files. UI will always leg behind the capabilities the user wants / need, and as the requirements increases, UI is very difficult to maintain and develop.
I assume that most of HA users are DIY guys and have the capability to handle configuration via YAML files.
I really hope that HA will reconsider and keep the YAML configuration for all integrations and will not encourage going in one path.
5 Likes
it should never touch the configuration file?
i dont want to break your bubble, but all the files in the .storage directory are nothing more and nothing less then configuration files!!
they are filled by the system and even in the blog its stated that that should be saved.
those configuration files could be in yaml instead of in json (and not hidden) and it would be identical.
but i personally agree with you. the configuration should never be touched by the system. that is exactly why i dislike the fact that its done through GUI.
i add my new integrations in yaml in appdaemon. doesnt require a restart either.
and like i stated before, saving it in a hidden json file doesnt change opposed to saving it in a visible yaml file.
Oh yes, manually adding screenshots or copy-pasting stuff on every change you made is way better than just having everything easily readable from just the configuration. What a bland argument.
4 Likes
I think that answers your question, as best as I understand it anyway
As a hater of YAML in the beginning, after getting used to it - it seemed ok for me.
Since some time, I’ve been migrating all my stuff to new config flow solution and I really don’t want to go back to the times of restarts after every change.
Things are changing, but what is generating the frustration for newcomers is YAML for sure.
I can’t wait to see where it will get back in future tho.
You and @aidbish are the kind of people that, at the minimum requirement of agreement and debate say: “It’s my way, or the road”, “take it or leave it”, and it is not like that.
Home assistant is big because it’s community, and they should listen to the community that made the project grow. Forking a project and divide the community just because people like you don’t want to have some discussion is absurd.
4 Likes
My point of view is: checking whether it gets the job done. If it does, the way is fine/irrelevant to me. (though I can’t see the integration list grow even more from the way it is now, to a list with 1574 integrations in the future…surely that’s all easily solved when the need arises)
UI config is immediate, and requires no more restarts. Which is an absolute blessing. Please do keep that, and expand, as much as possible.
Where issues arise is when UI config limits the functionality we can have with the same integration in yaml (Philips Hue can only set allow_groups, and allow_unreachable in yaml, so we need both UI and Yaml config). Or forces us to use sensor.names with our gps data in the names (and yes, we can change that in the editor, clicking here and there a couple of times)
Or even worse, when (because of the) modernization of the integration (it) stops offering the functionality we had before (Asuswrt seems one of these, where no more consider_home, track_new_devices, or interval_seconds are allowed, from the days this was still a device_tracker…)btw, only noticed that because I had to replace the Nmap tracker which all of a sudden is broken, without being acknowledged by the dev team, or by any known breaking change…
Seems that in modernizing integrations, necessary (to some) functionality is thrown overboard, because (most) people wont need it. I find that disappointing tbh.
Also, I do see a lot of people contribute their free and unpaid time to the development of this beta software, and quite often they are simply ‘told’ their request/suggestion/experience is against guidelines or what have you.
Please listen to the folks that help build this software in their way, spending many fee (pun intended) hours in tinkering, and trying to follow guidelines on posting Issues on GitHub (which when done incorrectly is not always met with the same courtesy…) Think end-users are of prime concern. What/who else make a product for?
So, I’d like to repost that its not ‘us’ simple folk that should uncomplainingly accept free software that comes with no guarantee whatsoever because it’s open software, but that its ‘us’ simple folk that help making this great product even better.
Having said all that, I’ve just updated to 108.4, and my HA setup has never been so quick and multifunctional. I do mourn the further demise of custom-ui which is still most dearly missed, but other than that. Hurray for HA!
further reading:
Comment Removed.
Would you mind explaining what is a non-pro user? An user that is interested on home automation, that is able to setup a server or raspberry pi, that is able to make informed decisions about what hardware can integrate with their smart home solution but that gets confused because of YAML?
Not to mention that, of course, a non-standard unilaterally decided UI is way more intuitive for everyone despite their background. Do you know all the things involved on an UI? User expectations, accessibility, responsiveness, user experience, being used to other different UIs, discoverability…
2 Likes
And update it on every change of the UI. Please don’t ty to sell an ugly workaround as a better feature.
2 Likes
and thats what this discussion all comes down to.
i dont want a system that has control over configuration that i dont control.
i want full control all configuration, and not through a GUI, because i cant rearrange that to my wishes.
8 Likes
To all of those trying to reduce this to the simplistic scenario of:
angry nerd users against well intention devs that give their free time
please stop.
This is not an attack against a group of people, this is people not being ok about a decision they were not part of.
On both sides of the decision there are users and devs. Or do you think that all HA users are just users? Why do you think people contribute to a project? Because they use it, they find it useful and want to make it better.
So please stop telling to people that has already contributed to the project to go away and fork the project. Specially when all this comes from users that has taken advantage of both, devs work and other’s users sharing their knowledge and time to help them. I understand that you feel guilty and want to support the project for all what you taken from it, but all the people who has contributed to make it better and bigger (and this last part is key, please re-read it) has the right to express their opinion.
Let’s not try to use empty arguments or demagogy.
13 Likes
Is that easier? I don’t think so. Plus discovered MQTT devices tend to disappear and reappear during reboots randomly. No thanks.
3 Likes
People want things free and even complain about them, go figure it…
I’m a user, not a programer, jumped to the HA wagon and had to learn many many thing to make it work, linux, command lines, YAML, doing many copy and paste, and I loved it, had and still have a great journey with it.
It is understandable the move away from yaml in the integrations, I enjoyed implementing them in yaml in the configuration file, but had to restart HA every time I change something, now is much easier, love the new helpers ui implementation, when I need one, they are just couple clicks away, without restarting!
Even thou, YAML is very important for me, it is the only way for making my automations, scripts and Lovelace dashboard. The Lovelace UI builder is nice, but if you use more cards that the UI provide and want to customized de dashboard a lot it become very difficult, so YAML is better. the same for automation and scripts.
The ADR-0010 seems good to me as an user, YAML will be always an option for the things that really need it, and UI configuration for what is not needed, like integrations, which are one time configuration and even better not to be needed the HA´s restart.
The reload services for the YAML files (scripts, automations, customization, etc.) are great and should be expanded for every part possible to eliminate any need of restarting beyond updating HA.
The shareability of the users “configurations” should be maintained, I learnt a lot looking in others configs, I still do, and I don’t miss anything with the changes being made, I only look for how to do scripts, automations, templates, styling, etc. The more techy things, the integrations, and onboarding things are equal for everyone, are documented, so there is no need for be looking in another´s configs.
In the end, If you don’t like how HA works search for something else, and if use it, support it.
2 Likes
The only way I’d foresee this working is if there was a “RAW” editor like the Lovelace UI editor has because I actually loath the UI interface for doing automations.
4 Likes
Then why is it available to the user? You can’t have it both ways. This is where the credibility comments are coming from.
I have had to edit the json files to purge defunct devices from the system on several instances because leaving them produced errors. If I hadn’t been able to do that, I would have had to start over.
4 Likes
So maybe a solution to all the whining would be something similar to the way you can configure lovelace via yaml/storage methods? eh?
2 Likes