The future of YAML

Blog
87

You don’t have to chuck comments all over the place though. Where you used to put your integration config, you’d simply replace it with something like this (most likely saving lines in fact):

# Set up this integration via Configuration -> Integrations 
  # Enable the following options: HTML Parser, X, Y, Z

I think this approach is much simpler overall - clear instructions for users browsing your repo, no confusion over secrets.yaml stuff, no possibility of breaking their config by improperly pasting YAML, no missed options, no need to restart afterwards, no breaking changes during upgrades since the config gets migrated, etc.

If you can accept needing to do things a slightly different way, I think this change is beneficial for the most part.

3 Likes
88

I see the reasoning in moving to a more UI-oriented configuration; but having everything tidy and machine-readible in one configuration file was for me always a key feature of Home Assistant. (I’m not saying I haven’t browsed this board hour-long to find the right combination of single-double-quotes to make the config work…)

Isn’t the obvious solution to keep both – that is, UI-based configuration and YAML-based configuration – and make a two-way converter as part of Home Assistant core? That would keep the good and proven flexibility and sharability of YAML but would enable Home Assistant to a broader audience. It would also lift the burden from integration developers; they simply integrate abstract read_config methods which deliver data defined either via UI oder YAML.

16 Likes
89

I would classify myself as a user (definitely not a developer) and am in two minds about that idea @Thewho

The present focus seems to be on building a low level user friendly environment.
It’s clear to me that comes at the expense of people who want a machine that is totally user friendly to those who want to dig in and learn stuff to make a personalised environment.

Is there even a roadmap for a stable version 1 at the moment?
When is it planned for? 0.150.xx? or much later?

Why not officially fork it now?

What if you forked it prior to the commencement of the UI and progress that to focus on a stable version 1 for those who want to delve in deeply with all the freedom of YAML config.
While on the other fork you can then continue to make your fancy UI to better interest your target group?

It would be very interesting to see which fork becomes the most downloaded, very interesting!

PS: To Be Clear…If something along these lines were to happen I would like this to be an official fork as I am a Nabu Casa subscriber and I want to continue with that fantastic service.

90

Agreed, this is forking time. This is HA’s big Darwin moment, it adapts to a new audience and you either make it the best at what it aims to be or you fork and keep on rolling as you have been. Either the low level audience is where it’s at or home automation is all about YAML-savvy people: fork and let’s find out. I’m staying with HA. Again, it’s not my preferred solution but at some point you have to realize there’s a greater goal here, a higher purpose, a use case that extends beyond my use case.

Why would I be mad if a project made by thousands and used by thousands doesn’t perfectly fit my one specific need?

1 Like
91

I do accept doing things a different way. For my own personal setup that is no longer shared with the community it makes no odds if they get rid of yaml completely - I’ll still use it as it’s the best tool for the job.

I just pointed out that the suggestion that people only need to share their automations isn’t necessarily true, and that the extra work that this approach caused me meant me removing a helpful resource from the community nearly a year ago now that people are still asking me to reinstate, but I’m not going to because it’s now just too time consuming for me.

As @finity says, the more things are made difficult to interact with, the less the community will be willing to help. I’ve certainly reduced my interactions here and on reddit because of this.

As I mentioned above, the thing that upsets me is not the removal of yaml, it’s the suspicious way such things are delivered to the community.

We’re not going to do that. We’re definitely not going to do that. No. Absolutely not. Here’s a long blog post telling you we ARE doing it and if you dare point out that we said we wouldn’t we’ll treat you with disdain.

As a point of interest, of the 10 ADRs that have been published, 7 of them have a link to the discussion that generated them (a discussion which technically any member of the community could have had their say in). Of the remaining 3 that have no public prior discussion, one is simply the explanation of the fact that ADRs will be the way architecture rules are now presented, and the final 2 are both about removing yaml.

I’m just saying that such behaviour, in line with a number of other things the ‘senior’ devs do raises suspicion as to what they are doing with a project that a lot of people rely on to control their homes, and it makes people anxious.

5 Likes
92

Danger Will Robinson!!!

Do you really have the ability to steer the development of a project that has about 75 git projects/repositories, half a million lines of code in core alone. Which provides releases in many formats every 3 weeks (plus point releases). I don’t see any one of the core devs (paid or unpaid) wanting to fork, until that happens, it is not a goer.

3 Likes
93

Splitters!

MontyPythonsLifeOfBrian-364M9eoT-subtitled
MontyPythonsLifeOfBrian-364M9eoT-subtitled700×394 63.3 KB

IMO there aren’t enough devs to address the current backlog of issues and keep moving forward with the roadmap. Dividing them (if any did jump ship to the new fork) would not help.

1 Like
94

I, personally, like the way HA is progressing for the most part.

I am looking forward to the day I can recommend HA to someone and know I am not going to be “technical support” for a very long time to come.

I like the idea of removing the breaking changes because it is controlled automatically through the UI.

I like that the more personalised parts, automations, scripts, scenes, etc, remain yaml and fully personalised. I recently split my automations out to seperate files so I could still have manually written automations as well as UI created automations, as I found it virtually impossible to set-up automations with zigbee devices without using the UI to initially tell me device ids etc.

I am very grateful for the works the devs have put in and very grateful to the contributors that have, and continue to, create some amazing integrations and continue to evolve and (for the most part) improve on them.

