The future of YAML

A lot to catch up on so here goes…

I see a lot of references to the need to “restart” for changes to take effect instead of “reloading” as a motivation to do away with yaml. But I don’t think those are necessarily valid concerns. Or at least they are self-imposed limitations causing those concerns.

There are way fewer reasons to have to do a restart now than there were before.

We have a lot more availability of doing “reloads” of more things now than we used to that required a restart. At one time we could only reload customizations, scripts, automations and groups. And if any of those things were included in packages you also had to do a restart then because a reload wouldn’t work.

Now we can reload all of the above in packages too, input_* entities, and all of the Lovelace stuff (even if it is written completely in YAML like mine).

I’m not really sure if there was some sort of technical limitation that has changed to allow the newer “reload” functions instead of requiring a restart on those. But the question is then why can’t that same modification be made to allow all of the other stuff to be reloaded instead of needing a restart?

IOW, what’s the technical difference between an input_boolean defined in yaml and a sensor defined in yaml that allows the former to be “reloaded” and the latter required to be restarted?

The people who would want that type of solution already have those options. There are many, many commercial options that are “dumbed down” and made for the masses. HA has always been for those who want to “do more” than most commercial options allow.

You can make HA easy or you can make HA powerful but you can’t have both.

I see no real benefit for HA to just become just another appliance geared toward the least common denominator aside from the future profit it might bring to nabu casa. And if eventual profit isn’t the motivation then why do the devs want to dumb it down to bring in more users to the possible detriment of advanced users?

exactly.

This is a great community. People here are extremely generous with their time to help other people.

Just because we have disagreements over important topics like this doesn’t take away from that. I’d say that it’s a sign that we have a passionate user base that knows what it wants and is willing to say something when things are being done to impede that. To me that’s a positive.

yep and HA has grown into what it is over the years in spite of (or more likely because of) the flexibility that the yaml programming provided. How many have come to HA from other more restrictive platforms (like Domoticz)? It has to mean that HA, even with it’s “confusing and hard” yaml, was better.

Do you have any data that suggests that there are droves of integrations that aren’t being maintained simply because of the need to use yaml? If that was the case then there wouldn’t be over 1500 integrations right now because until recently everything used yaml and all of those integrations have always been maintained

Just because we don’t have a “flag” doesn’t mean we don’t contribute in many other ways. And it especially doesn’t mean that our opinions don’t count.

Generally speaking, yes.

How many times do we all tell new people to “post your config in text and not in screenshots” because nobody wants to be required to type all of the code out to correct/modify their code to be able to help them? I know I’ve said it a bunch. we all know it’s way easier for us to copy/paste/edit text than it is to write it all by scratch from a screen shot.

And for those reasons you will never really be able to use HA for it’s full potential.

But why should others who do use those things and, frankly, have been around for a lot longer than you have be deprived of the advanced possibilities/functionalities to cater to someone who won’t and doesn’t want to ever use those things?

And the exact reason for that potential is because HA is flexible/powerful and hasn’t been intentionally hamstrung by trying to cater to “the masses”.

No, it doesn’t “unlock” any other functionality other than remote access and easier voice integration.

13 Likes