Z-Wave

Origins and Design Goals of Z-Wave

Around 2000, home automation products still used fragmented and often incompatible radio protocols. A homeowner combining lighting, thermostats, and security sensors had to match products by vendor and frequency. Wi-Fi delivered internet access but consumed too much energy for many battery-powered sensors. Bluetooth targeted personal-area links such as headsets and keyboards. Other protocols were proprietary, so devices from different suppliers often required separate gateways.

Zensys needed a wireless technology for dependable home automation. A battery-powered window sensor had to run for years, the radio had to cross walls and floors, and a switch from one company had to control a bulb from another company through a defined command vocabulary.

Z-Wave emerged from this need. Zensys was founded in Denmark in 1999, and its first Z-Wave product followed in 2001. Early Z-Wave used a vertically integrated protocol controlled by one technology supplier. The Alliance formed in 2005, and Z-Wave later became the open ITU-T G.9959 standard represented by the Z-Wave Alliance and supported by multiple silicon suppliers. Certification defines required command classes and protocol behavior so products from different manufacturers can interoperate for supported functions.

Sub-GHz Frequencies in Z-Wave

One defining characteristic of Z-Wave, and a difference from Wi-Fi or Zigbee, is its radio frequency choice. Instead of operating in the 2.4 GHz band, Z-Wave uses regional sub-gigahertz (sub-GHz) radio bands governed by local ISM or short-range-device rules. The exact frequency varies by region to satisfy local regulations:

• North America: The US frequency plan includes 908.40 or 908.42 MHz and 916.00 MHz, depending on data rate.
• Europe: The EU plan includes 868.40 or 868.42 MHz and 869.85 MHz, depending on data rate and region.

Depending on the channel, classic Z-Wave supports data rates of 9.6, 40, or 100 kbps. Frequency, transmit power, and duty-cycle limits come from the regional plan, so a device intended for Europe should not be moved to a North American network unless its radio and certification support that region.

Choosing a sub-GHz band gives Z-Wave two practical advantages for home automation:

1. Less Competition in Typical Homes: The 2.4 GHz band is shared by Wi-Fi, Bluetooth, microwave ovens, cordless phones, and other devices. Congestion can produce lost frames and retries. Z-Wave uses a different sub-GHz allocation, so its frames avoid much of that local 2.4 GHz traffic, although interference still depends on the devices and regulations in a particular area. A lost message matters for a smart lock or security sensor.
2. Propagation at a Lower Frequency: For the same antenna and regulatory conditions, lower-frequency radio waves generally lose less energy in many building materials than 2.4 GHz waves. A 900 MHz Z-Wave link can therefore cover some walls more effectively than a 2.4 GHz link, but the result depends on output power, antenna placement, construction, and interference. A mesh may then need fewer hops to cover a given area.

Mesh Topology and Routing in Z-Wave

Like Zigbee, classic Z-Wave uses a mesh topology to extend coverage beyond a direct radio link. A classic Z-Wave network supports up to 232 nodes, each identified by a NodeID inside a shared HomeID. The controller builds a network map and the sender places route information in frames, while failed links can trigger another route or an Explorer Frame. Z-Wave Long Range, introduced in 2020, is a distinct star-topology mode whose standard allows up to 4000 nodes at 100 kbps.

Device Roles Inside a Z-Wave Network

A Z-Wave network has controllers and end devices. Older Z-Wave documentation often called end devices slaves, but current role descriptions use end device terminology:

• Controllers: Controllers manage the network. A controller is responsible for forming the network, including or excluding devices, managing associations, and computing routing paths. Every Z-Wave network must have a single Primary Controller that maintains the authoritative network view. Secondary Controllers can initiate commands but receive their network data from the primary device. Examples include dedicated smart-home hubs, handheld remotes, or USB sticks attached to a server.
• End Devices (historically called Slave Devices): These nodes receive commands from controllers and can report status back, for example when a sensor detects a change. Their power source determines whether they can relay traffic. Two common roles are:
  • Always-On Routing Devices: Mains-powered devices such as smart switches or outlets keep their receivers on. They participate in the mesh, relay messages, and extend coverage.
  • Sleeping End Devices: Battery-operated nodes such as door and window sensors spend most of their time in a low-power state. Reporting sleeping nodes do not relay traffic. Frequently Listening Sleeping End Devices can wake for a beam, but they also do not act as repeaters.

