Home Assistant waters my plants
finnian.io
finnian.io
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.
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.
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).
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.
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.
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).
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".
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.
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.
- Smokeping - Nginx proxy manager (with tailscale and - copyparty - home assistant - regular samba fileserver
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).
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.
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.
I don't run addons though, which might be part of 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.
But it was also quite easy to pass a USB device to the HAOS VM in Proxmox.
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.
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.
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.
YMMV certainly applies but I feel like the warning is important.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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?
The HAOS ISO cannot install itself onto a machine. That is my minor complaint.
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?
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.
There's nothing wrong with running it on bare metal but this is easier with the VM image.
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.
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.
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.
I'd love to read more about this!
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.
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.
I just bought Home Assistant Green: https://www.home-assistant.io/green and a z-wave dongle
That's about as easy as it gets.
Since many devices are also Zigbee router (it's a mesh network after all), maybe some additional lightbulb for exterior would suffice ?
Let's hope you don't have to get to the bathroom quickly late at night...
Most likely there is some sort of motion or presence sensor that turns on the lights which then turn themselves off after some time or no more presence is detected. There are also small wireless switches that could be used in place of the actual wall switch.
I have done so in my apartment for example. Since the bedroom light switch is for some reason outside of the room I taped it down and put a wireless switch in a more reasonable spot. Another example is the hallway light, which only turns on by motion sensing when the sun is starting to go down.
And even the living room automatically adjusts lights based on the playing status of the AppleTV (playing = dim, pause = brighten up a bit).
Oh and the staircase, haven't found the motivation/courage to climb up 10m to the ceiling to switch out the ye olde light in there :D Maybe this year?
The Living room would need two presence sensors that talk to each other in a smart way (a big room, one isn't enough) and I haven't yet found the semi-manual way of adjusting the lights via phone/Siri to be too cumbersome to bother.
There is another option that I don't think many people are aware of: You can put a battery powered relay downstream of the (dumb) switch, and have it broadcast events when power comes on and off, to control other smart devices, which just have to listen for the events (via a broker like HA).
This is the only solution I'm aware of that gets you all of:
* dimmable,
* colour temp and RGB control,
* regular switches that work as expected,
* no "forbidden" switches,
* lights always available for automations,
* lights go on and off with the switch when HA is down.
Depends on your definition of "regular switches," I suppose -- but anyone with 3-way wiring (i.e. multiple light switches for a single socket) has given up on "up=on" for their switch.
* No battery powered devices in walls,
* Lights don't come on automatically following power cut.
If the Shelly relays supported ZigBee direct bind then it would be even better, but with decent ZigBee devices it's not bad with my setup.
I have a door sensor that monitors my kids bedroom door, and when it opens it turns on a desk lamp in my room. This allows me to get to him before he gets to my partner who's sleeping with the new born.
I find home lab stuff has far more return on investment for like automatic blinds, lights, etc. It’s not like you can just stay inside anyways and get amazing vegetables, you still need to be on top of thing like checking for pests and disease. The automatic garden is a myth.
1. Water tank and gravity
2. Medical IV flow regulator¹
3. Servo hooked up to that IV flow regulator via a 3D-printed part
Your suggestions should be fine for hardware failure but I'd be more concerned about software failure: what if a bug in your software makes it unresponsive and stuck in the state with the flow open? Maybe a watchdog or some other system running in parallel checking for a heartbeat or a max amount of time water can be flowing?
Also my track record of writing stable, bug free embedded software has been pretty solid as of now. But if human life would be on the line (for example) special precautions like multiple independent failsafe mechanisms are non-negotiable.
Really makes me want to integrate the whole thing into an ESP32 with a display so such a thing doesn't require HA.
Automation to determine that the thing watering the plants has failed is crucial.
This is especially true if the system is some form of setup in which there isn't a bunch of soil to buffer a couple of days of not watering correctly (like hydro- or aqua- ponics).
The valves were 12v solenoids from ali express, and the plumbing was from the hardware store. I almost guarantee it was far, far cheaper than this project.
1) install HAOS, running it any other way is a step towards madness
2) get a decent zigbee controller
3) https://sonoff.tech/en-uk/products/sonoff-zigbee-smart-water...
Job done, the rest is all up to taste using either sensors or public data to infer water state.
The important thing is that it's pretty much always easy to make an upgrade thanks to the good design of the backup system. Don't forget to set up backups in either case, it's a sin to not use such a complete system :)
…having said that, as the other poster alludes to, it’s peak requirements that are problematic. If your device can handle them, it’s not a massive power suck because idle requirmements are low.
Home Assistant does a surprising amount of Disk I/O, if for nothing than for logs. Sibling commenters are also advising not running it on the SD card to avoid wearing it out, so there's definitely some truth here. This means we're adding a Pi M.2 hat + SSD into the mix. The Pi5 SSD kit for 256 GB, when it was available, was around $60 USD. A Pi5 with 8 GB of RAM is $130 USD. Now we need a cooler, a case that will fit the Pi5 with said M.2 hat, and a power supply. We're already well north of $250 USD, encroaching on $300, and we're not even using the core benefits of the Pi's platform. No need for GPIO pins, tightly integrated cameras or other sensors, none of that.
For all we know, the blog author did this assessment (or trusted the assessment of others, eg: Jeff) and came to the came conclusion - it wasn't worth the price of entry.
^1: https://www.jeffgeerling.com/blog/2025/intel-n100-better-val...
My home assistant also waters my plants. She generally enjoys working in the garden.