The future of YAML

I don’t have a contributor flair, but I have submitted both code and documentation PRs that have been merged, and I appear on the list of ‘built by these awesome people’ so I don’t think the flair is a good indication of contributors.

Also, I actually didn’t complain about the change. I just pointed out that it will make it harder for me to help others. I think I’m considered a ‘power user’ so I can just get on with it for my own configuration. I just won’t be able to help new starters as much.

My ‘complaint’, as always, is in the delivery of the ‘news’ and the anxiety that it brings in for people who are using this software to automate their homes. If you don’t feel you can trust the dev team, it’s worrying.

That’s not entirely true either. Most of the complaints in that regard are born from actual observations of how people are treated.

7 Likes

I really don’t understand what’s wrong in quoting you and giving my point of view in the light of your comment and this topic in general. Documentation is one of the ways one can contribute.

It’s part of the discussion and I didn’t want to reply to every single person individually as it forms a complete picture.
I did not want to offend you personally or anyone else sharing here their views.
Quite the opposite, I tried to stick to the facts and to explain my vision of the situation.

2 Likes

Usually there’s a cog in the upper right corner to re-configure an integration.
Example:

image

Not all integrations have this option for their own reasons, but quite a few do.

1 Like

Yes fair point, and I agree.

I disagree. The help will just be different. As I stated above, my company went through this exact change. We went from a text file only configuration to a ‘snapshot encrypted zip file’ configuration.

The only thing that changed was how we help people. Documents that were created contained screenshots instead of text lines.

That’s about it.

Not every argument for a PR is won. I’m just saying that it doesn’t get ignored.

2 Likes

That’s not quite what I was saying, but it doesn’t matter :slightly_smiling_face:

1 Like

Maybe that worked for your company. Could you give us a bit more of background of what you do so we understand how this was better for your use-case and how it relates to home assistant?

1 Like

I looked at two, IKEA Trådfri and Unifi. IKEA does not have one, and Unifi does…but it does not allow you to change the IP, only a bunch of other options. So if you, for some reason, changes the IP of a device connected to an Integration you cannot update the configuration through the UI. And if it behaves like the IKEA one, you need to delete-restart-add to change the configuration otherwise all the entities would end up with new names. So that kind of defeats the purpose of not needing to restart HA when you configure Integrations in the UI.

1 Like

It doesn’t have to be like that. There maybe some technical reasons as to why it’s like that, contact the codeowner and or submit a feature request :slight_smile:

Is this related to this change because you were previously able to change it manually or you are just commenting some problems you had with the new UI?

You make a great point there. Maybe I went on this a little too short sighted…
To be honest I’m just happy to see that it is moving in the UI direction, I’m not so great at YAML and never tried and probably never will do that templating thing…

@123, I know I came from Hubitat. But to be honest I think their UI is an terrible example of UI in itself. And that is the cause why it’s not for everybody. I tend to do as less as possible with RM. And the whole reason how the HE team reacts to suggestions and complaining is the reason I’m back here. I was here before Hubitat, but couldn’t figure out the whole YAML stuff and went to Hubitat. But I still think HA is the platform with the most potential in the market. Even compared to closed source platforms. So I’m going to invest in HA for the future and since I can manage my current demand in automation with what HA currently offers I’m very happy with what has been done the past year!

3 Likes

Sorry I thought we were relying on UI to get things done from now on :wink:

this is meant wholly light heartedly

3 Likes

I could have and chose not to do so. No need for naming names and throwing mud, is there. If anyone feels like I directly talked about them, that is most likely not the case. I spoke of the general tendense and more than a handful of users that I feel are out of line. This is my personal opinion, and if you disagree that is fine by me. I am just trying to get the point across that we can all talk like adults.

You are right, I stand corrected. My assumption was that the fast majority is using HA as a free product.
I have no idea about any numbers of paid usage, and honestly I’m too new to HA to really know what the paid tier actually brings.
Please correct me if I’m wrong but I think we’re talking about Nabu Casa here? My understanding of this was that this brings a cloud service to HA without having to set up your own SSL and port forwarding in your router. Or does it also extend the GUI / Yaml interfaces?

Nabu Casa also makes setting up voice assistants super duper easy. I’m surprised I put up with emulated hue for so long after this being available.

However I configure the Cloud component via YAML because individually clicking 150+ entities to enable/disable them is a complete PITA

1 Like

I can’t dive too deep into this but we have a software package that had configuration files that were set up in the UI. The UI drove text configuration files, something that looked like this:

CATAGORYA PARAMETER_A 0
CATAGORYA PARAMETER_B 1
CATAGORYA PARAMETER_C 5400

Now immagine 100s of these files and mix in .ini files here and there all residing in one location. Oddly enough, we called it ‘config’ as well.

Everything was text editable and required a restart if edited. If you edited through the UI, it did not require a restart. We also had a backdoor keyboard hot key combination that would bring up a text editor and you could view and edit the files that way (which also didn’t require a restart).

So…

Our machines measure things in all sorts of markets. If you mess with the configuration you can basically lie your way into correct measurements if you know how to manipulate the files. Not only that, you can shorten the life of your device if you use incorrect values.

The other drawback to this system was that people would drag files from one machine to another. This was no good because no two machines are alike.

It also held us to a rigid structure for our database which made development a pain in the ass. If we wanted to change everything a migration tool needed to be developed for each revision.

