But reality seems to be more nuanced than that:

Matter devices can be "dumb". They're intended to be able to work without Internet. Matter uses IP, and Thread provides IPV6, but that doesn't mean that either thing needs to be able to talk to the WAN.

Wifi devices can also be "dumb". For example: I have ESPHome devices that Just Work and that don't have any outside connectivity.

I don't advise anyone who asks me about smart home stuff. I'll tell them some about what I'm doing in my own home, and answer any questions they have accurately, but their eyes glaze over when they hear phrases like Zigbee or MQTT, and they've completely stopped listening by the time something like Home Assistant comes 'round.

I don't know that Matter and/or Thread will make anything better or more secure by default. The Matter 1.0 spec is only a year and a half old and it isn't clear at all how implementation is going to wind up being shaped in the real world.

But they can improve things and I hope that they will.

The main thing that i remembered from thread/matter is that vendors can lock out devices and other users hostile stuff. I sure hope plain zigbee is here to stay as having bigtech decide the brand of my in-wall switches are wrong would truly suck.

How can a vendor "lock out" a device that cannot talk to the outside world?

MAC address ranges or something would make sense

Perhaps so, but if that is what is being suggested then that's not anything that is in any way unique to Matter or Thread.

I use both and both work well. There a pos/negs to both, Zigbee tends to be cheaper, but there is a complete lack of dimmer plugs.

I use both as well and see no reason to pick only one or the other. The USB stick hubs are very cheap and Home Assistant does all the heavy lifting seamlessly. Having both gives me pretty much unlimited flexibility.

For devices I usually pick whatever standard has the device I want at a more reasonable price or is on sale. So far I've yet to run into a scenario where I wish I had chosen the other standard for a specific device.

I also have a ton of devices on WiFi via Esphome on both esp8266 & esp32. Fantastic project, years of them running completely trouble free.

I have dimmer switches, and I only have Zigbee.

Candeo are pretty reliable.

There’s really good WiFi smart home hardware out there, like anything Leviton ships I’d recommend. There’s also a lot of crap out there too.

I think the ideal smart home device can connect to the internet to check for updates either when I manually want to update it or setup an auto update schedule. An account should NOT be required, which sadly lots of smart home hardware requires.

Thread is based on Zigbee. It functions fine without the internet.

I thought both Thread and Zigbee run on top of IEEE802.15.4, but Thread is based on 6LoWPAN / IPv6 where Zigbee uses its own network layer. But Thread idd functions fine without the internet (although you probably could connect devices to the internet if you'd want to).

Also important is that Zigbee is both the transport protocol and multiple home automational protocols. Zigbee compatibility is pretty good with the same protocol but not across different protocols.

Thread is a transport protocol for Matter home automation protocol. Matter is complex because it tries to do everything in one protocol.

Thread is based on Zigbee in the sense that the thread designers read papers about the Zigbee spec. Also matter is partially based on Zigbee with its use of Zigbee clusters (deep in the stack, away from end users).

Zigbee and thread are different protocols and incompatible. You cannot mix them and that’s what most people are about.

There are some fantastic products (LIFX, Twinkly) that are WiFi and don't require the cloud. Zigbee falls apart when controlling a large number of devices in real-time.

I’ve used Tasmota with Wi-Fi and mqtt and it works great.

I use Hubitat but everything is Z-wave except for one Alexa-only bulb, which was a gift so I can't get rid of it.

What I've learned is that smart wall switches of all types are still too failure-prone for me. Now I'm converting back to standard wall switches with Z-wave relays wired in behind them. I don't like the extra lag they have, but I do like that standard wall switches last forever compared to smart wall switches.

If anyone knows how to reduce the lag, I'm all ears. The switch operates the relay which sends its signal to the hub, which then sends a signal back for the light to turn on. This process introduces a noticeable time delay between the switch closing and the light coming on.

Do you have a recommendation for the relays? Would love to decouple the smart stuff from the switches.

Zooz ZEN51 and ZEN52 are what I've been using, but there are other brands I'd like to try.

My delay could be just that my hub is pretty old & needs to be updated.

> I'm not super keen on Thread/Matter seeing how one of its goal seems to be allowing your devices access to the internet which is the exact opposite of what I want.

Happily, that's not a goal and definitely not a requirement. Thread/Matter work great without internet access unless you use them via a platform which does (e.g. Alexa).

Most commercial platforms, which people will realistically use, are border routers. IP routers with internet access.

Beyond that, the protocol allows for logs to be uploaded to your ecosystem of choice, and allows for OTA installation of software updates.

Internet access is not a requirement for protocol, but neither is any other part of the modern “networked software” stack. Good luck with your internet-disabled SMTP server.

I think your attitude is almost exactly right but I will add: you can pick both. The two ecosystems don't really step on each others' toes and as long as you find a hub(s) to feed a single view there are basically no downsides.

I can think of two downsides:

- Harder to get coverage. Both zigbee and zwave use mains powered devices (like light bulbs) as signal relays for other devices. If you're using both, you need to ensure proper coverage for both networks.

- No protocol native groups and scenes. At least zigbee allows you to set any number of bulbs to a certain scene using a single fast broadcast command. When using something like Home Assistant to unify both networks, recalling a scene will cause each individual bulb to be sent a separate command, which can be sloooow when you have many bulbs in one room.

In my experience it's more nuanced. Some of my most unreliable devices are Zigbee (but they're also Aqara, and that may well be the real problem there). My Z-Wave devices have been pretty solid once configured, but they were also some of the most finicky to get paired up and on the network. My WiFi switches have been rock steady, not a single problem.

