[slimginz]

Now that Matter and Thread are finally starting to roll out, is there really any good reason for new products to still use Z-Wave? Or am I just crazy to see this as Z-Wave trying to continue a format war (first started with Zigbee) that they're almost certainly going to lose?

[ihattendorf]

Z-Wave devices are almost universally better (longer battery life, longer range, more reliable, etc.) than Zigbee (I have both). Not sure if this is based on price (Z-Wave devices being more expensive), certification, different radio frequency, or something else.

With the investment into Thread (still sharing frequency with 2.4 GHz WiFi) I could see this changing.

[vineyardmike]

I don't own ZWave devices, but comments here seem to question their superiority.

The range and battery life is likely due to the lower-frequency it uses, which is less congested and longer range. Typically, this will translate to a lower power usage (better battery life).

[CommanderData]

Linus tech tips has done a few videos on his smart home (z-wave) and he does not seem overly happy with it..

I'm really glad I went Zigbee as its been almost completely pain free even with third party non cloud software.

I can't fault it but I do worry about future security updates should something be discovered in Zigbees stack.

[vineyardmike]

> I can't fault it but I do worry about future security updates should something be discovered in Zigbees stack.

I agree it’ll likely be few devices that’s ever see an update but I think theoretically Zigbee proton supports OTA from the hubs. I know home assistant supports automatic OTAs from a handful of brands.

[yencabulator]

> longer battery life

Meanwhile, this HN discussion has people telling others to never use battery-powered Z-Wave devices, or it'll be laggy...

[ars]

Z-Wave has a much better range, and uses a less congested radio band.

Matter and Thread can work with Z-Wave devices with the help of a bridge, so it's not as bad as you might think.

But yes, this is an attempt to compete with Zigbee.

[worldmerge]

Do Matter and Thread use wifi or are they a different radio freq?

[dwaite]

Thread is a mesh protocol on 6LoWPAN, which in turn is based on the same underlying 802.11.4 as Zigbee in the 2.4 Ghz spectrum.

Its claims to fame is having reasonable response times/batteru life and being based on IPv6. Being based on IP allows devices to talk to one another, and for bridging those devices to the broader network and potentially to the internet with clear layer separation.

Matter is a IP-based IoT discovery and use standard. Devices advertise Thread and/or Wifi support for wireless support. It also standardizes onboarding (I know BLE is an option there) and the underlying security, and mandates certain capabilities such as supporting multiple 'admin' software at once.

Devices using other wireless tech can also theoretically work with Matter with a gateway that does protocol translation, supports device onboarding, and then exposes them onto the network.

[kps]

> Devices using other wireless tech can also theoretically work with Matter with a gateway

Signify (née Philips Lighting) has got Matter certification for their Hue hub.

[ihattendorf]

Thread is a mesh IPv6 based network that operates over the 2.4 GHz ISM band but is not WiFi. Matter is a communication protocol built on top of Thread, WiFi, and BLE (and potentially others in the future).

[vineyardmike]

> Matter is a communication protocol built on top of...

Matter is a communication protocol built on top of IP, with a special blessing to Ethernet, Wifi, BLE, and Thread.

[petre]

Thread and ZigBee operate in the 2.4 Ghz and also 833/915 Mhz although in practice I've never seen any devices that explicitly claim to be using the sub Ghz bands. It's not WiFi, it's IEEE 802.15.4. Matter supports devices connected through WiFi, Thread and Ethernet with BT provisioning.

[ocdtrekkie]

Z-Wave is a better technology. I want home automation hardware to be simple, reliable, and not Internet connected.

[vardump]

I'm using no cloud Zigbee home automation. Seems to be very reliable and has really great range thanks to the mesh networking. It's also really simple.

Zigbee allows using multiple vendors with ease, not tied to just one manufacturer.

Again, no internet connection required.

[ocdtrekkie]

I'm using Insteon personally, which is mesh networked but relatively similar to Z-Wave. (And it's entirely proprietary still.)

It's not just about cloud connectivity though: I don't want my home automation hardware speaking IP or anything like it. Nor do I want them to need a complicated enough protocol to justify requirements like firmware updates. All of this introduces opportunities for security flaws and the ability to create botnets.

Home automation hardware should be simple, take simple instructions over local communication bands, and then a single central controller should bring the greater intelligence and access.

