The future of YAML

Blog
44

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.

3 Likes
45

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.

10 Likes
46

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.

1 Like
47

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.

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

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

28 Likes
48

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

49

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 :slightly_smiling_face:

1 Like
50

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

18 Likes
51

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.

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

…/Frenck

2 Likes
52

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

53

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.

5 Likes
54

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.

1 Like
55

So it was the latter then. Good to know.

56

You have a hard time reading :joy:

Already then, time for me to get some sleep!

…/Frenck

2 Likes
57

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

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.

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.

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.

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. :wink:

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.

2 Likes
58

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.

23 Likes
59

Ok, so if the goal is to make the user experience easier, then why are transport items not included in that level of integration? MQTT devices account for 95% of my devices and I suspect similar for the majority of users. Yet, we still have to add them through yaml edits. I suspect that this will also change to the UI and may as well be removed for “simplicity.”
I don’t necessarily mind this but I think it is a bit disingenuous to state that moving much of the integration to json is for security of user data and ease of use but not encrypt passwords.

3 Likes
60

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.

61

The intentions were presented in the state of the union (was that how it’s called?). Put simply, the goal for version 1.0 is to make Home Assistant more accessible and easy to use for non-pro-users. To me that perfectly matches the choice to go with UI integrations, with the option for integration developers to additionally maintain yaml-based integration if they feel it serves a purpose. :man_shrugging:
And lets not forget: usually an integration is set up only once, and from that point on it’s working. It’s nothing that’s being edited every other day. Whereas automations, scripts etc. do change frequently in direct comparison. And those are the things where, for now, yaml will still be available.

8 Likes
62

The simple solution to this would just be to add a comment to the top of your YAML file?

# This integration can be set up under Configuration -> Integrations
# Once that is done you can use all my awesome automations below

This way the user gets a really nice and simple guided setup process.

I don’t see how this below example code is of much use to anyone:

integration:
  username: !secret integration_username
  password: !secret integration_password
  api_key: !secret integration_api_key
  port: !secret integration_port

This cannot be simply copied and pasted since it’s specific to you. It doesn’t tell users where to obtain the API key or anything like that, they have extra work to do still. And it requires a restart too unlike adding it from the UI. And what if you shared a minimal config? I would be potentially missing out on options that I could’ve seen had I set up the integration myself.

The useful things to share are automations, scripts, template sensors, icon customizations, etc - which can all continue being defined in YAML. I don’t think it’s necessary to have integration config there too.

5 Likes
63

You don’t see it. Plenty of people did.

I thought about chucking comments all over the place, but I didn’t like it. It messed with my OCD.

It’s not all about username and password, it’s about configuration options. My telegram codes require using the bot with parse_mode html. How will readers of the repo know that I selected that when I set up via UI? They won’t unless I put it in a comment, when it’s configured in yaml on the same page as the automation it’s there for all to see.

It may only be small things but lots of small things add up to a lot of time to keep on top of, and I couldn’t think of a decent way to cater for it all and also keep the repo ‘tidy’.

Before these changes I didn’t have to spend any extra time writing comments or whatever, I just pushed my changes and they explained themselves really.

4 Likes