What I do not like is seeing someone spend a lot of time working on a project to evolve and progress their integration, only to be met with comments that are hurtful and/or not in the least bit helpful. I just imagine that person sitting in front of their computer thinking " Why do I bother if nobody appreciates my effort anyway?" Well I appreciate what they are doing, even if i don’t use the integrations they produce. That is what makes Home Assistant what it is, that is what sets it apart. The community around Home Assistant was one of the biggest pulls for many of us, but as the project evolves and many more people come on board there has been a stark shift in the number of negative comments and extremely unhelpful calls for help in the forums.

As stated by many people many times, no one is forcing you to use this free, open source software. If you are actually outraged at the direction HA is going in create a fork, or find something that more aligns with your goals. Do not think it is acceptable to make hurtful and angry comments at the people who have worked long and hard on this.

I am sure the devs and the contributors appreciate feedback and constructive criticism as it helps evolve and improve, but no-one appreciates being yelled at, even virtually, and berated because what you have produced doesn’t suit one person’s use case out of the ten thousand or more users.

Sorry for the long post, I just think some people need to take a step back and think about how they communicate online.

I also think Home Assistant is shaping up nicely and is pretty amazing.

Cheers and stay safe.

18 Likes
95

Love that quote!

No, nor do I want to, please read the rest of my comment. I put my efforts in helping HA succeed, however they choose to progress. (Well, ok, there are limits ^_^)

96

I wrote my first config flow for a custom component this evening, and all I can think about is how much easier this is for my users, and how well structured the framework is to build out a configuration flow. Kudos to everyone involved.

I still see YAML having value for scripts, automations, etc, but even that may go away eventually as more functionality is built into the editors in the UI.

(i admittedly was a “how do I back up?” complainer)

5 Likes
97

EXACTLY like this.

1 Like
98

@frenck are you going to switch from JSON to YAML in config files from the .storage folder? You said good bye JSON in UI and favored YAML. But all config files still use JSON? I think for the sake of consistency and to make things easier for people who want to maintain HA by files, not UI (not me) it would be the right thing to do.
In general however I agree switching to UI setup is the right move

2 Likes
99

I’ve been using HA for a long time already and over the years it has only improved for me. Yes, changes are sometimes difficult and i a have cursed developers more than on one occasion. But, overall the entire system improves with every release. Making it more accessible for common folk by making changes to integrations and YAML usage is a good thing. More users means more visibility. Other companies might even notice HA and start making integrations for us all to use.

3 Likes
100

Those are different things. The config stored in JSON is not meant to be read or written by the user. The YAML is.

3 Likes
101

I was disappointed to read this. I am happy that we are empowering the less technical users, but I see a problem in this statement:

In doing this, you are DISempowering the technical users who have valid needs to manage their configurations in YAML. I won’t restate the use cases mentioned in the comments, but there are several. If you were interested in empowering and serving your user base, you would allow volunteers to maintain the YAML that they both desire and need. Instead, what I see is a sort of authoritarian fiat to crush what is perceived as the minority. That’s unacceptable.

If people who use YAML want to volunteer to maintain the YAML code, marginalizing them for the sake of ideology is incompatible with the claim of this being an open volunteer-driven project. If it were technically impossible for YAML and GUI to both be options, OK, but that is not the case. So instead of producing a situation where the feature set is richer and more people can get involved (YAML and GUI) you are now producing a situation where the project is limited and could fork.

Please reconsider the prohibition of YAML, and allow people to scratch their collective itch where they are willing to put in the work.

23 Likes
102

As soon as anything becomes ‘monetised’ (yuk) it changes everything. We now have four(?) people whose very livelihood depends on HA and its success/growth. It impossible for the focus not to shift when that happens

This is where the ‘it’s open source be thankful’ argument begins to show cracks.

There is Open Source.
There is Open Source but for profit
There is Closed Source

They are all different things with different philosophies. And I believe the gap between the first and second is greater than the gap between the second and third.

As you (@anon43302295) rightly point out we have a handful of people now making decisions about the direction of HA based on very different criteria than those of us who ‘only’ use it.

Time will tell how that works out…

That was all meant to be objective observation.

This isn’t… :wink:

I’ve mentioned this before but for a system of, “home automation that puts local control and privacy first” it is ironic* that the first and still(?) the biggest ‘selling point’ for Nabu Casa is the fact that it makes control via Amazon and Google easy to set up.

*Actually I think ‘ironic’ is being kind diplomatic.

10 Likes
103

So this page https://www.home-assistant.io/docs/ecosystem/backup/backup_github/ will probably change to remove the following line:

# Ignore folders.
.storage

As the .storage folder is needed in backups now?

1 Like
104

No don’t do that, The problem I see is that the files there seem to have a lot of password info, like nabucasa hooks, my ssid and password for my access point, MAC addresses of all my esphome devices, my exact street address (in mobile_app), the lat/long of my office (as it is a zone). Once you share them to github, they are there forever.

How do we use the equivalent of secrets in automated configuration. At least in typing my yaml I can think on each line “oooh thats sensitive, put it in secrets”.

6 Likes
105

image
image541×850 71 KB

“…it won’t…”, but it slowly is. the yaml-ditching trend is in works I guess :frowning:

6 Likes
106

I have a private github repo so I just push everything at the moment, don’t see a problem doing the same with the .storage folder. I also take daily backups of my hassio VM so even the github backup might be overkill :smiley: