The future of YAML

[ReneTode]

@danielperna84

Oh, one more thing: if I’d get a dollar for every time a newbie posted “I can’t do yaml, I’m not a programmer”, I’d be rich!

to that i can relate after 4 years of helping people.
so i am not against a gui (i wasnt either against it, when they stated that there wouldnt come such a thing, because they didnt want anything from the frontend editing the yaml)

Although I do believe that this is not the primary motivation for the Home Assistant devs

can there be any other reason to store things in hidden files?

this hidden file from my setup:

{
    "data": {
        "entities": [
            {
                "config_entry_id": "78f99db242e24df392042d7e195cb881",
                "device_id": "2ae044d629be4fa1a246d4caf595bfd8",
                "disabled_by": null,
                "entity_id": "switch.switch1",
                "name": null,
                "platform": "tplink",
                "unique_id": "1C:3B:F3:41:04:2A"
            },
            {
                "config_entry_id": "78f99db242e24df392042d7e195cb881",
                "device_id": "4136a6c0c38b4813968113bf939fd09a",
                "disabled_by": null,
                "entity_id": "switch.kachel_kelder",
                "name": null,
                "platform": "tplink",
                "unique_id": "50:D4:F7:45:69:7C"
            },
            {
                "config_entry_id": "78f99db242e24df392042d7e195cb881",
                "device_id": "ed634752800d426ea0736a436dd18ffe",
                "disabled_by": null,
                "entity_id": "switch.tp_link_smart_plug_73c7",
                "name": null,
                "platform": "tplink",
                "unique_id": "50:D4:F7:45:73:C7"
            }
        ]
    },
    "key": "core.entity_registry",
    "version": 1
}

could as well have been saved as yaml, and not as hidden file.
that would have given the possibility to edit and to read it better.

there is nothing in python that makes that its better to store it in a hidden file. and the yaml lib is as good as the json lib.
so from programming point of view i see absolutely no reason to chose this way.

[danielperna84]

@ReneTode

could as well have been saved as yaml, and not as hidden file.
that would have given the possibility to edit and to read it better.

there is nothing in python that makes that its better to store it in a hidden file. and the yaml lib is as good as the json lib.
so from programming point of view i see absolutely no reason to chose this way.

What reason do you have to read and, more importantly, edit this? By editing this by hand you’re exactly doing what you’re not supposed to do. Manual edits in the core-files can lead to your system breaking. If you change the unique id, then the entity points at a non existent mac address. If you change the platform, then the configuration does not match what another platform of your choice would require. Only for the entity ID I would understand the wish to edit it. But I honestly don’t see a reason why editing it in the core-config could be preferred over clicking the entity in the UI and specifying the ID there.

[nickrout]

@anon43302295

And as for

Those contributors do this in their free spare time, for which we all are eternally grateful. It is their work that enables Home Assistant to do what it can right now. It is what automates your home.

So what about integrations that remove YAML support?

Some contributors have decided to remove the YAML support to reduce their maintenance and support burden.

… Everyone driving these changes is on the payroll, and thus they aren’t providing these contributions for free, they’re being paid.

I don’t think you are correct. I don’t have time to go through every integration, but from the 0.108 release thread:

Many integrations now available to set up from the UI

It is absolutely amazing to see all the upgraded integrations this release! Many contributors have gone out and added support to a lot of integrations to allow them to be configured via the Home Assistant frontend.

Not all of them were ready in time for this release; nevertheless, the list is amazing already:

• Freebox , done by @Quentame
• Monoprice , done by @OnFreund
• Roku , done by @ctalkington
• Doorbird , done by @bdraco
• Elk-M1 Control , done by @bdraco
• Logitech Harmony , done by @bdraco
• MyQ , done by @bdraco
• Network UPS Tools (NUT) , done by @bdraco
• NuHeat , done by @bdraco
• Rachio , done by @bdraco

I don’t believe any of those people are employed by Nabu Casa. I think that is limited to @balloob, @frenck, @cogneato and @martinhjelmare. Of course there are some that may be paid part time by Nabu Casa (as @cogneato was prior to full time emplyment).

[anon43302295]

I said the people driving the changes. The people you listed who are submitting new stuff and adapting old stuff to void it of yaml are doing so based on the policies set by the people you tagged.

