[davemp]

Fun project. Though it’s kind of unreal how complicated it is to set up HA and I literally do this for a living, both embedded sw and backend web dev.

Docker compose with a zwave management server, reverse proxies for TLS, vlan isolation for the server, macvlan for HA container so it does see the host network, etc, etc. All to turn on and off a lightbulb with the sun. All the while AI is telling me to configure things insecurely.

I think when I get some more spare time, I’d like to write a statically linked program that handles a zwave controller and basic automation scripting. No IP networking needed for my lightbulbs. Then it wouldn’t feel risky to just make a system user and udev rule to give it permissions to the controller, and run with systemd.

[paranoidrobot]

While you can run HA as a container. I think it's a mistake - Its more complicated and has reduced features.

I would instead recommend people use HAOS instead - either running on dedicated hardware OR as a VM. Just dont run it from an SD card if you go down the Raspberry Pi/SBC route - it will kill the card from IO cycles.

I have an IOT VLAN on my network that all the IOT bits sit in, including WIFI devices. What internet access it gets (if any) depends on the device profile.

I tried splitting things up into multiple VLANs but a whole lot of things assume just a flat network, so things stop working if you get too fancy.

[zikduruqe]

> it will kill the card from IO cycles.

It might not. I have a Raspberry Pi 2 that has been running a weather station for over 12 years, and it has been on the original SD card. I have other RPi's doing dumb things around the house and I have never had an SD card failure.

YMMV and all that.

[mholm]

HA in particular creates a lot of log churn. It's not a 100% certainty, but after running for 4 years I finally had to copy the SD image to a new one because it had become unwritable.

[KeepFlying]

Dirty power kills my raspis faster then write cycles. I've been really surprised with the stability once I moved by Pis to my UPS

[kalaksi]

Yeah, I haven't had issues with SD cards in a long time. Many years ago (maybe 10), I think they weren't quite as good and I probably skimped too much when buying a card. RPi 1 also had power regulation issues. Now I only use higher tier cards and make sure there's enough free space for wear leveling and operations.

[robrtsql]

My friend bought an ODROID and an SD card at the recommendation of some tech YouTuber for Home Assistant. Within 3 years the SD card was dead, and I had to help him re-set-up all of his stuff (this time, with a more resilient storage medium and remote backups).

YMMV certainly applies but I feel like the warning is important.

[paranoidrobot]

I wouldn't put running a weather station in the same class of disk activity as running Home Assistant. It is writing a fairly large amount of logs, plus statistics for every attribute/sensor for every device. The more devices you have, the more you will be writing.

There are regularly threads from people with "I restarted HA and now I get this weird boot error message", and it's because their SD card died.

You do you, but it's common enough of a problem that I think it's worth calling out as a "Don't do this".

[zikduruqe]

I run HA on another RPi, so I am familiar.

On the weather station I wrote to the SD card 1,068,266 database records, along with all the nginx logs, etc...

> it's common enough of a problem

It's probably survivorship bias, where everyone complains about SD card corruption, while those with no issues really don't say anything. Well, except my comments today.

[cossray]

Fair point on survivorship bias. But, I think SD card being flash memory is technically expected to fail over time, with that failure compounded by the number of write cycles. These cycles are a spec of the SD card. If a section/page of the flash is being overwritten more frequently than the other, then surely it'll fail faster than an SD card whose erase/write cycles are distributed uniformly across all the sections/pages.

[93n]

I go the container route, and have only had one issue: allowing HA to access my system's Bluetooth adapter. I had some ESP32s lying around, so I used ESPHome to make a Bluetooth proxy, which solved that issue.

I don't run addons though, which might be part of it.

[ryukoposting]

Interesting. I also run HA in a container and getting it to pick up my Zigbee dongle was so easy I don't even remember how I did it.

I haven't tried BT, but my HA box lives underneath a couch with a big steel pull-out bed so I don't imagine it would work very well anyway.

[93n]

The host I run HA on is Ubuntu server. If memory serves me right, the Bluetooth issue was related to apparmor and dbus restrictions on docker

