I have to disagree. Lovelace is a great example in this case.
4 Likes
yeah, i stand corrected, because i already stated before that there were some big changes that were said before that they would never happen.
but in most cases it was custom code that was at some point assimilated.
still the general course has been quite a long time now:
- get as many users as possible, do the thinking for them, dont care when the users who contributed most are dissatisfied.
we had those discussions many times before, and it doesnt change anything.
so i stop responding here now, before you tell me again to go fuck myself. 
3 Likes
I donāt take any offense, but it would probably have been easier to quote that particular sentence of mine and tell me that, from a technical point of view I was wrong, no need to even be explicit about why or how. That would also stopped others thinking my guessings were right, effectively ending that part of the conversation there. But there is always a way of improve everything so, no problem with that.
I made that statement based purely on my experience working with JSON and YAML and what I know about hassio, which is that it is already capable of reading and writing YAML.
While it is not a discussion topic of this, I would love to be pointed to which key parts of the project are involved, itās not realistic to expect that I can figure it out myself on a reasonable amount of time.
1 Like
I donāt tell you that. I, for one, respect peoples opinions.
It is all about balance, and yes, decisions sometimes need to be made.
For what it is worth, I love YAML. Yet, I personally do agree on this being the best solution available. Hence, Iāve signed off on this as well.
Yes, I published / wrote the parts, the decision however, was made with a lot of people, including our main contributors.
Ok, I must be totally misinterpreting the nature of your reply to me because thisā¦
sounds in my head (and if I read it outloud) like you think Iām too slow to understand.
Anyway, Iāve said what I came here to say and Frenck clarified his stance on the subject so, Iām good.
Not at all. The first quote explains the second quote.
M-kay. 
To @frenck and all others that are doing this amazing job for paid or on a free time. Thank you very much for the effort you guys have made for HA! Looking forward to see new integrations also from UI. Only thing that I really hope is that the documentation would also be updated.
Keep up with the good work!
1 Like
Well, it has improved a lot already. Especially the fact that we block code changes if there is not a matching change in the documentation prepared.
This has been enforced quite a while now, and that ensures it keeps up.
However, I do agree there is a lot of other things that still need to be done. For that matter, if you see something, hit that edit button on the top right!
It is an easy way to contribute and help out 
2 Likes
Easy instructions here:
3 Likes
then you obviously have changed. thats great to hear.
a bit over a year ago you did (in discord PM), because i spoke out in a simular topic.
the decision was made long ago though. the moment that the storage directory was created first, this decision was made.
2 Likes
All I am reading here is bickering, accusations, and assumptions, yet those who dislike the changes not offering up solutions. Quite disappointing.
4 Likes
There have been some very constructive arguments made. That post however contributed nothing.
3 Likes
As an IT professional I will always advocate for readable, shareable and trackable configuration files.
If the change to UI-only configuration means the removal of these capabilities (which is my understanding of the post), I will review my continued use of this platform.
I understand that YAML isnāt newbie friendly for a lot of people (and donāt get me started on templating), but UI only will be just as unfriendly to a section of the current userbase.
6 Likes
To be honest I donāt think it would be necessary to share config if itās intuitive in the UI. The only thing you would share is automation ideas. The rest would everybody be clicking together easily then. No need for other to go wonder around in yaml and templates to understand half of it and still have 100 questions about how to do it themselves. (speaking from my own experience)
1 Like
You have to consider people wo:
- move configs between different servers
- made tests on their configurations with different hassio versions
- made bulk edits of dozens of components
Iām glad it works for you, but that is breaking lots of other peopleās workflows. People who has invested considerably amount of time on it.
8 Likes
Thank you @rpitera for that info. I am newbie with all of this and still have to rely on a documentation almost in every thing that I am going to do with HA. I will read those instructions you linked and maybe some day (over the rainbow) I am good enough to try with those. 
About the futureā¦ @frenck ā¦is there going to be some kind of āconversion toolā for older yaml based integrations that will provide that good old yaml to UI compatible? Or do we have to do everything with the UI from zero and what happens if the integration is not done for the UI? 
Totally agree with that. I much prefer updating configuration in readable and self documented yaml file (that can be versionned, sometimes generated, backupped, is repeatable, etc ā¦) than navigating through a user interface. Basically in an Infrastructure as Code or Home Automation as code fashion rather than what is already doing google and apple for more basic home automation.
I can understand why some user likes a nice GUI for configuration and itās true something has to be done to rationalize the architecture because configuration pieces start to be scatered all over the place.
I just wish we could have an option, like it was done for lovelace, to either manage everything in GUI or everything in yaml. Best of both worldsā¦
7 Likes
This is not a great way of looking at things IMO.
The whole idea is that you shouldnāt need to be a power user in order to operate Home Assistant. It shouldnāt be overly complicated to integrate your devices and services with Home Assistant. It shouldnāt require learning a markup language, spending a long time reading documentation, googling solutions in forum posts, looking up GitHub repos and YouTube tutorials, etc.
Everybody who contributes in these areas and assists the community is very much appreciated. But things should not be this difficult in the first place. Most people become interested in home automation to save themselves time and make their lives more convenient. When users are instead spending their valuable time simply trying to make things work and becoming frustrated, thatās not a great user experience, and we should fix that.
By suggesting that non-tech savvy people would be completely lost without power users to hold their hands, that shows the value of changes like this which are focused on making things easier.
8 Likes
If you want proof to refute your theory, take a peek at the Hubitat community forum. Hubitatās ārulesā are created exclusively via its UI; rules cannot be exported for sharing. So, are the users just sharing automation ideas and then just āclicking them together easilyā?
No. To troubleshoot their rules, or to share them, they post screenshots of the rules. They also report they wish they had the ability to export them because itās inconvenient to share them as screenshots (or only as ideas).
Thereās a strong argument to be made that Home Assistantās popularity grew because it was so easy to share everything (like the configuration of integrations and entities, automations, scripts, etc). More than one person has simply copy-pasted something, made a minor customization, and was delighted to have it work for them (sometime without having a deep understanding of what they just copied).
Anyway, this is all academic because Home Assistantās Automation Editor has always stored automations in YAML thereby making them easy to share (and thereās not even a hint of this feature being removed). Eliminating that ability would be unpopular, to say the least.
7 Likes