Z-Wave Simulation: Topology and Failure Experiments
This lab belongs to Z-Wave Acceptance
Start With the Decision
A Z-Wave route can fail when one repeater goes dark or an endpoint sleeps. The first experiments isolate those topology faults.
Route Overview
This is part 1 of 2. Continue with Z-Wave Simulation: Timing and Evidence Analysis.
Part Objectives
- Run mesh, repeater-failure, and sleeping-node experiments.
- Record route and delivery evidence from each simulation.
Chapter Roadmap
- Start With the Story
- In 60 Seconds
- Quick Check: Z-Wave Simulation
- Core Ideas
- The Simulation Boundary
- Phoebe’s Field Notes: What “Battery Behavior” the Simulator Cannot See
- Eddie’s Math Bridge: Price a Simulated Route Repair
- Scenario Design
- Route and Topology Exercises
- Exercise 1: Classic Route Feasibility
- Exercise 2: Repeater Failure
- Exercise 3: Sleeping Endpoint Timing
Start With the Story
Picture a home mesh where one wall switch stops passing a message. A model can show route choices before anyone moves real devices.
First, name the question, map, radio type, sleep rule, and fault to test. Save the start state and the result for each run.
A simple model makes cause easy to see, but it may leave out walls, noise, or battery wear. More detail feels real, yet it can hide a poor rule in many settings.
That is the simple story, but a model cannot certify a real site. The later cases show how to join route proof with field checks.
Use the Practitioner sections to build and compare fault runs. Use the Under the Hood sections to study timing, retries, range, and model limits in more depth.
Plain check
- Name the site map. Name each node. Mark each radio type. Mark each sleep rule.
- Save the start route. Save the start time. Save the test fault. Save the expected result.
- Test one dead relay. Test one weak path. Test one slow node. Test one lost frame.
- Run the same case twice. Keep each result. Explain any change. Fix hidden chance.
- Mark model limits. Mark field unknowns. Plan the real test. Keep both records linked.
- Compare old and new paths. Check retry cost. Check user delay. Check safe recovery.
- Use Practitioner to run. Use deeper timing checks. Test the weak edge. State each bound.
A Z-Wave simulation is not RF proof, but it is a useful way to test reasoning before buying or moving devices. It can expose topology assumptions, repeater dependency, route repair ideas, and failure scenarios in a controlled space.
Use this lab to separate model evidence from field evidence. Run the scenario, record what the simulation teaches, and write down exactly which behavior must still be validated with real hardware.
In 60 Seconds
A Z-Wave simulator is useful when it makes assumptions visible. It can test whether a topology graph has enough always-listening repeaters, whether a route exceeds the configured classic-mesh limit, how a controller should react when a route fails, and whether a scenario produces the evidence needed for a design review. It cannot prove RF range, antenna performance, certification status, regional compliance, battery life, or installed reliability. Those claims require real hardware, certified products, controlled measurements, and field validation.
This chapter shows how to design simulation scenarios, inject failures, interpret route evidence, and hand the results to hardware validation without overstating what software-only tests can prove.
Learning Objectives
By the end of this chapter, you should be able to:
- Define what a Z-Wave software simulation can and cannot validate.
- Build scenario records that separate topology assumptions, device roles, route constraints, events, and assertions.
- Exercise classic mesh routes, sleeping endpoints, and Z-Wave Long Range star links without treating the model as RF proof.
- Inject route, node, inclusion, security, and command-class failures in a controlled way.
- Convert simulation output into a hardware-validation checklist for controller, device, route-health, and installation tests.
- Explain why simulation evidence supports design review but does not replace certification or installed RF validation.
Quick Check: Z-Wave Simulation
Core Ideas
A useful Z-Wave simulation begins as a repeatable scenario record: topology, device roles, assumptions, events, and pass/fail assertions. Its graph represents allowed links rather than measured RF propagation. Within that boundary, the model can enforce classic repeater constraints, prevent a sleeping endpoint from becoming an always-available relay, and inject failures such as a missing acknowledgement, dead repeater, stale route, failed inclusion, or incomplete interview. The result is an evidence handoff for bench testing, not a claim about the installed network.
The Simulation Boundary
Start every simulation by writing down the boundary. The boundary is not paperwork; it is how you stop a useful model from becoming a misleading claim.
Use Figure to locate the exact handoff from repeatable software checks to physical proof. The diagram separates what the scenario can assert from what must be measured first on the bench and then in the final installation.
On the left of Figure, Software model contains Topology, Rules, and Assertions. Their output is an Evidence packet that must record pass, fail, and exclusions rather than hiding assumptions inside a green result. Follow that packet to Bench, where real devices can challenge the model, and then to Installed, where the final place supplies the environmental evidence. The lower Not proven in software band names the remaining claims—RF path, antenna behaviour, certification, regional compliance, and battery behaviour. This boundary anchors the rest of the chapter: simulation narrows route and state-machine questions, while hardware and site tests decide whether the design works physically.
Software simulation can check:
- whether the modeled device roles are coherent;
- whether classic mesh routes stay within the configured repeater limit;
- whether sleeping devices are excluded from repeater paths;
- whether a controller retry or repair policy is triggered after a failed acknowledgement;
- whether a Z-Wave Long Range endpoint is modeled as a direct star link rather than as a mesh repeater;
- whether inclusion, interview, and command flows are complete at the level of states and events;
- whether the scenario produces a clear pass/fail record.
Software simulation cannot check:
- real RF propagation through walls, metal, appliances, water, people, or landscaping;
- antenna orientation, enclosure effects, or installation workmanship;
- regional compliance or device certification;
- controller firmware behavior beyond what the model implements;
- battery life, wake timing, or power behavior under real use;
- interoperability with a specific certified device unless that device is tested;
- user support outcomes after hub migration, firmware updates, or renovations.
Use the simulator to narrow the design question. Use hardware tests to answer the physical one.
The mathematical gist. Eight 40 ms radio steps at 30 mA and 3 V cost 28.8 mJ, or 0.008 mWh. A 220 mAh cell derated for five years of 1% self-discharge and a 20% reserve holds about 502 mWh; one repair each hour would spend 0.192 mWh per day and yields a 7.2-year repair-only screen before sleep, sensing, and ordinary reports.
A useful model might contain 1 controller, 7 always-listening classic repeaters, 3 FLiRS locks, 14 sleeping sensors, and 1 Long Range endpoint. It can test whether the classic lock route uses only repeaters, whether a route stays inside the configured repeater limit, and whether the LR endpoint remains a direct gateway link. It cannot prove that the garage wall, metal door, antenna orientation, or regional device choice will work in the actual building.
Make every route an assumption with a label. For example, the model can say that Node 21 lock reaches the controller through Node 6 stair switch and Node 12 hall plug. That is design evidence only if the run also records that the Node 12 link is synthetic and must be validated later with the installed plug powered in its final outlet.
Use simulation to reject bad designs early. If the only passing route uses a sleeping contact sensor as a repeater, the model should fail. If moving one plug removes every route to a critical lock, the design needs another fixed repeater or a different topology. If the model passes only by treating an LR endpoint as a classic repeater, the rules are wrong and the pass result should be discarded.
Scenario Design
A useful scenario is small enough to explain and strict enough to fail. Avoid demonstrations that only show a happy path. A route simulation that never loses a repeater, never sleeps a battery device, and never records assumptions is just an animation.
Inspect Small enough to explain, strict enough to fail and Classic mesh + LR star in Figure for scenario design. For the evidence behind scenario design, compare Small enough to explain, strict enough to fail with Classic mesh + LR star in it. The route closes at Result log — pass or fail, with reasons.
Read Small enough to explain, strict enough to fail with Classic mesh + LR star in Figure for scenario design. Trace its responsibilities by locating Small enough to explain, strict enough to fail, assigning Classic mesh + LR star, and ending at Result log — pass or fail, with reasons. A fault should remain attached to Small enough to explain, strict enough to fail or Classic mesh + LR star. Attach the next action in scenario design to Result log — pass or fail, with reasons.
Each scenario record should include:
- Question: the design decision the simulation is meant to inform.
- Topology: controller, classic repeaters, sleeping endpoints, LR endpoints, and allowed links.
- Mode: classic mesh, Z-Wave Long Range star, or a mixed model with both called out.
- Assumptions: route limit, retry policy, wake behavior, failed-node timing, and any simplified RF rule.
- Events: inclusion, interview, route calculation, command send, acknowledgement, route repair, wake-up, exclusion, or failure.
- Assertions: the exact conditions that mark the run as pass or fail.
- Known exclusions: RF measurements, certification, real controller quirks, battery behavior, and installation workmanship.
Good scenario questions are concrete:
- Can the modeled door lock still receive a command if one hallway repeater fails?
- Does the simulated route ever use a sleeping contact sensor as a repeater?
- Does the network record a failed interview before the device is accepted?
- Does an LR endpoint remain a direct star endpoint rather than improving the classic mesh?
- Does the handoff record say which hardware evidence is still missing?
Route and Topology Exercises
Topology exercises should teach the route decision, not promise a deployment result.
Inspect R1 and failed in Figure for route and topology exercises. To make route and topology exercises reviewable, keep both R1 and failed visible in it. The route closes at lock.
Read R1 with failed in Figure for route and topology exercises. Trace it from R1 through failed to lock. That ordering makes lock depend on R1. Preserve the lock condition in the handoff for route and topology exercises.
Exercise 1: Classic Route Feasibility
Model a controller, several always-listening repeaters, one sleeping sensor, and one lock. Define the allowed classic-mesh links manually. Then ask the simulator to find a path from the controller to the lock.
The pass condition is not “a route exists.” The pass condition is stricter:
- the route uses only always-listening classic mesh devices as repeaters;
- the route respects the configured classic repeater limit;
- the route does not use a sleeping battery endpoint as a forwarding node;
- the run records which link assumptions were synthetic and require RF validation.
If the path only works because the model allowed an endpoint to repeat while asleep, the model is wrong even if the graph search succeeds.
Run it: Test this controller-to-lock route in the source-routing animation below. Set the Route Request destination to Front lock #62 and run Discover Route to watch the controller build the hop list inside the command frame, checking that only always-listening repeaters carry it. Then compare a Cache hit against a Stale route, and use Clear Cache, to see when the controller trusts a cached path versus rediscovering one — the feasibility evidence this exercise asks you to record.
Exercise 2: Repeater Failure
Start with a passing route. Then remove one modeled repeater or force it to miss acknowledgements.
The simulator should record:
- the original route;
- the failure event;
- the retry or repair trigger;
- the alternate route if one exists;
- the reason for failure if no valid route remains;
- the hardware test that must confirm real route repair behavior.
The lesson is not that Z-Wave always heals instantly. The lesson is that route repair is observable evidence and must be tested with the actual controller and devices before acceptance.
Run it: Start from a working route in the mesh animation below, then break it. Pick a Source node and Destination node, let the route form through the repeaters, then use Fail the selected repeater and watch the Route Evidence show the failure, the repair trigger, and the alternate path — or the reason none remains. Raise the Wall / placement penalty or change the Radio range model to see how a marginal repeater turns a passing route into one that needs real-hardware confirmation, exactly the evidence this drill records.
Exercise 3: Sleeping Endpoint Timing
Model a battery sensor that wakes only during event or maintenance windows. Send an application command or configuration update while it is asleep.
The expected result should be one of these:
- queue the command if the modeled device class and controller policy support that behavior;
- mark the command as waiting for wake-up;
- fail the command if the scenario policy requires immediate delivery.
Do not let the simulator hide wake behavior by treating battery devices as permanently available.
Continue to the Next Part
Carry this evidence into Z-Wave Simulation: Timing and Evidence Analysis, which begins with Exercise 4: Classic Mesh and Long Range Side by Side.