So we put an end to all that by moving to ‘snapshots’, we don’t call them that but I’m not going to use the real name.

The benefits of a software controlled configuration are:

  1. You can easily build a version controlled migration tool that handles upgrading and downgrading databases without impacting the customer. With a good api, the database under the hood doesn’t matter as long as the software understands how to get the information out through the migration tool.
  2. You can constrain what is placed inside the configuration. You no longer have to worry about Joe Schmo putting 1000 into a field that shouldn’t go above 10.
  3. 1 big ole database. You don’t need to maintain 100s of files. Everything can be contained in 1 big database. And you don’t have to hunt an peck for the information. Your software should do that for you.

Ultimately we did need to add a few tools to help users:

  1. We added a backup/restore function.
  2. We added a way to backup/restore ‘chunks’ of configuration.

In the end, the interaction users have now is now just done through the UI instead of text file configurations.

1 Like

[quote=“123, post:192, topic:186879”]
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.[/quote]

Absolutely, yes. I started reading the article and thought it was a sincere reach out to the community, and was impressed until I got to the ADR section where I was like… Wait, what? Are they flipping us off? … … Yes, yes they are. That is truly how it felt.

In the end, we need to find a way to move on. Would pretty much all of us “whiners” (words from those that say the other side is name calling) stand down if .storage was editable YAML, where the system could be in control it but still let us tweak things? Yes, of course, but that decision was already made quite some time ago.

Will everyone’s voices be considered going forward to see if there can be there be common ground in the future or will this be another Emby/Jellyfin in a few years?

Stay safe, everyone.

8 Likes

I’m only bothering to mention this because I’m sympathetic to your point of view that we should not attack people.

Calling someone “childish” is, by most accepted norms, a personal attack. You’ve effectively negated your request to “don’t attack people because your opinion is different” by attacking people whose opinion is different. It’s challenging to establish common ground this way.


I believe what fires some of the heated posts is this post made last year:

The statement was broad and did not make exceptions (like “Except for this, that, and the other thing, YAML is here to stay”). As a result, it has been interpreted as being one of the founder’s commandments (like ‘privacy focused’). For everyone who had used Home Assistant for more than a year (at the time) it was comforting news.

Since June of 2019, observant users have noticed the original statement isn’t without exceptions. Whether ones calls it ‘change of direction’ or ‘back-sliding’ (or stronger language) there was mounting evidence that YAML is not entirely ‘here to stay’.

Ideally, the original statement should have been clarified at the author’s earliest convenience. However, here we are almost a year later, allowing for more than enough time for people’s suspicions to evolve into grievances.

As I’ve already stated, this announcement might have had a warmer reception if it began with something like “I misspoke.” Instead, it comes across as revisionism; yes, of course, YAML is here to stay but

Having observed past contentious decisions, it’s highly unlikely that ADR-0010 will be repealed (especially that design decisions are now being codified). YAML will continue to be used but is being phased out for certain applications.

6 Likes

Which is precisely why I put a word ‘news’ in quotes earlier on. This isn’t news, it’s been happening for at least 11 months (I know this because I binned my github repo 9 months ago, which was a result of a two month uptick in correspondence), probably longer.

So to ‘write it down’ yesterday and say ‘this is brand new and this is what we’ll be doing from now on’ is, frankly, a lie and to deliver it in such a sketchy manner does not inspire confidence.

The announcement should have been made about a year ago, with in a similar vein to the ‘mea culpa’ suggested above.

2 Likes

Full disclosure, I have not used Hubitat but have watched their official instructional videos and I occasionally browse their forum. It’s good to know what others do in order to gain perspective.

Although Rule Machine’s UI won’t win any prizes for innovation (Bruce himself admitted it could be prettier but hasn’t the time for it) it is significantly more powerful than Automation Editor. That’s mostly due to the fact it exposes every possible capability via the UI (arguably it has to because there’s no other way to compose a rule).

In contrast, Automation Editor exposes some but not all of what can be done with an automation. If one were to say Rule Machine’s UI is a “terrible example” then it would be best to exclude Automation Editor from any comparison.

For anyone interested, they can view this introductory video and compare functionality for themselves. The video presents a rule (automation) that you should ask yourself how you would do it with Automation Editor.

To be clear, I’m not disrespecting the fruits of anyone’s labor. Automation Editor just happens to be one part of Home Assistant that needs to attract the attention of more developers. Much has been done to improve it and more remains to be done.

1 Like

To be fair, it’s extremely hard to get on that level. Not because of technical complexity but rather because of the culture of the HA Team.

You of all people should know that best. You’re so aware of this it’s even the first sentence of your Github bio.

“Slightly assholic at first sight :face_with_thermometer:

If a project is actually interested in contributions from outside the inner circle, it’s simply not possible for its team to ignore communication/cultural issues… let alone taking pride in them.

But that’s just my 2ct. Since I’m not a paying customer, feel free to completely ignore them.

4 Likes

Stating that HA would not be interested in contributions from “outside the inner circle” is ridiculous and untrue. Everyone interested in contributing is welcome to do so. HA as a project would not be where it’s now if this would true. Just take a look at the number of contributor alone for the core repository counts 1880 individuals who shared their effort to improve it.

So I really don’t understand where you get that idea from.

3 Likes