I'm still figuring out Home Assistant. I love that it has a real ecosystem and that it seems to have a decent HTTP/WebSocket API (that I just started playing with).

Some things I don't love:

* A lot of the integrations seem half-baked or to not quite fit the generic Lovelace cards. I think to some extent this is an inherent problem in supporting a lot of devices that have crappy, non-standardized APIs. Example: if I bump up the low temp on my Venstar thermostat on the Home Assistant dashboard, Home Assistant will immediately set it back. If I dig through logs, I see the thermostat complained that in auto mode (heating or cooling as needed), the low set point and the high set point have to be (at least) six degrees apart. When I adjust the thermostat through its own touch screen, the high set point automatically raises to meet that constraint. Home Assistant should do the same. I've been meaning to look into fixing it myself, but there seem to be weird things like this on every integration.

* You need multiple automation rules to do almost anything. I think it's common to want the state of one thing to match another (for example, garage door open => sticky notification on my phone, person in driveway after sunset within last 5 minutes or switch on => driveway light on). You need a rule in their YAML DSL to for the off->on transition and another for the on->off. It'd be nice to set a rule that defines a level rather than an edge and have it internally do the transformation. It'd also be nice to define the actions of a notification's buttons inline, rather than as a separate automation.

* The companion Android app's notifications seem to be flaky. At least, they're sometimes slow. I think they can be delivered out of order and possibly are lossy, which aggravates the problem with not having something that just sets the state reliably. I assume it's pretty hopeless to have it reliably be in the right state if your phone was off when a notification was supposed to be delivered or Home Assistant was down on state transition or the like.

* Some things seem to be only checked at startup, so my house has race conditions after power outages. For example, if Home Assistant starts up more quickly than my Yamaha AV receiver (+ network switch + DHCP server), I can't control my home theater setup until I restart Home Assistant.

> ... for the off->on transition and another for the on->off. It'd be nice to set a rule that defines a level rather than an edge and have it internally do the transformation

The "solution" I found was to poll, and use "choose", and sometimes some helper switches for state, to do what is needed. But, I think at any reasonable level of complexity, you're better off using one of the three python components: the one built into Home Assistant, pyscript, or AppDaemon.

Home Assistant Python: https://www.home-assistant.io/integrations/python_script/ No imports.

pyscript: https://github.com/custom-components/pyscript Full python. Supports Jupyter. Straightforward.

AppDaemon: https://appdaemon.readthedocs.io/en/latest/HASS_TUTORIAL.htm... Full python. A little lower level. Allows the creation of dashboards.

Related, the Matter protocol is on its way. I'm waiting for these devices before I redo my house, or put much more effort into any of this: https://en.wikipedia.org/wiki/Matter_(standard)

Thanks for that. I just tried out pyscript. I found it a lot more pleasant to write automation in a real programming language. It also more or less addresses my complaint about needing multiple rules. In the tutorial, [1] the motion_light_rear example addresses this via sleeping + task.unique. It's not the approach I imagined, but it's aimed at the same problem.

[1] https://hacs-pyscript.readthedocs.io/en/stable/tutorial.html

Matter is interesting. But...

> The project group was launched and introduced by Amazon, Apple, Google, Comcast and the Zigbee Alliance, now Connectivity Standards Alliance (CSA).

I'm having a real hard time believing that anything user-beneficial will come of this, unless you're willing to sell out your smarthome and privacy to big tech.

Another way to look at this - maybe this is a way to give a pressure relief valve for all the privacy conscious so they stop harassing them so much for the 90% of consumer case that doesn’t care?

I think people are also very unhappy with latency. The only way to get low latency is to keep things local, and for devices to work together, directly. But, people still want remote access.

> I'm having a real hard time believing that anything user-beneficial will come of this, unless you're willing to sell out your smarthome and privacy to big tech.

At this level, the way data is handled is vendor agnostic.

I see Matter as more akin to USB, or indeed, the internet, as the idea is that devices are supposed to be able to communicate via IP, not just by ZigBee.

> my house has race conditions after power outages

I'd be inclined to find something with an SNMP counter that counts up either "seconds since boot" or "megabits of traffic passed" or whatever else and have a script that runs shortly after the RPi boots to reboot the Pi if that counter if below some threshold.

Running this from the pi will query the uptime on my router in milliseconds:

  snmpwalk -v 2c -On -c public 192.168.2.1 .1.3.6.1.2.1.25.1.1.0

You could have a startup script on the Pi do something like "wait until you get a valid reading of this uptime and if that reading is less than 180000 [3 minutes], then sleep for N minutes [long enough to not double/triple reboot on a power outage] and reboot the RPi (or restart HA)"

If HomeAssistant needs to be recycled after every router reboot (not just on a power dump), have that script run in a cron job looking for an uptime less than some threshold and rebooting the Pi.

It might feel inelegant or even "gross", but I look at it as just reliably automating the fix and therefore better than what you're doing manually already.

On my Venstar you can adjust the spread. I guess you probably wouldn't really want to.

Looks like that integration is implemented on top of an external library (so you have 3 layers of implementation):

https://github.com/hpeyerl/venstar_colortouch/blob/master/sr...

The HA integration doesn't use it, but the library exposes the spread value.

I also hate that you have to install it as an OS or VM to be fully featured.

If you use the docker version it is crippled with no "supervisor" mode.

Also every now and then a light or switch will go greyed out in HA, their official apps still work, and I have to restart HA to be able to use it in HA again. Pretty annoying when you get home after a long day, soaked in rain, fumbling in the dark to turn on lights and now you have to fumble more to restart the damn server before you can use your lights.

Supervisor mode is basically operating system configuration stuff (DNS, audio, etc.) telemetry for the dev team, and health checking: https://www.home-assistant.io/blog/2020/09/16/supervisor-joi.... (Unless I'm missing something?)

It seems fine that this isn't available in docker, since you can do all of this via docker and your host's configuration system. It would be nice to have a GUI for it, but if you need a GUI then you probably aren't running HA via docker, you used their image.

How is the container version crippled?

An anecdotal data point, but I've been running the home-assistant container image on k8s without any issue, and I have a lot of integrations.

Same here. Running on a pi 3 with nodered, both in docker containers. Works perfectly and reliably with hundreds of entities, numerous automations, etc. Just make sure you have an official pi ac adapter and boot off an SSD drive not SD card otherwise you will have problems.

You can't run HACS, supervisor mode, Kelvin-sun matching plugin ...

I'm running HACS in the container release right now, it's worked for a long time. So long as you have your HA configuration folder as a volume etc it will preserve across restarts/upgrades.

I'd go as far as to argue the (officially supported!) container release is the best way to get a production quality install of HA - containers are a great way to package and release complex web apps like HA. Mines automatically updates itself every time new container image released, has done so with no intervention from me for over a year. With the container lifecycle/config, you don't really need Supervisor mode either.

To say it is crippled is nonsense, it is literally one of the two officially recommended install paths:

> https://www.home-assistant.io/installation/

Official support for Docker release in HACS:

> https://hacs.xyz/docs/setup/download#home-assistant-containe...

Totally agree. I use the docker containers and persistent volumes and works great. No loss of function,.

HACS works in a container, or is there specific functionality of it that doesn't work? I've been using it inside a Docker HA container on a Pi without issue.

Try using nodered for HA automations. Much simpler and flexible.

They've also been pretty hostile to OS packagers trying to let you run it without dedicating an entire device to it, most publicly NixOS but they indicated they planned to insist the same against Fedora and Gentoo too: https://github.com/NixOS/nixpkgs/pull/126326

That behaviour kind of makes it hard to trust that it won't lead to the next Marak situation.

This kind of pushed me away from HA. I've ended up using integrations built using hc [0] to bridge devices to HomeKit, either existing or ones I've built, and then using Promtheus to collect metrics. It's not something that 'just works', but I feel much happier with how it works than HA.

[0] - https://github.com/brutella/hc

For what it's worth frenck does not represent Home Assistant and the first sentence of his profile is "Slightly assholic at first sight"...

That said you have a point but in my usage of Home Assistant almost since birth when it was a single pip install command I can tell you the sheer functionality, integrations, etc make getting it fully running a nightmare. Not to mention from their perspective actually supporting it almost impossible. Maybe this speaks to a wider problem but I'm very happy to install it with docker on the distro and hardware of my choice and have everything more-or-less just work.

I referenced the operating system approach here because it's the quickest and easiest path to get up and running on a Raspberry Pi and therefore relevant to the article.

I run it in a VM and don't mind it; it's got the updater, it feels pretty self contained.

I even do USB passthrough to give it access to my z-wave stick.

I've been running homeassistant installed by pip3 for years now (before they even had a os) and that has always worked fine.

I gave up on it solely because of the GUI. It's confusing as heck and very far from Apple's Home app, which is the preferred UX of the CFO (Chief Family Officer), even for fairly complex automations.

So I just used homebridge for everything, with a smattering of Node-RED for (very few) device shims (it is _very_ easy to do MQTT handling with it).

Also, I now have zero YAML to maintain, which is also a boon.