[paranoidrobot]

I haven't done it either. But it should just be a case of passing the device to the container. You might need to disable the host from using it and pass admin rights to the container too.

But it was also quite easy to pass a USB device to the HAOS VM in Proxmox.

[paranoidrobot]

Add-ons (now apps) can't be done without HAOS. It's one of those non-obvious things.

There's other things I forget which are also more difficult/annoying to manage on the container version.

I have a rather large docker compose stack so my first experiments with HA were as running it there.

That lasted maybe a week before I went and ran it as a VM instead.

[rickypp]

Yeah, I ended up buying a dedicated mini PC ($100 refurb) to install HAOS on. HA is pretty much useless without being able to run add-ons. I run everything on k8s in my home server, I don't have a VM system set up and didn't want to bother just for HA. It's funny, the pattern of a central application that uses docker containers to add plugins seems like a perfect fit for a Kubernetes Operator. I suppose it still misses out on some of the advantages of running everything "on metal" for integrating with physical components like USB dongles.

[dawnerd]

It's kind of silly since they're just containers it runs anyways. I'm sure there's other reasons. At least running it as a VM isn't too hard. Pretty easy to use their image and run from that.

[tjoff]

Apps/add-ons is just another container, so you can add them manually in the compose file.

[93n]

Yep, I run esphome in a separate stack w/o issues.

[zimpenfish]

> I go the container route, and have only had one issue: allowing HA to access my system's Bluetooth adapter

Even without running in a container, I had huge problems with Bluetooth on Linux (it would just ... stop then not reappear or it would only talk to half the devices but a different set of devices every other day, etc.)

(This isn't specifically a HASS problem, mind; I've had countless problems with Linux Bluetooth since 2003 over many different iterations of hardware, OS and dongle.)

> I used ESPHome to make a Bluetooth proxy, which solved that issue.

Same. It's a great solution.

[grvdrm]

What router and associated configuration software are you using? I have a Eero mesh network that leaves a lot to be desired for a fiddler like me.

[paranoidrobot]

I'm using OPNSense for the router, on their dedicated hardware - DEC750 iirc.

The switches are mostly Mikrotik, with some Unifi switches.

The wifi APs are all Unifi - they are all PoE and wired into the same network, no mesh. Even between buildings I ran fibre.

For the switching and routing, were I to do it again now I might go all Unifi. They recently implemented some much needed updates to make doing things like firewall rules and routing based on device much easier. I have a complicated set of rules in OPNsense to route IOT VLAN traffic out via a VPN connection, which require static IP assignments via DHCP, but under the new Unifi network I could do it with a few clicks and being able to use device attributes rather than a static IP.

I am also using an SLZB-MR1 for a ZigBee controller and Matter over Thread border router. I've got a bunch of IKEA and Mercator ZigBee light bulbs/fixtures that act as ZigBee routers. It's a strong enough mesh I rarely have issues with the ~180 devices on the net.

[zer00eyz]

> While you can run HA as a container. I think it's a mistake

Just because you CAN run something in a container, does not mean you should.

HAOS exists because it is a docker run time. It is a whole ecosystem, not just the home assistant software itself.

[dewey]

The happy path is to buy https://www.home-assistant.io/green/ and then go from there. That's what I did and it was a very smooth setup for everything. I've long resisted HA as I thought it's one extra thing to fiddle with but the whole process, the updates, adopting my devices was much nicer than expected.

I've since also bought https://www.home-assistant.io/connect/zwa-2/ and got rid of all my third party bridges (Ikea, Hue etc.). I also feel good about buying devices from them as it supports the project and the work they are doing on it.

[MintPaw]

I've never heard about "Home Assistant Green". Seems like another step down the slippery slope of "work on my machine". First docker, than a dedicated OS, now dedicated hardware. I wonder why is Home Assistant so complex as to require all this.

[rickypp]

I have no problem with them offering a ready-to-run hardware solution for Home Assistant, but I am annoyed that it's probably a motivating factor for why there isn't a self-installing image for HA on BYO hardware...

