RFID, NFC & UWB · Study deck

Z-Wave Acceptance

Picture a door sensor that joins beside the controller but misses events from its final wall.

Radio Remi is your guide for this deck.

z-wavenetwork-plannings2-security

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

After studying this chapter

Learning objectives

You will be able to:

Build a Z-Wave deployment inventory that separates controllers, classic mesh repeaters, sleeping endpoints, access-control devices, and Z-Wave Long Range endpoints.
Place mains-powered classic mesh devices where they create useful paths instead of merely adding device count.
Assign S2 security classes based on physical-access risk and authentication capability.
Diagnose failed inclusion, incomplete interviews, stale routes, and sleepy-device symptoms without rebuilding the whole network first.

Major section

Start With the Story · In 60 Seconds

A device list cannot prove that the installed path works.

A gateway means the boundary system that joins local devices to another network or service.
This check covers one layout and set of devices, not every radio change.
Pairing a device beside the hub is just the first clue.

Major section

Planning Inputs

Inventory records each device’s role, power source, location, region, and classic or Long Range support.

The topology choice then sets repeater or direct-link expectations.
These five records must be read as one plan.

Z-Wave practical planning loop that starts with device inventory, chooses topology mode, places the classic backbone, assigns S2 security, and closes only when acceptance evidence matches installed reality.

Major section

Selection Workflow: Device Role Review · Placement Review

Wakes for local events, periodic reports, or manual wake actions.

Usually does not repeat traffic.
The common planning error is counting every node as if it strengthens the mesh.
A set of battery sensors can be valuable, but it does not create a backbone.

Z-Wave placement evidence plan showing fixed classic repeaters, sleeping endpoints, access-control devices, a Long Range endpoint, and weak edges that need installed proof.

Major section

Always-On Devices Define the Backbone

Battery devices sleep to save energy and generally do not repeat for other nodes.

The practical planning question is not "where are my sensors?" but "do my always-on devices form a connected mesh that reaches every critical location within the route budget?".
A two-floor house might have 1 controller, 8 in-wall switches, 2 smart plugs, 1 powered thermostat, 3 locks, and 18 battery sensors.
The installation has 33 nodes, but the classic mesh backbone is only the 11 always-listening devices: 8 + 2 + 1 = 11.

Major section

Always-On Devices Define the Backbone (continued)

The 21 battery-powered locks and sensors matter for coverage goals, but they are not the devices that carry other nodes' traffic.

If 7 are clustered in the kitchen and living room, only 4 remain to bridge the hallway, upstairs rooms, garage wall, and exterior entry.
Moving one smart plug from behind a TV to the stairwell may improve the architecture more than buying more battery sensors, because it changes the route backbone instead of only adding endpoints.
If the front lock, garage controller, and upstairs hallway sensor are the three most important endpoints, each needs an explicit path story.

Major section

Security Assignment

S2 security is not a single label.

It separates network keys and inclusion rules into classes.
The practical decision is to match the class to device risk and authentication capability.
The mains hall switch and sleeping window contact may use S2 Authenticated when their DSK or QR authentication succeeds.
If authentication fails, stop and investigate before route repair.

Z-Wave S2 security assignment flow that routes physical-entry devices to S2 Access Control, normal authenticated devices to S2 Authenticated, constrained cases to S2 Unauthenticated review, and legacy devices to exception handling.

Major section

FLiRS, Sleeping Sensors, and Command Latency

Those rows explain what each device can do for the network and what evidence proves it is accepted.

A mains device is available immediately.
A light switch may use an authenticated class and serve as a repeater.
A lock should be treated as an access-control endpoint and validated more strictly.

Major section

Selection Workflow: Inclusion Sequence · Troubleshooting Flow

Prepare the record: Confirm regional frequency, controller firmware, device support, SmartStart or manual inclusion method, and security target.

Manually wake them when configuration or interview evidence is needed.
Repair and verify: Run route repair or controller health checks after moving repeaters, replacing failed devices, or adding major backbone devices.

Z-Wave practical troubleshooting flow from failed inclusion through radio visibility, prior-network exclusion, S2 authentication, interview completion, route repair, and acceptance record update.

Major section

Hop Budget and Acceptance Evidence

Lay out always-powered switches, plugs, modules, and powered sensors so that every critical location sits within a short chain of them.

A FLiRS lock also needs a mains repeater within direct radio range; it cannot lean on other battery devices to relay.
Acceptance should be measurable.
Long Range changes the evidence, not the need for evidence.

Major section

Hop Budget and Acceptance Evidence (continued)

Sub-GHz propagation helps through ordinary walls, but thick masonry, foil insulation, appliances, metal doors, and utility spaces still create weak paths that a well-placed fixed repeater must solve.