Kudos, though, for Home Assistant auto-discovery, which I use with my Tasmota-reflashed devices (there is a homebridge plugin that transparently adds them to HomeKit as soon as they're set up).

For folks here I strongly recommend installing the appdaemon integration and just writing python scripts. The downside is there is a good bit of learning curve and time investment just to get the hello world going (turn on a light at sunset?).

Once you are there, you can write shared libraries, abstract away whatever you want, have legit tests, and just do anything you would normally want in your coding environment (vscode, auto-formatters, source control, etc). Obviously not the right recommendation for a consumer system, but if you are like me and feel more comfortable with a programming language, it's the way to go.

I can do that with homebridge-mqtt (I just stopped doing it in Python because Node-RED did what I needed and gave me a dead easy chart for temperature sensors).

Fully agree.

Interested about the tests though. I’m not a professional python developer but would love automated tests for my appdaemon code. How did you set it up, and how do you run the tests?

I used https://pypi.org/project/appdaemon-testing/. You can write a simple test file which does things like sets a device state, then asserts that services were called or whatnot.

It doesn't test that the service calls are correctly written, just that they were made. So, very useful for unit testing syntax / logic, but not a full end-to-end integration test solution. Still, with python being an interpreted language, this is super useful. I don't want to have to wait for it actually to be sunset to determine I have a syntax error in that branch of the code, for example.

I don't actually have the tests running on the HA device. I have them on my desktop where I develop the appdaemon scripts, and then I copy only the scripts over to HA. I'm sure there are multiple ways to do it.

Thank you, that’s helpful.

I recently set-up HA on a Raspberry Pi, integrating my lights, security system and other devices. You're right about it having a steep learning curve but once it's up and running it's pretty much set and forget. With HA I'm able to use my Hue switches to toggle a TP-Link Kasa smart power outlet. It also has the added benefit of only requiring ONE application on my phone instead of nine.

I'd also suggest to everyone looking into HA to take the time to learn Node-RED. After running HA for a year and a half, but only ever creating basic integrations, NR has really unlocked the power of HA for me. Part of it is the tutorials for NR explained the internal data model of HA in a way that I finally get it. Plus just ergonomically, I find NR MUCH easier to deal with than HA's native automation UI.

Same. I've been a huge Home Assistant fan and minor contributor for many years. My house is among the smartest houses I've ever heard of. HVAC control, security system, air quality monitoring, multi-site IT systems monitoring, lighting controls (including LED strips that update to the right color scheme for the next holiday), whole-house networked audio (including streaming off-site if connected to the VPN), on and on. All self-hosted, on-prem, zero cloud, coordinated by Home Assistant. Offsite notifications via email, offsite control and monitoring via my Openwrt router's VPN server.

Have your written up your implementation? What type of air quality sensors have you used and how are they integrated into the home’s behavior?

I have done a bunch of writeups, in this category [1]

The weather station post in particular with the sensors is here [2]

[1] https://partofthething.com/thoughts/category/electronics-and...

[2] https://partofthething.com/thoughts/weather-and-air-quality-...

Thank you.

+1 for the air quality sensors question. I only found 1 for CO2 levels, and it is not connected. And even that one costed $120.

Tuya Zigbee air quality sensors on AliExpress start around $20. I can't speak to their accuracy, but they are supported by Zigbee2MQTT and provide a CO2 reading.

https://www.zigbee2mqtt.io/devices/TS0601_air_quality_sensor...

Answered here: https://partofthething.com/thoughts/weather-and-air-quality-...

Home Assistant has been nothing short of amazing. I started out just wanting to control my Christmas lights back in early December; tried going the HomeKit with HomeBridge route, only to realize I needed an iHub or some other (i) device on my network to have it work remotely. It was a bad experience even while on my network, luckily stumbled upon Home Assistant looking for better options a week or so into the journey. Now I'm controlling everything, even watching my security cameras, through HA.

The one caveat in my experience has been trying to run Pi-Hole on the same server as HA Supervised or using Adguard Home. Trying to run HA and PiH, even though they were both in docker containers, caused the Pi 3B+ to freeze every few hours. HA makes it clear running anything else is a bad idea, and that proved correct. I deleted PiH and tried the Adguard Home addon for my DNS for awhile, it was really slick and had a lot of features, but I found myself missing the PiH for several reasons. For one, it really sucked to be tinkering with HA while other people on the network were on the web; every time I needed to restart HA (which was often setting up the cameras), I'd get constant groaning and moaning about the internet being out. I also found it harder to control white/black lists; adding individual sites here and there was not as simple as it is in PiH. It also lacked the simple "disable for X minutes/seconds" feature I used so much.

I ended up installing just PiH on the Pi 3B+ and grabbing a cheap Chromebox off ebay to run HA. All the things I was doing on HA really pushed the Pi at times and I read one too many stories about SD cards dying from heavy use. Now everything is zippy and I feel safer with HA installed on the internal M.2 SSD.

I've had luck running HA and node red on a pi 3 but with 250gb SSD drive, responsive and reliable. I think that's the bottleneck. You can't use SD card. Also must use AC adapters specifically for pi, usually slightly above 5 volts and 2 amps I think. Also pinhole must be on separate device I agree with that.

Yep, I could have made it a better situation with some extra addition$ (I always put my Pi on a quality AC adapter from the start, those constant command line voltage nag warnings had their intended effect), but the cost of the SSD + another Pi is actually more than a used SFF device with a substantially more powerful Intel processor that comes with a M.2 SSD. It's amazing what you can get for < $50 these days. Great time to be alive for us tinkerers!

I spend my last weekend setting up Home Assistant using VMWare on my spare machine. To say that it has been very rewarding is understatement. I am completely blown away by the possibilities that it enables. For instance, I have all my unsupported devices magically supported in HomeKit via the HomeKit Bridge integration in HA.

I've really wanted to get into this to some extent but it's such a complex (and expensive!) topic that I really would like some distilled knowledge from someone who's been through it and figured out what works and what doesn't, the pitfalls, etc. This is probably a good place to ask - does anyone know of a reliable guide (or ideally blog) to get started? Or maybe would be a good topic for a future HN submission.

My personal focus would be on cloud-free/self-hosted systems. Looping through the cloud as a convenience is fine but I don't really want to rely on cloudshit 100% for the operation of my house.

Also I've heard really good things about the Lutreon stuff? Not open, and not cheap, but it works, and I've heard the z-wave stuff isn't always 100%.

I’ve used Home Assistant on a Pi 3B+ for about a year now. My main objective is like yours, I want as few devices as possible connected to the internet and generally only buy devices that have a local API (local polling in HA terms). I do pay for Nabu Casa, HA’s cloud service for convenient access to everything but nothing I use requires it. This also help support a project that I really enjoy using and rely on.

I have most devices connected to an old wireless router that is completely disconnected from the internet. The raspberry pi is connected to my main network through ethernet and is connected to my “smart network” over wifi. I like to think of the HA instance as a two way mirror since it can reach the internet and see the devices but the devices themselves can’t phone home or access the internet in anyway.

For bulbs, light switches, and smart plugs I generally stick with TP-Link Kasa. The local API works great with HA though I believe they are removing this in future firmware updates [0]. This appears to be for the UK only but I’m not 100% sure on that. I purchased a plug a few months ago that still works.

My thermostat is a Venstar color touch with the local API. I have it connected to the internet but I could disconnect it and everything would still work how I want.

You can flash Wyze v2 cameras with the official RTSP firmware to view them locally. You lose some of the features of the Wyze cams but I think this is a fine trade off. While this works with the Pi, streaming video taxes it a lot. It isn’t a perfect experience by any means.

I also use Zigbee devices instead of Z-Wave (no real reason other than the first device I wanted was Zigbee). I have a Sonoff Zigbee bridge flashed with Tasmota that allows me to use any compliant (or quasi compliant in the case of Xiaomi Aqara) plug, motion sensor, temp sensor, etc across brands. The Zigbee bridge is also has access to the internet because it needs to connect to an NTP server. This means that these devices work fine when the internet goes out but if for some reason the hub gets power cycled while having an internet outage they stop working.

You can get Zigbee antennas that connect directly to the Pi but I avoided this because the USB ports can cause interference. You can fix this by getting a USB cable extender.

Feel free to ask any other questions about my setup.

[0] https://alerts.home-assistant.io/#tplink.markdown

I setup Home Assistant to be able to talk to my solar inverters and see my battery voltage without walking out into the garage (over modbus).

Since then I started adding in door sensors and my thermostat. I just need to find a way to see how much propane I'm using and I'll be set.

How do you handle network security? I wouldn't trust an IoT device on the same network as any of my family's computers or phones for example.

I personally just flash everything possible with open-source software. All my light switches and Wi-Fi lightbulbs run Tasmota, which I password protect and semi- regularly update. The one odball is my Gree AC unit, which is on a separate WiFi network and subnet (I just run hostapd on my RPi since it's close-by). But it's more to protect it from the outside, not the other way, because it's controlled with JSON sent over UDP, and if you send a malformed packet the microcontroller inside crashes. When this happens and the compressor is engaged it will freeze up, possibly destroying itself and start flooding the floor, because the condensation pump won't turn on.

> But it's more to protect it from the outside, not the other way, because it's controlled with JSON sent over UDP, and if you send a malformed packet the microcontroller inside crashes. When this happens and the compressor is engaged it will freeze up, possibly destroying itself and start flooding the floor, because the condensation pump won't turn on.

Wow, the future is truly here folks!

>> When this happens and the compressor is engaged it will freeze up, possibly destroying itself and start flooding the floor, because the condensation pump won't turn on.

Do not buy Gree. Check.

Or maybe not automate destructive devices. Might be simpler and more responsible anyway, since equivalent harm can be had if your kids ask Siri to warm up the house...

Automation bugs are dangerous on any home device. I once accidentally programmed an infinite recursive loop on all the lights in the house so had on and off signals being sent nearly simultaneously. Scary and not a good thing but easy to do particularly with wifi and mqtt messaging. Had to shut main power off. Luckily only one light switch broke.

What lightbulbs do you find are best for running tasmota? I'd prefer not to have to setup a zigbee setup in addition to my zwave.

Smart lightbulbs are crappy, since If you turn them off using a light switch, you can't turn them back on via Wi-Fi. I've installed smart relays (Sonoff mini) behind light switches, which means I can control them localy and remotely at the same time.

That being said, anything that can be flashed using tuya-convert will be good. But beware, because not all Tuya lightbulbs hava an ESP chip inside and they have patched the exploit tuya-convert uses in newer firmwares. So check your model on google.

How did you find that out? You mean random UDP packet can destroy AC?

/me having a Gree unit that is to be installed

Before I got a Raspberry Pi with home assistant, I was trying to write a simple client for this protocol in C so I could host it on my OpenWRT router. Of course my client bugged and sent some random junk which caused the unit to completely lock up, it displayed 88 on it;s display and didn't respond to the IR remote. After this I had to reset it via the circuit breaker.

If I recall correctly, the data was encrypted using a static AES key, and I think the unit checked if the data decrypted correctly, but don't quote me on that.

In addition to all of the "use Z-Wave/Zigbee as much as possible" comments (which I personally do), for stuff where there's no choice like Roombas, I have a separate SSID on a VLAN that can only talk to the internet, my DNS server running Adguard, and HA (which is on the main network). I also have stateful rules that allow connections to be initiated from the main network to the IOT network, but not vice versa. I also try to find things with ESP* controllers, as mentioned.

I've really been trying to move away from cloud based stuff not only because of data privacy, but concerns about services going away and (most importantly) latency.

My old wifi smart plugs had 2+ seconds of latency from when I'd hit the button in HA to actually turning on. Zigbee/Z-wave stuff is (from my meatsack perspective) instant. I have a zigbee door sensor on the door to get into my garage, and a zigbee smart plug connected to the overhead florescent lights. By the time the door opens enough for me to actually see inside the garage, the lights are on. Sometimes I think they never turned off. It's fantastic.

How do you setup a separate VLAN and SSID? None of the "pro-sumer" wifi mesh setups under $500 support VLANs

I use Unifi for wifi gear, which supports it out of the box.

https://www.ui.com/unifi/unifi-ap-ac-pro/ for the wired AP, https://store.ui.com/products/uap-beaconhd for the extension into the back of the house. Pricy, but not completely outrageous IMO.

For an actual router, I run OPNsense in a VM (on the same box as HA, funnily enough). My server has dual 10 gig ports, so I pass through one of them to OPNsense and run it as a "router on a stick", where the basic internal network is the untagged VLAN, and the public side is VLAN 99. My switch then strips the VLAN 99 tag from the packet before sending it to the cable modem, and vice-versa. My switch is https://mikrotik.com/product/crs328_24p_4s_rm, which was $379 in 2018. However, you can get similar functionality from MUCH cheaper microtik or unifi/ubiquity switches if you don't need 10 gig support.

If you're starting from scratch I might get something like https://store.ui.com/collections/unifi-network-unifi-os-cons..., and an el cheapo dumb switch, as long as it'd pass through vlan tagged traffic. You want anything that's crossing a vlan boundary to end up on the router anyway, so you can apply firewall rules to it.

Do you feel that using a virtualized router with other things on the box puts you at greater risk? I.e. you're putting an awful lot of eggs in that one basket. I've considered setting that up before but shied away from it.

Availability risk? Sure, but that's 99.9% my own doing (constant experiments, etc)

Security risk? Not in the slightest. I'm running an up to date proxmox which is just KVM+QEMU with some scripting and a website on top, basically. I know how to setup IOMMU groups and such. If it's good enough for the big cloud providers, it's good enough for me.

Yeah primarily I'm concerned with availability. I have a "production" hypervisor now with all of the household services running on it that I've promised my spouse I wouldn't mess around with which cuts off one avenue of experiments.

Ah yeah, I definitely have the distinct advantage of living with me, myself, and I :)

In this case, if maintenance starts happening without your knowledge, something else is going on.

Do you know if Dreammachine can work with another ubiquity Access point in a mesh fashion?

Yes, the Unifi OS console they talk about is similar to the Unifi controller that you can run standalone on your desktop. It'll handle the adoption, handoff coordination, everything you need.

The Ubiquiti Access Point AC Mesh Pro[0] (~$200) appears to support multiple SSIDs and VLANs. Of course you'd need at least two of them to count as a "mesh", which is $400… was your $500 budget per access point or for the whole system (and if so, for how many APs)?

[0] https://store.ui.com/products/unifi-ac-mesh-pro-ap

2 will cover my needs. Do they actually work like a mesh? As in use backhaul radio to communicate between them and allow seamless switch from one to another as you travel around your home?

Yes, this model supports Wireless Uplink with Plug & Play Mesh:

> Wireless Uplink functionality enables wireless connectivity between APs for extended range. One wired UniFi AP uplink supports up to four wireless downlinks on a single operating band, allowing wireless adoption of devices in their default state and real-time changes to network topology. For devices that support Plug & Play Mesh, this functionality is extended to allow multi-hop wireless uplink – so wirelessly uplinked APs can support uplink to other wirelessly uplinked APs.

(quote is from the datasheet PDF)

I use mikrotik hap ac2. Cost $50. But complicated imo. Extremely versatile though.

I prohibit IoT devices from connecting to the Internet at all, and only use devices that can be controlled by the local network [0]. Thus firmware updates don't matter (as long as the manufacturer hasn't included any logic bombs), as the trust model is that devices are just an extension of the network segment.

