Hacker News Reader

What I wish I had known: HA is just a python program, it's pretty easy to run it manually.

After my Pi's sdcard died, I wanted to use an old laptop (more reliable with a built-in backup battery) so I followed the deployment recommendations and used the VM image. After that, for the first time I started having problems with HA not running - because VirtualBox would run only about a month before crashing. And I didn't like how much memory a VM locked up on the host.

The documentation makes it sound super complicated, but if you can make a venv and `pip install`, the setup is that easy. I tend to just run `hass` manually but there instructions for setting up supervised. I wish the documentation made this clearer, it really tries to scare people away from that method but running a whole VM is a lot of overhead for my pretty simple zwave-js setup.

Just use Docker?

There are a few things you can't do with docker (my case was an addon that I wanted). The install docs have a good grid of the differences.

I also don’t think Docker can do ARP network interrogation, though I could be wrong about that. Also not sure how it handles mDNS.

You can run in host network mode to avoid that.

The benefit of docker for home assistant is the packaging of it, rather than isolation. You can always run a container with host network mode and privileged mode so that it can access everything it needs to the same as if it were running directly on the host.

As an alternative to host network mode, you can give the container a dedicated IP on your network using the macvlan driver.

I've ditched all ARP, mDNS in my setup. Everything is static IP addresses: it vastly improved robustness against network glitches, which absolutely will happen to you.

If my router is unplugged or offline, everything with power can still communicate for example.

Nearly everything is static on mine too. I keep track of all the various devices' MAC addresses and assign them one IP. I also make sure that, even should I reinstall an OS on a device and "forget" to assign it a static IP, my router always assigns that MAC address the static IP I picked for that MAC address. I then keep a little range of IP addresses for unknown devices that the router is allowed to use when a new device shows up. Once in a while I log into my router and look which new device(s) I forgot to assign a static IP too.

When you say you ditched all ARP, did you do anything special? For example do you configure, on all your machines, static ARP entries for each MAC address of all your devices?

Sorry what I meant was I don't depend on any dynamic discovery systems like inspecting ARP tables.

Overlooked option for running these things in containers is macvlan networking. Just give it its own MAC address on the network. Works great and you don't have to compromise on isolation.

You can get mDNS working in Docker, but IMO it's much easier to give up and use host networking. It is _very_ difficult to get mDNS working in K8s.

I think it can, if you run your Docker containers in host network mode. I run my HA in docker using host mode, and it auto-detects all new devices that pop up on my network.

Can't do with docker or can't do as easily with docker as you can with HAOS? My understanding has been that everything can be done by just adding new containers or files, and it's worked for me thus far.

If you're using things like USB Zigbee dongles, they can be a pain to pass through to the docker container, or just not possible at all on macOS.

HAOS uses docker to containerize everything, so it can’t be that difficult, and it really is not. Docker has a —-device flag for this purpose, udev makes it easy enough to assign stable names.

zigbee2mqtt makes things easier to establish the bridge. Running as a container, next to home assistant container.

Docker does not support USB/serial device passthrough on macOS https://docs.docker.com/desktop/troubleshoot-and-support/faq...

macOS is not really a good OS for running a server anyway, and Docker Desktop is intended for development more than anything else.

Trust me it's not worth the effort to get USB passthrough for HAOS on Docker.

What do you mean by “HAOS on docker”. HAOS is a standalone complete Linux system with its own fully managed kernel, not meant to be containerized. It uses docker internally itself though and “pass through” works transparently.

If you’re talking about running home assistant in a docker container, sure you’re more on your own, but since official home assistant in HAOS must run in docker, none of this is terribly difficult to configure.

The dongles are usually exposed as tty devices and I’ve been running zigbee2mqtt and Zwavejs addons in docker containers for years with no issue. HAOS takes care of stable naming (based on default udev rules) out of the box.

Unlike system virtualization, there isn’t really anything that needs passing through, it’s a naming and permissions issue - the container just needs an appropriately permissioned dev node ideally with a stable name. If you are using official addons it is effectively zero-config, and if you’re not, sorry but I don’t find the configuration to ensure a dev node to be anything but straightforward container config.

As someone else mentioned it may be as simple as:

  devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

But you can just as easily use the /dev/serial tree to have stable names. Those names come out of the box with udev. You can always make your own too, I’ve done it, it’s not hard.

HA can be deployed as a container. Yes it uses containers.

I’m impressed with your knowledge of the Linux ecosystem. Regardless, passing usb devices to the containerised version is still more effort than it’s worth for the average user.

I'm doing USB passthrough for Z Wave right now and it's trivial. Just bind a volume to the device file.

Maybe Zigbee is different for some reason?

USB passthrough for docker (and LVM) is a massive pain. Avoid if you're just starting out. VMs or physical deployments are much more straight forward.

