‘Zigbee’ and ‘Z-Wave’, heard these terms very often? For those of you wondering what on earth those words mean, we have taken a stab at it here, to de-mystify these terms for you.

In this three-part series, this first blog will focus on what Zigbee and Z-Wave are. Why are they needed? The second and third episodes will explain the various aspects of Zigbee and Z-Wave in further detail, providing you an overview of how they work.

Simply put, Zigbee and Z-Wave are IoT short-range wireless communication protocols. Similar to Bluetooth and WiFi. What makes them significantly different from Bluetooth and WiFi is that they are designed specifically for IoT Wireless Sensor Networks that require long battery life. Based on the IEEE standard 802.15.4 PHY and MAC layers, both Zigbee and Z-Wave are designed to satisfy the following objectives:

  • Utilize low energy during wireless transmission and reception of IoT wireless sensor data: Battery-powered devices that are operated quite frequently (such as Motion Sensors, Contact Sensors, Door Locks, etc.) should work for years utilizing tiny batteries (CR123A/AAA batteries in most cases). In contrast, Wi-Fi networks are designed for High Bandwidth and Low Latency traffic patterns, and this ends up requiring a different base system architecture that results in a huge battery drain. Zigbee and Z-Wave utilize IEEE 802.15.4 PHY and MAC layers, that are designed specifically for Low Bandwidth (tiny packets and longer latency), and allow for long deep sleep cycles to enable a sensor’s battery to last for years!
  • Allow IoT devices to talk to each other wirelessly over a large area such as a home or office with multiple storeys. While the Low Battery requirements compel the designer to throttle the TX power budgets thereby impacting the range over which transmission can occur (as in the case of Bluetooth), Zigbee and Z-Wave extend their range by utilizing a mesh network topology. In this mesh architecture, it allows packets to hop over nearby nodes in order to reach faraway nodes. The Bluetooth Special Interest Group (the ones that standardize Bluetooth Low Energy (BLE) and Bluetooth) responded a whole decade later in 2017 and introduced Bluetooth mesh for IoT, their own version of a mesh networking protocol for IoT running on top of Bluetooth.
  • Security built right into the protocol. Users of an IoT network want to expand their network to new use cases. But security is paramount. Zigbee and Z-wave standardize how devices join and leave the network in a secure manner. Additionally, IoT devices need to communicate securely with each other without compromising the network.
  • Interoperability. Provide a common language for IoT devices to exchange commands and data. This common language is known as an IoT Application Protocol. Zigbee and Z-Wave provide open standard protocols for the Application Layer messages and thus allow devices from different manufacturers to interoperate with each other on the same network.

So, while we gain on power optimisation, security, interoperability, control, configuration, the one thing we lose by introducing such low energy networking protocols is the ability for Zigbee and Z-Wave devices to communicate with everyday client devices (like a mobile phone) which use TCP/IP. So a typical Zigbee or Z-Wave solution uses a device known as a Gateway to bridge the Zigbee/Z-Wave and TCP/IP networks over which a client and device exchange messages. More about this in the coming blog entries.

The COCO IoT Platform has been integrated into multiple COCO Gateways that support all the important IoT protocols like Zigbee, Z-wave, BLE, and WiFi. Additionally using the COCO Standard, these multi-radio gateways allow the COCO Home iOS and Android apps to be used to operate 2000+ Zigbee and Z-Wave devices available in the market without requiring the end-user the hassle of understanding the nuances between these protocols. Each COCO Gateway consists of our Zigbee and Z-Wave Middleware built on top of our COCO Device SDK, so that IoT solutions around Smart Energy, Building Management, Connected Guest, Shared Condos, etc. can be built using the COCO Client SDK without the low-level knowledge of these protocols.

The following table provides a comparison between the various short-range IoT WSN protocols:

FeatureBluetoothZigbeeZ-Wave
Range (Typical Noisy Wireless Environment)5 meters10-20 metersUp to 100 meters
Frequency Band2.4GHz2.4GHz and Sub-GHzSub-Ghz depending on region
Bandwidth270 Kbps250 Kbps (in 2.4Ghz configuration)20-40 Kbps
Battery LifeYearsYearsYears
Network TopologyStar & MeshMeshMesh
Application Layer StandardsNoneZigbeeZ-Wave
Closed or Open StandardsBothOpenOpen

Do we need them both to co-exist?

So that brings us to the important question on why do we need both Zigbee and Z-wave to exist? 

Well, the Sub-GHz is an important attribute for Z-wave, but the challenge is that device makers need to manage different SKUs in different regions. Zigbee is the only standard that supports both 2.4Ghz and Sub Ghz, but the market for Zigbee 2.4Ghz has become the de facto standard for Zigbee.

To us, it’s clear that we don’t need them both to co-exist, they both are extremely similar in their architectures (they both share the same PHY and MAC layers), and they both focus on standardizing the IoT application layer for Wireless Sensor Networks. We believe the market will consolidate over time – but for the next 5 years at least, there is enough room for them both to exist and for one of them to prevail.

Read on to Part 2 – a more in-depth technical review of the protocol layer similarities of Zigbee and Z-wave.