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
I think we (well the frontend team and contributors, i’m pretty lost in frontend development myself) balanced that greatly with Lovelace tbh.
3 Likes
Thanks for explaining the reasoning @frenck, I think this post is one of the best examples of good communication between the development team and the users, especially with such a hotly debated topic.
One point from the myth busting section:
One of the problems I have with this approach is that .storage is constantly changing, and is mixing configuration and state. Instead of a clean history, real changes are often lost between things like battery level changes on mobile apps, last seen or last updated timestamps on various entities, etc…
Is there anything we can do for a cleaner separation?
4 Likes
Those are all stored in the .storage/core.restore_state file. I personally would exclude that file in the .gitignore in that case.
Good point, I’ll exclude it, but it’s not the only one. .storage/auth changes often (I’m guessing that can be excluded too), but also .storage/core.config_entries gets refreshed with new access tokens (and that’s definitely a file I want tracked), .storage/mobile_app (not sure if it’s a file I want tracked).
2 Likes
I agree.
Although I don’t customize the Lovelace UI nearly as much as others (a significant portion of the community’s posts involve deep-dives into UI customization), I do use the YAML version. The fact it is available is, in my opinion, an advantage.
I’m imagining an alternative timeline where the Lovelace UI was introduced without any ability to “take control” using YAML. Its internals would be stored in “Don’t Touch” JSON format. Given this scenario, I have my doubts the Lovelace UI would’ve been so warmly received nor have developed a large ecosystem of custom cards, as compared to our timeline.
So, yes, credit where credit is due; it was a good call to allow the Lovelace UI to be optionally configurable via YAML. Same for the Automation Editor’s ability to store automations in YAML (albeit not very legible YAML).
BTW, this thread would be half its current length if the announcement started with a mea culpa:
We spoke too fast when we stated YAML wasn’t going away. Since then we’ve learned new things and have changed our minds. We’ve decided that it will go away in some places but remain in others. It depends on the use-case. Here’s why we’ve chosen this new direction … etc etc.
11 Likes
It absolutely is imperative that configurations are shareable.
I maintain a dev and prod separation so that my messing around and trying things out does not disrupt the actual, usable HomeAssistant experience for the people I live with. This way I don’t have to explain how things used to work, how they work now and why I thought midnight on a Sunday is a reasonable time to break things like lights, alarms and the security setup.
Shareable configurations ensure that if something works on one system, it works on another and reduces time to recovery when things go wrong.
3 Likes
Exactly.
And exactly. The current method for delivery (on many subjects, not just this one) is “Screw you guys, we’re amazing and this is what we’re doing” unsurprisingly this is not well received by people. A simple change of tone from the ‘senior’ devs would work wonders for relations with the community.
6 Likes
I welcome the changes and really have no arugment for or against. I currently work for a company and we moved away from editable configuration files about 5 years ago. At first, we had this same pushback. Now… 5 years later, crickets. Everyone seems to love the UI only approach. We offer up a backup system very similar to snapshots. People just move the snapshots around and everything works. Our forums are filled with images of configurations instead of text files.
I think the arguments against this move home HA come from inexperience (with everything graphical) and an unwillingness to change. It really wont be as bad as everyone is making it out to be.
Will there be hiccups? Sure. That’s the nature of software. But to have all this emotion filled arguing doesn’t help anyone.
I’m sure at some point one of you yaml lovers will come up with a custom solution that gets back the lost configurations anyways. All it takes is 1 stubborn dev.
7 Likes
Snapshots only exist if you run the version of HomeAssistant that supports them, they’re not a HomeAssistant universal feature.
2 Likes
The snapshot is just a zip of the config folder. Literally. It’s not hard to replicate with git or a cron of some sort.
4 Likes
How will this change affect Hass-CLI that has no UI with which to configure anything?
1 Like
After some more digging, looks like .storage/auth can’t be easily excluded, or I’ll lose the Person <> User connection.
So right now, I have at least 3 files that are constantly changing yet include important configuration:
.storage/auth.storage/core.config_entries-
.storage/mobile_app(not entirely sure about this one, maybe it can be excluded)