Zigbee, Thread & Matter · Study deck

Zigbee Network Topologies

A hotel room reports that a window is open.

Radio Remi is your guide for this deck.

zigbeetopologynetwork-roles

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

After studying this chapter

Learning objectives

You will be able to:

Explain: Under the hood, formation evidence becomes stale when the channel environment changes, the coordinator or gateway is replaced, joining authority changes, devices are moved, parents change, or replacement devices enter the network.
Explain: A device may associate and receive network material, but the product still needs to prove the expected report, command, state, or gateway-visible behavior after joining.
Explain: The claim should say which coordinator, site boundary, channel and PAN decision, device set, join method, and application behavior are being approved.
Explain: An unexpected identity changes the decision even if every expected device also joined.

Major section

Start With One Packet Path · Overview: What a Zigbee Topology Claim Means

A hotel room reports that a window is open.

The first route works through a powered room unit and reaches the desk.
During cleaning, that powered unit is unplugged.
A network shape becomes useful only when those roles match what the installed units actually do.

A topology claim should connect the network shape to observed coordinator, router, and end-device roles before it is used as release evidence.

Major section

Practitioner: Build a Topology Evidence Record · Under the Hood: Role Dynamics, Route Drift, and Retest Triggers

A practical topology review starts with a decision claim.

The claim should say what behavior is being approved, where it applies, and what evidence makes it ready.
The record should then separate role evidence from path evidence so a tidy diagram does not hide fragile dependencies.

Scaling approval is bounded to the observed site, roles, paths, workload, latency, and recovery evidence. New zones, parent or router load, weak RF areas, group commands, automation, or support changes require renewed evidence before the larger claim is approved.

Major section

Zigbee Network Formation · Overview: Formation Is the Network's First Evidence Record

A green setup screen is not enough.

Close entry as soon as the planned group is complete.
The first must stay out.
The second must either return through an approved path or leave a clear failure record.
The beginner mistake is to treat formation as a setup screen.

Formation approval should follow one bounded evidence flow: claim, channel and PAN evidence, Trust Center custody, controlled joining, association, key transport, operations owner, and retest trigger.

Major section

Practitioner: Build the Formation and Join Record

A practical formation review starts with a claim that has boundaries.

The claim should say which coordinator, site boundary, channel and PAN decision, device set, join method, and application behavior are being approved.
Everything outside that observed boundary stays out of scope until it is reviewed.
"Joining authority is just a technical default.".

The join evidence record keeps custody, permit-join control, selected parent, key transport, application observation, owner, and retest trigger in one reviewable artifact.

Major section

Practitioner: Build the Formation and Join Record (continued)

An unexpected identity changes the decision even if every expected device also joined.

Intermediate Example A failed sensor is replaced with a new unit that should inherit the same role.
A reviewable decision does not approve the replacement from gateway visibility alone.
"Gateway-visible means all join evidence is complete.".

Major section

Under the Hood: Formation Evidence Can Drift · Summary

Under the hood, formation evidence becomes stale when the channel environment changes, the coordinator or gateway is replaced, joining authority changes, devices are moved, parents change, or replacement devices enter the network.

The review should treat these events as retest triggers instead of assuming the original setup remains valid forever.
The most important separation is between network-side evidence and application-side evidence.
A device may associate and receive network material, but the product still needs to prove the expected report, command, state, or gateway-visible behavior after joining.
Conversely, application visibility should not erase missing custody or parent-selection evidence.

Major section

Zigbee Routing · Rehearse the far-room story

Deepen route-discovery, route repair, source-route, and recovery evidence after topology roles are known.

It measures joining a route, a synthetic reading and path repair; Zigbee security, application profiles and Matter are not simulated.

Deck summary

Key takeaways

A hotel room reports that a window is open.

A practical topology review starts with a decision claim.
A green setup screen is not enough.
A practical formation review starts with a claim that has boundaries.
An unexpected identity changes the decision even if every expected device also joined.

Retrieval practice

Recall check 1 of 6

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

Q1A team says its Zigbee deployment is a resilient mesh because several powered nodes are installed. Which first review response is strongest?

AAsk for coordinator custody, router role evidence, end-device parent records, and observed route alternatives.

BApprove the mesh because the powered-node count suggests there is enough spare forwarding capacity.

