Difference Between ZigBee and Z-Wave?

Question

I've have installed Z-Wave switches and outlets in a few places around my house. However, I noticed when purchasing the devices that there were a couple of different wireless options available in the brand I was looking at.

I'd be curious to know some of the pros/cons between Z-Wave and ZigBee devices. A comparison like this post on when to use WiFi over Bluetooth would be amazing.

For instance, I'm curious in information like if one style is potentially more favorable in houses with many walls or if one fairs better in "noisy" wireless homes (eg. many wireless devices/signal types).

Answer 1

I think there is mainly one thing you should care about: Is the ZigBee solution 2.4 GHz or 868/908 MHz? The 2.4 GHz penetrates less then ~900 MHz through walls, and the 2.4 GHz shares the spectrum with Wifi, Bluetooth, the microwave oven, to mention a few. The Z-Wave is only using the 900 MHz band.

Both solutions have complete network stacks, but the are not interoperable, at least not for applications such as light control. Neither of the technologies are common in mobile phones and such, so if you want app control you need to pass through a gateway for chosen technology.

Answer 2

There are a few things that really distinguish Z-Wave and ZigBee from each other.

Frequency

The first (as Eirik M noted) is the frequency on which they operate. Z-Wave operates within the 915 MHz ISM band. This gives it reasonable penetration of building materials (better than Wi-Fi) and good overall distance. The fact that few other household devices use that band (now that 900 MHz cordless phones are less widespread) means there's also less interference.

ZigBee can operate at either 2.4 GHz or 915 MHz.¹ 2.4 GHz is a busy band; it's where Wi-Fi and microwave ovens (among other things) operate. That means that 2.4 GHz ZigBee devices are subject to more interference than 915 MHz Z-Wave and ZigBee devices. They also don't go through walls as readily. (The 2.4 GHz band does give higher bit rates, which is why WiFi lives there (and also uses the 5 GHz band), but most IoT devices don't need to transfer lots of data quickly, so the lower bandwidth of the 915 MHz band isn't a drawback.)

¹ 915 MHz is only used in North America. Although 2.4 GHz is available worldwide, ZigBee's lower frequency band varies from one regulatory region to another. The various bands are mostly in the 700 MHz to 900 MHz range, so the statements about the 915 MHz North American band are generally applicable to other regions, too.

Openness

ZigBee is an open standard, though you need to join the ZigBee alliance (for a fee), if you want to sell ZigBee devices. Z-Wave is a licensed proprietary standard, although the high-level protocol is documented publicly. If you want to make Z-Wave hardware, you have to license the specification from the Z-Wave Alliance and then have your device tested for compliance to the standard. If you buy a Z-Wave device with an appropriately-programmable interface, you can use the already-licensed hardware with the public protocol specification to write your own software.

Price

Because of the lower barrier to entry, ZigBee devices can often be less expensive than Z-Wave devices with the same functionality. Consumer IoT hardware can vary widely in price for many other reasons, of course.

Interoperability

Z-Wave devices tend to have better interoperability overall. When new versions of the Z-Wave standard have been released, they've maintained backward compatibility; any Z-Wave device should be able to communicate sensibly with any other Z-Wave device, regardless of the age or manufacturer of each. (Obviously, newer protocol features won't be present, but the older functionality will be preserved.) Interoperability testing is part of the Z-Wave compliance process. ZigBee doesn't have as rigorous a testing regimen, so it sometimes happens that two ZigBee devices that should be able to talk to each other cannot, due to implementation flaws in one or both devices.

