The future of YAML is going to be exactly what the paid employees want…so all the rest of you whingers can just crawl in a hole and be silent!
6 Likes
I’d imagine it is because it’s not meant to be manually edited and because JSON can easily be converted to a native Python dictionary. However, I’m a Python beginner and more importantly not one of the devs so I could be wrong.
yaml as well.
5 Likes
Those users have more time on their hands than me, clearly. I just liked adjusting my configuration and running a script to ping it up to github.
Not to mention that this method requires more effort to work out what devices / integrations / etc are relevant to which automations, entity_ids and whatever else.
2 Likes
Yeah python is also space delimited syntax. Lets go to visual basic or cobol.
3 Likes
I also see the move to the GUI very critically. First off, I dont 't like all that clicky stuff, it is usually inefficient compared to editing files. Second, my feeling is that I loose control. It is not about backups only, it is about getting a fast overview, how things work, and how things break. Without this maintaining my Home Assistant config can get a nightmare, as all the stuff is abstracted to some shiny stuff. I had problems with integrations before (Luftdaten) , could not fix it, so I dropped it and made an own template sensor… Not the best experience so far.
20 Likes
Fair point. I suppose JSON is closer to a dict than YAML though.
i read this whole blog like this:
we dont remove yaml (yet) on the places where we have difficulty removing it, but as soon as we see an option to remove it somwhere, we will.
why do i read it like that?
because in the last 4 years i have seen many statements from the devs, explicitly stating that they didnt want something to happen, only to change their mind a few months later.
I suppose JSON is closer to a dict than YAML though.
does it matter how you store it? the only difference is if you use the json lib or the yaml lib.
30 Likes
I’ll quit while I’m behind and leave it to the devs to answer that. Sorry, I shouldn’t have commented about it in the first place 
Pressing the little heart does not show nearly enough appreciation for this, so I’m also QFT.
13 Likes
Even though I’m not involved with this decision / direction, I definitely support it. But maybe for sort of other reasons.
As a software developer, you provide functionality for a set of users whose technical qualification is unknown to you. Because of that it’s desired that the users are able to use the software with as few problems as possible. If the developer does a good job (or the functionality doesn’t require a higher skill level from the user), then this is not a problem. But sometimes the configurations users have to make have a tendency to fail. For numerous reasons, but in a lot of cases simply because they don’t entirely understand what exactly they are doing. And in fact, they shouldn’t have to know. That’s the whole point for the devs to make those integrations. Users, in most cases, shouldn’t have to be aware about things like “if x, then you have to configure y, but use z instead if it’s a leap year”.
What I’m trying to get at: quite a few times I have seen people posting their configurations, and they obviously have copied it blindly from somewhere, seemingly not actually really knowing what they have copied. After all, the documentation tries to cover the typical cases. But sometimes they just don’t fit the requirement. And that’s the point where people get stuck. Or worse they copy a snippet from who knows where, and of course it doesn’t work as designed because some other bit is missing.
This is the point where the UI configuration, at least in my opinion, provides a solution that eliminates a lot of possibly broken configuration. Simply because a streamlined UI configuration doesn’t even allow you to do something stupid. And if users can’t do stupid things, they can’t shoot their own feet.
To put this a bit more into perspective: I while ago I occasionally had a look at what shodan had to offer regarding Home Assistant. And I’ve stumbled upon quite a few installations that where, at least to a certain degree, insecure because of bad configuration. Things like people believing the encryption of the http-component does anything to protect from unauthorized access. Or public MQTT brokers.
The point here is, that there just are enough users out there that don’t understand the details of what they are doing. And that’s fine. After all most people with a drivers license don’t know what the camshaft is doing. All they need to know is how to operate their vehicle, fill the tank, maybe change tires. Of course it’s never a bad thing if the driver also knows how to change the light bulbs. But for the car manufacturer it just makes more sense to keep it as simple as possible, and as a result have less customers with issues, simply because the customers don’t even get the chance to mess with their cars in ways that might break the car.
All that being said, within the context of Home Assistant I don’t really care that much about such a topic because I’m fine with both UI or YAML. But my everyday job is being a developer, and I constantly have to deal with situations like the once shown in this comic:
And being annoyed by such situations so frequently in my professional life, I can relate to other devs looking into solutions that prevent their users from doing anything else but what they are intended to do. Although I do believe that this is not the primary motivation for the Home Assistant devs, more a positive side effect.
Edit:
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! 
23 Likes
I’ve only been using home assistant for about a year and a half so maybe my opinion isn’t too valuable, but I understand the shift away from YAML for some things, especially to help home assistant reach more users and to reduce maintenance. I do like seeing all the integrations I have set up in configuration.yaml and do like configuring them in YAML but I can certainly live without that.
However, I create all my automations, scripts, etc. manually in YAML, so that going away would be pretty bad for me but based on the post that’s not the case, so that’s good.
Also, I have of course gotten slightly upset with a couple of changes in the past but I always go back to realizing that home assistant is very good at what it does and is, more importantly, free. And because it’s free and I currently have no ability to contribute directly to the project and can only provide user support here and on Discord, I can’t really complain 
5 Likes
So true. I never realised I was ‘programming’ LMAO…
The UI method sure does cut down on yaml formatting being off for the newer users 
3 Likes
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.
7 Likes
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. 
5 Likes
I don’t think you are correct. I don’t have time to go through every integration, but from the 0.108 release thread:
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).
7 Likes
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.
5 Likes