Hacker News new | past | comments | ask | show | jobs | submit login

> The biggest problem with HomeAssistant, however, is its really overengineered setup for running on mini computers like the Raspberry Pi, which was my goal.

False, i ran mine on rpi for 2 years now with many sensors. Zero issues and not even close to maxing out the pi.

> I have a strong aversion to Python due to its horrendous package management history (we use dozens of languages at work, guess which language is the only one that causes build issues all the time?). It’s a nice language, but for things like home automation, having build/dependencies problems is the absolute last thing I need.

Not sound reasoning imo, this is mangable if you know what you're doing. Clearly, HA doesnt have any problems related to this version management.




Agreed, package management is fine. Just make a home assistant virtual environment and you're done.

  python -m venv /opt/venvs/hass
  source /opt/venvs/hass/bin/activate
  pip install homeassistant
boom done.


Great, now tell me how to maintain it.


`pip install -U homeassistant` when there's a new version.


If pip was a good package manager, this would be the correct answer. Sadly, pip is crap.


Care to expand on that, or is that just the usual FUD about old versions of pip?


> first, it’s based on Python. I have a strong aversion to Python

Yeah, that's how we engineers feel - if it ain't my eavorite/elegant language, BYO... Program :)

> overengineered

Yeah, I also ran off of RPI4 for a few years, along with MQTT, Nextcloud (+SQL), photoprism, bitwarden and whatever needed for proxying via nginx. I only migrated to better hardware because I wanted to browse my pictures faster, photoprism solved that even on RPI, but I wanted faster indexing and offline face recognition where RPI turned out to have too little RAM.

On normal load, my RPI would still have room for other containers.

Having HA within a container was a feature - not too much to configure and everything is isolated, so I can still run other services from RPI. And easy upgrades.


> Not sound reasoning imo, this is mangable if you know what you're doing.

I dunno; if the author is correct about this bit:

> The recommended way to run it is with a fleet of Docker containers (and they even tell you to install their own Linux distro to make sure all the large amounts of software you’ll need is managed more easily).

then, yeah, it's horribly over-engineered.

I tried finding docs to understand how to create a plugin to support a new protocol and didn't really find anything.

I also got turned off by the outright obstinacy of the support forum (example: https://community.home-assistant.io/t/mosquitto-broker-annou...)

Home assistant is not what I have in mind when I think "perfect for the job". It really is over-engineered, with (apparently) great plugin support, but very little in the way of docs.


It's really not that hard to run. I run mine on an Intel NUC by just running a docker container managed by systemd. It took me 2 min to set up, and 10 to configure.


> It's really not that hard to run. I run mine on an Intel NUC by just running a docker container managed by systemd. It took me 2 min to set up, and 10 to configure.

Are you perhaps being sarcastic? Maybe sarcastically pointing out how much of a pain in the rear it is to run Home Assistant?

The type of homeowner who wants home automation isn't going to learn what "NUC" means, what "Docker" means, what "Container" means, what "Systemd" means.

What you said is the equivalent of telling the average car driver "It's not really that hard to replace the timing belt on a Golf 1. I just removed alternator, timing cover, lined up the marks on the camshaft's sprocket and the crank pulley, and slid the new belt on with the square-keyed-adjustment tensioner that it came with. Took me 30m".

I find, as I get older, that I get more critical of complexity. I'm even more critical when it's in a field I am proficient in, because then I can see how much of that is simply complexity for complexities sake.


The thing is, you /don't/ need to know any of that that; it's all under the hood. Sure you can open it up, but the recommended setup of flashing HassOS to a drive & booting off it is really simple, you don't even need to know Docker etc are in the backgrounds unless you are heavily customizing or writing add-ons.


Brilliant juniors are most common source of this in my 20 years of software dev experience. The usual 'they were busy with how it could be done and didn't check if it actually should be done'. One of the worst things for creating long-term technical debt is to let such bright folks run free.

KISS principle above all, when you look at products from really long term perspective and treat people as replaceable (which they always are and all will eventually leave), absolutely nothing trumps that. Unless of course somebody plays politics and create some cathedral for them to maintain, and only them. Which is behavior that should be recognized early and 'punished' accordingly.


If they want something easy, they should stick to Google Nest/Apple Home.

HA is for DIYers, they should know a tiny bit of how systems work. Docker is really simple.


And then you try to add an MQTT broker and learn you cannot install addons because you are on docker. Now you have to tinker on your own and add more docker containers.


Docker adds a high level of complexity for non-technical people.

If you're trying to mass market something (like Home Assistant) to non-technical people, containers are a dealbreaker.

OTOH, if you are selling something to technical people, containers are a feature.


You can do the same with EMQX or Mosquitto. I have both my broker and HA being started at boot by systemd.


This is the way to go. It’s absolutely solid and is part of my docker-compose.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: