Zigbee, Thread & Matter · Study deck
Thread Development and Integration
Picture a building team adding window units that report open or closed.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Write a Thread development claim that can be reviewed and tested.
- Identify the evidence needed for router, router-eligible, full end device, and sleepy end device behavior.
- Separate Thread networking evidence from Matter application evidence.
- Review commissioning, dataset custody, and integration handoff without relying on product-specific setup steps.
Major section
Start With the IPv6 Mesh Claim
Fifty units across several rooms must still join the right network, keep their identity, reach the controller, and recover after power loss.
- The developer should begin with one complete path.
- A larger network is ready only when ordinary faults do not change the meaning.
- This simple path does not cover every shared-radio rule.
Major section
Start With the IPv6 Mesh Claim (continued)
A lost or retired unit should lose access, leave a clear record, and be replaceable without copying a shared secret by hand.
- The support guide should tell a new worker how to repeat these steps.
- A worker should not need to compare long hidden codes during a fault.
- Under the Hood explains network roles, addressing, route repair, keys, and constrained internet messages.
- The simple review path is join, address, route, recover, and observe.
Major section
Development Evidence Map
The development evidence map keeps the implementation claim separate from role evidence, Thread evidence, application or Matter boundaries, commissioning, diagnostics, tests, and release decisions.
- A demo might prove one application path but leave role configuration, commissioning custody, diagnostics, or release limits unreviewed.
Major section
Role Configuration Evidence · Thread Stack and Application Boundary
Listening behavior The record explains whether the device must be reachable immediately or can sleep between communication opportunities.
- Role configuration should be reviewed by behavior, not by copied code.
- The key question is whether the device role matches the duty it will perform in the deployment.
- A development review should keep those layers separate.
Major section
Service Discovery Path · Registry Instead of Plain Multicast
That registry model is not a shortcut around validation.
- A controller should not have to broadcast blindly or rely on a hard-coded IPv6 address to find a Thread light, lock, or sensor.
- This name-based discovery path is also important for Matter over Thread.
- The review record should still prove registration, update, removal, and recovery behavior.
Major section
Matter Integration Boundary · Commissioning and Credential Flow Evidence
Matter can run over Thread, but Matter readiness is not the same as Thread readiness.
- A Thread development review should say which layer each item proves.
- Thread layer Attachment, roles, addressing, routes, Border Router service, and mesh diagnostics.
- Service layer Remote access, notifications, analytics, dashboards, cloud handoff, or support tooling.
Major section
Diagnostics and Test Evidence
Diagnostics should answer release questions.
- A long command transcript is weaker than a short record that connects observation to decision.
- Observation What changed during the test or failure, described without assuming the cause too early.
- Good tests include ordinary behavior and at least one boundary behavior.
Major section
Integration Review Record · Review Sequence
The second figure shows how development evidence becomes an integration record.
- One record should cover one release claim.
- If the same device has a sensing path, a control path, and a commissioning repair path, each path may need separate evidence.
Major section
Worked Development Records
Sleepy sensor integration Claim: the sensor can report environmental telemetry through a Thread mesh while preserving low-power behavior.
- Evidence: role configuration shows sleepy attachment, telemetry is accepted by the application, and diagnostics identify the parent and retest trigger.
- Limit: command-response behavior is not included in this approval.
- Limit: remote cloud control is a separate service review.
Major section
Worked Development Records (continued)
Local control endpoint Claim: an actuator can receive local control messages over Thread.
- Evidence: the device stays reachable for the required control path, the application command changes the expected state, and a restart test confirms reattachment.
- Evidence: Thread attachment and Border Router service are reviewed separately from endpoint, cluster, command, and event behavior.
- Limit: certification or ecosystem behavior is not implied by this internal review.
Major section
Common Mistakes
Copying role settings blindly A role that is correct for an always-on device can be wrong for a sleepy sensor or a gateway-like device.
- Confusing Matter and Thread evidence Matter behavior and Thread mesh behavior are both important, but each proves a different layer.
Major section
Key Takeaway · Concept Relationships
Thread Development and Integration Evidence should turn Thread planning into deployment evidence for commissioning, role changes, border routing, diagnostics, repair, and operational ownership.
- Implementation claim Connects device behavior, Thread role, integration boundary, and release owner.
- Role configuration Connects routing responsibility, listening behavior, power assumptions, and repair control.
- Thread evidence Connects attachment, route behavior, Border Router service, and diagnostics.
Deck summary
Key takeaways
Fifty units across several rooms must still join the right network, keep their identity, reach the controller, and recover after power loss.
- A lost or retired unit should lose access, leave a clear record, and be replaceable without copying a shared secret by hand.
- The development evidence map keeps the implementation claim separate from role evidence, Thread evidence, application or Matter boundaries, commissioning, diagnostics, tests, and release decisions.
- Listening behavior The record explains whether the device must be reachable immediately or can sleep between communication opportunities.
- That registry model is not a shortcut around validation.
Retrieval practice
Recall check 1 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q1In Thread development, why treat a device's role (router, child, sleepy child) as evidence to review?
Show answer
Answer: A A Thread role must match the device's power, latency, and routing responsibilities, so role configuration is reviewable evidence.
Retrieval practice
Recall check 2 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q2What does SRP (Service Registration Protocol) let a Thread device do?
Show answer
Answer: A SRP lets a Thread device register its services for DNS-based discovery by other devices.
Retrieval practice
Recall check 3 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q3How does a controller find a specific device, such as a light, on a Thread network?
Show answer
Answer: A Devices register with SRP; controllers resolve names through DNS-SD before communicating over the selected application protocol.
Retrieval practice
Recall check 4 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q4Why does Thread use SRP with a border-router registry instead of plain multicast mDNS for service discovery?
Show answer
Answer: A SRP avoids costly multicast and lets an always-on registry answer discovery queries for sleepy devices.
Retrieval practice
Recall check 5 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q5A device attaches to Thread and sends one successful telemetry message. The team wants to approve Matter control and remote service behavior too. What is the strongest review response?
Show answer
Answer: B Each layer needs evidence that matches its responsibility.
Retrieval practice
Recall check 6 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q6A battery-powered sensor is configured with the same always-on role profile as a powered control device. What should a reviewer ask for?
Show answer
Answer: A Role configuration should be justified by the device behavior and deployment needs, not copied from another device class.
Print reference
Answers 1 of 2
Answer key.
- A · A Thread role must match the device's power, latency, and routing responsibilities, so role configuration is reviewable evidence.
- A · SRP lets a Thread device register its services for DNS-based discovery by other devices.
- A · Devices register with SRP; controllers resolve names through DNS-SD before communicating over the selected application protocol.
- A · SRP avoids costly multicast and lets an always-on registry answer discovery queries for sleepy devices.
- B · Each layer needs evidence that matches its responsibility.
Print reference
Answers 2 of 2
Answer key.
- A · Role configuration should be justified by the device behavior and deployment needs, not copied from another device class.