All previous Zigbee and current Thread devices are physically incapable of connecting to the internet - the hub they talk to might, but since these are standardized (Matter and/or Zigbee define standard protocols for devices like this), you wont have problems picking another hub.
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.
> the hub they talk to might, but since these are standardized (Matter and/or Zigbee define standard protocols for devices like this), you wont have problems picking another hub.
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].
Pretty sure Zigbee also defines a control layers, so there's such a thing as a standard switch or power meter, or thermostat which can be controlled by any generic piece of software.
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.
I guess I got into smart homes quite late, and have the benefit of accumulated knowledge and got to skip out on decades of half-working devices.
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.
Having bought a few Matter devices now, I have discovered that, in practise, Matter is just as full of vendor extensions as ZigBee, and the quirks ecosystem that allows for interoperability despite vendor extensions is far less mature than with ZigBee.
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.
I realize Thread devices need a border router, but once they're connected to that router don't they get an IPv6 address with internet access? Or am I just misunderstanding the protocol?
A border router is not necessary in a typical installation! Its something you only need if you want to do fancy things. Otherwise a commissioner is sufficient (to bring the device onto the network.)
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.
Almost all real-world Thread networks I'm aware of have a border router in the form of an Apple TV, Nest Hub, Amazon Echo, etc, so I'm not particularly reassured by the fact that the protocol doesn't technically require one.
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.
Not 100% sure about Thread as I'm more used to Zigbee, but afaik the Thread router acts as either a proxy between your regular network and the Thread devices (you can wrap IPv6 packets so they can be exposed over regular ethernet) or the router is the smart hub itself and the nodes are not really accessible from the Wifi network.
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.
I have accumulated so much smart-stuff fatigue, I can't stand anything branded as "smart". This means, as you point out, 1) any outage in the chain between me and the vendor's app shuts everything down for me, 2) stuff behaves inconsistently all the time. (e.g. Bluetooth speakers with a smartphone/tablet player app -- every other time something goes wrong: the app frozen completely because search autocomplete lost packets; you can't find the damn playlist buried in a sea of features; another your device wakes up and steals the bluetooth speakers.)
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.)
Modern smart switches are pretty small (most of them are designed to fit into wall sockets behind plugs/light switches).
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.
That is my approach. It requires quite a few components to work:
* 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.
Currently renovating our house, everything will be KNX based. Offline, no servers needed (even within the house) but nice for visualization, standard, 500+ vendors of compatible hardware. Highly recommended.
Elegrp switches can be used offline. They need to be provisioned online first though, unless you flash with esphome (which can't currently be done wirelessly), but then you'll have to write a custom integration config.
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.
* 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.