Is Home Assistant shifting towards a different audience?

21

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
22

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.

23

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
24

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
25

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
26

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
27

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
28

I will agree to disagree and say no more.

2 Likes
29

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
30

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
31

Are they? :face_with_raised_eyebrow: 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… :rofl:

2 Likes
32

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.

33

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
34

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
35

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
36

I think the devs will have good reasons for their decisions, and changes done to the integrations. Hoverer sometimes things are not taken into account, or not completely thought through.

The removal of the scan_interval is a change already introduced years ago, and applied to ping as well now. It might be more difficult to set up as simply changing a number in your YAML config, but it does give you a lot more flexibility in the end. And making it more difficult is one of reasonings behind it, as it will make it more difficult to overload an external server by flooding them with ping requests.
What wasn’t completely thought through was the default setting of 5 minutes, which has been corrected in 2023.12.1. Also the consider_home parameter has been removed, but there is already a PR pending to put it back.

Also the removal of the forecast attributes is really understandable, but (as also admitted by Frenck in the livestream) the mistake was made to not have the option to target multiple entity_ids in the service call from the start, so a new service call had to be added now (to avoid breaking the templates based on the old one, and giving the users time to adjust their config).

What is a bit lacking is the communication to the community. Some changes are hidden in the backwards incompatible changes and barely covered in the live stream, and should be communicated in more detail to the community. For these changes it would be nice to have explanatory (blog) posts which can be referred to from the release notes, and can be updated when needed.

As there was a vacancy for a Community Manager announced last month, I expect this to be one of the tasks of this new Nabu Casa employee

3 Likes
37

I think the community manager cant hurt, but I dont think this is just a communication issue. Have they considered extending the beta testing period for future releases? Its short and I always seem to miss it. There were a lot of issues in this release that have already needed patching (ping time, thermostat card modes, and now reversal of the local login) that i think may have been caught with more testing- I’m thinking it might be a good idea to have the beta be a full month ahead of the production release.

38

I don’t think this has anything to do with communication. It’s simply that when presented with a range of options on how to implement a certain feature, a breaking change (I refuse to use the new ridiculous politically correct term) is all too often their first choice rather than the absolute last as it should be.

I work on commercial enterprise grade software in my day time job. As far as I know, we had one single breaking change planned in 2023 that was considered unavoidable. And a tiny one, compare to the type of breaking changes common in HA. It took months of internal meetings, assessing damage mitigation strategies, reaching out to beta customers, etc, to approve the change. In the end, we didn’t do it. The risks of upsetting customers were deemed too high and a backwards compatible workaround was implemented instead.

I know I know, not the same target audience, HA is open source, can’t complain about free software (even though a lot / most people pay for NC sub), etc etc. But your users time is usually not free. Respect goes both ways.

10 Likes
39

The good old days… Most likely the best wording. Are there really good old days? Not sure, neither private nor at home assistant.

I’m enthusiastic user since 5 years, what was at the beginning? Coming from loxone, openhab, iobroker I ended at Home Assistent. UI configuration was not yet there, but I was convinced to stay there. I can remember my thoughts: oh my god it’s so great, but I would never recommended it to friends, to complicated for non-tec users. Now 5 years later I have installed and recommended HA to many users, especially since Green came out. This was only possible concentrating on stability and UI configuration. The only way to reach the mass, and in the end it makes life also more relaxed for a tec-user… Thank you Home Assistent.

Nevertheless I want also to be a little bit critical, I’m not sure if HA is moving 100% into the right direction. Is a nice login page really required, is the whole voice stuff worth the effort? There are so many things which could be improved, just read the top WTH topics. So, voting for Year Of WTH 2024 :slight_smile:

4 Likes
40

I see where you’re coming from, but there’s more to it. It’s not just about how long something is tested, but who’s doing the testing and how they’re doing it. Testers are super important. They’ve got to have the right skills like a sharp eye for detail, a knack for thinking like the end-user, and being able to think critically about what might go wrong. Testers need to be particularly tolerant to frustration, as crafting bug reports and pointing out errors in a comprehensible way can be challenging, especially when dealing with open source developers. Effective and efficient testing happens during software specification and implementation. Beta testing typically happens too late and attracts end users, a kind of tester, while motivated, typically not very skilled in most of the skills mentioned above.

3 Likes