If a device only succeeds at the edge of the hop budget or drops during heal, add or reposition a mains repeater instead of hoping the radio will cope.
If the controller reaches a front lock through a hall switch and then an entry switch, record that installed path and the fact that both intermediate devices are mains powered.
It needs direct gateway reach, regional support, controller support, security inclusion, and installed signal evidence.

Major section

Hop Budget and Acceptance Evidence (continued)

If the only observed path runs through a removable smart plug, record that dependency and decide whether to replace it with a fixed repeater.

The problem is not the number of nodes; it is whether a critical route depends on movable or weak backbone devices.
Unplug one non-critical smart plug or move one portable repeater back to its intended outlet, then confirm the lock, garage control, and farthest sensor still have acceptable evidence.
If one change breaks a critical path, the network needs another fixed mains device or a revised placement plan before acceptance.

Major section

Capacity and Scaling · Worked Example

Classic Z-Wave has a 232-node network limit.

That number is a boundary, not a target.
Practical designs should leave room for replacement devices, failed-node cleanup, and future additions.
Classic mesh repeaters: fixed in-wall lighting controls and any mains-powered thermostat or module that the controller confirms can repeat.

Major section

Common Pitfalls

Treating every device as a repeater: Sleeping endpoints may be useful sensors, but they do not create the classic mesh backbone.

Using security class as a substitute for placement: S2 protects communication; it does not fix weak route evidence.
Skipping prior-network cleanup: Used, tested, or moved devices often need exclusion before a clean inclusion.
Moving repeaters after acceptance: A relocated plug or switch can invalidate routes that looked healthy during handoff.

Deck summary

Key takeaways

A device list cannot prove that the installed path works.

Inventory records each device’s role, power source, location, region, and classic or Long Range support.
Wakes for local events, periodic reports, or manual wake actions.
Battery devices sleep to save energy and generally do not repeat for other nodes.
The 21 battery-powered locks and sensors matter for coverage goals, but they are not the devices that carry other nodes' traffic.

Retrieval practice

Recall check 1 of 4

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

Q1A Z-Wave design is not accepted just because every device appears in the controller app. What else must the plan show?

AAn inventory that labels each device and its controller association.

BA controller-app connectivity trace showing each device online during setup.

CEvidence of mesh repeater placement, route health, and correct security inclusion.

DA controller firmware health and update record for the installed mesh.

Show answer

Answer: C A Z-Wave plan is accepted on repeater placement, route health, and security inclusion evidence, not mere app visibility.

Retrieval practice

Recall check 2 of 4

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

Q2A door lock and a lamp join the same controller. How should their security plans differ?

ARequire authenticated S2 Access Control for lock entry; record a supported policy-approved class for lamp.

BGive the lock the weakest security class to speed inclusion, leaving entry control unauthenticated.

CTreat both devices as secure merely because joining succeeded, without reviewing either security class.

DUse the lamp's route as proof of the lock's class because devices on that route share inclusion behavior.

Show answer

Answer: A Entry control requires verified S2 Access Control inclusion; the lamp's granted class must match its support and policy.

Retrieval practice

Recall check 3 of 4

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

Q3A Z-Wave network has many contact sensors but only two mains-powered devices. Edge sensors report intermittently. What is the most useful first design fix?

AAssign every sensor to S2 Access Control before placement tests.

BFactory-reset the controller before testing placement.

CAdd always-listening mesh repeaters near weak areas.

DCount the sensors as repeaters because they are part of the mesh.

Show answer

Answer: C Classic Z-Wave mesh coverage depends on always-listening routing devices.

Retrieval practice

Recall check 4 of 4

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

Q4A battery-powered Z-Wave door lock at the edge of the house must lock on command within a second, but it is unreliable. What device behavior is involved, and what fixes the reliability?

AAccept delay because plain sleeping sensors cannot receive instant commands.

BAdd battery sensors nearby as repeaters for the door lock.

CRaise lock transmit power beyond four hops to reach the controller.

DPlace a mains repeater in range for the FLiRS lock's beam wakeup.

Show answer

Answer: D A battery lock is a FLiRS device: it wakes on a beam for low-latency commands but does not repeat, so it needs a mains-powered repeater within direct range and a route inside the 4-hop limit.

Print reference

Answers 1 of 2

Answer key.

C · A Z-Wave plan is accepted on repeater placement, route health, and security inclusion evidence, not mere app visibility.
A · Entry control requires verified S2 Access Control inclusion; the lamp's granted class must match its support and policy.
C · Classic Z-Wave mesh coverage depends on always-listening routing devices.

Print reference

Answers 2 of 2

Answer key.

D · A battery lock is a FLiRS device: it wakes on a beam for low-latency commands but does not repeat, so it needs a mains-powered repeater within direct range and a route inside the 4-hop limit.