4 ms·

No need for that mate, just deploy home assistant or something similar and you will get this (and more) out of the box

mindslight 2y ago
Right up until the Home Assistant UI turns into a lagfest, the installation dies, and you can't debug why because Docker. At least that's what happened to me. And no, it wasn't RPi SD power issues. This happened on an otherwise-stable amd64 server. 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.
- cyberax 2y ago
  HA is actually pretty debuggable. Just install the SSH plugin, then SSH into the HA box, and then simply "docker exec" into the target HA container.
  - mindslight 2y ago
    ... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall. 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.
    - TeMPOraL 2y ago
      > because you're inside someone else's "works on my system" that they threw over the wall. 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.)
      - mindslight 2y ago
        It's certainly within my gamut to jump into an embedded system to debug it, bringing/building tools as I go. I'm just not looking to opt into doing that on something that doesn't need to be that complex in the first place. Same reason I run one decently powerful amd64 server that does many things rather than a stack of Raspberry Pis, one per software package.
        cyberax 2y ago
        But how would you do it differently? 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?
        mindslight 2y ago
        At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it. 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.
        cyberax 2y ago
        > At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it. 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.
    - cyberax 2y ago
      > ... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall. 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.
- baq 2y ago
  It's a Python app, of course being distributed as a docker image is the sanest way of doing it. I don't see why you couldn't just pip install it if you really wanted, but having been a Python developer for close to two decades, I wouldn't want to.
  - mindslight 2y ago
    I'm talking about distribution package managers, not pip.
    - darkwater 2y ago
      I happily ran a dockerized HA on a Debian for years now, no need to do any complicated debugging (and even if I did, it would not be difficult to inspect it properly)
      - mindslight 2y ago
        Dockerized HA on Debian is exactly what died on me. About 5-6 years ago. I'm sure it works just fine for most people. Just once bitten, twice shy.
  - Izkata 2y ago
    That was the standard way a long time ago, and the first startup would take a really long time because it would install even more stuff. And sometimes fail. It wasn't very reliable if you used any addons, and some required a ton of extra steps that it couldn't automate like the modern deployments do now.
- tw04 2y ago
  Nobody is preventing you from running Home Assistant core and deploying everything else yourself manually. 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...
  - mindslight 2y ago
    What do you mean "demanding support" ? I remember Home Assistant authors being actively hostile to people packaging their software outside of the official Docker or RPi images. Which is why it wasn't in the Debian repository, pushing me down that Docker path in the first place. Here's the same dynamic on an associated project in 2021: https://github.com/NixOS/nixpkgs/pull/126326 https://github.com/NixOS/nixpkgs/pull/126326 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.
    - tw04 2y ago
      So... your example is a developer of HA stating that he sees major flaws with how they're distributing his package, and that he has absolutely no interest in supporting users that pull his code in a way that is unmaintainable by him. 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.
Havoc 2y ago
Grafana is a hell of a lot nicer & controllable than HA HA is great, but it's not the answer to everything
- madaxe_again 2y ago
  Agreed. 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.
- zimpenfish 2y ago
  Seconded - HA's graphs are great for a simple "is this going up or down" glance but when you want to put a whole bunch of things together for comparison or perform aggregations or calculations, that's when you want Grafana et al.
- Cyph0n 2y ago
  Why not both? You’ll need to run a server either way. 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.
- icehawk 2y ago
  It might be, but for all of the examples in the blog post, HA does this out of the box.
Banditoz 2y ago
Why not both?
whitehexagon 2y ago
I'm also looking at a custom solution for my current migration from WiFi sockets to Zigbee. It seemed impossible to do an offline installation of home assistant, and discouraging signs for running it without an internet connection. 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.
- baq 2y ago
  HA will happily run offline; if you mean HAOS then I don't know what it does but it's an unorthodox Linux distro, but once it installs it should also run offline without issues. I'm also using their skyconnect zigbee coordinator and it works very well.
  - whitehexagon 2y ago
    Yeah one of the tests was a RPi image and it wouldnt complete without a LAN internet connection (only got 4G). And it seemed far too weighty for a bit of home automation. I recall the online requirement was for some ntp server requests that cant be disabled.
    - baq 2y ago
      Yeah that's more of a rpi hardware requirement as it doesn't have a battery and you realistically want to have accurate time on your smart home controller, even - especially - after it cold boots after power loss.