I’d be amazed if any of those people would have refused to participate in this project if it were still accepting yaml based configurations.

[nickrout]

@system

Some contributors have decided to remove the YAML support to reduce their maintenance and support burden. The amount of energy that needs to be put in (to maintain both capabilities) can be too much and is complex. We have to understand and accept that. If we do not do that, a contributor could simply stop contributing.

So @anon43302295 you are saying the above is simply a lie?

[ReneTode]

the same reasons that the devs had, when they said they didnt want a gui managed configuration.

if i want to change or add a bunch of entities, areas, etc. its easier in yaml.
i got a bunch of cameras. and they have all different settings.
for example they have all different passwords.
i got them in a specific yaml file, and when i need to look it up, i open that file and find the password i need. or the ip that i need.

when i need to do that through the gui, then i would need to click through all those entities. after i already needed to start the gui, and go to the appropriate pages.

the fact that the devs did change their mind, doesnt mean that everyone needs to agree with that change.
and personally, i am a gui kind of guy.
i use the ubuntu gui, and do everything i can with gui.

except when i am programming.
i got over 600 entities.
programming with that is impossible when you dont have a good list of the things you need.
and no the gui isnt helpfull there.

first of all because of the partly translated stuff (which was also stated that it wouldnt happen) (might be better in a newer release, but i never found the option not to translate)
and then its all in 1 single very long list.

[anon43302295]

I’m saying, quite clearly, that whenever anyone criticises the direction this software takes the argument you get is “this is all done by volunteers”. It’s not.

The person who wrote this blog post is getting paid. The person who wrote the ADR is getting paid. The people who decide whether or not a PR gets merged are getting paid, and they only merge stuff that fits the narrative that they decided on whilst getting paid, regardless of whether the people who pay their 5 dollars a month say ‘please don’t take away our yaml’ or not.

This project got lots and lots of contributors before the shift to UI and I don’t think the people that are contributing now are only doing so because of the UI integrations. eg I’m sure if someone wanted to integrate something new and the only option was to add it via yaml, I don’t see why they wouldn’t.

[ReneTode]

@nickrout

So @mf_social you are saying the above is simply a lie?

im not saying its a lie, but for me as developer its hard to see it as a reason.

there is hardly any efford needed to translate from json to yaml.
its complex, because the devs MADE it complex, not because it IS complex.

[frenck (Franck Nijhof)]

@anon43302295

The person who wrote this blog post is getting paid.

Yes, I am. And I’m honestly really thankful for being able to spend all my time on this project, while still be able to provide for my family.

@anon43302295

The person who wrote the ADR is getting paid.

It is actually written by multiple people. I’m the poster of the PR.

@anon43302295

The people who decide whether or not a PR gets merged are getting paid,

You have NOT looked at the PR. That is for sure. You would have found out it is actually signed off by a lot of contributors that are not @ Nabu Casa. All our regular and large non-paid contributors were involved in the process. Not only the ADR, even the blog post itself.

I see you don’t like the choices made, which is said to hear. But you are reaching the point where you are starting to spread incorrect assumptions, that is not nice imho.

…/Frenck

[MatthewFlamm]

@frenck What about integrations gathering data from outside sources? Are these defined as “integrating services” and therefore are required to have config flow? Or is the distinction whether it requires a username/password type of thing? This doesn’t seem super clear in the ADR to me.

[anon43302295]

@frenck

You have NOT looked at the PR. That is for sure. You would have found out it is actually signed off by a lot of contributors that are not @ Nabu Casa.

So they can merge PRs that do not meet the requirements of the ADR? Or is the decision made by people who get paid?

I suspect the latter.

I can’t look at the PRs anyway, you banned me remember

[aidbish (Adrian)]

Arrrrggghhh this again

The same argument comes around every now and again. 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

Sorry this might sound harsh and apologies if your offended but this argument of YAML going away is old and tiresome.

Hopefully the ADR they have put out will end this nonsense once and for all and HA can continue to evolve
My last comment in this thread. Done

[frenck (Franck Nijhof)]

@anon43302295

So they can merge PRs that do not meet the requirements of the ADR? Or is the decision made by people who get paid?

I suspect the latter.

