RFID, NFC & UWB · Study deck

Z-Wave Architecture and Devices

A Z-Wave network has an identity story before it has an automation story.

Radio Remi is your guide for this deck.

z-wavesource-routingsmart-home

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain how Home IDs and Node IDs define the boundary of a Z-Wave network.
Classify controllers, routing endpoints, sleeping endpoints, and Z-Wave Long Range endpoints by their network responsibilities.
Distinguish classic Z-Wave mesh behavior from Z-Wave Long Range star behavior.
Explain why mains-powered devices, not battery sensors, form the classic mesh backbone.

Major section

Start With the Story · In 60 Seconds

A Z-Wave network has an identity story before it has an automation story.

Z-Wave architecture is built around a network boundary, device addresses, and device roles.
In a classic Z-Wave mesh, a controller owns the Home ID, assigns Node IDs, and uses route evidence to reach devices through mains-powered repeaters.
Battery devices are usually sleepy endpoints: they report events and receive queued configuration updates when awake, but they do not form the routing backbone.

Major section

Core Ideas · Why Architecture Matters

Controller: the gateway or hub that includes devices, maintains network state, and coordinates route repair.

Routing endpoint: a mains-powered, always-listening device that can repeat classic Z-Wave mesh traffic.
Sleeping endpoint: a battery device that wakes for events or periodic checks and normally does not repeat traffic.
Fifty battery sensors do not create fifty repeaters.

Classic Z-Wave network boundary showing one Home ID, controller-owned Node IDs, mains-powered repeaters, and sleeping battery endpoints inside the same network.

Major section

Home ID and Node ID · Command Classes and Security Context

That distinction prevents a common design error.

A classic Z-Wave network uses a network identifier plus per-device addresses.
Identifies one device inside a Home ID.
A Z-Wave device is described by the command classes it supports.
Counts can be misleading unless they separate identity from routing responsibility.

Major section

Device Roles · Controller

Z-Wave architecture is easier to reason about if you classify devices by network responsibility instead of product category.

To make device roles reviewable, compare: Z-Wave Device Roles with: Route backbone in it.: Separate evidence identifies the later check.
The controller is the administrative anchor for the network.

Z-Wave role review showing controller ownership, classic routing endpoints, sleeping endpoints, and Long Range star endpoints as separate architecture responsibilities.

Major section

Classic Mesh Routing Endpoint · Sleeping Endpoint

A routing endpoint is an end device that also helps the network carry traffic.

The best repeaters are not always the devices with the strongest direct signal to the controller.
Most battery sensors are endpoints.
They wake for local events, periodic reports, or manual wake actions.

Major section

Eddie's Math Bridge: Budget a Regional Sleepy Endpoint · Z-Wave Long Range Endpoint

The mathematical gist.: A catalog-typical 850 mAh cell leaves about 647 mAh after five years of 1% self-discharge and a 20% reserve, which permits 14.8 µA average.

Z-Wave Long Range is different from classic mesh repeating.

Major section

Classic Mesh vs Z-Wave Long Range

The important decision is not "old versus new"; it is topology fit.

the building has many mains-powered devices distributed through rooms.
devices need local path diversity around walls, metal, appliances, or RF dead zones.
the deployment is within classic network capacity.
direct gateway-to-device communication is preferred.

Major section

Classic Mesh vs Z-Wave Long Range (continued)

existing devices and controllers are classic Z-Wave or Z-Wave Plus.

endpoints are spread beyond the practical classic mesh backbone.
a large address space is required.
the controller and devices explicitly support LR in the deployment region.
Mixed deployments need records.: For every device, record whether it is classic mesh or LR, whether it can repeat, what security class it used during inclusion, and what evidence proves it is reachable after installation.

Major section

S0, S2, and the DSK

The Device Specific Key is the linchpin.

S2 also separates keys by security class; a door lock can use an access-control class key that is distinct from ordinary sensor traffic.
The lock is critical, the two switches and plug may form the local classic mesh backbone, and the contact sensors are sleepy endpoints.
That sequence gives battery devices a real backbone during inclusion and gives later route repair useful evidence.

Major section

Source Routing and Route Repair

Classic Z-Wave uses source-routed behavior: a selected path is placed in the transmission rather than requiring each repeater to independently decide the next hop.

This keeps normal delivery predictable, but it also means route evidence can become stale when devices move or the RF environment changes.
Route repair should be visible in operations records.

Classic Z-Wave route repair showing a stored source route, failed acknowledgement, Explorer Frame discovery, route-table update, and command retry.