On top of that, ZigBee supports a number of different profiles which all share the same underlying protocol but use different communication details. (This is somewhat analogous to two different HTTP APIs; both use HTTP as a transport, but the Google Maps API isn't going to be very useful if you're talking to GitHub's servers.) Most IoT ZigBee devices use the Home Automation profile, but that's not typically documented on the device, so you can run into unexpected problems. As an example, Philips Hue lights use ZigBee, but do so in a deliberately inoperable way so you have to use the Philips Hue Bridge to control them. (Contrast that with Z-Wave: the Z-Wave certification process requires that any Z-Wave light bulbs use the standard control classes and, thus, can be managed by any compliant Z-Wave controller.)

The ZigBee Alliance is currently in the process of developing a new iteration of the ZigBee protocol named ZigBee 3.0. It looks like part of the new specification's goal will be to increase interoperability among ZigBee devices. We'll have to see how that goes, though. There doesn't seem to e a timetable for finalization of the new standard yet, though.

Similarities

As long as I've written the above, I figured I'd mention a few things that ZigBee and Z-Wave have in common that differentiate them from other protocols used for IoT devices.

ZigBee and Z-Wave are both mesh networks. Unlike WiFi and Bluetooth, where every device needs to see the controller, Z* devices are okay as long as there's some communication path between them, other Z* devices in the same network, and the controller. (Z-Wave devices will only mesh with Z-Wave devices, and ZigBee devices with a particular profile will only mesh with other ZigBee devices with that profile, of course.)

ZigBee and Z-Wave are both multi-vendor protocols. Notwithstanding the stuff in the "Openness" section above, both ZigBee and Z-Wave have devices available from a variety of companies who often compete with each other. (e.g. companies making Z-Wave light switches include GE, Aeotec, Linear, DragonTech, and others.) Many other IoT-related protocols are single-company silos (e.g. Lutron Caséta); while they might have gateways that let other systems control them, only that company's devices can join the network.

Answer 3

As a software guy—and a protocol stack guy at that—I tend to look differently at this than you might.

To me, these protocols are "low level" stuff (layer 1 & 2 of the OSI 7 layer model).

I don't particularly care about power consumption, unless the device is battery or solar powered. In my professional life, I can leave decisions about hardware, which , if it is off-the-shelf, tends to dictate the choice of the Layer 2 protocol, to the hardware guys. In my private life, I choose by price, support (size of community & availability of forums is very important) and a best guess understanding of the spec

I tend to look for the functionality of the overall system. For instance, for mesh networks, there are some excellent ZigBee solutions.

For example, do some signals work better long-range and some better in "noisy" environments?

For long-range, I cannot recommend highly enough Flutter with a 1km/half mile range, as opposed to 100m.

It costs only US $20, and here is a picture to give you some idea of the range

Noisy environments is not my speciality—I leave that to the hardware guys, sorry—but you might want to look into things like the Shannon limit, which is a software, as opposed to hardware, approach to noise (also, Forward Error Correction, etc)

As I said, those protocols are "low level" stuff to me, as an application developer (layer 3 guy, actually, which is a little lower).

Yes, it is important that you consider that sort of thing, but many will just say "I know, I will go with Raspberry PI (or whatever)" and accept whatever it offers.

After that, when developing your application, you need to decide which higher level protocol to use. Generally, unless your server dictates a particular protocol, you have three main choices:

• Use TCP, and develop a proprietary protocol.
• Use HTTP(S) and develop a RESTful interface (go AJAX if you want asynchronous, non-blocking, for instance if you multi-thread). Unless you have many transactions, are time critical, or your server operations will take a long time, you can get away with a blocking interface.
• Choose one of the plethora of IoT "standards". I would only advise this if your device provides strong support for one particular protocol, or your server demands it.

I hope that I understood your question correctly. Perhaps you can tell us whether you are more hardware or software oriented, and whether you will be developing only for the IoT device, or also for the server, or maybe this is just a general question (which is not encouraged)?

Answer 4

A tad late, but adding my experience for completeness and for a 2023 solution.

I have a almost fully automated home using the Fibaro system. It uses Zwave. I decided to go with Fibaro

1. It was a more professional looking system
2. I asked vendors in NZ to show me their last home/install. Only the Fibaro guy came to the party.
3. I have 120+ devices and 100s of scenes to control lights, blinds, AV etc automatically, with a wall mounted tablet, with mobile apps and with Alexa/Google/Siri

Their recent server Home Centre 3 now supports Zigbee and other devices as well. So, finally I can communicate to both Zwave and Zigbee and have inter-operable scenes.