Right up until the Home Assistant UI turns into a lagfest, the installation dies, and you can't debug why because Docker. At least that's what happened to me. And no, it wasn't RPi SD power issues. This happened on an otherwise-stable amd64 server. 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.

cyberax 2y ago
HA is actually pretty debuggable. Just install the SSH plugin, then SSH into the HA box, and then simply "docker exec" into the target HA container.
- mindslight 2y ago
  ... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall. 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.
  - TeMPOraL 2y ago
    > because you're inside someone else's "works on my system" that they threw over the wall. 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.)
    - mindslight 2y ago
      It's certainly within my gamut to jump into an embedded system to debug it, bringing/building tools as I go. I'm just not looking to opt into doing that on something that doesn't need to be that complex in the first place. Same reason I run one decently powerful amd64 server that does many things rather than a stack of Raspberry Pis, one per software package.
      - cyberax 2y ago
        But how would you do it differently? 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?
        mindslight 2y ago
        At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it. 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.
        cyberax 2y ago
        > At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it. 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.
  - cyberax 2y ago
    > ... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall. 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.
baq 2y ago
It's a Python app, of course being distributed as a docker image is the sanest way of doing it. I don't see why you couldn't just pip install it if you really wanted, but having been a Python developer for close to two decades, I wouldn't want to.
- mindslight 2y ago
  I'm talking about distribution package managers, not pip.
  - darkwater 2y ago
    I happily ran a dockerized HA on a Debian for years now, no need to do any complicated debugging (and even if I did, it would not be difficult to inspect it properly)
    - mindslight 2y ago
      Dockerized HA on Debian is exactly what died on me. About 5-6 years ago. I'm sure it works just fine for most people. Just once bitten, twice shy.
- Izkata 2y ago
  That was the standard way a long time ago, and the first startup would take a really long time because it would install even more stuff. And sometimes fail. It wasn't very reliable if you used any addons, and some required a ton of extra steps that it couldn't automate like the modern deployments do now.
tw04 2y ago
Nobody is preventing you from running Home Assistant core and deploying everything else yourself manually. 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...
- mindslight 2y ago
  What do you mean "demanding support" ? I remember Home Assistant authors being actively hostile to people packaging their software outside of the official Docker or RPi images. Which is why it wasn't in the Debian repository, pushing me down that Docker path in the first place. Here's the same dynamic on an associated project in 2021: https://github.com/NixOS/nixpkgs/pull/126326 https://github.com/NixOS/nixpkgs/pull/126326 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.
  - tw04 2y ago
    So... your example is a developer of HA stating that he sees major flaws with how they're distributing his package, and that he has absolutely no interest in supporting users that pull his code in a way that is unmaintainable by him. 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.

Havoc 2y ago

Grafana is a hell of a lot nicer & controllable than HA HA is great, but it's not the answer to everything

madaxe_again 2y ago
Agreed. 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.
zimpenfish 2y ago
Seconded - HA's graphs are great for a simple "is this going up or down" glance but when you want to put a whole bunch of things together for comparison or perform aggregations or calculations, that's when you want Grafana et al.
Cyph0n 2y ago
Why not both? You’ll need to run a server either way. 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.
icehawk 2y ago
It might be, but for all of the examples in the blog post, HA does this out of the box.

Banditoz 2y ago

Why not both?

whitehexagon 2y ago

I'm also looking at a custom solution for my current migration from WiFi sockets to Zigbee. It seemed impossible to do an offline installation of home assistant, and discouraging signs for running it without an internet connection. 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.

baq 2y ago
HA will happily run offline; if you mean HAOS then I don't know what it does but it's an unorthodox Linux distro, but once it installs it should also run offline without issues. I'm also using their skyconnect zigbee coordinator and it works very well.
- whitehexagon 2y ago
  Yeah one of the tests was a RPi image and it wouldnt complete without a LAN internet connection (only got 4G). And it seemed far too weighty for a bit of home automation. I recall the online requirement was for some ntp server requests that cant be disabled.
  - baq 2y ago
    Yeah that's more of a rpi hardware requirement as it doesn't have a battery and you realistically want to have accurate time on your smart home controller, even - especially - after it cold boots after power loss.