I think my Insteon thermostat is nearly the ideal smarthome product: It's a thermostat, and can work entirely standalone as just that. It cannot be updated or reprogrammed. But it will accept commands (no different than button presses on the front of it) over the RF protocol, and of course, send its sensor data and operating status.

Things like incidents where Nests had software updates that let everyone freeze or whatever in the winter just... isn't really a concern with a good design like this.

[vineyardmike]

> I'm using Insteon personally, which is mesh networked but relatively similar to Z-Wave. (And it's entirely proprietary still.)

One of the benefits of non-proprietary (especially IP based) is that you're more immune to company failures, like when Insteon shut down.

> I don't want my home automation hardware speaking IP or anything like it

Why? Its just a protocol? It doesn't mean a cloud is involved, it doesn't even have to be networked to your main LAN.

> Home automation hardware should be simple, take simple instructions over local communication bands, and then a single central controller should bring the greater intelligence and access.

IP seems the simplest option. Even though its more layers than a binary protocol, the interoperability and easy ability for most software people to create IP software means longer future.

> It cannot be updated or reprogrammed. But it will accept commands (no different than button presses on the front of it) over the RF protocol, and of course, send its sensor data and operating status.

What was your plan when Insteon went belly up? The lack of ability to reprogram means you couldn't update it to work with a newer hub/protocol.

[ocdtrekkie]

> like when Insteon shut down

Agreed, though I am not reliant on the Insteon company for anything but parts, since it's an entirely local protocol. And they're producing new parts again! I was also in a bit lucky of a position: I had plenty of spare hardware on hand while the company was shut down.

> IP seems the simplest option

If security is unimportant, sure. Insteon hardware has been around for three decades, but nobody in their right mind would be using network hardware from back then. This is a case of where complexity kills. Home hardware needs to work for decades.

> Plan when Insteon went belly up

I use their PLM interface which is just a COM port on my PC. The company's existence has no impact on my ability to connect it to newer things.

[vineyardmike]

> If security is unimportant, sure. Insteon hardware has been around for three decades, but nobody in their right mind would be using network hardware from back then.

Sure to hardware but we’re all still using IP protocols. Countless companies have risen and fallen and that hasn’t changed. Networking equipment if kept LAN only should still work fine after 3 decades.

> which is just a COM port on my PC. The company's existence has no impact on my ability to connect it to newer things.

This sounds just as complex and risky as any modern protocol, just more obscure. If you need a PC for newer devices then it’s all the same anyways.

[bombcar]

As an aside I have some Best Buy "HomeKit" compatible switches, and they shut down the app long ago (and gave me gift cards for the price I paid for the switches) - but they're still working with HomeKit and if that were to fail they'd still be a switch.

[rlpb]

AIUI, Z-Wave means interoperability at device level, without even a controller or a compatibility shim, across a variety of manufacturers. Niche devices can exist because it's easy for a niche manufacturer to integrate. And if my Internet connection is down, or even the controller is down, the system still functions with graceful degradation only.

With Zigbee, AIUI you get a mostly closed system locked in to whichever Zigbee vendor you chose. Interoperability only occurs at a higher level in a much more error-prone and lowest common denominator fashion.

[vineyardmike]

> With Zigbee, AIUI you get a mostly closed system locked in to whichever Zigbee vendor you chose.

No, all devices should work with other vendors. Some vendors don't play as nice, however. The Zigbee light-link spec should allow all lights to work with all light controllers (eg zigged remotes on the wall). Any "true" hub should work with all zigged devices too. Some minor company's hub may not support all products, but thats if they don't comply with the protocol - ZWave theoretically has that problem.

Zigbee is probably more "open" since the protocol has less certification requirements. The only main bifurcation is that "Zigbee" and "Zigbee Light Link" are slightly different and you may end up with a "ZLL" hub that doesn't support non-light devices.

> And if my Internet connection is down, or even the controller is down, the system still functions with graceful degradation only.

Zigbee supports this behavior. You can pair lights/remotes for example with no hub required. Its usually advertised as a graceful upgrade path instead of a degradation path.

[rlpb]

Based on what others have also said, it sounds like you're describing interoperability in Zigbee in theory, whereas I described interoperability in Z-Wave in practice.