Home Assistant waters my plants

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.

> I think I need more Zigbee repeaters to get a reliable mesh network, but to date I haven’t found any consumer-grade devices certified for use in NZ.

Since many devices are also Zigbee router (it's a mesh network after all), maybe some additional lightbulb for exterior would suffice ?

I wanted home assistant compatible plant watering solution that works on a solar panel and does not require being connected to the water line and is Zigbee compatible. Unfortunately, I could not find any. So I did a DIY solution: a big barrel which I manually fill with water, a 12V pump (usually sold for camper vans), some rechargeable batteries, 10W solar panel, a solar charging controller, and Tuya ZG-2002-RF switch.

Cron waters my plants :)

Nice! For the hardware, why didn't you considered using a Raspberry Pi?

> I think I need more Zigbee repeaters to get a reliable mesh network, but to date I haven’t found any consumer-grade devices certified for use in NZ.

Since many devices are also Zigbee router (it's a mesh network after all), maybe some additional lightbulb for exterior would suffice ?

This - the move is to grab some zigbee smart plugs. Once you have HA up and running there are so many applications for these.

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.

Pretty much all mains powered Zigbee devices also act as routers in the mesh.

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.

Nice! For the hardware, why didn't you considered using a Raspberry Pi?

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.

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.

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.

> 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.

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.

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.

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.

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)

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.

This is a pretty common experience with Home Assistant

Cost-wise, there's a solid chance that the Pi would have been more expensive. Jeff Geerling ran some numbers (^1) on this last year, before the current chip crisis we're in, and it was bad enough already.

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...

I used to run HA on an RPi, but eventually migrated it to a similar NUC. The RPi eventually just wasn't powerful enough (peak compute needs), while the NUCs are still quite cheap. And you can run a surprising amount of Proxmox VMs and LXCs on barely a few cores and gigabytes of RAM.

Cron waters my plants :)

HA is essentially a better cron. It unsurprisingly uses the cron syntax where appropriate.

I dabbled in hydroponics for some years. Due to my inability to get my Rasberry Pi and Arduino working I ended up using a 12V pump and one of those cheap $10 electric timers on Aliexpress. I estimated how much time it took for my hydroponics system to drain and that's what I set on the timer. Other people I followed had all sorts of sensors rigged up, which I would have done if I had the time and skill but I failed, so in the end it was just the timer. I too had single solar panel and battery and the system worked for over 7 years with no issues. I just replaced the pump once or twice.

This feels like one of those cases where DIY ends up being simpler than waiting for the perfect product to exist

There are also irrigation controllers that use a ball valve and will work fine under gravity pressure e.g. raised rain barrel. Powered via battery that lasts months and months. No home assistant of course but water usage can be estimated from expected flow and programming.

An art student of mine once needed a way to electrically control precise small amounts of water. We solved that using:

  1. Water tank and gravity  
  
  2. Medical IV flow regulator¹  
  
  3. Servo hooked up to that IV flow regulator via a 3D-printed part

It worked very well. In medical applications off must be really off, so it was also quite safe in that regard as well. Her 3D-printed part had a little bit too much flex in it, but in principle this works quite well. If it is really, really safety critical I would still recommend a mechanical fallback that protects in case of power loss or when the servo fails open (e.g. bending the hose with the force of a spring if electricity is gone).

¹: see https://www.gvs.com/en/catalog/iv-flow-regulators

This - the move is to grab some zigbee smart plugs. Once you have HA up and running there are so many applications for these.

This is a pretty common experience with Home Assistant

This feels like one of those cases where DIY ends up being simpler than waiting for the perfect product to exist

Pretty much all mains powered Zigbee devices also act as routers in the mesh.

Exactly! I prefer the small power plugs that lets me control fans and other power systems as relays. Family has a habit if switching of light bulbs using light switches and i have not gotten the change approval to disable the physical switches in the house :)

HA is essentially a better cron. It unsurprisingly uses the cron syntax where appropriate.

HA is monstrously complex. cron just works. The same can’t be said for my homebrew esp32 pump relay controller, but at least scheduling is never the problem.

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

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.

> 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.

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.

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.

> 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.

HA is monstrously complex. cron just works. The same can’t be said for my homebrew esp32 pump relay controller, but at least scheduling is never the problem.

For me the best solution was to use smart switches (mainly dimmers) and dumb lightbulbs. People can use the switches like any other if they want, but I can still have my automations and remote control.

I can recommend Shelly for light switches over smart bulbs. It's a relay that fits inside the wall switch with zigbee to sit between the light and the switch.

I wouldn't recommend anyone to yank out physical controls for accessibility purposes.

It seems like quite the hassle to have to pull out one's phone every time one enters or leaves a room just to turn on lights?

Let's hope you don't have to get to the bathroom quickly late at night...

> 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.

> it will kill the card from IO cycles.

