The future of YAML

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

[anon3881519]

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.

[anon43302295]

@danielperna84

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

[danielperna84]

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

[SeanM]

@anon43302295

I then shared my configuration with the same level of detail, and people could look at my lighting package and see what integrations I used and what automations controlled them.

My github then basically became a load of automations only as the configs moved to UI. I started getting messages saying “I’ve copied this and it doesn’t work…” and I had to reply with instructions for them to add the integrations that the automations depended on, whereas before they could have seen it in the same file they got the automation from.

I got fed up with it in the end and binned my github repo. I still get people begging me to put it back up, but I’m not happy to do so until I can think of a way of somehow maintaining a list of what things rely on a UI configured integration without making a frick load of extra work for myself, as unfortunately I have a lot of other things irl that take up my time too.

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.

[anon43302295]

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.

[anon43302295]

@danielperna84

…for now…

dramatic music

{bat sense begins to tingle}

[Silicon_Avatar]

Comment Removed.

[chickenandporn (Allan Clark)]

So mark the yaml-dropping Components just like cloud-polling / local-polling are marked. Let us see which components are dropping Yaml. Shoot, let us filter the list so we’re not even distracted by those for whom yaml is sigh oh so burdensome.

[firstof9]

One thing I don’t like is when you setup an integration only to find out the configuration has failed even if you followed the documented configuration and have to restart Home Assistant 3 more times to get it working right.

It makes my zwave network very unhappy. So I welcome anything that causes me to have to restart Home Assistant.

[tom_l]

So you have this nice thing.

You want to grow this nice thing because if you don’t it tends to stagnate and die.

Understandable.

Pissing off a large section of your loyal user-base to grow the nice thing?

Unfortunately that has to be done sometimes simply due to practicalities.

You have to be very careful about choosing your new target demographic though. For example:

@danielperna84

But my everyday job is being a developer, and I constantly have to deal with situations like the once shown in this comic:

By dumbing down the nice thing you are going to attract a lot more dummies. And the situation shown in that comic is going to become more common, not less.

Ask yourself, do you really want Home Assistant to be used by people who would have trouble setting a clock on a microwave oven?

This is all a bit rambling and I do have to admit that so far the shift away from YAML has not affected me adversely. I can only remember one or two occasions where I had to delve into the undocumented .storage black box to fix things that were not fixable via the UI. That was in the early days though and I have not had to do this lately. I do actually like discovery and the way my commercial and DIY devices seamlessly integrate into Home Assistant.

One thing that has become slightly more difficult is community support. Rather than asking for correctly formatted configuration code so it can be easily cut/pasted/corrected I find I have to post more screenshots edited to show a button press procedure. This is time consuming and tedious but I’m not forced to do it. So I may just end up doing less.

Also I learned YAML and it was surprisingly easy. So new users should have to learn it as well. Now get the hell off my lawn. ~ Wanders away yelling at clouds ~ /jk

But seriously, I find it more efficient to define automations and scripts in YAML and JINJA than the UI and if the current ADR ever changes to exclude that I would have to re-evaluate my use of Home Assistant. It is good to hear there are currently no plans to remove this.

[DavidFW1960 (David)]

@tom_l

I find it more efficient to define automations and scripts in YAML and JINJA

Same even though I use Lovelace in Storage mode and I maintain lovelace in yaml and use cut/paste so I kinda get the best of both methods. I have pretty much switched to everything via GUI except scripts/automations and when GUI adds new support for integrations I switch to use them. I don’t see a good reason not to use the GUI where possible for that kind of stuff.

[tom_l]

@DavidFW1960

I use Lovelace in Storage mode and I maintain lovelace in yaml

I forgot about the the front end. Yes this is the best of both worlds.

[finity]

@danielperna84

What reason do you have to read and, more importantly, edit this?

I have an example of needing to do this…

A few weeks ago after an update/restart my frontend wouldn’t load (of course I did a config check first just like every other time!) and I started getting errors in my log about the HACS component (along with a lot of other related/unrelated things). And of course we all know that the first recommended troubleshooting step is to remove the offending custom component (it says so right there in the first lines of the log).

The problem was that I had HACS configured via the UI at some point and because I didn’t have access to the front end I couldn’t remove it via the UI. I was then pretty much stuck. It literally took several hours of troubleshooting/editing the .storage files to purge them of anything HACS related/etc. until it was all back up and running again. I even eventually had to create an entirely different virgin HA docker container and added things back a bit at a time from my original config until I “found” the issue.

So…without being able to edit those mostly not-easily-readable JSON files and then knowing how things were supposed to work in the first place because I usually configure (mostly…) everything in yaml I would have ended up needing to completely restart my main config from scratch. And even with my experience with things HA related I was still unsure about where all the bits of the HACS integration were spread out in the .storage files.

I still don’t know why things got broken like they did but I’m fairly confident in saying that if I was one of the newly-targeted “non-tech savvy” users I would have been completely lost on how to proceed to fix things. And having everything configured in the “black-box” of the hidden .storage files only adds to that.

And since there is no “customer service” that the non-tech savvy user can reach out to for help they will come here. Then we are supposed to try to help them fix their broken systems by telling them…what exactly? To use SSH/SAMBA (which they probably don’t know how to use and haven’t ever got it set up) and go into their .storage files and edit those un-editable files that are written in unreadable JSON and to delete every reference to some UI configured integration that might be spread across several files? But "oh, yeah…make sure you don’t mess up the syntax of those mysterious files because if you do all hope is lost for ever fixing it without starting completely from scratch. But, hey, no pressure. “Wait, you didn’t make a backup?” Of course not. And why would they since the new target user is not tech savvy…