Could you elaborate? I run HA in docker, and the extent of necessary configuration was adding this in docker-compose.yml:

    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

Maybe you can consider USB/IP to pass thorough USB device over network.

From what I know, HAOS runs on Docker in the backend, plugins are basically containers that are started up

Have HA running without any issue on a Linux KVM VM.

Good advice, except that I’d try whenever possible to get AA/AAA devices rather than button cells. Not only do the button cell devices burn through batteries, causing a maintenance headache if you have a non-trivial number of devices, but the rechargeable battery ecosystem is much better developed for AA/AAA. We’re currently working on swapping out all our button cell remotes, especially.

Also, the replacement process on the button cells tends to be so fiddly - tiny screws, tiny little doors, etc.

A battery detection automation really helps with the maintenance (even for AA/AAA): https://community.home-assistant.io/t/low-battery-notificati...

Low battery detection relies on reliable battery level reporting.

Most of my devices hover around 90% for months, then drop to 60% and die within a day. I've stopped bothering with preemptive maintenance, and just replace batteries when devices drop offline.

Thanks! That would probably help our WAF/wife acceptance factor a good bit…

Here’s hoping our device battery level detection is better than that of the sibling commenter.

Newer ikea devices are standardizing on AAA because they can be recharged. The new motion sensors, door sensors, and buttons all use AAA batteries.

Thanks for the update. The ones I have are the Remote Control N2 using AAA, and the motion sensors use CR2032.

Last week bought IKEA motion sensor - AAA

Sadly there's no AAA equivalent to the simple old square Tradri 0/1 on/off dimmer switches that use the cr2032 batteries. Those old switches are small enough that I could 3D print brackets to mount them in my standard wall covers. The newer AAA devices are all much bigger or try to do too many things.

The RODRET is the AAA version.

Sadly is too big to mount inside a standard 70x70 mm EU wall frame

Also: The IKEA rechargeable LADDA batteries are rebranded Eneloops, confirmed by multiple tests to be virtually identical in capacity and charge retention.

As far as hardware, you can just get https://www.home-assistant.io/green (plus https://www.home-assistant.io/connectzbt1/ if you need Zigbee and Matter).

I'd recommend a Raspberry Pi instead. Easier to source (you may even already have it!) and I can guarantee it will be supporter longer and better than whatever low-volume Chinese board they're using here. There is zero advantage to this box, it doesn't even include built-in interfaces for some of the more "exotic" protocols like Zigbee or Z-Wave so you still need dongles either way.

https://www.home-assistant.io/yellow has the extra interfaces for Zigbee and Z-Wave - and the compute board is an Raspberry Pi 4 or 5.

Or get an ODROID! Much more powerful for (nearly) the same price.

You probably meant the same by "dedicated machine" but HAOS runs great in a VM too. I run mine on Proxmox and it's been rock solid.

+1 for HA on Proxmox

I’ve had the opposite experience. The literally home assistant branded zigbee stick refuses to work with HA („unsupported forward“) even after updates so all the zigbee stuff is in a box

Have had much better luck with WiFi. Both commercial and self soldered circuits. 2.4ghz WiFi is as battle tested as it gets and between esphome and tasmota it’s pretty open and customizable. Just need to steer clear of the usual cheap trash that comes with an app etc

Wi-Fi is battle tested but the network stacks on a lot of these devices are not.

Not a lot of these devices seem to understand the complexities of IP addressing (ARP, IP, etc.) very well so I’ve noticed they can lose connection easily. I’m sure you can limit yourself to products that have good network stacks but it’s hard to tell until you’ve wasted money. My Zigbee/Z-Wave devices have fared a lot better because the protocol is simpler and there is less for developers to screw up.

I think this advice is pretty context dependent. Plenty of folks have tons of trouble with their wifi network. For example, someone in an apartment with a very crowded wifi spectrum might have better luck with zwave (900 MHz).

WiFi is not good for a network with lots of devices. It's star topology which limits multi-device performance. And the WiFi AP which can carry many devices is expensive.

Many WiFi smart home devices only support old WiFi standard, it will pull down both performance (If there is a old standard device, the AP have to fallback to old behavior to match it. OpenWRT's setting also inform that.) and security (You can't use WPA3 only, even WPA2/3). And because these devices use the same network technology with your home network, you need something like VLAN to isolate them.

It's whole terrible story.

>It's star topology

I personally see that as a feature. When I was researching what route to go (wifi/zigbee/zwave) I encountered enough horror story posts about mesh networks to know that it's not for me. Small network absolutely, especially for battery powered devices, but meshes seem to hit critical mass where it becomes unstable & then people end up doing stupid shit like having to physically uninstall wall light switches to temporarily move them closer to hub to re-pair them

Adding more 2.4ghz AP capacity is comparatively trivial. Hell even raspberry pis can act as APs.

>it will pull down both performance