I got a Sonoff Zigbee USB dongle to use with Zigbee2MQTT and it's been bulletproof. It even managed to upgrade my finicky IKEA Zigbee devices to rock-solid firmware versions.

I can also vouch for the Sonoff

If you're using 2.4GHz WiFi, then consider Z-Wave. It's a little pricier, but doesn't use the same chunk of RF spectrum (so won't cause interference).

Also wifi devices always seem to want a special app or account registration first, whereas with Zigbee you just allow new devices and then turn on your new device.

> Pick Zigbee or Z-Wave

Picking both is fine. Zigbee is significantly cheaper, but you have to make sure that the device is interoperable (Ecobee is a good example of a manufacturer to avoid - Zigbee interoperability is optional). If not, that's where Z-Wave steps in. Having an "off-brand" Zigbee adapter is a good bullshit force field. I use the Aoetec USB for Z-Wave and the Sonoff USB for Zigbee. Both are incredibly interoperability conscious, so I have no problem supporting them (I also have a lot of Zooz devices, who are equally awesome).

All the WiFi devices went to Goodwill.

Shelly's WiFi devices are all fairly cloud-optional - you can completely disconnect the internet and they will all work with Home Assistant just fine. Still, I'm not as excited about them as I used to be (mainly due to realizing there's a ton of cool-looking I/O flexibility they have that ends up being redundant once you settle on a control plane for wifi - MQTT in my case), and because their exposure of features and properties is somewhat inconsistent across device families.

But as a way to unburden your (usually one and only) Zigbee channel from certain types of chatty messaging, such as high-accuracy presence sending or complex lighting curve adjustments that can't be done ergonomically (or at all) via Zigbee, they are invaluable. Wifi (jailed in a VLAN, if you like) also provides a layer of failure protection should your Zigbee coordinator die unexpectedly.

Shelly is one of few HA component makers that have an open http API. I love that I can script a CURL call directly against a shelly smart plug.

That was my approach as well when I invested some years ago in various dimmers, heater controllers and such.

One positive with Z-wave is that fallback is built into the protocol. So the switches can talk directly to the appropriate dimmer if the controller is down, for example.

I can't say I agree with the "pick one" as had I done that I wouldn't have the ability to compare reliability post install and cost pre.

Certain devices just aren't available in one or the other network, or are not cost effective.

In the end it's just one more USB stick.