[ArchOversight]

https://www.home-assistant.io/installation/generic-x86-64/

you mean an image like this?

This is what I've been running on my generic x86-64 system for a couple of years now, 0 issues. Even migrated to a newer system recently because I wanted something that was slightly faster for ESPHome compilations.

[rickypp]

"self-installing" being the key point. Those instructions require you to use some other piece of software to write the image onto your boot disk. In my case I used an Ubuntu livecd to download and write the image to the machine. It's obviously not a showstopper but it is slightly annoying.

[troupo]

> hose instructions require you to use some other piece of software to write the image onto your boot disk.

I mean... That is how a lot of OSes are distributed: by giving you an ISO that you burn onto a USB dongle to install.

> In my case I used an Ubuntu livecd to download and write the image to the machine.

So... Same thing?

[ArchOversight]

It's not that it's that complex to need all of this. It's about ease of use. Home Assistant OS makes life simpler for users (such as myself), it makes it easy to use adding that run as additional docker containers, it makes plugging in USB z-wave/zigbee devices a breeze.

While it is technically no longer supported, you can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?

[josh3736]

> You can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?

This is how I did it, instead of the container or HA OS in a VM.

If you want the simplicity of everything preconfigured, managed, and hands-off, go with HA OS, whether in a VM on a beefier machine, standalone, or the HA Green/Yellow dedicated hardware.

But if you already have a home server and want to add HA, I found just pip installing to be easier than dealing with the container.

Maybe I'm just the silly type that enjoys fiddling with Linux, but I'd argue that it actually makes more sense to install HA bare metal over a container. HA doesn't actually have any major dependencies outside of what pip installs, so setup wasn't any more annoying than via container. And then you never have to deal with container annoyances like passing hardware through to it or weird failures and misconfigurations.

Contrast this with https://frigate.video/, which has so many fragile native dependencies and a super complex stack that trying to install manually is an exercise in futility. I gave up and used the container.

[radlad]

Docker would be the primary other dependency for Apps support.

There's nothing wrong with running it on bare metal but this is easier with the VM image.

[subscribed]

I think you're talking past each other. You're talking of capabilities, GP is talking about complexity.

[aconsult1]

I've tried using HA a couple years ago and gave up. It was too complicated to run it in a Pi4 - I'm an experienced software engineer, familiar with containers and Linux.

I was trying to get some of the IoT I have at home like pool equipment, lights, HVAC, blinds, etc. Some of the setup were an uphill battle looking for more information in forums and trying to figure out what was broken.

