The future of YAML

[finity]

@NK553

(options for integrations available in YAML should be kept in the flows).

This is what gets to the heart of the reason why some are opposed to this change. I don’t have an issue having the option for UI config. I use a couple of those myself (but I’m rethinking that situation after my experience with a broken HACS configured thru the UI and no easy way to recover…or I would rethink that if I still had that option but with this change I won’t…).

The issue is forcing users to only use the UI.

However, I will grant that the documentation isn’t always good. So I can see why there might be a push to bypass that. But the answer shouldn’t be to restrict users options. It should be to force devs to write good documentation. Which from the above sounds like is happening (finally?).

[cgtobi (Tobi)]

It is possible and has to be implemented.

[Tediore]

Thanks, I figured that was the case (and as someone else said some integrations already support it which I forgot about)

[pvizeli]

To go back to the original quote, the only reason I can see for something to be made easier so it will attract more people, is money . If there is no financial motivation, then why try and make it easy for the guy who can not program the clock on his Microwave to be able to use HA?

Yeah and that is the reason why the cloud is recommend, without you can’t use it. Do you see the Ironic?

The Goal of Home Assistant is ever time to make it for everybody, also for my Brother and Father, that is my motivation. Since 6 month they was able to start and build here own home, but there are to many barriers today which need to be lower. I don’t spend 18h per day for a small group of user, I spend this time to make somethings for all people.

[tom_l]

I missed the ironic. Soz.

In my defence, I am only just sober enough to type legibly.

[SeanM]

@kanga_who

My initial experience, along with thousands of others (I’m sure) was super frustrating, but you learn and you get help

Why should “super frustrating” ever be considered an acceptable experience that shouldn’t be improved upon? The attitude seems to be that since we all suffered through the same difficult experience as beginners, that future users should also be expected to undergo those same frustrations. Like it’s some sort of hazing ritual or something. I don’t agree with that thinking. If things are super frustrating let’s identify what those things are and come up with ways to reduce that frustration.

Making things easier is not some bad shady thing like you are implying. The only reason any of us are even using Home Assistant right now is because the contributors who know Python programming have made it easier and more approachable for others to use in the form of YAML. They could’ve simply said “read, learn python, make mistakes, get better” but they didn’t, because they wanted more people to be able to use it beyond just nerds and programmers. It’s silly to complain about things becoming easier for others when we’ve ALL been benefiting from that approach already since day one.

And another thing to keep in mind, there’s lots of others who often cannot receive the same level of help as us due to language barriers etc. Home Assistant is used all across the globe and translated to ~60 different languages. There are users who can’t read or write English too well (if at all) but the documentation, chat, and forums are only available in English. Simply saying “read the docs” is not nearly as easy for them.

@kanga_who

That was never the goal of this project.

It’s been the goal for a long time now if you have been watching the State of the Union videos etc. That’s why the Automation and Script editors launched in like version ~0.40 in 2017, so that users could do things from GUI. Then came Hassio which made backups, updates, and add-ons all super convenient without needing command-line experience. Then came Lovelace UI with the card editors, then Nabu Casa with one-click remote access and voice assistants, etc…

Things being harder back in the day was never some sort of intentional “feature” it’s just that the backend needed to be in place / more mature before the frontend portion could be built out.

Here is a good quote from balloob about this last year:

As Home Assistant grows and evolves, let’s make sure we don’t judge the additions and changes based on just our own perspective and needs. Think about how it can help other (potential) Home Assistant users. It’s our goal that a privacy-focused home automation platform is within everyone’s reach, regardless of background, location or income.

Paulus

[jfmcarreira (Joao Carreira)]

I feel like expressing my own opinion for what it is worth.

I believe the UI can be the way to go. I felt in love with Home Assistant and I am fully recommending it to my friends who want to start with home automation. Most of them have no programming experience and would most likely use some cloud based out of the box solution. I always try to push them against it.

With the UI getting more mature they are most likely to use it and enjoy the experience.

Or the other hand there are users like myself which love text based configuration (Gentoo Linux user here) and like to be in control of what is happening. I think we should not forget them.

I have a question (maybe feature request): why ui edited automations, scripts, etc are not stored in individual files in a dedicated directory? This could have the same impact on the UI, while being more readable. All automations in one file in one file is one of the reasons I do not enjoy creating them in the UI.

Thanks

[Emilv2]

• “I like to use a private git repository where I store all my data in, including my sensitive data, since it is not public. Without YAML this is not possible.” This is actually not true, the .storage folder contains all Home Assistant managed configuration files in JSON format, which in those cases, can be stored and versioned in a git repository.

I do like to use a git repo with sensitive data removed, it seems like this is not possible anymore then since there is no secrets file for the JSON configuration files.

[cgtobi (Tobi)]

This has already been answered.

@cgtobi

Restoring from backup works just the same way, as @nickrout explained one possible way, you copy you .homeassistant folder. That should be it.

Again, there is a difference between having a full backup and just some share files on GitHub.

I backup to my private git repo and that’s about it. Of course I also have a backup of that self hosted git server etc.

This thread is unfortunately not the ideal place to discuss backup strategies as it easily gets lost in the noise. So feel free to open a new thread to share ideas.

[someone]

IMO HA should stay a geek project for enthusiasts. If someone wants to use it, he’s free to learn and become a geek, too. The community will help every new inexperienced user to become a geek in this field - if the user is willing to learn. If he’s not, there are plenty of commercial easy to use platforms available.

[Emilv2]

@cgtobi

This has already been answered.

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.

[debackerl (Laurent)]

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.

[someone]

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.

[debackerl (Laurent)]

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

[Burningstone]

@debackerl

but only see the nice YAML-based options, nothing about the GUI.

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 .

[SeanM]

@kanga_who

@SeanM I don’t disagree with you on this and don’t think I ever stated it should be hard, my concern has always been that moving in this direction removes features for long term or advanced users. If “the old ways” of using YAML can be left to coexist alongside integrations this would keep the large majority of people happy. Not everyone will, or can be pleased, but this would certainly help.

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.

[debackerl (Laurent)]

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"

[danielperna84]

@Emilv2

I do like to use a git repo with sensitive data removed, it seems like this is not possible anymore then since there is no secrets file for the JSON configuration files.

Where does it say the secrets file will be removed?