Anything where I care about performance is on the 5 and 6 ghz band. 2.4ghz is too noisy in cities for general use, but is entirely adequate for IoT sending a couple bytes every now and then.

>[WPA] security

That one is indeed a problem. At some point I'll stick them on a separate AP device with a firewall between that and rest of network, but can't say its a priority

I started with HA in a VM and some WiFi devices, added BLU later, never had the need for Zigbee. More than a year later and over 40 devices in 2 locations (with VPN between, using the same HA server), I am more than happy with the results.

Conclusion: people have different needs and go different paths.

Two more important notes:

- Use an MicroSD card that can handle multiple read/write like the purple MicroSD cards. Can also be a benefit with too big card to save some writes, to make the card last longer. Talking about <1year vs +50 in how long they last.

-It’s just Python, Jinja and Sqlite3 at the core. For custom programs I find it easier to write the Python program and then just convert to Jinja syntax.

Good microsd cards have write cycle or bytes written estimates in their specs. I usually buy those meant for dashcams since they have a bigger reserve capacity and are decently fast.

Instead of an error-prone SD card, use an SSD (internal, external doesn't matter).

OR create frequent backups that are pushed to a better medium.

Or just get a mini PC. I have an Intel N100 based one that wasn't much more expensive than a higher-end Pi, housing, wallwart, SSD and adapter, is substantially more powerful, energy consumption is pretty close, and it's potentially more useful if it needs to be repurposed later.

And then set up backups.

Also a tip that will save you few days and save you few things from destroying in anger. If you have existing zwave integration in let say alarm.com hub you first need to remove the devices from the network. Resetting DOES NOT WORK. Enjoy!

If your devices are bound to an old or broken controller, you can rescue your devices by putting a zwave controller into exclusion mode near the device and triggering exclusion on the device (how to do this is device specific, but it usually means "pressing whatever switch the device has"). Note that this is different than what many devices call a reset, which usually doesn't fully reset the device.

Exclusion mode should work on all zwave devices, because they have been certified as zwave compliant with the zwave alliance. The problem is that exclusion mode is extremely counter intuitive. Here is what you need to know:

1. Any zwave controller can exclude a device from any network. It does NOT have to be the controller for that network.

2. The controller needs to be near the device, as other devices won't forward the exclusion messages... at least I think this part is true.

So to rescue your device, you can plug a zwave controller into your laptop and walk around your house excluding devices. I wrote a blog post on how to do this: https://notes.bayesup.date/How+I+Made+a+Mobile+Z-Wave+Exclus.... There are some USB zwave controllers that have a built-in battery specifically so you can do this without involving your laptop.

Anyway, this is so poorly designed I suspect many devices have been thrown away in frustration even though they could have been saved. I almost did this to over $1,000 in zwave switches until I figured out how to write the freaking exclusion program myself and walk around with my laptop.

They also have a nice piece of hardware you can buy if you want an appliance that just works: https://www.home-assistant.io/green

This is the way to go if you want get things running without wasting days. HA needs to be on on wired LAN for the best experience so one more reason to have it run on RPi and maybe have it sit next to your router.

Can openwrt run HA? To run it on the router itself?

I have the weirdest issues with HA. Like I can either make or find everything I need, except audio inputs and outputs which seem like some kind of horrifying netherworld of barely supported through config hacks.

Which wouldnt be an issue if their voice assistant stuff wasnt otherwise fantastic.

They seem to really rely on some kind of all in one third party device, but I havent found any that work for me.

Yeah, I never got the audio (stt and tts) / assistant pipeline quite working, always the weirdest issues. I tried running with Docker and other configurations I don't even remember. Discord folks weren't very helpful. It's too bloated to run on old Pi's, requires new ones which are just computers by now and not cheap anymore. Gave up on it long ago.

Pretty much any z-wave device is going to work as well.

Highly recommended zooz devices, they’ve been robust and get consistent firmware updates.

Can you share some of the zigbee devices that you are using? Thanks.

Happy to, but caveat emptor, your mileage may vary, and so on. The following is for a North American site I was just in.

The things that are battery operated, no big deal. The things that are full power, make sure they are UL, CSA, CE, AS/NCS, JIS, IS, and such listed. The cheaper the device the more likely to have quality shortcuts. Last thing we need is things to catch on fire unnecessarily.

Aqara Smart Plug

Linkind PIR Motion Sensor

Linkind Door Window Sensor

Seedan Zigbee Smart Light Bulbs

Seedan Zigbee Smart Plug

Sonoff SNZB-01 Zigbee Wireless Switch

eWeLink SNZB-03 ZigBee Motion Sensor

IKEA STYRBAR remote control

TRADFRI motion sensor

Some Zigbee devices go to sleep (e.g., STYRBAR) and disappear from the list or show unavailable. Once acted on, they would come to life and perform as expected.