The future of YAML

[frenck (Franck Nijhof)]

@123

Anyway, this is all academic because Home Assistant’s Automation Editor has always stored automations in YAML thereby making them easy to share. Eliminating that ability would be unpopular, to say the least.

I think we (well the frontend team and contributors, i’m pretty lost in frontend development myself) balanced that greatly with Lovelace tbh.

[DudeShemesh]

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:

@system

“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.

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?

[frenck (Franck Nijhof)]

@DudeShemesh

Is there anything we can do for a cleaner separation?

Those are all stored in the .storage/core.restore_state file. I personally would exclude that file in the .gitignore in that case.

[DudeShemesh]

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).

[123 (Taras)]

@frenck

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.

[Razgriz]

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.

[anon43302295]

@123

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.

Exactly.

@123

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.

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.

[petro]

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.

[Razgriz]

@petro

We offer up a backup system very similar to snapshots. People just move the snapshots around and everything works

Snapshots only exist if you run the version of HomeAssistant that supports them, they’re not a HomeAssistant universal feature.

[petro]

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.

[Razgriz]

How will this change affect Hass-CLI that has no UI with which to configure anything?

Introducing Home Assistant CLI aka. hass-cli

[DudeShemesh]

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)

[Ronaldt (Ronald ter Veen)]

Wow, haven’t been part of HA a long time but after reading through all the comments above, I’m quite amazed by some things said. This crying about really poops on the “great Ha community” that gets thrown around.

Some people… It may be out of frustration and in fear of their own beliefs on how a product (they use for free) should work for them. Even though it is developed, maintained and used by I don’t know how many more.

You can disagree with the path taken, you might be convinced you know a better way forward, you might have different look on things. That’s all okay, but please keep your tempor and don’t be this childish and unreasonable. That helps no one. Not you, not the devs, not any user.

I’m a programmer myself, tho not in the field of HA. I can relate to wanting to do things in code (or in Yaml) opposed to the GUI. I really get that. But I also understand the need for the GUI as “Yaml is so confusing and hard” is the one thing that always came back as a con in the comparison between HA and others like Domoticz. There is a huge following and need for a GUI. If you read the blog, it seems this decision is made to cater that, but not have the overhead and burn-out developers and maintainers of integrations.
I rather have working integrations in GUI than failing unmaintained integrations in Yaml.

Of course developers and founders of HA get in a say that is weigh in more than a single user or forum post. Some might be paid, some might not be. They all work towards the same goal, even though visions might differ. That is also what drives development, difference of opinion. If you feel strongly about a certain aspect, do the work and back your idea up. Talk about it with developers in Discord, find a way to get your idea heard. But please don’t attack people and start calling them out publicly because your opinion(!) is different.

Just my 2 cents.

[AhmadK (akasma74)]

@aidbish

The same people posting in these threads are normally the sames ones that are upset.
Just decide if you want to stay with the HA if its not going in the direction you want it to and accept it or leave. Its your choice

I love statements like this. “If you’re not happy with what WE are doing - shut up or go away”.
In this case it’s clearly not a community-driven project.
It’s a huge demotivator for both existing and potential contributors from the community.
What’s the point of spending one’s precious time if tomorrow they’ll face such a choice?
Actually, at that point it’s fair to rename the topic to “The future of Home Assistant” because it’s more than just “no more YAML”.

@anon43302295

I think the real problem is the way these things seem to happen here, it’s like the dev team are being shifty about things and it makes people suspicious about their overall intentions.

the real problem is that the community has no say and decisions are made “up there” with no surveys, RFCs etc.
what certainty can we expect? as I said - in that respect it is anything but a community-driven project as in community-driven projects people can contribute and influence the way the project goes.
and btw, I don’t think it’s only “evil dev team” - it’s more likely the general approach that is normally set by a founder, someone who pay salary etc.

@templewood

you are DISempowering the technical users who have valid needs to manage their configurations in YAML.