The least-involved way to set this up would be to set up an old wifi router to create a second network, don't connect this router to your existing network or uplink, and then set up your home automation server with two ethernet ports.

[0] eg TP-Link Kasa, although I heard this may have changed for recent ones? Either way, with this setup you'll be immediately aware of whether local control functionality works, so you're well within the return window. FWIW I stay away from Amazon's GENSYM brands, even though they'd be easy to flash with Tasmota etc, because I don't trust them to get line voltage design considerations right and I don't feel like QAing every single device.

if you flash openwrt/ddwrt to your router, you can create an isolated subnet with its own DHCP server and enter your own firewall rules (iptables) blocking all traffic from your local subnet to your IOT subnet. You can then bind that to a wifi ssid (the guest one). Its kind of a PITA to setup, but it works great once you get it. Netgear Nighthawk routers have worked great for me in the past.

Don't forget to set up a reverse proxy with ssl and automatic cert renewsl, even in your home network. Wifi can be hacked with trivial ease. Caddy or nginx/certbot will do you well there. If you also run a pi-hole you can have the pi on your local network pass ssl checks by overriding some DNS entries.

I just don't use Google or Alexa (devices from those ecosystems punch holes through my home gateway for a bunch of server-side glue that is extremely ill-advised, and a bigger risk than LAN security IMHO), moved most things (sensors, typically) to ZigBee, and reflashed everything I could with Tasmota.