Or GitHub org has a lot of people capable of merging that. Not sure about the exact number, but we have over 50 maintainers for sure.

So no, not the latter, the first.

@anon43302295

I can’t look at the PRs anyway, you banned me remember

Yet, you made a statement about it. Thanks for being honest about that.

…/Frenck

[anon43302295]

@frenck

So no, not the latter, the first.

What’s the point of the ADR then, if you’re going to accept PRs that don’t comply?

[nickrout]

@aidbish

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

Absolutely.

And at the risk of people howling “but I am not a programmer” I refer people to the big “Fork” button on the github page.

[frenck (Franck Nijhof)]

@anon43302295

What’s the point of the ADR then, if you’re going to accept PRs that don’t comply?

It is a guideline that is composed with those same people… ?

So, no we (as in GitHub org members) won’t be accepting PRs that don’t comply.

[anon43302295]

So it was the latter then. Good to know.

[frenck (Franck Nijhof)]

You have a hard time reading

Already then, time for me to get some sleep!

…/Frenck

[danielperna84]

@ReneTode

the same reasons that the devs had, when they said they didnt want a gui managed configuration.

My memory isn’t that good (and such a statement must be from ages ago), but I believe this was more about priorities and not to say “we will never ever do that”.

@ReneTode

i got them in a specific yaml file, and when i need to look it up, i open that file and find the password i need. or the ip that i need.

Shouldn’t you keep such data within a password manager? At least to me, using your secrets-file to organize the passwords seems like a really bad abuse. That’s not what the file is meant to do.
In general such information should be kept in a separate documentation. Or at least in the company I work for we do this, and it kinda makes sense to me.

@ReneTode

when i need to do that through the gui, then i would need to click through all those entities. after i already needed to start the gui, and go to the appropriate pages.

Just so I get this correct: in some, for this discussion irrelevant, interval you change the IPs or passwords of your cameras (I assume you do this manually by browsing to the cameras web interface, one by one), and therefore have to adjust the configuration in Home Assistant to keep the cameras working? I use ZoneMinder for my cameras. And if I were to change passwords / IPs, I’d have to change them there one by one as well. And I guess pretty much any other recording-software as well. So the possibility of doing this in a text file seems to be more like a historical convenience, cause by a lack of UI configuration. I’d argue that if it just was configurable via UI from the beginning, then you wouldn’t even miss the possibilities yaml gave to you.

@ReneTode

the fact that the devs did change their mind, doesnt mean that everyone needs to agree with that change.

That’s true. But as said above, I wouldn’t put it that way. I don’t think the “never ever” attitude was what they had in mind. And even if they did, Home Assistant does progress. And sometimes progress needs adjustments in places where the convenience for pro-users was present, but can’t be maintained in parallel if the development pace should be maintained.

@ReneTode

i got over 600 entities.
programming with that is impossible when you dont have a good list of the things you need.
and no the gui isnt helpfull there.

I image it to be totally horrible to manage 600 entities in yaml. I’d much more prefer sortable tables with options to filter so I can quickly find what I’m looking for. The devices dashboard for devices coming from UI integrations for example is great to get an overview of devices.

@ReneTode

first of all because of the partly translated stuff (which was also stated that it wouldn’t happen) (might be better in a newer release, but i never found the option not to translate)

Again something that I don’t really believe was intended to communicate. With it’s international base of users it just makes sense to add translations instead of forcing everything to be in english. and I don’t get why this even would be a problem.

[balthisar (Jim Derry)]

I hate web interfaces. They’re a necessary evil sometimes, but they don’t use paradigms that everyone knows and loves. For managing large amounts of structure information, nothing is better than a spreadsheet or text file as a front-end to a database.

JSON or YAML, I hate 'em both, but at least YAML is readable without having to paste it into a pretty printer. Oh, and you can comment it.

The biggest problems with web interfaces, though, is that you can’t tweak things that aren’t present in the web interface. You can, but you risk breaking things, because they’re not documented.

I’m wondering if I chose the wrong time to switch to Home Assistant. Having complete control is what interested me versus my current solution (paid, which doesn’t both me, but closed). Web interfaces take away that complete control.

Essentially, moving to a web-only UI is about taking away control from the user, plain and simple.