At least you got it. 
Yeah. I went back and looked at the release notes and noticed it was on the list.
EDIT:
Correct.
FWIW, I remind myself that HA’s best features are also it’s worst.
-
Such a huge diverse range of devices and integrations … also means that something is changing somewhere, and that it’s virtually impossible to test every combination
-
A monthly release cycle (unheard of in other projects) means that improvements are rolled out to users soon … but also that bugs also get rolled out, and that maintenance certainly feels continuous
I personally appreciate that the UI is so much more user-friendly now … but the documentation retains the “by developers, for developers only” vibe by diving straight into uber-technical detail leaving regular users wondering what the heck is its talking about.
4 Likes
Speaking as one of the new audience, I too approach upgrading HA with trepidation and lots of scanning of issue trackers, so I don’t know that the stated intent of the OP is being achieved.
This isn’t a complaint - it’s an observation.
I’ve never actually seen a clear vision stated on this - what does HA want to be? The hobbyist tinkerer project, or the solid secure home automation platform that can be depended on to keep the lights on?
(these are not mutually exclusive, but you do have to lean one way or the other eventually)
It’s taken me two years of poring through Community pages and Github issues to write and re-write my usage of HA to something that semi-survives upgrades, device replacements, backup restore hiccups, and all the other quirks of HA design decisions. So if there were good old days, I’m curious how they were better, genuinely.
Take something trivial like turning the lights on. This is a mission-critical piece of functionality for a home.
I daren’t upgrade HA or addons until I have a week spare to thoroughly test & debug any potential breakage, because my loved ones will absolutely not tolerate pressing a light switch and nothing happening - or HA and smart goes in the bin.
The outcome of home automation has to be stable & rock-solid. That means not upgrading if upgrades break things. This is a self-fulfilling prophecy.
Would it be better if Core were split into e.g. a hundred addons and packages, each with semantic versioning? Run your upgrades like you would pip or npm? I’m pretty sure the topic has come up before. It’d be theoretically easier to upgrade and downgrade - but now you’ve got countless combinations to test, a need to truly grasp what is a breaking change (much harder than most devs think), and most of your audience will still just hit Upgrade All.
I suspect HA would likely be better off with a Year of Documentation & Updated Detailed Examples, vs the pain of that kind of rearchitecture - but some projects do eventually go through it out of necessity.
It’ll be interesting to see where it all goes.
2 Likes
In the “good old days” everything was managed in yaml and and you could create IDs as you like. There were even recommendations for good semantic names for those IDs. If you redesigned a bedroom into an office, with a bit of shell magic and a restart of home assistant you could rename the things that stayed in that room like climate, ceiling light etc. in a few minutes. If an integration fundamentally changed how it had to be configured and you had a dozen devices managed by that entity? A bit of shell magic and a restart and you were done in a few minutes. Through the UI theses things take a lot more minutes and sometimes even a few hours.
You can still do many of these things. The configuration still is yaml in .storage.
But it seems like the next step will be replacing human readable semantic IDs with autogenerated random strings and that will make that shell magic a lot more complicated and error prone and will likely also take many minutes instead of a few.
For things that have to work (like lights), I’ve stopped relying on home assistant. Wherever supported it’s device to device communication using ZigBee or MQTT) and home assistant is just an optional GUI, not in any way required to control these things.
Hi all. I completely agree and really miss the yaml old days.
I’ve got a pretty complex home automation and it was great to backup/port to other device/batch modify using only cli and explicit config files.
Of course, features are more and more impressive, but I’d like that a “developer mode” using yaml only for instance would still be available.
It is sad that HASS is becoming a “black box”, yet powerful.
The target audience has been shifting to the lowest common denominator mass audience for a while now. At least ostensibly. But many things that get moved to the UI under the guise of “make it easy” ends up reducing the functionality of the original config requiring non-user-friendly workarounds.
Literally every release comes with a litany of “backwards incompatible changes” (the artist formerly known as “breaking changes”) that everyone who is affected by has to deal with.
Almost every one of those changes force the user (newb or seasoned) to figure out the workarounds needed to restore the old functionality. These are always sold as “make it easy” when in fact they almost inevitably end up as “make it harder” for users of both experience levels.
Recent examples are (obviously) the topic of the latest kerfuffle being the scan_interval changes and the big one before that was the removal of the weather forecast attribute. Both of those (and many more…so many more) required the user to implement complex workarounds for something that was once simple built-in functionality.
OK, so some people were abusing the scan_interval. So instead of completely removing it make it optional with a warning against abusing it or just hide it with a drop-down in the UI config flow to open the edit field. The system can then leave the default at whatever it wants unless the user intentionally changes it.
The weather forecast attribute was removed in my understanding to reduce the attributes of the weather entities to make it easier for users to access that info (and maybe because of the scan interval so see above). But then the user has to figure out how to recreate the forecast sensor again by using way more complicated template sensors and manually calling services. And that workaround just ends up creating an entity with a bunch of forecast attributes that the user STILL has to figure out how to access. There was no benefit that I can see. It only reduced functionality and made getting back to the same point we were at more complicated. I don’t get it.
The alternative workarounds to both of those examples is not user friendly and is in complete opposition to “make it easy”. I keep putting that in quotes because that was the whole original justification for putting everything in the UI vs yaml and was basically the tag line of a blog post (the Future of Yaml) introducing the migration to the UI.
from that blog post in April of 2020:
Enabling configuration via the UI
Before talking about YAML, let’s explain the reasoning behind all the UI features introduced.
The Home Assistant project has grown at a ludicrous rate in the last few years. Being one of the few solutions to provide a local home automation platform, that puts privacy first, has gathered interest from all kinds of people on this planet.
In the beginning, Home Assistant was a small project; aimed at developers and the tech-savvy. With the growth of privacy concerns, but also the growth in the availability of IoT devices in our homes in general, the project gained traction; attracting lots of new community members that are not always the tech-savvy types.
This is great, but that also means we need to adjust, to make it usable for everybody. We want everybody to enjoy what we all have been enjoying already. No matter your level of experience.
Considering that, enabling and empowering people with managing their Home Assistant instance via the user interface is needed. Not just for the lesser tech-savvy, since it also brings convenience, that even many technically capable users enjoy and prefer.
Goal: Making things easier.
The goal of making it easier is currently the main focus.
Breaking changes
We all dislike them, those breaking changes when a new release is published. We all scan the release notes hoping you are not affected by any of them in that release.
There is a big upside on using configuration via the UI: Home Assistant manages that configuration part for you and handles the upgrades and migrations. Virtually removing the chances of hitting a breaking change, we all hate just as much.
“Virtually removing the chances of hitting a breaking change, we all hate just as much.”
That’s a bold statement and here we are three and a half years later still waiting for that promise to be fulfilled.
HA is over 10 years old but still with every release comes new challenges to try to figure out how to deal with constant (and mostly unnecessary and self-inflicted) “backward incompatible changes” to the point that many users (myself included) dread the new release because you never know what will pop up that could take hours of research to mitigate the effects of the latest and greatest “BIC”.
And my system becomes harder to maintain on every release because all of these workarounds cause the config to be spread all over between the UI, !include files and packages.
Actually it gets stored as json in .storage.
If it was yaml then it would be way easier to edit but the way it is now there is no easy/good/safe way to edit those files unless you really know what you are doing.
Yeah, what the developers keep losing sight of (and it was even mentioned in that snippet of the blog post above) is that HA became as popular as it did BECAUSE of the flexibility and power that HA provided. It wasn’t in any danger of getting LESS popular because there was no UI config. It was getting more and more popular IN SPITE of there being no UI config options.
The latest popularity seems to come at the expense of the things that made HA popular in the first place.
agreed.
8 Likes
It is always the same thing in foss community. Battle between make it simple and popular vs. keep it ui basic and let users mod it how they wish.
The best approach in my opinion will be middle of the road. Yeah make as much as possible in ui, but on the other hand give power users possibility to keep their mods and to mod it by their code.
It will always be like that. The only question is how to reconcile both worlds without loosing functionality.
I tend to agree. I’m trying to remain positive but slowly over time I’ve started losing excitement over the releases, and now just scroll down immediately to the “backward incompatible changes” hoping I’m not impacted this time. The last several releases have needed updates on my end to fix things.
First off, the word salad of renaming these breaking changes to “backward incompatible changes” in an attempt to make it sound better is admission these are a problem. Things that are positive and working well don’t need this “rebranding” to hide things. The users are not dumb and know what this means still.
I would expect these breaking changes more when Home Assistant was new, but after 10 years as you pointed out there should be some stability. I don’t have any other program that has this many breaking changes. I’ve heard many ask for an LTS release as a solution here - many other projects do this. Not sure why Home Assistant can’t have that at this point.
I’ve found myself moving more things out of home assistant and into node red and mqtt to try and insulate myself from these changes, but even something as stable and unchanging as mqtt they have managed to break with their “backwards incompatible changes” with the constant updates to templating requirements. I read the logic and github notes around these changes, and they always make sense individually, but I don’t think developers are considering the cumulative impact of all these. If this was a business and business software, a cost benefit analysis would be done for each breaking change to calculate how much in time and productivity it would cost the business to adapt to it. There might be many changes that seem like good ideas for code housekeeping or whatever the reason is, but the cost to the business associated with all the users to needing to reprogram would be too high to justify the change. I think a good approach would be to factor this in to breaking changes - they have the analytics and should know how many hours it will cost all the users of an integration to need to invest in updating. If its a lot of total hours, the change really needs to have some immediate and justifiable benefits, not just “clean things up for something we might do down the road”.
9 Likes
I’ve given up on this. It’s just not worth fighting against this anymore, it’s a waste of time and energy. The devs actively don’t want this software maturing to a point of stability. For reasons beyond my understanding they want to keep this software in a permanent beta, ever changing state. When a breaking change affects me now, I reprogram the missing or changed component myself into an external module and move the functionality out of HA onto my MQTT backend. It’s more work at first obviously, but it pays off in the end. I’m not dependent on the whims of some random dev anymore and if there is a breaking change, I have only myself to blame for it.
HA has become somewhat of an empty shell in my setup at this point, only used as a data logger and a (admittedly very nice) web UI. Oh well. Had I known this from the start when I moved to HA a few years ago, I would have saved myself a lot of headaches and endless hours of meaningless discussions on the forums about random breaking changes backwards incompatible changes.
I think my entire view of home automation changed. It was a great thing to tinker with during Covid, but now I expect maturity and stability from my system. I want to rely on it for my everyday life and not maintain and babysit all the time just because a random update broke something random again. Life’s too short for these kind of things.
5 Likes
I actually visit the forum pretty much literally everyday and have since I started using HA.
It used to be because I wanted to learn and I spent a lot of that time trying to give back to the community and the developers for providing this software for free (aside from my monthly NC payment) by helping others. After it was indicated in pretty much no uncertain terms that my help was not appreciated because I didn’t fall in lock step with every decision I’ve backed off on that quite a bit.
But I now still find myself watching the forums almost as much mainly to try to figure out what problems others are seeing to know if it affects me and if it does what I need to do to mitigate the impact without trying to figure it out from scratch all the time. I’m always worried that I’m going to miss that one thing that is going to be a big unforeseen pain point in my fairly extensive setup.
This project is so useful since it brings so many things together under one umbrella but it’s unfortunate that the monthly time spent on trying to maintain it is getting fairly tedious.
3 Likes
Yes, it is. The shift is towards the non-techy user who only cares about a pretty UI and simple controls.
That’s the direction, but not the goal. Meaning that I don’t think product management at Nabu Casa would kill the software by alienating the advanced users who are the majority audience.
With every major release I first read the breaking changes and then wait a few days for others to test it. Before upgrading I also take a snapshot of the vm besides the built-in backup. So far I’ve had about zero problems (knock on wood).
Still, I consider HA a superb piece of software. But it’s become clear that the pull towards giving it the feel of a toy is intensifying. There are already examples of this above, and don’t get me started on the mess of the new login page. In my opinion an IoT platform as powerful should move in the very opposite direction. If we wanted a pretty, fluffy approach we’d be all using SmartThings or some other random app.
All in all, the project keeps being cutting edge, amazingly stable and even user friendly (for open-source this advanced). But my advice to Nabu Casa is to not let themselves be lured by the temptation of flattening the software for the sake of making it nice in the eyes of everyone. Yes, that would be nice, but then it wouldn’t be Home Assistant any more.
5 Likes
Not at all the reason. It has to do with the way you provide your feedback, your past history with doppelgänger accounts, and the frequent arguments you get got into with other community members.
1 Like
I will agree to disagree and say no more.
2 Likes
I can understand the will to improve the system. But for example, lets just step over the fact that the weather forecast was changed and assume it really needed to become a service. What baffles me that, is it three months later, the service is changed again and is becoming obsolete in order to add support for getting multiple (same thpe!) forecasts in one go?
To what end? Who needs it? It likely involves calling all services one by one so it isn’t more efficient, the data structure now has fields that are depending on entity names which isn’t very good api design. How many of you ever felt the need for this? So hundreds of people, if not thousands, need to change their setup again. Because it seemed like a good idea to some one? Like so many things, it is an architectural decision without any regard for backward compatibility and with no business value for the user whatsoever.
Home Assistant is to become a system that everyone can use. Some of you might have seen that there’s a topic here about what happens to HA when the maintainer should die. Well, take it from some one who almost died: my wife was already thinking about hiring an electrician to take everything out. Despite two kids who both like IT. No one else can keep up with the changes. And you can only stop updating for so long until something breaks. And then the changes are sooooo many that you’re better off starting over.
So if everyone is supposed to be using this, there should not be breaking changes unless there is no other way. Because only enthousiasts are willing to keep up. And this way, even they are getting tired of it.
6 Likes
It was the number 1 request during beta when everyone was testing the feature. Without it, you ran into issues tabulating information from multiple entities due to the namespace & scoping limitations of automations. If you had to get multiple returned service data from any data returning service, you couldn’t loop across the entities. You had to manually enter each one as a separate service. Making automations, blueprints, scripts harder to manage. It made using entity/target selectors near impossible to use with the service, which are the foundation for blueprints and script inputs. There’s a lot more that goes into these decisions than you think.
2 Likes
Are they? 
How are things in your rose-tinted bubble?
There are 295,627 active installations. Are 147,814 of them advanced? Really?
I’d say 10,000 max. And if we’re going by the ones who hang out on the forum… well… counts on fingers… 
2 Likes
Anyone who ventures into using HA is an advanced user in comparison with the everyday Joe who uses off-the-shelf solutions. Obviously I’m not referring the “advanced” users among HA users. These will always by reduced a group. But I shouldn’t have to spell that out.
From the analytics, 26% of the installations are core, container, or supervised. I think we can agree that these are “advanced” install types. That means there are at least 76,000 “advanced” users, and that doesnt even include advanced users that choose to run a HAOS install, of an already complicated and advanced program versus something like Smartthings.
So while it might not be half, it’s more than 10,000, and it’s important to keep these users in mind when trying to make things easier at the cost of functionality.
4 Likes
l can appreciate that. But as you said, it was a strong request during the beta. Emphasis on the last words.
So the release of the change to a service call could been postponed altogether. Or the service call could have been prepared to be compatible with multiple entities before release (and add the actual multiple implementation later). Or it could have come with a big red warning: please keep using the attribute until we’re done, the service call is not definitive yet.
I tend to adjust to deprecation warnings a.s.a.p. because if I don’t I’ll run behind too much or i’ll forget it and have a breaking change later on. And now I’ve done pointless work, and I’m probably not alone. And on top of that the forum is now filled with example code on how to change to the service that is outdated.
This is what makes it all feel like others have stated: that there’s no restraint on preventing breaking changes and deprecations (delayed breaking changes). I realize there will always be breaking changes, I just advocate restraint.
2 Likes
No it couldn’t. The strong request came during 3 separate betas and 3 releases. 1 for forecast (get forcast), 1 overwhelming response for calendar (get_events), and 1 more overwhelming response for todo (get the todo events). All needing multiple. All changed at the same time.
I’m sorry that this change affected you negatively. But these are all things that many users use. These are all things that many blueprints need. Sorry, but the overall community need outweighs your opinion on this matter.
Yes, it probably was an oversite to only have a single entity callback when it was first introduced with the conversation agent. But as everyone knows, hindsight is 2020.
1 Like