CReject the deployment outright, because Zigbee networks only support star topologies centered on the coordinator.

DApprove recovery from a successful online check, since a reachable device has a working route.

Show answer

Answer: A Mesh language needs role, parent, route, ownership, and retest evidence before it supports a resilience claim — with route alternatives observed where resilience is claimed.

Retrieval practice

Recall check 2 of 6

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

Q2A topology record lists every Zigbee device, but it does not show end-device parents, router responsibilities, or what happens when a planned router is unavailable. What is the correct release decision?

ARevise or retest before approving the topology claim because inventory evidence does not prove parent or route behavior.

BApprove the topology because the inventory includes spare devices that could replace a failed router during maintenance.

CTreat the deployment as a star topology, since missing parent evidence means devices must be reporting directly to the coordinator.

DIgnore the router-loss question, because topology evidence is only needed during initial commissioning of the network.

Show answer

Answer: A A device list is useful context, but topology readiness needs role, parent, route, recovery, and owner evidence — recovery behavior is unproved here too.

Retrieval practice

Recall check 3 of 6

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

Q3After a powered Zigbee router is moved, most devices still report, but two end devices now use a different parent and show delayed reports. Which review action is strongest?

ARetest the topology boundary, record the new parent and route evidence, and approve only recovered paths.

BKeep the old topology approval in place, because most devices still appear online after the router move.

CDiscard the earlier topology record and build a new baseline, so reviewers do not rely on outdated parent relationships.

DApprove resilience because the affected end devices found a new parent and resumed reporting after the router move.

Show answer

Answer: A A router move is a topology retest trigger, and the decision should stay tied to observed parent, route, and application behavior — with delayed devices flagged until the fragile dependency is resolved.

Retrieval practice

Recall check 4 of 6

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

Q4A team says a Zigbee network is ready because a coordinator formed a network and one test device joined. Which claim is strongest?

AThe recorded channel and PAN decision, Trust Center custody, and permit-join rule support this boundary.

BThe successful test join proves that any compatible device can safely join the network later.

CThe coordinator should remain open for joining so future devices can connect easily.

DThe selected channel will stay valid permanently, because it carried the test join without interference during setup.

Show answer

Answer: A A formation claim is reviewable when it is bounded by the observed evidence and custody controls — including the association result, key transport, owner, and retest trigger.

Retrieval practice

Recall check 5 of 6

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

Q5A replacement device appears online, but the record does not show who opened joining, which parent accepted it, or whether Trust Center approval followed the deployment rule. What is the correct review decision?

ARevise or retest the join record before release.

BAccept the replacement because the device is visible in the gateway.

CLeave joining open so the record can be completed later.

DAccept association’s parent choice without a separate parent record.

Show answer

Answer: A Replacement readiness requires identity, joining permission, parent selection, Trust Center approval, and application evidence.

Retrieval practice

Recall check 6 of 6

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

Q6Why should a Zigbee formation review keep Trust Center custody, selected parent, and application behavior as separate evidence fields?

ABecause a device can appear online while custody, parent choice, or product behavior remains unproved.

BBecause the Trust Center log can supply the parent and application fields from its record of joining approval.

CBecause parent selection becomes irrelevant once the device has received its network address from association.

DBecause gateway visibility replaces the need for joining logs and Trust Center custody records.

Show answer

Answer: A Formation readiness needs separate evidence for authority, association path, and application outcome — any of them can be unproved or outside the approved boundary while the device looks online.

Print reference

Answers 1 of 2

Answer key.

A · Mesh language needs role, parent, route, ownership, and retest evidence before it supports a resilience claim — with route alternatives observed where resilience is claimed.
A · A device list is useful context, but topology readiness needs role, parent, route, recovery, and owner evidence — recovery behavior is unproved here too.
A · A router move is a topology retest trigger, and the decision should stay tied to observed parent, route, and application behavior — with delayed devices flagged until the fragile dependency is resolved.

Print reference

Answers 2 of 2

Answer key.

A · A formation claim is reviewable when it is bounded by the observed evidence and custody controls — including the association result, key transport, owner, and retest trigger.
A · Replacement readiness requires identity, joining permission, parent selection, Trust Center approval, and application evidence.
A · Formation readiness needs separate evidence for authority, association path, and application outcome — any of them can be unproved or outside the approved boundary while the device looks online.