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?
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.
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).
> 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.
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.
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).
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.
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.
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.
> 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.
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.
> 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.
Most people aren't equipped to ensure their IP devices can only talk to other LAN devices (I am, my cameras live on a VLAN that can't route to the web). Combine IP capability with the possibility for software updates, and you have botnet fuel. It's why IP cameras are a leading source of botnet participants: Long-lasting IP hardware often managed by users without VLAN segmentation.
I agree that segmenting VLANs and stuff aren’t accessible to average people, but there are accessible alternatives. I recently upgraded to Google WiFi pucks after babysitting a ubiquiti installation for almost half a decade, and you can “disable internet” on devices without disabling LAN. You’d have to trust the device to be friendly on the LAN but it’s good balance for consumers. After Eufys whole security meltdown I updated a bunch of IOT junk to lose internet access. I saw a lot of tech site’s recommend this, and it’s definitely “easy enough for the parents to do”.
That's a single proprietary option from a single vendor with its own storied history of both poor privacy and poor long-term hardware support. (I believe they've effectively bricked the first generation of their routers already!)
It's so much smarter to just not have smarthome devices on the network, and have a single interface or bridge which acts as a security barrier.
I think many routers have a simple feature to restrict internet access for a device on the network. I simply highlighted a consumer product (highly recommended by tech sites) that many average consumers may have.
This is not a realistic view. Most users do not mess with the settings on their router. Most, do not have this feature either. This isn't a good or practical assumption to make of most home networks.
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.
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.
> 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.
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.
