[mindslight]

> You just can't expect HA to be able to do autoupdates for these daemons.

I'm not expecting or even wanting HA to do autoupdates. A good framing of the crux of the problem here is that I want to use HA but not HAOS.

> even with MQTT you'll need to run ZWave and ZigBee bridges.

Yes, the point is wanting to keep them as part of my overarching OS-level deployment config so that I can manage them along side email, nginx, matrix, netfilter, hostapd, kodi, etc.

I only brought up NixOS specifically because you asked for an example of a different approach of encapsulating and abstracting service configuration. I'm happy using NixOS, regardless of what you consider a dealbreaker. I used to choose Debian instead. If you prefer HAOS then please continue using HAOS. If I had to create and hand off a machine to my "grandmother", I might even choose HAOS for that myself. We shouldn't need to argue about distributions when talking about software packages.

[cyberax]

> I'm not expecting or even wanting HA to do autoupdates. A good framing of the crux of the problem here is that I want to use HA but not HAOS.

You can do that. It's not even hard, the HA documentation is pretty stellar in that regard: https://www.home-assistant.io/installation/#advanced-install...

The HA team rightly doesn't want to officially support it, to avoid being inundated by people who don't want to keep the pieces.

> Yes, the point is wanting to keep them as part of my overarching OS-level deployment config so that I can manage them along side email, nginx, matrix, netfilter, hostapd, kodi, etc.

Then this is just not going to happen, unless the world changes a lot. There's just no way something like HA can be both useful for most people, and be released according to the Debian Stable calendar. HA has to move fast to adapt to third-party API changes, new integrations, and to just be able to bring features to users.

> I only brought up NixOS specifically because you asked for an example of a different approach of encapsulating and abstracting service configuration.

NixOS is not that much different from the HA approach. You also can't just get into the NixOS system and edit random files in its storage tree, you'll end up with a broken system. So you need to create a new flake, and then do the changes within this flake's env. If it's a deep dependency, you'll need to modify the dependent software to use your new patched version.

Of course, nix is far more flexible than HAOS, but then they also are made for different kinds of users.

[mindslight]

Back when I was using HA, Core and Container did not exist (at least as first-class recommendations), so I'll admit not having been really aware of what they were. Core would have meet my deployment policies at the time, and if it had existed I would have gone that route instead of Supervised and been much happier. So I will give credit there for HA getting better distribution options since my poor experience.

> There's just no way something like HA can be both useful for most people, and be released according to the Debian Stable calendar

People running Debian Stable expect and want slower updates. It's a feature, because things don't change out from under you. It means perhaps not being able to use some new device, but it also means that your current setup just doesn't break/change out of the blue to accommodate some new feature. Essentially the reasons you've said are already being taken into account by people running stable - like yes, running a HA moderated by Debian Stable while trying to use fleeting online APIs is going to be a bad time. Just like trying to use yt-dlp out of the Debian repo is.

> NixOS is not that much different from the HA approach

Sure, but the difference is that I opted into using NixOS as my OS distribution to meet my needs for my entire environment. Whereas HA pushes using their HASS [0] mini distribution as part of using HA. We've discussed the necessary reasons for that, and I agree that the all-encompassing solution makes sense for many people. But the fact remains that is essentially managing a new instance of a bespoke distribution. And that's what really made for my negative experience.

With the advent of Core, it does seem like my previous specific situation has been addressed. But the memory of my experience remains, and then I see things like https://github.com/NixOS/nixpkgs/pull/126326 which make it look like that same rejection of the larger ecosystem dynamic is still alive and well. It just gives me pause, regardless of the continued existence of HA-on-NixOS.

As I said, I'm certainly not against Home Assistant. I'll eventually try using it again when I want some kind of easy UIs for my automation setup. The problems I'm currently solving really just require logging, graphs, and automation rules. And so I've just decided to focus on MQTT-first as the nucleation point, rather than putting all my eggs in the Home Assistant basket again.

[0] Whatever the mini Linux distribution that runs inside the Docker container is called. When writing the previous comment I had thought that was HAOS but now I'm seeing that HAOS isn't included in Supervised or Container. I believe it was called HASS back then, so maybe it's still HASS?