Major section

SmartStart and Architecture Acceptance

The installer scans the device QR code, which carries the DSK, into the controller before powering the device.

S0's weakness was concrete: to bootstrap encryption, the new device and controller exchanged the network key protected by a temporary key that was effectively public.
SmartStart makes secure onboarding easier to operate.
Capacity should also be treated carefully.

Major section

SmartStart and Architecture Acceptance (continued)

Reachability asks whether the node has a working route after installation.

An attacker recording that brief inclusion window could recover the network key, so security depended on nobody listening during pairing.
S2 removes that pattern by deriving a shared secret through ECDH, where each side contributes public material but the resulting key is not transmitted in recoverable form, and by authenticating the physical device with its DSK.
Security, routing, and device-role evidence must be reviewed together.

Major section

SmartStart and Architecture Acceptance (continued)

A controller reaches a lock through Switch A and Plug B.

When the device comes online, the controller can include it over S2 without the same manual pairing window.
Identity asks whether the DSK, security class, command classes, and controller record match the intended physical device.
If Plug B is unplugged, the stored route fails and the system may need Explorer frames or route repair to find a new path.

Major section

Design Review Checklist · Troubleshooting Patterns

To ground design review checklist, use it to distinguish 1.

Validate routes. Only when evidence matches the installed layout makes the purpose concrete.
Validate routes, and only when evidence matches the installed layout as separate entries.
Validate routes need evidence.
The Home ID boundary is clear.

Z-Wave deployment review loop connecting placement plan, inclusion order, route evidence, sleepy-device validation, and operating records.

Major section

Worked Example · Common Pitfalls

A three-floor home has a controller in the first-floor utility room, a smart lock at the front door, six in-wall switches, three smart plugs, ten contact sensors, and four motion sensors.

Counting endpoints instead of repeaters.: A large number of battery sensors does not create a stronger classic mesh.

A Z-Wave controller routes through static relays, detects a missing acknowledgement at Relay C, and heals through alternate Relay D to a door lock.

Major section

Summary · Key Takeaway

Z-Wave architecture starts with a Home ID boundary and Node IDs inside that boundary.

Classic Z-Wave mesh reliability depends on always-listening routing endpoints, while sleeping battery endpoints conserve power and usually do not repeat traffic.
Source routing makes normal delivery predictable, but route evidence can become stale after devices move, fail, or get excluded.
Z-Wave architecture review should include controller role, device classes, mesh routing, inclusion, security, interoperability, and home-automation ownership.

Deck summary

Key takeaways

A Z-Wave network has an identity story before it has an automation story.

Controller: the gateway or hub that includes devices, maintains network state, and coordinates route repair.
That distinction prevents a common design error.
Z-Wave architecture is easier to reason about if you classify devices by network responsibility instead of product category.
A routing endpoint is an end device that also helps the network carry traffic.

Retrieval practice

Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q1In a classic Z-Wave network, what does the primary controller own and assign?

AThe Home ID for the network and a Node ID for each included device

BThe Wi-Fi SSID and password used by the home router

CThe IPv6 prefix that every device advertises on the mesh

DThe manufacturer cloud account tied to each device

Show answer

Answer: A The Z-Wave controller owns the network's Home ID and assigns each included device a Node ID.

Retrieval practice

Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q2Why does Z-Wave S2 inclusion resist an attacker who records pairing traffic, while S0 did not?

AS2 uses a longer AES key than S0 and leaves pairing unauthenticated.

BS2 moves pairing to 2.4 GHz so sub-GHz sniffers cannot record it.

CS2 pre-loads one shared factory key onto every certified device.

DS2 uses ECDH key agreement and verifies the printed DSK.

Show answer

Answer: D S0 sent the network key under an effectively public temporary key.

Retrieval practice

Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q3A classic Z-Wave network has 45 devices, but 38 of them are battery door and motion sensors. Several edge sensors are unreliable. What is the most likely architecture problem?

AThe network simply has too many devices for classic Z-Wave addressing to handle.

BMost devices are sleepy endpoints, so the mesh has too few always-listening repeaters.

CThe battery devices should all be configured as secondary controllers instead.

DThe Home ID should be changed on only the unreliable edge devices.

Show answer

Answer: B Classic Z-Wave mesh reliability depends on always-listening routing endpoints.

Print reference

Answers

Answer key.

A · The Z-Wave controller owns the network's Home ID and assigns each included device a Node ID.
D · S0 sent the network key under an effectively public temporary key.
B · Classic Z-Wave mesh reliability depends on always-listening routing endpoints.