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