If you are thinking of deploying Home Assistant (HA), let me give you a few tips that I should have known when started. HA environment is vast. There are myriads of options, features, and functions. There are some gotchas that can be costly down the road.
All of the following are "for now, as you start out":
Do not gyrate over which version of HA to run. Run the HAOS loaded on RasPi, or a dedicated machine. You can migrate to other solution if that does not end up to be the best choice.
Make sure you get the latest Zigbee radio dongle the HA Forum recommends. I use in all my HA installs a combination dongle for Zigbee & Z-Wave and it works flawlessly (NORTEK Quickstick Combo).
Start with a few cheap Zigbee devices. Stay away from WiFi, LoRaWAN and other solutions. Z-Wave devices are great, but more expensive. You know you do not know if you even want to do this.
Initially, just use the built-in Zigbee (ZHA) integrations. Once you are comfortable deploying other ways, like MQTT can be established easily.
Do not spend too much on the devices now. I suggest you pick up a PIR motion sensors, door & window opening sensors, temperature & humidity sensors, smart plugs, and light bulbs. Anything else is overkill to try out. Sub-tip: all of these are battery operated, so try to consolidate on a standard battery. The ones I listed can all run off of 2032 cell batteries. Ikea sells most of these, Aqara is well known, and so on. If it is Zigbee (not Matter) you will have 96% chance it will work with HA.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Also: The IKEA rechargeable LADDA batteries are rebranded Eneloops, confirmed by multiple tests to be virtually identical in capacity and charge retention.
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.
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.
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.
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.
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 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).
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.
- 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.
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.
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.
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.
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.
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.
All of the following are "for now, as you start out":
Do not gyrate over which version of HA to run. Run the HAOS loaded on RasPi, or a dedicated machine. You can migrate to other solution if that does not end up to be the best choice.
Make sure you get the latest Zigbee radio dongle the HA Forum recommends. I use in all my HA installs a combination dongle for Zigbee & Z-Wave and it works flawlessly (NORTEK Quickstick Combo).
Start with a few cheap Zigbee devices. Stay away from WiFi, LoRaWAN and other solutions. Z-Wave devices are great, but more expensive. You know you do not know if you even want to do this.
Initially, just use the built-in Zigbee (ZHA) integrations. Once you are comfortable deploying other ways, like MQTT can be established easily.
Do not spend too much on the devices now. I suggest you pick up a PIR motion sensors, door & window opening sensors, temperature & humidity sensors, smart plugs, and light bulbs. Anything else is overkill to try out. Sub-tip: all of these are battery operated, so try to consolidate on a standard battery. The ones I listed can all run off of 2032 cell batteries. Ikea sells most of these, Aqara is well known, and so on. If it is Zigbee (not Matter) you will have 96% chance it will work with HA.
Have fun!