RFID, NFC & UWB · Study deck

Z-Wave Routing and Healing

A Z-Wave route fails at the worst time: after furniture moves, a repeater is unplugged, a sleeping sensor misses a wake window, or a device sits at the edge of coverage.

Radio Remi is your guide for this deck.

z-wavesource-routingroute-repair
Radio Remi, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Explain how a classic Z-Wave source route is selected, carried, acknowledged, and remembered.
  • Identify which devices can act as repeaters and which devices should be treated as non-routing endpoints.
  • Describe how failed acknowledgements, alternate routes, Explorer Frames, and rediscovery fit into route repair.
  • Distinguish a targeted route repair from a broad network rediscovery or "heal" operation.
iotclass.org

Major section

In 60 Seconds

Classic Z-Wave routing is source-routed.

  • A sending node uses stored route evidence, places the route in the frame, and each repeater forwards to the next listed hop.
  • The successful route becomes the route to try first next time.
  • When direct or stored routes fail, the network can try alternate routes and then use Explorer Frame discovery as a last resort.

Key terms

Mains-powered always-listening devices
Mains-powered always-listening devices are the classic mesh backbone; sleepy battery devices and Z-Wave Long Range endpoints do not strengthen that backbone.
iotclass.org

Major section

Core Ideas

Source route: the selected path is carried in the transmitted frame instead of being decided independently at every hop.

  • Repeater: an always-listening classic Z-Wave node that can forward routed traffic for other nodes.
  • Last Working Route (LWR): the most recently successful route a node can try before less proven alternatives.
  • Explorer Frame: a discovery frame used when known routes no longer reach the target.
iotclass.org

Major section

Core Ideas (continued)

Rediscovery or heal: a controller action that rebuilds route and neighbor evidence after topology changes or repeated failures.

  • Sleeping endpoint: a battery device that wakes for events or scheduled communication and normally does not repeat traffic.
  • Frequently Listening endpoint: a low-power endpoint that can be reached by wake-up beams but still does not act as a route repeater.
  • Z-Wave Long Range endpoint: an LR node that uses direct star communication with the gateway rather than classic mesh routing.
iotclass.org

Major section

Source Routing, Not Hop-by-Hop Routing

Classic Z-Wave repeaters do not run a full distributed routing decision for every packet.

  • The route is selected before transmission and included in the frame.
  • Each repeater reads its position in the route and forwards to the next listed node.
  • That ordering makes for later commands depend on route + LWR.
Classic Z-Wave source route showing route evidence, a frame with an ordered hop list, repeater forwarding, acknowledgement, and Last Working Route update.
Classic Z-Wave source route showing route evidence, a frame with an ordered hop list, repeater forwarding, acknowledgement, and Last Working Route update.
iotclass.org

Major section

Source Route Evidence Is an Installed-Location Claim

A house might show one controller, nine mains-powered switches and plugs, four FLiRS locks or thermostats, and sixteen sleepy sensors.

  • The app reports thirty nodes, but the classic route backbone is only the nine always-listening devices.
  • The FLiRS and sleepy endpoints can be destinations; they are not the devices that carry another endpoint's command.
  • The repeater limit is also an acceptance constraint.

Why it matters

If the same lock later routes through a movable smart plug, the evidence packet should say so because the route depends on an outlet that may be unplugged.

iotclass.org

Major section

Repeaters and the Classic Mesh Backbone

A battery contact sensor, motion sensor, button, or handheld remote should normally be treated as an endpoint, not as a path-building device.

  • In classic Z-Wave, the reliable backbone is built from always-listening devices that can forward traffic.
  • Product category alone is not enough.
  • Good repeater evidence is measured after installation.
iotclass.org

Major section

Sleeping and Frequently Listening Endpoints

To test sleeping and frequently listening endpoints, inspect how: Hub relates to: No repeat in it. Not endpoint count makes the purpose concrete.

  • Twenty sensors plus two repeaters is still a two-repeater backbone.
Z-Wave endpoint behavior showing always-listening repeaters forwarding routed traffic, frequently listening endpoints receiving wake-up beams, and non-listening sleeping endpoints communicating only when awake.
Z-Wave endpoint behavior showing always-listening repeaters forwarding routed traffic, frequently listening endpoints receiving wake-up beams, and non-listening sleeping endpoints communicating only when awake.
iotclass.org

Major section

Route Repair and Healing

Route repair starts when a command path stops producing the expected acknowledgement.

  • A controller or sending node may try the last working route, then other known routes, and then Explorer Frame discovery when known routes fail.
  • The remaining question is and a post-repair command succeeds.
  • Reopen route repair and healing whenever try known paths changes.
Classic Z-Wave route repair loop showing a stored route, failed acknowledgement, alternate route attempts, Explorer Frame discovery, route update, and verification.
Classic Z-Wave route repair loop showing a stored route, failed acknowledgement, alternate route attempts, Explorer Frame discovery, route update, and verification.
iotclass.org

Major section

When Known Routes Fail

Furniture moves, a plug-in repeater is unplugged, a controller is relocated, a metal appliance appears near a route, or a battery device waits for a manual wake-up.

  • Z-Wave route recovery should be read as layered evidence rather than as one "heal" button.
  • If that fails, it tries other known routes from the controller's routing table.
  • If known routes fail, Explorer Frame discovery can search for a fresh path.
iotclass.org

Major section

When Known Routes Fail (continued)

If both fail, the evidence points to a local path problem, not a reason to exclude every device.

  • If a new route through Node 8 and Node 14 acknowledges commands, record that before-and-after path and the physical change that made it work.
  • A broad rediscovery can produce useful route tables, but it can also hide the original cause if it is run before anyone records the failed path.
  • If a window sensor has a stale interview, wake it on schedule or manually before treating routing as broken.
iotclass.org

Major section

Explorer Frames Are Controlled Flooding

Pure source routing has a weakness: if the controller's map is stale, every precomputed route can fail and the message is stuck.

  • Explorer Frames are the last-resort discovery mechanism.
  • When a node exhausts known routes, it broadcasts an Explorer Frame that neighboring always-listening nodes rebroadcast under a hop limit.
  • Long Range changes this logic.

Why it matters

Node 6 forwards, but Node 14 no longer hears the frame because a powered repeater near the entry was moved.

iotclass.org

Major section

Explorer Frames Are Controlled Flooding (continued)

Duplicate suppression and the route limit keep the search bounded.

  • Most commands use cheap precomputed source routes with bounded latency.
  • When topology has shifted, Explorer Frame discovery can repair the path without a full network heal.
  • The controller sends to Node 24 using cached route controller -> 6 -> 14 -> 24.
iotclass.org

Major section

Explorer Frames Are Controlled Flooding (continued)

When stored options fail, an Explorer Frame asks nearby always-listening nodes to propagate the search while suppressing duplicates and respecting the route limit.

  • The sender then uses that route and caches the successful result as fresh route evidence.
  • If the route only works through a portable plug, the repair is operationally fragile even though the protocol found a path.
  • The evidence packet should include the physical role of each repeater.
iotclass.org

Major section

Explorer Frames Are Controlled Flooding (continued)

Explorer Frames cannot make every case healthy.

  • If all candidate paths would require more than four repeaters, the topology is too stretched for classic routing.
  • If the only nearby devices are sleepy sensors, there is no forwarding backbone.
  • In a mixed installation, write down whether each endpoint is classic mesh or LR before adding repeaters.
iotclass.org

Major section

Troubleshooting Evidence Packet

Z-Wave troubleshooting gets weaker when it is based on screenshots that only say "offline" or "busy." Build a packet that explains the route failure in terms an installer or future maintainer can retest.

  • A low signal reading, a stale route, and an unplugged repeater are different problems even if the app surfaces each as "unreachable.".
Z-Wave routing evidence packet with seven fields: node identity, power and listening state, route evidence, delivery evidence, health evidence, physical evidence, and repair evidence that confirms a verified route.
Z-Wave routing evidence packet with seven fields: node identity, power and listening state, route evidence, delivery evidence, health evidence, physical evidence, and repair evidence that confirms a verified route.
iotclass.org

Major section

Classic Mesh vs Z-Wave Long Range

Z-Wave Long Range changes the topology.

  • Z-Wave Alliance material describes LR as using a 12-bit address space with support for up to 4000 nodes, while classic Z-Wave uses the smaller classic node space.
  • The more important routing point is that LR nodes do not become repeaters for classic routes.
Classic Z-Wave mesh contrasted with Z-Wave Long Range star topology, showing repeaters only on the classic side and direct gateway links on the Long Range side.
Classic Z-Wave mesh contrasted with Z-Wave Long Range star topology, showing repeaters only on the classic side and direct gateway links on the Long Range side.
iotclass.org

Deck summary

Key takeaways

Classic Z-Wave routing is source-routed.

  • Source route: the selected path is carried in the transmitted frame instead of being decided independently at every hop.
  • Rediscovery or heal: a controller action that rebuilds route and neighbor evidence after topology changes or repeated failures.
  • Classic Z-Wave repeaters do not run a full distributed routing decision for every packet.
  • A house might show one controller, nine mains-powered switches and plugs, four FLiRS locks or thermostats, and sixteen sleepy sensors.
iotclass.org

Retrieval practice

Recall check 1 of 3

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

Q1How does classic Z-Wave routing move a frame toward its destination?

AHop-by-hop routing, where each node independently picks the next hop itself.
BFlooding every single frame to all nodes on the network at once.
CA fixed star where every device always reaches the hub directly on its own.
DSource routing: the sender puts a stored route in the frame and each repeater forwards it.
Show answer

Answer: D Classic Z-Wave is source-routed: the sender embeds a stored route and each repeater forwards to the next listed hop.

iotclass.org

Retrieval practice

Recall check 2 of 3

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

Q2A Z-Wave device's usual route stops working after a repeater is moved. How can the message still get through, and why is this not done for every message?

AEvery message is flooded to all nodes, so a moved repeater does not matter.
BBattery-powered sensors become repeaters to bypass the moved device.
CKnown routes fail, then an Explorer Frame discovers and caches a new path.
DThe controller must be manually reset before any message can route again.
Show answer

Answer: C Classic Z-Wave normally uses cached source routes through mains-powered repeaters.

iotclass.org

Retrieval practice

Recall check 3 of 3

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

Q3A classic Z-Wave command to a door lock fails after the controller tries the Last Working Route and several known alternatives. What is the next routing mechanism to look for in the evidence?

AExplorer Frame discovery, because it is used when known direct or routed paths fail.
BA cloud routing service, because Z-Wave route repair is handled outside the local network.
CBattery-sensor repeating, because nearby sleepy nodes can forward the failed command.
DLong Range fallback, because a direct LR link could bypass the failed repeaters.
Show answer

Answer: A After known routes fail, Explorer Frame discovery is the local mechanism that can discover a new path.

iotclass.org

Print reference

Answers

Answer key.

  1. D · Classic Z-Wave is source-routed: the sender embeds a stored route and each repeater forwards to the next listed hop.
  2. C · Classic Z-Wave normally uses cached source routes through mains-powered repeaters.
  3. A · After known routes fail, Explorer Frame discovery is the local mechanism that can discover a new path.
iotclass.org