Routing Mechanism: Source Routing

Z-Wave can use source routing, a key difference from Zigbee’s dynamic routing or Bluetooth Mesh’s managed flooding.

In a source-routed exchange the controller maintains the network map and available route information. When it needs to deliver a command from Node A to Node D, it can select a route such as A to B to C to D and place the hop list in the frame. This gives the sender a known path instead of relying on each hop to discover a path independently.

Each intermediate hop, B and C in this example, reads the next hop encoded in the frame and forwards the packet. If a route fails, the sender can try another route, and an Explorer Frame can discover a path as a last resort. Network maintenance then updates the map when a device moves or fails.

Command Classes and Certification

Z-Wave certification defines a common application vocabulary so products from different manufacturers can interoperate for the functions they implement. A controller still has to support the relevant device type and command classes.

Command Classes: Z-Wave’s Vocabulary

The Z-Wave “language” consists of a library of predefined capabilities known as Command Classes. They are analogous to Zigbee clusters or Bluetooth profiles/services. Each command class represents a distinct function the device can perform. A node reports its supported command classes and versions to the controller, which can then select commands for that device. For example:

• COMMAND_CLASS_BASIC: A minimal command class for simple on/off control.
• COMMAND_CLASS_SWITCH_MULTILEVEL: Used by devices that have more states than on/off, such as dimmers or multi-speed fans.
• COMMAND_CLASS_SENSOR_MULTILEVEL: Allows sensors to report continuous values like temperature, humidity, or light level.
• COMMAND_CLASS_DOOR_LOCK: A specialized set of commands for controlling and reporting the status of smart door locks.

Mandatory Certification and the SoC Model

Two mechanisms keep this vocabulary consistent. First, a product carrying the official Z-Wave logo must pass a certification process administered by the Z-Wave Alliance. Certification checks required command classes and protocol behavior for the product's device type.

Second, Z-Wave historically followed a System-on-Chip (SoC) model in which the radio and the protocol stack are supplied in a pre-certified chip. Silicon Labs acquired the Z-Wave business of Sigma Designs in 2018, while Sigma Designs had acquired Zensys in 2008. The 700 and 800 platform families are silicon generations, while Z-Wave Long Range is a distinct network mode rather than a replacement name for classic mesh. Device makers build products around this core, reducing the amount of protocol code that each manufacturer must implement.

Z-Wave Security: S0 and S2

Smart homes can control door locks, security alarms, and garage doors, so the protocol must protect both inclusion and ordinary traffic. Z-Wave added S2 to address weaknesses in the earlier S0 security scheme.

• Security S0: The Original Standard

  The first Z-Wave security framework encrypted network traffic with AES-128. Its key exchange during device inclusion was vulnerable to interception by an attacker close to the devices at that moment.

• Security S2: Authenticated Inclusion

  In April 2017 the Z-Wave Alliance made Security S2 mandatory for new product certifications. S2 uses authenticated inclusion and separates access control, authenticated, and unauthenticated security classes:

  • Elliptic Curve Diffie-Hellman (ECDH): Establishes a temporary shared key before the network key is transferred to the joining device.
  • QR Codes and PINs: Out-of-band authentication uses the device-specific key printed on the product or its packaging. The controller can ask the installer to scan a QR code or enter the first five digits, confirming that the intended device is joining.
  • Secured Traffic: S0 and all three S2 classes use AES-128 for encrypted traffic. S2 also uses unique transmission values and authenticated inclusion to reduce replay and rogue-node risks.