Recently I decided over the weekend to use Claude and write a small app that controls my pool equipment and then deployed it using Cloudflare Zero Trust (kind of a reverse VPN). What a joy! Not only I had lots of fun reverse engineering my pool equipment API (I didn't want to depend on existing libraries - which I know exist) but I managed to create a fun and custom UI with React that my kids and wife love using. For example, whenever the pool heater is on, it adds an animated flame to the UI and change the background to a red-ish color. Plus it has a bar chart that shows the pool temp progression (takes hours to heat it up) with an animated volcano colors. The theme of the app is beach/pool vibe.

I don't think anyone here would be that excited if we were using the lower-denominator that HA turns out to be. I know it's a very cool automation tool, but just not very exciting and pretty obscure to configure every equipment I have at home.

I've been thinking about writing a blog post with the details of my fun project, let me know if anyone is interested in this. So far I've done the blinds and pool equipment. Next will be HVAC and lights. Took me 1-2 weeks total for each using Claude in my spare time.

[turtlebits]

"pretty obscure to configure every equipment I have at home"

HA actually makes configuring every piece of equipment and integrating them easy. If I have only 1 thing to control, then yeah, it's probably overkill.

[amluto]

HA is an absurdly heavyweight pile of Python and Docker. Get it a real computer — a used “thin client” with 8 GB of RAM is probably less expensive than an RPi4 plus case and power supply.

[baq]

an intel n100/150 minipc is perfect, if you get an old enough build (don't ask) you can install proxmox on it and set up hass as a vm as God intended.

if you have to ask, mine was too new and had to settle for a non-LTS Ubuntu Server. it works, but I can't wait for LTS in a few months.

[amluto]

What’s the issue with new ones? Proxmox should work just fine on new hardware.

I’m rocking a Dell Wyse “thin client” that cost rather less than any comparable N150. It’s fanless, still gets firmware updates (via LVFS!), and takes about 5W at the wall plug.

[baq]

proxmox itself should work, but the installer has a much older kernel and didn't have the network interface driver.

[finniananderson]

> I've been thinking about writing a blog post with the details of my fun project

I'd love to read more about this!

[Aurornis]

> Though it’s kind of unreal how complicated it is to set up HA and I literally do this for a living, both embedded sw and backend web dev.

I had the same thought after I joined a local group for Home Assistant users.

Everyone always talks about a happy path where you pick the right choices, use the right setup, and everything just works immediately. More often when people come to this local group's shared Slack channel it's because they're 10s of hours into trying to set up something that appeared to be simple. Then all of the old timers remember that they, too, suffered through something similar once and share what they can remember.

I think HA can be a lot of fun for people who like to experiment and debug, but if you're not the kind to be entertained by debugging your home's operation then it can feel like a chore. Some have an easy time setting it up and then get trapped when an upgrade breaks something or they try to add a new device with less than mature support.

[briHass]

You're making it complicated with all the VLANs. HAOS in a VM (proxmox helper scripts for one-line install), and HA has plugins for all the other things.

Just deny WAN access to the IoT junk you don't trust at the router, or for things like cameras, a separate switch for those. That usually makes sense, since they're one of the few devices that must be powered with PoE and doesn't require gig+ bandwidth. A cheap 100mbit PoE switch will handle a good number of cameras.

[davemp]

I’m not giving untrusted devices unfettered access to my lan and an airgapped network sounds more complicated tbh. VLANs aren’t really that bad with good networking gear.

[vladvasiliu]

I have HASS running on a dedicated VLAN, IoT junk on its own, separate VLAN without internet access, through a managed switch. OPNsense sits in between and does the routing. Didn't have to mess around with anything, just ran the "vm appliance" or whatever it's called for hass and I was off to the races. Wireguard on the firewall gives me access from outside the house.

Actually, both OPNsense and Hass are VMs on the same machine, with the latter's network not even connected to any physical port outside the box. I'm not even running Proxmox or anything fancy, just libvirt on Arch. The only "fancy" thing is a 2nd hand Mellanox NIC I got off eBay for 30 €, which presents virtualized interfaces to the VMs, but HASS doesn't actually use those.

There's also no need to manually screw around with any reverse proxy for TLS; HASS does it with the Let's Encrypt add-on. The only missing piece when I set this up a while ago was something to regularly renew the cert (the add-on would only get started at boot-up).

[c-hendricks]

What zwave devices do you have that also require LAN access?

[randusername]

I also feel overwhelmed with HA homelab stuff.

HA on my RPI is just not reliable, requiring a reboot 4-6 times a year for reasons I don't understand. Frustration at being in the literal dark doesn't translate to the right mindset to root cause.

What I need is an opinionated guide on minimum viable virtualization, but so much of the resources online are from folks that are homelabing maximalists.

I feel the same temptation as parent to create a spartan solution.

[zer00eyz]

> What I need is an opinionated guide on minimum viable virtualization

Get a nuc or a mini pc: i5-8500 or better (used, ebay https://www.servethehome.com/introducing-project-tinyminimic... for a baseline of what's out there)

Ram is your friend (but prices are gross). Dont be cheap on storage.

Get an external USB drive (3/2/1 rule).

Install proxmox on said device.

Use the proxmox community scripts to install HAOS as a VM. https://community-scripts.org/categories?category=operating-...

Pass through what ever USB devices you need (or spring for POE devices ).

Enjoy your HA setup.

Proxmox is the way to go here. Once you have a working install dont over commit before you learn to: 1. back up, 2. restore. These should both be local and remote (HA can enable this to various sources).

As a bonus you now have a runtime (proxmox) that can do tons of other things (see the whole community scripts link).

I have been running HA for years now, and this method makes things a pleasure and is easy (at least if you're a nerd) and cheap (the solutions are lower power).

[dgacmu]

An enthusiastic two thumbs up to this approach. It's exactly what I run at home that has been working solidly. I run on an N100, which is just a hair smaller than an i5-8500, with 32GB DRAM and a 1TB SSD (total overkill). I keep it under proxmox; the box also runs my unifi SDN controller, pihole, and a linux VM for various little services. Two USB dongles for z-wave / zigbee / matter (because I'm a glutton for punishment). Backed up to a NAS. It's fast, easy, and has been very reliable.

[jabroni_salad]

1.get a cheap used miniPC from ebay

2. Buy a relevant dongle/antenna for the protocol you want to use. I recommend the ones from Sonoff or from the Home Assistant foundation (I started with the sonoff for zigbee, but added the ZBT-2 for matter/thread. they are both good)

3. install proxmox to the metal.

4. use tteck's install script to make the HAOS vm. Don't make the containers, make the HAOS VM specifically: https://tteck.github.io/Proxmox/#home-assistant-os-vm

5. Plug in your dongle(s) and don't forget to assign them to the new VM. You should now be able to start using home assistant. If you're using zigbee, choose zigbee2mqtt rather than ZHA, it's more reliable overall.

My setup is around 2 years old and I haven't had to administrate it at all.

[xolox]

If you are at all comfortable with Linux system administration, manually setting up one or a handful of KVM/qemu powered virtual machines is not actually that hard at all (in my experience). If you like a GUI to guide your initial steps, "virt-manager" is pretty okay. I've been running 3-5 virtual machines for several years now based on a pretty vanilla Ubuntu Linux install (Debian would work just fine as well).

Now I do like a challenge every now and then, so I'm currently setting up Proxmox to gain live migrations and high availability for virtual machines, because I've become quite dependent on all of these services in virtual machines actually running successfully :-) even in the face of eventual hardware failure (like what happened to me in the past months).

[the__alchemist]

IMO Linux system administration, KVM/Qemu, Docker, and virtual machines, and third-party tools in general are not something that should be involved in smart light bulb/sensor/pump etc management.

Task for an RTOS or no OS IMO. Or a single executable that runs on any OS without config. Should be simple, fast, "just work".

[ewoodrich]

Home Assistant supports an absolutely massive number of both manufacturer and community maintained integrations that are necessary for a truly universal all-in-one home automation setup without vendor lock-in.

Plus, for the full HAOS experience (as a “server”) running add-ons that are convenient one-click installed Docker-based packages for popular 3rd party tools used for home automation (but not developed by Open Home Foundation themselves) like Zigbee2Mqtt, Frigate (DVR for IP cams), EspHome etc so you can manage everything in one central location.

You could definitely flip light switches and read sensors with a 20kb executable. But you’d sacrifice the core value-add of HA serving as the single lynchpin connecting every smart device you own today plus whatever you may add in the future.

I started with a 100% Philips Hue setup that forced me to use their app, and eventually wanted to add some unsupported Zigbee devices that Google Home didn’t do a good job exposing which pushed me to explore Home Assistant.

Since then I’ve added (and removed) countless different protocols, proprietary cloud integrations for robovacs or air purifiers, ESP32 boards I built myself, web cams, TVs, etc over the years with the only unchanging constant being Home Assistant at the center linking it all together.

[mytailorisrich]

> You could definitely flip light switches and read sensors with a 20kb executable. But you’d sacrifice the core value-add of HA serving as the single lynchpin connecting every smart device you own today plus whatever you may add in the future

Very unclear what is the rationale for this claim.

It's great that Home Assistant supports "n absolutely massive number of both manufacturer and community maintained integrations" but that is quite irrelevant. The point is that running what you need to (mostly) flick switches and measure temperatures should not pull huge infrastructure, software requirements, and hardware capabilities. If it does then it does mean massive bloat.

[subscribed]

exactly. Its stunning it has to be like this.

[vablings]

I have had the opposite experience; I have an old trash intel NUC with a decent SSD and a moderate amount of RAM and it runs several services (on proxmox).

- Smokeping - Nginx proxy manager (with tailscale and - copyparty - home assistant - regular samba fileserver

[_flux]

I got myself a NUC. It's been worth it: tiny, has 16 GB of memory and 504 days of uptime.

I have servers for running VMs and containers but I felt like it would be nice to have this one as a separate device. It's also easy to plug in radio devices.

[benmanns]

Same. The complexity of HA also leaves my family with a bus factor of one re: keeping the lights on.

[Larrikin]

The minimum viable setup is the Home Assistant Green. I run it on a slightly better ODroid, since the green did not exist at the time. Any heavy task, like using Ollama, are passed over to my far more main computer.

[eurekin]

Few years on an OrangePi - zero issues. Few months on an N100 Odroid - no issues.

[bravoetch]

HA on R-pi running for almost a decade without issues here, including moving house a few times. Sounds like you're making it difficult with that setup. Mine is connected to light switches, alarm, duckdns for outside network access, motorized blinds, garage door opener, hvac, landscape lighting. It's magically awesome and takes none of my time to maintain.

[troupo]

> Though it’s kind of unreal how complicated it is to set up HA and I literally do this for a living, both embedded sw and backend web dev.

I just bought Home Assistant Green: https://www.home-assistant.io/green and a z-wave dongle

[cameronh90]

Sounds like the complexity is somewhat self-inflicted?

I set up HA from scratch on a new mini PC with Proxmox and HAOS in about 30 mins having never touched either before.

For VLANs, I just used port-based VLAN to attach it to the IoT VLAN, with firewall rule to allow UI access, but Proxmox has tagging support if preferred.

[davemp]

There’s like 10 replies telling me it’s not actually that complex then describe an equally or more complex solution that’s probably missing some of the security or features I have. I guess I wrote “complicated to set up” when I meant “complicated stack”.

A heavyweight blob of python running in a container talking to other containers running node-js on a Linux VM on a Linux host behind layers of networking to toggle 1 bit of information over a UHF link is really complex even if it only took 1 button click. My solution just removes the linux VM.

I’m not even saying I struggled, it took me like 1-4hrs depending on if you include the non HA stuff. I can clone the repo I made, populate the secrets/gateway, and type ‘make’ to rebuild my setup on a new machine. Everything is “zero-trust” with signed SSL certs, dynamic DNS+wireguard to tunnel in from a stable url, and room for more services. It’s cool, but it’s only toggled 1 light for years.

[Spivak]

Well sure, with those requirements running any piece of software will be complicated. None of the complexity has anything really to do with HA.

My pretty minimal stack:

- Intel NUC running Ubuntu LTS.

- Zigbee dongle I bought off Aliexpress.

- Zigbee2MQTT installed via package manager configured to use the Dongle.

- One single container running HomeAssistant with net=host

That's it. Has worked for years. Whenever I feel like it I ssh into the box, docker pull the latest image, rerun my two line bash script to recreate the container and go on my merry way.

[Rebelgecko]

I went through a similar process with Home Assistant. And the kicker is that months or years down the line, you'll hit some feature that doesn't work with the Docker version (I've ran into a couple)

[estimator7292]

I spun up a VM on my proxmox server and loaded HAOS. Job done. The only added steps involved giving the HAOS IP to my reverse proxy, now it's reachable from the outside net.

That's about as easy as it gets.

[steezeburger]

I run an HAOS vm via VirtualBox and then use Tailscale for a secured network.

[SwtCyber]

This is a pretty common experience with Home Assistant

[IncreasePosts]

Hate to be that guy, but I've had a lot of luck promoting gemini-cli to implement whatever I want in home assistant, and it's pretty good

[doctorpangloss]

The agents have saved Home Assistant. Every piece of content marketing about it should be showing how to use an agent to set up Home Assistant.