No need for that mate, just deploy home assistant or something similar and you will get this (and more) out of the box
HA is great, but it's not the answer to everything
I live off grid, so energy monitoring is a big deal for me. HA is fine for “at a glance”, but if I want any kind of detail, I use grafana. I actually have my old openhab instance still running purely as I can’t be faffed setting up all the piping from MQTT into influx again.
It’s also possible to integrate the usage over time using a dynamic time window to get Wh figures from wattage, which is enormously useful for me, and is more accurate than the figures HA gives in their power system.
HA is dead useful for getting alerts when the laundry finishes, though - dumb machine, smart plug, look for a sudden drop in power. Also does all our climate control.
So different tools for different jobs.
HA can export data to Prometheus. Setting up and running HA is much easier than figuring out how to get a set of different smart devices to export metrics to Prometheus/Influx. Let HA deal with that.
The Home Assistant authors' hostility towards simple native distributions is now a show stopper for me. Long term reliability is more important than quick initial setup.
It's obviously possible to debug what goes on inside a Docker image. It's just not something I'm particularly interested in dealing with, especially under duress.
FWIW, this can also be called stable state you can retreat to. And build upon, e.g. adding a layer of debugging tools.
I don't really like to deal with Docker, but at least I have reasonable certainty it'll work. I prefer system package manager or MSI, but if not that, it beats having to build something when it's near-guaranteed that what I'll get is not the binary the authors had in mind, if it even runs at all.
(Then again, I routinely rebuild Emacs to stay on the bleeding edge. But it took a while to work out all the usual dependency mess, and I even broke my system once doing it.)
You need to host a bunch of daemons (MQTT, ZWave and ZigBee bridges, and whatever else you might need). And a bunch of these daemons can have their own gnarly dependencies (e.g. they can be written in JS and built with NPM, ugh).
So you kinda _need_ to use Docker to make it at least sane.
And if you're using Docker for the plugins, then why not use it for the HA core itself?
And once you do that, you don't really need much from the host system. So why not use a minimalistic OS instead of something like Debian?
These days I'd say that NixOS captures that requirement, allowing orchestration of many daemons and other system config to be abstracted into a packaged solution (eg NixOS Mailserver), that the user can override as much or as little as they'd like.
I believe NixOS does package (or at least attempts to package) HA, but given my past experience and what I believe is still the throw-it-over-the-wall desire of the HA maintainers, I'm wary of adopting it as an overarching solution. I'm certainly not ruling it out for performing some functions, like UI. I just would rather set up my automation efforts as MQTT-first, keep logging and automation rules as their own separate things, and not be fully committed to HA.
You can do that just fine even now. I'm doing experiments with voice control, and I run the complete AI stack locally on my computer. So I just set up everything as regular background processes.
You just can't expect HA to be able to do autoupdates for these daemons.
The other problem is that most of required dependencies are not packaged in Debian. So you'll have to install multiple NodeJS servers and tons of NPMs somewhere on your system.
> These days I'd say that NixOS captures that requirement, allowing orchestration of many daemons and other system config to be abstracted into a packaged solution (eg NixOS Mailserver), that the user can override as much or as little as they'd like.
You can do that with HA as well. Just push in a new image, and tag it appropriately.
The last time I played with Nix, it needed to download tens of gigs of data for a few programs. I don't think this is acceptable for HA.
You can definitely do HA in a piecemeal fashio, but there's just no way it can be done as a reproducible system that you can give to your grandmother. Given these constraints, HAOS is actually pretty remarkable.
> I just would rather set up my automation efforts as MQTT-first, keep logging and automation rules as their own separate things, and not be fully committed to HA.
Raw MQTT still needs a UI that is user-friendly. And even with MQTT you'll need to run ZWave and ZigBee bridges.
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.
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.
> 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?
The thing is, the "it works" is reproducible because of containers. Which is a step above just hoping that it works.
HA is also easy to "patch". You can just install your custom components in `config/custom_components`, it can also be used to "override" core HA files.
Finally, if you are doing intrusive development, you can easily launch HA locally. macOS, Linux, and WSL are supported. You will lose the ability to install add-ons via the addon manager, but that's about it.
FWIW, I had the same aversion to their custom OS and their crazy container-based setup initially. For a couple of years, I used to run HA as a Python app and managed the dependencies manually. Then I tried the HAOS and it... kinda just worked.
Demanding the authors who gave you the software for free also provide support for an installation method they've offered up with no support is a bit ridiculous, don't you think?
That attitude is what causes open source projects to die though...
If anyone chimes in and says they've been running Home Assistant from nixpkgs (where I am now) for several years with no hiccups, then I will certainly reconsider my opinion. But based on my experience and what I've continued to read since, it feels like trying to do that is an uphill battle. One I'm not looking to take on, especially for automation I'm relying on.
YOU believe he should support this anyway, because of various "we promise end-users won't reach out to you" which is comically incorrect because history has shown repeatedly that a user's first step when something is broken is to google package_name broken - which will absolutely turn up the author's name.
BECAUSE he doesn't want to support his software being repackaged in a way he believes isn't supportable, you're upset. You want him to support your unicorn config because that's what you want to do, and his refusal to comply makes him a bad person.
Thank you for reinforcing EXACTLY why open source devs burn out. He has a workflow that he is willing and able to support and doesn't want to support anything outside of that. Your response is: but you need to do it for me because it's what I want.
I think the most surprising thing is that you can’t see how unreasonable your complaints are.
What I do see is a project calling itself FOSS, while its maintainers really don't like it being used as Free Software. If one wants to control downstream uses of one's software, the answer is quite simple - release it under a proprietary license. Don't grant freedom while going on and on about how you support freedom, but then be upset when someone actually uses that freedom to do something.
> deal with end users bugging me about it being broken.
The nixpkgs maintainers asked how much this was actually happening, and even preemptively proposed solutions. OP didn't engage and just repeated his demands. And in general how is this any different from the common DRM-authoritarian refrain that companies are justified locking down devices they make, lest end users modify them and then clueless people might attribute the outcome to the original manufacturer?
There seems to be a sonoff usb stick that might act as a hub and allow command-line monitoring of all devices, should be perfect for feeding into grafana/prometheus.
I recall the online requirement was for some ntp server requests that cant be disabled.