Z-Wave Simulation: Timing and Evidence Analysis

Start With the Decision

Classic mesh and Long Range may reach the same node by very different paths. Their delay and failure evidence must be compared under one setup.

Route Overview

This is part 2 of 2. Review Z-Wave Simulation: Topology and Failure Experiments for the preceding evidence.

Learning Objectives

• Compare Z-Wave mesh and Long Range timing.
• Analyse association, latency, and injected-failure results.

Chapter Roadmap

• Exercise 4: Classic Mesh and Long Range Side by Side
• Latency, Associations, and Timing Assumptions
• Failure Injection
• Explorer Frame Flood and Retries
• Release Rule
• Quick Check: Explorer Flood
• Evidence Handoff
• Worked Scenario
• Knowledge Check
• Match the Evidence Types
• Order the Simulation Workflow
• Common Mistakes
• Simulation Review Checklist
• References
• Summary
• Key Takeaway
• Concept Relationships
• Try It Yourself
• What’s Next?

Latency, Associations, and Timing Assumptions

Two models pay off immediately. First, model latency by hop count. Each hop adds transmission time, per-node processing, and acknowledgements, so a four-hop path is meaningfully slower than a direct path. Z-Wave data rates are modest compared with Wi-Fi, so the simulation should make hop count and retry cost visible instead of hiding them behind a single “reachable” result.

Keep timing arithmetic honest by making it a model parameter, not a product promise. For a workshop scenario, you might assign 40 ms of modelled time to each transmit-plus-ack step. A direct command then costs one step, a route through two repeaters costs roughly three steps, and a route through four repeaters costs roughly five steps before any retry. Those numbers are not measured Z-Wave latency; they are a visible assumption that lets students compare route shapes.

Now add retries. If the scenario allows 2 retries after a failed acknowledgement, a marginal four-repeater path can consume three attempts before repair starts. The result log should show each attempt, the failing segment, and whether the route finally succeeded, switched to an alternate, or escalated to Explorer Frame discovery. That timeline is more useful than a green “reachable” label because it explains why a command feels slow after a device has moved.

Second, model associations. The Association command class lets one device directly control another, such as a wall switch bound to a lamp module, without a hub round trip for that action. Modelling associations shows why an associated pair can react faster and continue working when the controller is busy or offline.

Associations need the same discipline as route timing. A switch-to-lamp association can be modelled as direct device control only when the scenario states the source device, target device, group, and command being sent. If the lamp also participates in hub-driven scenes, the test should include two assertions: direct association still toggles the lamp when the hub is busy, and the hub scene still records or recovers state according to the controller behavior being modelled.

Hand the timing model to hardware validation. The bench test does not need to reproduce the placeholder milliseconds. It needs to verify that direct, two-repeater, and repaired routes are distinguishable in controller diagnostics or command observations, and that association behavior matches the selected devices rather than the simplified model.

Failure Injection

Failure injection is the most valuable part of a simulation chapter because it turns a drawing into evidence. Inject one fault at a time so the result remains explainable.

Useful faults include:

• Dead repeater: remove a mains-powered routing endpoint and verify that affected routes are recalculated or marked failed.
• Stale route: keep an old path after a repeater moves and verify that failed acknowledgements trigger repair evidence.
• Sleeping endpoint: send configuration while a battery device is asleep and verify wake-up handling.
• Failed inclusion: simulate a device that starts inclusion but never completes interview or security setup.
• Wrong role: mark a battery sensor as a repeater and confirm the scenario rejects that topology.
• Command-class mismatch: include a device whose advertised behavior does not satisfy the automation requirement.
• Regional mismatch placeholder: mark a device as incompatible by region and verify that the model blocks inclusion, while clearly noting that the simulator did not test radio hardware.
• Controller migration: remove the controller identity or route database and verify which evidence must be restored from backup or rebuilt.

For each fault, record three things:

1. What the simulator changed.
2. What assertion failed or passed.
3. What real-device test remains before deployment.

Explorer Frame Flood and Retries

The most instructive thing to simulate is what happens when a route breaks. A Z-Wave transmission is acknowledged with retries, so first model the retry: a lost frame is retransmitted according to the scenario policy, each attempt adds latency, and then the node gives up on that route. When known routes are exhausted, an Explorer Frame can spread outward through the network to discover a new path.

That flood is controlled, but it is still much more expensive than a normal routed message. Neighbours rebroadcast under a hop budget, duplicate suppression keeps repeated frames from expanding forever, and the destination reply lets the network cache a recovered path. A simulation reveals the cost: route repair briefly generates more traffic than a normal command, which is why explorer behavior is a last resort rather than the default.

Use an event log rather than a single final state. A route-repair scenario for Node 21 can start with cached path controller -> 6 -> 12 -> 21. At event 1, remove Node 12 or mark its acknowledgement as failed. At event 2, retry the same route according to policy. At event 3, try an alternate stored path such as controller -> 8 -> 14 -> 21. At event 4, if stored paths fail, launch the explorer-frame search.

The flood model should track duplicate suppression and hop budget. If Node 6 and Node 8 both hear the explorer, each may rebroadcast according to the ruleset. If Node 14 receives duplicates, it should forward only according to the model’s suppression rule. If every discovered candidate exceeds the classic repeater limit, the run should fail with “no valid classic route” instead of inventing a longer path.

Record three counters: normal route attempts, repair transmissions, and accepted path length. A healthy scenario might show 1 normal attempt before failure, 2 retries, 5 explorer-related transmissions, and then a recovered two-repeater route. A weak scenario might show many repair transmissions but no valid route because the only apparent bridge was a sleeping endpoint.

Release Rule

Quick Check: Explorer Flood

Evidence Handoff

Simulation evidence is most useful when it is written for the next reviewer. A good handoff says, “Here is what the model checked, here is what it assumed, and here is what hardware must still prove.”

Inspect Assumptions and Security state in Figure for evidence handoff. Before carrying evidence handoff forward, separate Assumptions from Security state using it. Keep Certification is not created by simulation with the decision.

Read Assumptions with Security state in Figure for evidence handoff. Read its ownership map from the Assumptions responsibility across Security state to Certification is not created by simulation. The hand-off to Certification is not created by simulation needs an assigned owner. That is the review order required by evidence handoff.

The simulation evidence packet should include:

• scenario name and purpose;
• model version or ruleset;
• topology graph and device-role list;
• event script and injected faults;
• pass/fail assertions;
• failed paths, repair attempts, and excluded routes;
• known exclusions and hardware follow-up items.

Bench validation should then check:

• inclusion and exclusion with the actual controller and target devices;
• reported security class and command-class interview completion;
• controller route or health diagnostics after real commands;
• behavior when a real repeater is powered down and restored;
• sleeping-device wake, report, and configuration behavior;
• logs that show failed acknowledgements, retries, or repair actions where available.

Installed validation should then check:

• final physical placement, not a bench layout;
• regional device compatibility;
• route health after every major device is installed;
• critical device behavior after route repair or network heal;
• support records for controller backup, failed-node removal, device replacement, and future retest triggers.

Certification remains separate. A simulator can help prepare a product or installation review, but it does not certify a Z-Wave device, validate RF compliance, or prove that a mixed installation meets certification requirements.

Worked Scenario

A design review needs to decide whether a smart lock near an exterior door has enough classic mesh support. The team has not installed hardware yet, so they build a software scenario.

The scenario model includes:

• one controller in the utility room;
• three mains-powered routing endpoints between the controller and the door;
• one smart lock at the edge;
• two battery contact sensors near the door;
• one optional LR sensor elsewhere on the property.

The first run passes because the lock route uses two mains-powered repeaters. The contact sensors are excluded from route paths. The LR sensor is modeled as direct to the gateway and does not improve the classic route.

The failure run powers down the hallway repeater. The simulator finds one alternate route through a different always-listening device, but that route is marked marginal because it depends on a synthetic link. The result is a conditional pass:

• The topology has at least one alternate software path.
• The model did not prove the alternate path exists in the building.
• Hardware validation must test the lock from final placement, power down the hallway repeater, send real lock commands, and record controller diagnostics.

The review decision is to keep the design as a candidate, not to accept the installation. The simulator reduced the risk before hardware arrived; it did not replace the installation test.

Knowledge Check

Match the Evidence Types

Order the Simulation Workflow

Common Mistakes

Treating the graph as an RF survey. A route edge in software is an assumption until measured or observed with real devices.

Letting sleeping devices repeat. This creates false paths and hides a weak classic mesh.

Mixing classic mesh and LR rules. A Z-Wave Long Range endpoint should not be counted as a classic repeater in a route exercise.

Running only the happy path. A useful simulation includes at least one failed acknowledgement, removed repeater, incomplete interview, or sleeping-device case.

Accepting a device because inclusion was simulated. Real inclusion must verify controller support, device state, security class, command-class interview, and regional compatibility.

Reporting certification from simulation. Simulation can prepare evidence for review, but certification requires the formal process and certified device records.

Simulation Review Checklist

Before accepting a simulation run as design evidence, check that:

• the scenario has a clear question;
• the model separates controller, classic repeater, sleeping endpoint, and LR endpoint roles;
• route limits and retry behavior are explicit;
• each pass/fail condition is written before the run;
• at least one failure was injected;
• result logs identify assumptions and excluded evidence;
• hardware follow-up is specific enough for another person to execute;
• no RF, battery, range, cost, or certification claim is made from software-only output.

References

• Z-Wave Alliance: Z-Wave Long Range Technology
• Z-Wave Alliance: What Is Z-Wave Long Range?
• Silicon Labs: Z-Wave Networking Basics
• Silicon Labs: Z-Wave Fundamentals
• Silicon Labs: Z-Wave Security Whitepaper

Summary

Z-Wave simulation is strongest when it is narrow, explicit, and connected to hardware follow-up. It can test route logic, role classification, failure handling, and evidence quality. It cannot validate RF hardware, certification, regional compliance, installed reliability, or battery behavior. Good simulation records make those limits visible and hand the remaining questions to bench and installed validation.

Key Takeaway

A Z-Wave simulation should test inclusion, routing, device failure, latency, and scene behavior before assumptions reach a real installation.

Concept Relationships

Builds on:

• Z-Wave Overview and Fundamentals: protocol purpose, regional context, and ecosystem position.
• Z-Wave Architecture and Devices: Home ID, Node ID, controller, repeater, sleeping endpoint, and LR topology roles.
• Network Topologies: graph reasoning, route paths, and topology tradeoffs.

Prepares for:

• Z-Wave Routing and Healing: deeper route repair, failed acknowledgements, and diagnostic evidence.
• Z-Wave Network Planning and Acceptance: converting topology evidence into installation choices.
• Hardware acceptance testing with the selected controller, devices, and installed environment.

Compares with:

• Zigbee Fundamentals and Architecture: distributed mesh behavior and coordinator/router roles.
• Thread Network Architecture: IPv6 mesh behavior and border-router responsibilities.

Try It Yourself

Create a five-node scenario with one controller, two mains-powered repeaters, one sleeping sensor, and one critical endpoint. Run three paper or software passes:

1. Baseline route with all repeaters available.
2. One repeater removed.
3. Sleeping sensor incorrectly marked as a repeater.

For each pass, write the route result, the assertion outcome, and the hardware evidence still required. The final answer should not be “works” or “fails”; it should be a short evidence packet that another reviewer can use.

What’s Next?

• Z-Wave Routing and Healing: study route repair behavior in more detail.
• Z-Wave Network Planning and Acceptance: use simulation evidence to plan real device placement and acceptance checks.
• Z-Wave Overview and Fundamentals: revisit protocol context if the simulation assumptions are unclear.

Continue Your Route

This final part closes the route from Exercise 4: Classic Mesh and Long Range Side by Side through What’s Next?. Return to Z-Wave Simulation: Topology and Failure Experiments or continue from the rfid-nfc-uwb module index.