It's extremely inconvenient to have IoT devices segregated from, say, TVs and media devices, especially if you rely on AirPlay or Chromecast to get audio around the place, so I just secure my Macs (and PCs) properly as if we were still traveling and visiting clients.

I keep tabs on Apple security bulletins (HomeKit has relatively few issues, and works mostly inside the LAN except if you're outside the house - it then switches to a variation of the old iCloud "back to my X" tunneling).

One, I avoid WiFi products entirely if there is a good alternative. Zigbee and ZWave are two good ecosystems, you get a USB radio, plug it Home Assistant machine and you're up and running.

A second option is finding devices that can be flashed with Tasmota or ESPHome. This could also mean putting together your own devices with an ESP8266, ESPHome is basically plug and play for simple things like temperature sensors. You assemble the device, configure which pins to use via YAML, and then flash it to the ESP.

You don't even need to download a local build toolchain, the ESPHome add-on to Home Assistant can flash devices plugged into your computer just from the web interface, and then do OTA firmware updates.

Not OP, but I make extensive use of VLANs to isolate off security cameras, IoT devices, etc. etc. into their own mutually isolated network environments.

I also don't use Wifi for any of these devices anymore. It's usually a bad experience. Either use ethernet or a dedicated IoT-oriented wireless protocol. Z-wave seems OK but not very flexible, Zigbee is a pain in the rear (but the only option for many device classes), and I'm hopeful that Thread will actually be good.

For me I mainly use Zigbee and Zwave Devices not WiFi Devices.

I am sadden that wifi seems to be taking over and ZigBee and Zwave are starting to lose favor.

I like to believe that it's because matter protocol is on its way, so hardware isn't being developed: https://en.wikipedia.org/wiki/Matter_(standard)

But, I think it's actually because wifi is easier for the average person to get working. With Zigbee, you need a Zigbee hub, but sometimes you need a brand specific Zigbee hub, sometimes you don't (even though it's advertised that you do), and sometimes the Zigbee compliance is so bad that adding a device from another vendor break your whole Zigbee network (looking at you Aquara). Zwave throws more incompatible hubs to the mix. And, even within these, it's rare to have devices work with each other in a way that makes sense.

Hopefully matter saves us, so I don't have to install 5 integrations in Home Assistant to remind me that my car isn't plugged in at night or my back window is open, while the heater is on, and then another to make any of it accessible to HomeKit.

I must be lucky then because I have lot of Zigbee and Zwave devices all running Transmitting to Nortek GoControl USB stick attached to a rPI running Home Assistant.

I have several vendors of both Zwave and Zigbee Sensors, HVAC thermostat, Bulbs, Switches, etc.. All of them play nice with each other, and FAR FAR simpler to setup than WiFi which often requires the use of some weird mobile app, and play hopsotch with the networks..

Zigbee I just pair them to the GoControl and it is done

hell I even bought some no name used Door Sensors off ebay that were Zigbee, I mainly use them for Temp monitoring in various places.. They had no problem connecting to my network either

Yes, but you are not the average consumer, who is making Wi-Fi popular.

> all running Transmitting to Nortek GoControl USB stick attached to a rPI running Home Assistant

> and FAR FAR simpler to setup than WiFi

These two sentences are absolutely silly, for that average consumer. An average consumer can install a proprietary app in a few minutes and is totally uninterested in installing operating systems on little computers.

Before I moved to HA, I was in the smart-things Ecosystem

That was also very easy out of the box, far easier than WiFi Device

I am not sure why you are doubling down on WiFi being easier, it is not

The reason these companies are going for WiFi is because they want to Lock People into continue Telemetry being sent to the cloud, not local hubs.

It has nothing to do with ease of access, or consumer friendly and everything to do with Lock in, and Privacy violating data collection

> Before I moved to HA, I was in the smart-things Ecosystem. That was also very easy out of the box, far easier than WiFi Device

No offense, but I think you've already proved that your perspective is a bit skewed towards the technical. I don't understand how buying and installing a hub, then installing an app to connect with that hub, and then using that app to pair is somehow easier than installing and app, and then using that app to pair.

> It has nothing to do with ease of access...

Looking at Amazon, I'm seeing many times the reviews for WiFi smart switches. This would make it appear that people are purchasing them. Why? Are they already locked in? My theory is that people see the product description, see WiFi, and say "I have that!". People see Zigbee or "hub" and say "I don't have that, it's $50 more!". If we could do a word count for "incompatible" between the two, I'm sure it would be many times lower for WiFi devices. I know I see that word often when I look through Z-Wave and Zigbee reviews.

I use mikrotik router with separate vlans. Also use open firmware (usually tasmota) on 95% of devices.

If you don't have any need for bleeding edge devices, Openhab still works on a rpi4 as an alternative to HA. I like that I can just install it as an apt package onto an existing rpi with other things and java just does its stuff, rather than dedicating the entire rpi4 to it or running in a container.

> I like that I can just install it as an apt package onto an existing rpi with other things and java just does its stuff, rather than dedicating the entire rpi4 to it or running in a container.

If you try Home Assistant again, you'll probably like Home Assistant Core. No separate OS or container needed, just a Python virtual environment. That's how I have it installed. I have to do the updates and backups manually (rather than it self-updating automatically / through the UI) but I find that preferable to dealing with an extra machine, VM, or container.

+1 for OpenHab. I have tried HA several times, but always cone back to OH for its super simple ui and app layout editors. Apt install is also nice.

Also, plugging in a half-decent zigbee controller usb dongle and receive native zigbee controls in the system, no need for a bridge like mqtt

I had a terrible experience with Home Assistant. Slow, buggy, unreasonably difficult to implement non-trivial automations.

My heuristic since then has been to minimize the amount of node.js in my home automation codebase and this has worked wonders for its reliability and usability; currently the only component I still have that's node-based is zigbee2mqtt, which (possibly not) incidentally gives me more issues than any other component.

The best approach I've found has been to have (in isolated jails/containers) zigbee2mqtt dealing with zigbee network stuff (you must use CC2652 based coordinators and routers for any kind of reliability), mosquitto acting as an MQTT broker, and a custom program (write it in whatever you like) talking to mosquitto, with Pushover for push notifications.

I'm not understanding how node.js relates to Home Assistant (written in python)?

I don't speak for the op, but the current recommended z-wave integration is via a sidecar javascript service: https://www.home-assistant.io/integrations/zwave_js/

One of HA's selling points for me originally was that everything was written in Python. It's frustrating that I am now faced with pulling a javascript service into the mix. Most of my devices are z-wave and I'm still running on the legacy integration and dreading this migration.

I've had mixed experiences with python (mosquitto is fine for example) but more uniformly bad experiences with node stuff.

I would vastly prefer all of this crap to be written in Rust or Haskell or OCaml or anything oriented towards correctness. It's relatively very important that the code which runs your home works correctly.

I do the same for the automation part (mosquitto+zigbee2mqtt+custom scripts), but I do have Home Assistant for GUI and logging. For example I have a card in Home Assistant that shows whether any system at home doesn't ping.

Here is an example of an automation script, turning a zigbee plug on/off depending on solar roof output: https://gist.githubusercontent.com/bonzini/c705bdd47fd5cd16a...

Does anyone know how Home Assistant compares to node-red? As far as I can tell Home Assistant is better at building a dashboard of things, but node-red is better at actually automating specific actions (unless you want to grapple with HA's YAML based scripting language).

Is this about right? Is it possible to combine Home Assistant and node-red, or has Home Assistant outgrown the need for something like node-red?

For me node-red is more of an addition to homeassistant. There is node-red-contrib-home-assistant-websocket [1] to let node-red speak with homeassistant, you can watch state changes etc. I use ha for like two years now and at the start there was no inbuild automation-backend like it is now so we did everything with node-red.

https://flows.nodered.org/node/node-red-contrib-home-assista...

I was thinking about getting started with HA, and then I saw the YAML. Dear God. May just be the ugliest scripting language I've ever seen.

It is possible, and a few years ago seemed quite a trend (just going by /r/homeassistant spectating) - https://github.com/hassio-addons/addon-node-red - but I gather HA's own automation scripting has at least visualisation if not GUI programming now.

IME: For simple automations, HA UI is far easier. For complex ones, if you want a GUI, node-red, if you want to handwrite scripts, HA. If you don’t care it really depends, in some cases coding them is easier, in some cases node-red is easier.

But then this is about Node-Red integrated into HA.

I've settled on homebridge to talk to the Home app on my iPhone (which is where all the automation is done, and then executed on an Apple TV) and a little Node-RED for custom flows.

I have zero YAML to maintain, and I'm happier for it.

They are not comparable because node-red is a generic low-code programming tool while HA is home automation software.

If you mean how they compare when you plug in node-red to HA and use it for automations, rather than use HA's "native" automations... I believe the consensus is that node-red is more user-friendly in that way, and because it can plug to other things on its own it can provide more flexibility. On the other hand, HA has recently worked on the UI of their automations, and it is already pretty good for simple flows. In the end both of these approaches are great, each with its own pros and cons.

Not to mention that, with the help of appdaemon[0], you can write Python code to implement all the logic you can dream of.

I found this much more powerful than the base GUI, and much more expressive (and less clunky) than Nodered or the yaml automations.

[0]: https://appdaemon.readthedocs.io/en/latest/

+1 for Home Assistant. Have it running on RPi4 for almost two years already without single glitch. It has tons of integrations, and besides that you can always build your own Arduino modules to connect with it over MQTT if you have your special use case. Web UI is really nice, you can even access and edit config files with it without going ssh. Android/IOS app also works pretty well.

Do I really need to do Home Assistant Operating System? It stresses me out that this is not just some packages I can install.

No. Install Raspbian light, docker, docker compose, and HA docker container. Use an SSD drive for boot and official pi ac power.

i have a NUC i plan to dedicate. i seem to recall that there were some features missing from the installs that were not managed (or whatever the Whole OS thing was called?

I'm aiming to use a supervised installation to free up the pi for other tasks, but concerned about performance. Will be booting from SATA to help to this end, and to avoid degradation from writing to microSD often (this may be the case when I start recording security footage)

You will probably not have a great experience running cctv from a pi. You may want something a bit beefier unless your cams are low res, mostly due to transcode/copying costs.

In terms of disk, you want multiple disks as either raid/zfs/btrfs/lvm. It will probably be better to do this on a separate machine and mount it via nfs.

For your boot volume, you can also use a usb thumb drive to help avoid sd card fatigue.

I haven't had any issues just using the stock image on an SD card - it seems to be fast enough. YMMV especially if you plan to run other things on the Pi, though in this case I'd recommend going for a mini-PC instead and just installing a standard Linux distribution on it.

I see. Really it was just going to be something like pihole which is supposedly light. Maybe better not to use the supervised if this is focused on running HA?

In the future I'll consider the mini-PC, thanks. This will have to do for now.

Does anyone have some experience to share with integrating home assistant with Homematic devices? I'm stuck with those for controlling my heating but really dislike the interface.

They have a really welcoming community from my experience. Try either their forum or discord.