* I can fully control them without the cloud on a non-internet connected network
* I can either pay for updates, or they have free updates for at least 12 years, ideally 15
If a hurricane or tornado strikes, or some dictator tries to tell me what I can and can't do, my devices need to remain under my command.
As for software updates, they can be updated, but these devices are so simple they can be reasonably bug free after a while - and security's not a concern (that much) since they don't really have internet access.
Some devices were known to have vulnearbilities where the attacker was physically present to get in radio contact with the device, but those are pretty rare and impossible to exploit en masse.
How it works in Home Assistant afaik is that the border router is a piece of software running in docker that has access to the radio, and then HA talks to the thread devices via the virtual network interface of Docker.
That said, it is entirely up to you how you would configure the system that the thread border router connects to. Thread specification uses local addresses for the thread devices, so in order for these devices to get access out into the public internet you would need to NAT the IPv6 pretty much (or the devices would have to be smart enough to figure out a globally routable IP address, via e.g. DHCP.) At the same time since it is all bog-standard IPv6, you also get full control with firewall rules, NAT/forwarding and such.
Overall you'd need either a very unusual device or a major misconfiguration off the beaten path to get thread devices talking on the public internet.
I was under the impression IPv6 doesn't need NAT. But you're saying they only get unique local addresses, so even with a border router bridging the connection back to my local Wi-Fi network they still can't send packets out to the internet? "They would have to ask DHCP for a real IP first" doesn't seem like much of a barrier.
For Matter (regardless of network connectivity - WiFi, Ethernet, or Thread) this is part of the certification, the devices must be controllable locally and without internet connectivity at least for basic or core functions.
For Zigbee there's no such thing. Zigbee is the network protocol and the manufacturers usually implemented whatever communication protocol they wanted on top. This is why my Tado thermostats that communicate with the hub over Zigbee aren't compatible with any other hub and need the cloud connectivity even when integrated with HA [0][1].
[0] https://www.home-assistant.io/integrations/tado/
[1] https://www.home-assistant.io/blog/2016/02/12/classifying-th...
A lot of devices are not compliant though and either have extra functionality exposed in a nonstandard way, or don't comform to the standard well enough.
So your Zigbee light switch will probably workout any fuss regardless of vendor but more complex devices might not.
That's exactly the problem, there was no standard protocol for communication over Zigbee. Manufacturers could implement whatever they wanted on top of it and put the Zigbee logo, like you can put the WiFi logo on a device that speaks a proprietary protocol over WiFi. You bought into an ecosystem and if you wanted a device from outside of it, you needed another hub.
> So your Zigbee light switch will probably workout any fuss
Big "depends". Out of the box it will only work for the few manufacturers who look to be compatible with some other hubs. I tested a lot of basic devices (simple switches or bulbs) with various hubs with little success. Philips, IKEA, Bosch, Tuya, Aqara, Osram, etc. Couldn't discover, add, or control them properly without the corresponding hub.
If you use a device with HA and a Zigbee stick (router/coordinator) then you benefit from a lot of development done in the background to "translate" between all the variations. But that's not something non-techies want to deal with, it's too much of a hassle.
This is the problem that Matter solves. Certified devices must implement the standard communication protocol over the network of choice. So no matter the manufacturer, if I see a Matter logo I know the device will work with my Matter.
Maybe this will get better with time, but we're half a decade into the Matter era and the end-user experience is _worse_ than with ZigBee. In that sense, Matter has failed.
Nowadays, from what I've seen, Zigbee devices seem to be based on a couple of good ICs (and software stacks), which are inexpensive and battle tested.
Forgive me, I don't have a comprehensive experience on what standard does exactly what and how, but from what I've read Matter is a no go for homemade stuff - you need to go through cert for the hubs to talk to you.
As for out of the box support, I've read mixed things - I've heard that for many devices that are Matter compatible (more particularly, the Aqara W100 thermostat), you can't do everything the device supports via Matter that you can do with more proprietary APIs. Considering many of these companies are pushing their own ecosystems, they have an incentive to keep an advantage. Many people are already going for using Thread without Matter.
I feel like Matter is like the joke where they try to solve N competing standards by adding another one, and experience shows this isnt the way to go. The way to go is what Home Assistant does - they keep an open ecosystem with support for plugins, and for example for Zigbee, they implement the 'quirks' of your device into the framework, so you don't have to deal with it.
Regarding the electric switches, I was fond of bypass switches (where you can turn on/off by flipping any of the switches connected to a lamp) and made a lot of them in my apartments. Turned out not all of them were needed. I didn't need much control at home, e.g. I don't need to control the lighting above the kitchen desk when I'm not in front of it.
Wifi switches allow a lot of freedom in positioning and re-positioning them, but they escalate everything to the unreliable realm of IP/internet devices. I'd probably vote for a controller on a lamp, and switches not actually inerrupting 230V~, but be connected with a thin and flat 12V= bus, and just signalling, and hence be easy to put under wallpapers. (5V= would be hard to send further than 3 metres.)
I personally think relays are a much more reliable than solid state switches and are very unlikely to fail in a dangerous way, and fully interupt the circuit, but they do have a 'click' some people dislike, and have a lifetime of 100k-ish switches, so for an application where you keep switching rapidly (e.g. not light switches), this might be a problem.
Ikea used Thread and Zigbee which are not Wifi, they use a mesh network and don't suffer from saturation the way Wifi does, in fact adding more devices tends to make the network more reliable since devices can route around failing or congested nodes.
I've had good experience with them in practice, but do be mindful that they share the 2.4GHz band with Wifi so in an apt building, you might run into radio channel congestion.
Personally I use smart home stuff for controlling heating devices and a few other key items, I don't think it makes sense to make every light switch smart, but technically people have done so and it tends to work all right.
* Multiple VLANs - segregate devices - I usually have two for IoT devices: "THINGS" and "SEWER" * Router/firewall segregation * Home Assistant * etc
So my doorbell has a camera and I run the likes of Frigate or Zoneminder. It is PoE and also has a chime relay. It will still ring if the network goes down.
I am gradually migrating my home light switches to zwave ones. They will still work, regardless of HA being up.
My car (EV) and utility provider (Octopus) and so on are getting complicated and have multiple apps. I have a single Home Assistant box that manages all of that lot.
All of that is quite complicated. I'm an IT consultant with 30 years experience but a novice can go quite far already and it will get better.
Pros: very inexpensive, and they look great. Cons: WiFi/ble only, they feel cheap, dimmers don't support a "transition" comment, so you cant dim over time easily.