YMMV and all that.

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.

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.

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".

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.

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.

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

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.

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.

> 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.

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.

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...

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)

I wouldn't recommend anyone to yank out physical controls for accessibility purposes.

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.

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.

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.

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.

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.

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.

An art student of mine once needed a way to electrically control precise small amounts of water. We solved that using:

  1. Water tank and gravity  
  
  2. Medical IV flow regulator¹  
  
  3. Servo hooked up to that IV flow regulator via a 3D-printed part

¹: see https://www.gvs.com/en/catalog/iv-flow-regulators

I can recommend Shelly for light switches over smart bulbs. It's a relay that fits inside the wall switch with zigbee to sit between the light and the switch.

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

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).

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.

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.

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

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

> 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).

I use an RPi 4 w/ 4GB of RAM and a 1TB usb 3.2 SSD and it flies through all my workloads. Though I don’t do any video encoding things.

Wow, not sure how to interpret your experience that a RPi wasn't powerful enough to manage watering a few plants. I can only suspect the overall software setup is massively bloated.

> If it is really, really safety critical

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?

That's what I am doing too, though I did have to drill out some wall to fit it, in some cases.

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).

Agreed, people get very frustrated if they have to remember to not use certain switches. Using smart switches fixes this.

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.

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.

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).

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.

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

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

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?

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...

It seems like quite the hassle to have to pull out one's phone every time one enters or leaves a room just to turn on lights?

Let's hope you don't have to get to the bathroom quickly late at night...

As a another comment said, the smarter way to have a smart light is to replace the switch with a smart one or even better put a relay behind the existing dumb switch to smartify the switch. For me it's important to have a manual override; you shouldn't need an app for a thing as basic as turning the lights on.

Disabling the physical light switch should usually only come after setting up a different way of controlling the light by hand, without a phone.

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.

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".

> 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.

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).

Agreed, people get very frustrated if they have to remember to not use certain switches. Using smart switches fixes this.

That's what I am doing too, though I did have to drill out some wall to fit it, in some cases.

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.

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.

I use an RPi 4 w/ 4GB of RAM and a 1TB usb 3.2 SSD and it flies through all my workloads. Though I don’t do any video encoding things.

Thanks for sharing, your comment helped me track down that my RPI HA was disk constrained. I didn't think to add a USB.

The cool thing is that it's very easy to migrate it to better hardware. HA backup and restore system is highly reliable. For this reason I can definitely recommend an RPi to start with, and who knows perhaps it will be enough forever, but if not then moving is a matter of ~one evening.

> If it is really, really safety critical

Good point. In my case the program was so simple and the risk low enough that this wasn't needed. The worst thing thar could have bappened was some minor water damage to an exhibition space.

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.

Wow, not sure how to interpret your experience that a RPi wasn't powerful enough to manage watering a few plants. I can only suspect the overall software setup is massively bloated.

If you want to run EspHome inside HA, and you recompile the devices (every release of EH), you want a decent processor/disk. The ESP stuff is a surprisingly heavy compile for a puny microcontroller.

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.

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.

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

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.

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.

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

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".

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.

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?

Disabling the physical light switch should usually only come after setting up a different way of controlling the light by hand, without a phone.

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".

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.

Some readers will know, but most will not, that I am a bit of a self-confessed foodie. I enjoy cooking, but especially so when others get enjoyment from it. Be it friends, family, or neighbours, and sometimes all three, I’m always up for putting something together.

Food isn’t what this post is about, but it’s the underlying motivation for much of the things I talk about, mingled with a healthy dose of nerdism.

At work, some of my colleagues enjoy tinkering with Home Assistant. For anyone unfamiliar, HA is a platform for collecting data from devices, controlling them, and running automations. It’s pretty cool. I was unfamiliar with it, but it sounded pretty cool. OK, so we have a solution. Now to find a problem.

My property has a basic irrigation system for the lawns. 6 zones, you attach the right hose to the tap and let it run until you remember to turn it off. All well and good, but I figured it could be smarter and safer. So, that became the first thing I decided to solve with Home Assistant.

Here are the requirements for the system:

Simple. No crazy electronics.
Safe. Pissing water out for 24h would be bad.
Cheap. Let’s not break the bank.
Build in an extendible way to pave the path for future ideas.
Observable. I want proof it’s all working properly.
Run unsupervised.
Avoid cloud dependency where possible (a common desire for Home Assistant users)

The hardest part was choosing some hardware for this new platform. I didn’t want to mess around building a server, something off the shelf would suffice. I ended up going with a Beelink EQ14 Intel Twin Lake N150 which seemed like a good fit. It has a 500GB SSD, gigabit ethernet, 16GB RAM and a decent CPU. I paid $259 USD shipped to NZ. It’s definitely overkill for running Home Assistant and a couple of containers, but I wanted some headroom for future projects like a media server and it uses very little power.

