Zigbee, Thread & Matter · Study deck
Matter SDK Setup
Imagine building a smart light that should work with more than one controller.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Review a Matter SDK choice without overclaiming platform or vendor support.
- Separate product requirements, SDK fit, toolchain reproducibility, hardware readiness, and lab infrastructure.
- Identify when a sample application is only a reference baseline rather than approved product evidence.
- Specify development environment records that survive workstation changes, SDK upgrades, and CI migration.
Major section
Start With the Device Experience · Matter SDK and Development Environment Evidence · In 60 Seconds
A clean repeat is more useful than a lucky first build.
- The software kit must build the same device behavior on every developer machine.
- A software development kit (SDK) is a set of code and tools for building that product.
- A missing hidden step should fail the review.
Major section
SDK Setup Review Claim · SDK Environment Evidence Map · Implementation Evidence Route
The claim is intentionally bounded.
- It says the environment is controlled enough to begin or continue reviewed implementation work.
- The first figure shows how a development environment moves from product intent to a bounded implementation baseline.
- Product scope should lead SDK and lab decisions, not the other way around.
Major section
Evidence Families · Product Scope Before SDK Choice · SDK Fit Evidence
SDK selection should begin with the product claim.
- A reviewer should ask what the environment must support before comparing SDK names.
- If those answers are missing, SDK selection becomes guesswork.
- SDK fit is a bounded decision.
- The approval should name the exact SDK baseline and the product scope it supports.
Major section
Common Stack and Platform Port · Reproducible Toolchain Evidence
Matter development commonly starts from the open-source connectedhomeip SDK, also known as the CHIP project.
- That common stack provides Matter protocol code, example applications, and tools such as chip-tool, but it is not the whole environment for a product.
- Real hardware needs a silicon-vendor platform port.
- A review that names only "the Matter SDK" has not yet named the silicon boundary that will carry the product.
Major section
Silicon, Toolchain, and Commissioning Infrastructure · SDK Selection Boundary Check
Product scope should drive silicon choice before detailed SDK configuration.
- A Thread device needs an IEEE 802.15.4 radio and a border-router test path.
- A Wi-Fi device needs Wi-Fi credential handling, access-network assumptions, and local reachability evidence.
- Commissioning infrastructure is part of the SDK environment.
Major section
Hardware and Network Lab Evidence · Sample-to-Product Boundary
The lab record should make it possible to reproduce a failure.
- The lab should match the transport and commissioning claims.
- A Thread device, Wi-Fi device, Ethernet device, bridge, and controller-like product do not need identical lab records.
- Product delta.: Record every meaningful change: endpoint model, clusters, storage, credentials, power behavior, diagnostics, update path, and manufacturing assumptions.
Try it: Hardware and Network Lab Evidence · Sample-to-Product Boundary in the chapter
Major section
Build, Flash, and Debug Evidence · Commissioning Infrastructure
An approved environment should produce traceable artifacts.
- The goal is not to make the chapter a command reference.
- The goal is to prove that build output is connected to the device behavior being reviewed.
- SDK setup is not complete if the team cannot commission and operate the device in the lab.
Major section
Version Control and CI Evidence · Security and Provisioning Boundaries
Environment evidence should not live only on one workstation.
- A project needs enough version control and CI evidence to detect drift.
- Source control: SDK baseline, application source, patches, generated files, and configuration are tracked or intentionally excluded with a reason.
- CI does not replace hardware testing, commissioning, or certification.
Major section
Attestation and Factory-Data Boundary · Worked Review Records · Record 1: Thread Sensor Baseline
A real Matter product needs device attestation and factory data.
- Development often uses test DACs, test passcodes, and a lab attestation root so engineers can commission prototypes freely.
- A device that commissions on a bench with test credentials still needs production credential provisioning, secret-handling rules, reset behavior, and retest evidence before a field or certification claim is safe.
- Production approval needs per-device DAC and key custody, setup payload policy, secure storage, manufacturing provenance, reset behavior, and a retest trigger for any SDK, platform-port, or provisioning-pipeline change.
Major section
Record 2: Sample Light Adaptation · Record 3: SDK Upgrade Hold
Scenario:: A sample lighting application is adapted into a product prototype.
- Evidence found:: The team records the original sample baseline, endpoint and cluster changes, persistent storage changes, build artifact hash, commissioning smoke check, and known warnings.
- The controller UI screenshot is retained only as supporting context.
- The previous baseline remains reproducible.
Major section
SDK Setup Review Record · Release Checklist
The second figure shows the minimum record needed before treating an SDK environment as an approved implementation baseline.
- Baseline: The SDK release or commit, silicon target, board support, examples, patches, and owner are recorded.
- Reproducibility: Toolchain versions, dependencies, build options, setup scripts, and artifact hashes can be recreated.
Major section
Key Takeaway · Concept Relationships
Matter SDK and Development Environment Evidence should leave deployment evidence for SDK setup, commissioning, clusters, interoperability, certification checks, failure recovery, and tested platforms.
- Matter Device Commissioning Evidence reviews the onboarding evidence that the SDK environment should be able to produce.
- Matter Implementation Evidence connects environment readiness to firmware behavior, endpoint implementation, and release decisions.
- Matter Testing and Certification Evidence explains how implementation evidence is prepared for interoperability and certification work.
Deck summary
Key takeaways
A clean repeat is more useful than a lucky first build.
- The claim is intentionally bounded.
- SDK selection should begin with the product claim.
- Matter development commonly starts from the open-source connectedhomeip SDK, also known as the CHIP project.
- Product scope should drive silicon choice before detailed SDK configuration.
Retrieval practice
Recall check 1 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q1A sample Matter light app builds on a development board. Why is that not enough to approve the SDK for product work?
Show answer
Answer: A SDK selection is a fit decision needing evidence linking silicon, transport, toolchain, and product scope, not just a sample build.
Retrieval practice
Recall check 2 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q2What must a Matter SDK setup name beyond the common connectedhomeip stack?
Show answer
Answer: A A Matter product environment combines the common connectedhomeip stack with the silicon-vendor platform port, board support, radios, secure storage, and toolchain for the target chip.
Retrieval practice
Recall check 3 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q3Why should silicon selection precede detailed SDK configuration for a Matter product?
Show answer
Answer: A Transport, power, memory, security, debug, and lab needs drive silicon choice; the platform port, build configuration, and commissioning infrastructure follow.
Retrieval practice
Recall check 4 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q4A team chooses a Matter SDK because a sample light app builds on a development board. What should the reviewer require before approving the SDK setup for product work?
Show answer
Answer: B A sample build proves that one example can compile under some conditions.
Retrieval practice
Recall check 5 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q5Why does a successful Matter lab commissioning run with test credentials not prove field trust?
Show answer
Answer: A Lab commissioning with test credentials is not production trust; field approval needs per-device DACs, protected private keys, factory data, secure storage, and retest triggers.
Retrieval practice
Recall check 6 of 6
Radio Remi says: answer from memory, then check your reasoning.
Q6A Matter prototype builds in CI and commissions in one lab, but the SDK baseline, local patches, and controller version are not recorded. What is the strongest approval decision?
Show answer
Answer: B Environment approval requires reproducibility.
Print reference
Answers 1 of 2
Answer key.
- A · SDK selection is a fit decision needing evidence linking silicon, transport, toolchain, and product scope, not just a sample build.
- A · A Matter product environment combines the common connectedhomeip stack with the silicon-vendor platform port, board support, radios, secure storage, and toolchain for the target chip.
- A · Transport, power, memory, security, debug, and lab needs drive silicon choice; the platform port, build configuration, and commissioning infrastructure follow.
- B · A sample build proves that one example can compile under some conditions.
Print reference
Answers 2 of 2
Answer key.
- A · Lab commissioning with test credentials is not production trust; field approval needs per-device DACs, protected private keys, factory data, secure storage, and retest triggers.
- B · Environment approval requires reproducibility.