Is Home Assistant shifting towards a different audience?

1

Hi,

I’ve been a part of this ecosystem since the pre-COVID era, transitioning from FHEM to Home Assistant for its sleek aesthetics and its “Borg-like” ability to assimilate virtually any device. The initial YAML configuration was challenging but rewarding, and over the years, I’ve appreciated the integration of more services, hardware, and enhanced UI configurability.

Despite this, I still find myself relying on YAML for bulk changes or speed. For instance, adding 20 smart plugs to the Energy Dashboard is a tedious process via UI, but a breeze with some command-line magic.

Lately, however, I’m finding myself apprehensive with each major update, uncertain about what might break or the rationale behind certain changes. Let me share a few examples in chronological order:

  1. MQTT Name Changes in 2023.8: This update had a communication mishap that led to unnecessary confusion and time waste for many, including myself. It felt more like a developer-centric change rather than user-focused. It took me 2 days to fix the aftermath and I was able to fix the last problems caused by this last week.
  2. Whatever broke automations in 2023.11 (#102937): This update broke many YAML automations and made bulk changes, which were previously simple, time-consuming in the UI. Communcation around this is again a mess. I don’t even know what the original change was, which is why I’m referencing a random bug report and why I’m still not sure if it’s a developer-centric change or a change for the sake of easier UI configurability. It took me a day to fix all my automations and I fear the next bulk change.
  3. Removal of Features like scan_interval in 2023.12: Moving crucial features to the GUI and away from user control seems counterintuitive to the advanced users’ needs.

Since a few releases I’m sticking with the previous major release at least till mid month to scan the issue tracker and the community what was broken or documented badly. So I can at least prepare for that when performing the upgrade. Wow. I’m losing trust in Home Assistant.

While I am not a proficient Python programmer to contribute significantly to the development, I hope this post sparks some thought. Home Assistant’s journey towards accessibility is commendable, but are we losing the very essence that made it appealing to the tech-savvy user base?

What’s your take on this? Do you share these concerns, or am I just nostalgically yearning for the “good old days”?

Looking forward to your thoughts and insights.

Best,
Sebastian

13 Likes
2

No. Addressing each of your points:

  1. Advanced users would know how to set up device and entity names as per the guidelines.
  2. Advanced users rarely use the UI for automations and if they do they know not to use device ids. And even if they did that they would know how to fix a missing one.
  3. Advanced users can easily disable polling and create their own automated interval.

There were no “good old days”. Home assistant has become more structured and stable with every release. It has lowered the bar to novice user entry while maintaining a very powerful automation platform. Not an easy thing to do.

9 Likes
3

I agree with thr statement that HA is becoming more structured, (and maybe more stable…), but there were “good old days”. And as much as I’m sure it’s an overlitigated topic, I think those days were before the “no more device yaml integrations” decisions.

Before that, power users could check their HA configs into git like every other piece of software and config.
After that, the only “change management” is whatever backups can offer, which isn’t the same thing.

I get it. I understand that Yaml integrations were causing pain for the integration devs who are the powerhouse that makes HA what it is. Honestly, I also do love the UI and how simple it is to set up simple integrations with it.
But the hard-turn from “yaml” to “no yaml” broke so many power users… Anything that’s not a ‘simple’ integration becomes a nightmare. And “batch” setup of integrations is literally impossible. (I have 20+ reolink cameras. With yaml + vim I could integrate them all in 10 minutes. With the forced-UI flow, it’s almost a whole day of click-boxes and steps.)

I still feel like the implementation of the “no yaml” direction could’ve/should’ve gone a different way.
Require everything to be both UI-onboardablr and YAML configurable. UIs for the ease and approachability for junior users, YAML for the power users that need it.

I don’t think that the “burden of maintaining both” had to fall on the integration devs, though.
It seems like core could’ve offered A “common config” layer through which integrations could be set up by either yaml or UI, without the burden of maintaining both being on the integration developer. Like so many CompSci problems, one extra layer of abstraction could solve/simplify this whole thing.

At this point, I’m more or less resigned to it. I can’t change it, ranting doesn’t seem to influence it, and as much as I’d love to actually contribute code, I do enough of that at my dayjob and can’t spare the personal time for it. At EoD, HA is still the best smarthome platform I’ve found, and I’ve happily paid my Nabu Casa subscription for years to help keep it alive and growing and support the team behind it.
I just hope, like OP I think, that HA doesn’t drift so far from power users I have to find something else, because I’d be really sad to do so.

10 Likes
4

I was dead against dropping yaml for integrations when it was first announced.

Now I’ve used it I find I quite like it.

1 Like
5

Since you linked to this post from a ping scan interval issue, let me link you to an explanation where I explain that this move is something that gives you way more freedom. Can’t set own ping interval · Issue #105304 · home-assistant/core · GitHub

6

Thanks a lot for that pointer. Indeed and as I already mentioned, it may be the case that things just need to get communicated and explained better.

Removing intervals from ping and replacing it with automations like mentioned in the documentation sounds like “we know it’s a bad idea to make this non-configurable, but here is a workaround”. The example you gave with solar panels totally makes sense.

Also the way, things are deprecated should be changed IMHO. Like:

  1. Create new functionality and mention in the release that this will replace x, y and z in let’s say 6 months. Deprecate old functionality in documentation only and log only when deprecated logging (if python has something like that) is enabled and point users to the new functionality
  2. Deprecate old functionality in code including warning messages in the User Interface, let’s say 2 months later.
  3. Kill old functionality when the 6 months have passed.

YMMV on the timings.

Currently its sometimes not even mentioning breaking changes in the Changelog and documenting after tickets or community hate flows ins.

2 Likes
7

With the deprecation you’re explaining, what’s the main difference with what we do right now? As we now do a 6 month deprecation, what are you missing in that?

1 Like
8

For example with the latest changes to Ping integration:

  1. In the June release it should have been mentioned in the release notes, that
    1.1. Ping integration is going to be moved from YAML to UI and
    1.2. That scan interval will not be configurable anymore and the default will be 5 minutes
    1.3. That xyz is the recommended way to handle that if another interval than 5 minutes is required and people are advised to change that now so they don’t forget in 6 months. It should also be explained, why this is happening. Up until your comment in Can’t set own ping interval · Issue #105304 · home-assistant/core · GitHub it felt like “we know it’s a bad idea to make this non-configurable, but here is a workaround” as already mentioned. While I still doubt there is any practical use for update_entity in the context of ping, I see a lot of practical use cases in other scenarios and in that big picture update_entity + there are practical use cases for that, maybe not in ping + unifying things is often a good idea, I would have understood the reasoning behind that and could have prepared 6 months ago. I also would likely have created a ticket mentioning that 5 minutes is not really a good default interval for the ping integration.
    1.4. Logs above a Debug/Deprecated log level should have contained a pointer to that documentation if Ping integration was used
  2. In the July release, the same log message as in 1.4 should be thrown, but on Warning level and expose the deprecation in UI if (and only if!) an update_interval was set in ping’s YAML configuration
  3. In the December release, the new implementation should have replace the old one like it did, including mentioning a breaking change if scan intervals were used linking to the documentation and explanation above.

Nothing of that happened. It was just released and not even mentioned as a breaking change.

We may argue if the relatively small changes to ping is worth all this. With the MQTT entity id stuff in 2023.8 and the broken automations in 2023.11 it would have saved many people many hours of their lives. Not only on the users side btw, also on developers side, community contributor side etc.

Speaking of if it’s worth the effort. My guess would be, if things like these were documented, communicated and explained properly, it would be easy to reduce the 6 months deprecation window.

1 Like
9

Ping wasn’t a breaking change. It was moved from yaml to the UI. All functionality is still available and sensors were auto-migrated to the UI. Hence no 6 month warning. That only occurs for things that are removed, like command line sensor platforms being depreciated in favour of a command line integration.

10

Breaking changes are not limited to removing functionality. Whenever users of a software are required to adjust their existing setup or workflow to continue using the software as before, that change is breaking. Removing scan_interval configurability from the integration and instead requiring automation is a significant change for those affected. Existing ping sensors behaved differently after the migration and things based on theses sensors sometimes stopped working or behave differently after the migration. That change sounds breaking to me. And that was not mentioned at all in the changelog (which IMHO is too late, users should be notified about upcoming breaking changes and their workarounds with a proper notice period). Balancing innovation with user convenience and familiarity is crucial for maintaining a satisfied and engaged user base. Home Assistant is not some kid’s stuff in our mancaves. Lights don’t turn on, alarms don’t turn off and things like this happen if home assistant doesn’t work as it’s users expect.

TL;DR: Breaking changes in software encompass any modification that requires users to alter their approach to using the software. Effective communication about upcoming changes, providing detailed documentation, and supporting users through transitions is crucial

6 Likes
11

Not a breaking change, it was a Backward Incompatible Change.

12

Those shouldn’t be buried below “Need help? Join the community!”.

More like this: Comparing home-assistant:a2cba7d1385214abbd669dcc2949f93708b2e988...nohn:proposal_better_change_documentation · home-assistant/home-assistant.io · GitHub

Where are the changes to device IDs that break automations for users mentioned in 2023.11 To-do: Add release title - Home Assistant?

13

At this moment, we do not know what we are deprecating in 2 months. It would slow down development a lot. We require yaml integrations to move to the UI before being allowed to add more features. Thus people putting in ~1 month of effort to get it to UI, then have to wait 2 months before being able to add new features. I personally think that’s very long. And the thing is also that we work on making this transition a breeze.

Also keep in mind that the lack of scan interval has been mentioned in the release notes.

The reason the deprecation period went up to 6 months is because there’s a large group of people not actively updating their instance. They update once every 2-3-4-5 months or so. With our previous 2 month deprecation period it would never have been able to import as it never has that code included. Now if they update within 6 months, everything is fine.

14

About the device IDs btw. I remember chilling on discord when someone joined who’s HA would not boot, since he had automations referencing devices that did not exist anymore. To avoid this, they added a check to avoid making HA unbootable

15

I assume that post was just being facetious.

So if it’s not a breaking change then where is the list of breaking changes for this release?

are there no breaking changes anymore? Just “backward incompatible changes” so the devs can claim there are no more breaking changes in HA?

otherwise it’s just a nice play on words …and a distinction without a difference.

2 Likes
16

At least you got it. :slight_smile:

Yeah. I went back and looked at the release notes and noticed it was on the list.

EDIT:

Correct.

17

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
18

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.

3 Likes
19

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.

20

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.