Going back to my first use-case for Home Assistant (irrigation), I needed something to control water flow. Various solutions exist, from off the shelf to DIY, but I didn’t want to muck around with custom electronics in close proximity to water, where the failure state is a flood. I also wanted something that operated locally to the property and didn’t require cloud connection. I stumbled across Link-Tap which can either run as a cloud client or it can use a local MQTT server, which I figured would be easy to integrate with Home Assistant, so I took the plunge and got their Q1 4-zone unit.

Once it all showed up, I started by testing out the Link-Tap with their app and cloud integration. It all worked flawlessly and I was really pleased with it. I ran the irrigation schedule for a few days to prove it was working as expected.

Link-Tap installed with transceiver placed up high.

Next step was to get Home Assistant installed and configured. I decided to go full nerd homelab setup and install Proxmox on the Beelink. This was pretty straightforward, I just made a bootable USB stick and ran the Proxmox installer.

I found it confusing as to whether I should run HA in a Linux container, or as a VM. As most guides suggested the latter would be easier if I wanted to pass-through USB (e.g. for a Zigbee transceiver, more on that later), I opted to do that. With that, Home Assistant was up and running!

The next step was to setup an MQTT broker, which was also really easy. I ran it as a container in Proxmox and then connected the Link-Tap gateway to it so communications could happen over MQTT. The sensors (water flow, etc) and switches immediately showed up in Home Assistant which was cool.

Irrigation dashboard in Home Assistant

I was able to easily configure an automation to run the irrigation every morning, taking into account the forecast for the day (e.g. don’t run if it’s going to rain!). I also added automations to send me push notifications when any zone turns on.

I mentioned Zigbee earlier. I liked the idea of various sensors around the house and outside the property for measuring things. I picked up a SONOFF ZBDongle-P for $32 USD as it had good support for Home Assistant. It was easy to get working with zigbee2mqtt running in another container.

I started with climate sensors in various rooms but I’ve also added soil moisture and humidity sensors to the mix. These were all cheap battery devices from Aliexpress. The climate sensors are great but the soil sensors report data sporadically. I think I need more Zigbee repeaters to get a reliable mesh network, but to date I haven’t found any consumer-grade devices certified for use in NZ.

Climate dashboard in Home Assistant showing data from various rooms.

To take things a step further, I wanted to be able to remote into Home Assistant to check on things. I only wanted to expose Home Assistant though, not any of the other services to keep the surface area minimal. I decided to use Cloudflare tunnels for this, in combination with WARP VPN for security. It’s configured to only allow connections from within my Zero Trust account for safety. It mostly works, there’s a bit of friction when the session expires but it works OK most of the time. The Home Assistant CarPlay app even offers up my irrigation controls when I’m driving. Lol.

I’ve setup automatic backup of VMs and containers in Proxmox (I need to add an external disk for redundancy). Having never used Proxmox, I thought this might be hard, but I was pleased with how easy it was to setup a backup schedule.

I ran into a weird problem every few months where the mini PC wouldn’t recognise it’s NVME drive and would die, then fail to boot. It did this once when I was away for 3 weeks which was irritating. I have hopefully resolved this by disabling NVME deep sleep with nvme_core.default_ps_max_latency_us=0, see this ChatGPT conversation. If that doesn’t fix it, it’s probably a low-quality SSD causing the issue and I may need to replace it or send it back to Beelink which would be annoying.

Further things I’d like to do:

Install a media server and somehow make it accessible on the TV.
Add energy usage sensors - I am going to get solar panels installed so this may happen as part of that.
Resolve my Zigbee mesh network problems
Add more irrigation lines for my planter boxes, or build a greenhouse!

I’ll leave you with some photos of the greenery!

Flat-leaf and curly parsley

Pak choy, spring onions, lettuces, beets

Tomatoes, capsicums, courgettes

Taragon, coriander, chives, thyme, sage, rosemary

Courgettes

Flower raised bed

Strawberry!

Thanks for sharing, your comment helped me track down that my RPI HA was disk constrained. I didn't think to add a USB.

Good point. In my case the program was so simple and the risk low enough that this wasn't needed. The worst thing thar could have bappened was some minor water damage to an exhibition space.

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.

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

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

you mean an image like this?

If you want to run EspHome inside HA, and you recompile the devices (every release of EH), you want a decent processor/disk. The ESP stuff is a surprisingly heavy compile for a puny microcontroller.

A recent RPi is sufficient to handle a few plants - though, yes, recompilation will take time. The ESP is a beautiful piece of software, hence I highly recommend it. My native language has an expression that describes this situation perfectly: the appetite grows with eating. Next thing you know you have 2k or more entities, and your HA even handles some video feeds.

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 :)

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.

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.

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

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

Hacker Times

Hacker Times

Home Assistant waters my plants

Discussion

Discussion