actually, it does much more than that - it means less options for those users to come up with some new ideas/tricks so in the long term there will be less and less thing like that because, let’s face it, it’s not ordinary users that usually create something amazing, and HA will lose them because to the current approach. not all of them and not momentarily, but it’ll do its job.

@kanga_who

It increasingly appears that the devs don’t want to involve the broader community in open discussion, before making changes.

I have never seen things like that happening here on serious matters so that’s the way it works.
that means we can use HA (actually, we are all testers), provide feedback, contribute code but we have no say when it comes to making important changes and nobody asks the community before implementing them.

@AJStubbsy

We are the Home Assistant team and the decisions have been made and there’s at least be some effort to explain those decisions.

There was no effort to find out is those decisions are welcome. And that clearly shows users their real role in this play. “Some effort” here is meaningless as first they decided to change something quite fundamental and after that they’re telling us we don’t actually need what we had.

@danielo515

Home assistant is big because it’s community, and they should listen to the community that made the project grow.

the first part is right but the second isn’t happening. people who make decisions play a clever game of persuading HA users that HA is created with them in mind, but that’s simply is not true and this topic is just one of many illustrations.

@Mariusthvdb

quite often they are simply ‘told’ their request/suggestion/experience is against guidelines

sometimes you won’t get even that. no response and your PR is doomed to silently die by timeout.

@frenck

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

that’s true and many of us did it but as I mentioned above, if we can contribute, test etc but cannot influence the course of this project, your appeal sounds strange.
what’s the point for us to help if one day we’ll be told to make a ‘tough choice’ because someone else made a decision that should make us all happy? that’s sad mate…

tl;dr it’s more than just “The future of YAML” that we’re discussion here.
everyone makes their own choice so basically it’s just one person to stay or to go.
and everyone who is staying agrees with the course of actions and methods used to enforce it.

[frenck (Franck Nijhof)]

@AhmadK

that’s true and many of us did it but as I mentioned above, if we can contribute, test etc but cannot influence the course of this project, your appeal sounds strange.

Thanks for quoting me there… Please start reading and try again. You failed horribly there imho, as I told how one could help out improving documentation…

With that response and quote you totally ripped that out of context, which is find rather disturbing.

Thanks.

…/Frenck

[petro]

@AhmadK

I love statements like this. “If you’re not happy with what WE are doing - shut up or go away”.
In this case it’s clearly not a community-driven project.

It is community driven. Start developing and you’ll notice… if you make a good argument for a PR, it will get merged. You’d know this if you provided contributions. One thing you’ll notice on all these posts against the changes is that not one of the people has the flag contributor next to their name. They make bold assumptions without facts backing it up. This is the point @frenck is trying to make. Come up with a good solution and it will get looked at and discussed. It will not get shoved under the table.

[nilrog]

I don’t mind switching the Integration config to UI. That’s something that isn’t done so oftenly.

But how do you change the configuration of an Integration that was added through the UI?
I looked at a few and I could not find a way to modify anything in the UI.

Are we supposed to delete the existing instance and add a new one? Last time I tried that, with the IKEA Trådfri integration, I got completely new names for all entities. So I had to delete the existing one, restart HA, and then add it back. Only then did I manage to reconfigure the integration and keeping the entity names the same so it didn’t break all automations etc. that used those entities.

[danielo515 (Daniel Rodríguez Rivero)]

@Ronaldt

But please don’t attack people and start calling them out publicly because your opinion(!) is different.

We are probably reading different threads. Could you please point to concrete disrespectful answers that are just personal attacks?
Also you just assume that everybody complaining is using the product for free. Why such assumption?

[petro]

@nilrog

But how do you change the configuration of an Integration that was added through the UI?

Yes, that’s a glaring issue imo. Hopefully it will be addressed in the individual integration. My advice for you is to write up an issue against the integration because it should show up in the options in the cog without having to readd it.

[frenck (Franck Nijhof)]

@danielo515

Could you please point to concrete disrespectful answers that are just personal attacks?
Also you just assume that everybody complaining is using the product for free. Why such assumption?

Please let’s not take that route. There is generally not ending pretty.

Thanks.

…/Frenck