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