MatterODM by Shenan YangguangWhat software runs inside a Matter sensor
A Matter security sensor runs the open-source Matter SDK — the connectedhomeip project, also referred to as Project CHIP — on top of a real-time operating system such as Zephyr or FreeRTOS, layered over the radio firmware of a standard CSA-certified Matter connectivity module, so the protocol stack and the radio are shared, vendor-neutral building blocks rather than secrets a factory invents. The module carries the radio and the lower protocol layers already certified; the SDK provides the Matter-specific logic; the RTOS schedules it all. What is left for the product is the part that makes a contact a contact and a PIR a PIR.
Understanding this stack matters for a brand because it separates what is shared from what is yours: the connectivity module and the SDK are common to many products, while the cluster behaviour, the reporting cadence and the sleep budget are the factory's work and the real differentiators between two seemingly identical sensors. A relabeller buys the differentiating layer finished; a builder writes it.
The layered SDK: data model and interaction model
The Matter SDK is organised as a layered stack — a data-model layer that implements clusters, attributes, commands and events, and an interaction-model layer that handles reads, writes, invokes and subscriptions — and together these two layers are what make a sensor's "open" or "motion detected" state visible and actionable to any compliant controller. The data model is where the ContactSensor or OccupancySensing cluster lives; the interaction model is how a controller subscribes to it and gets notified on change. Certification tests these layers directly, which is why their correctness is non-negotiable.
The cluster server is the factory's core deliverable
The cluster server — the code that answers "what is your state?" and "report on change" for the product's device type — is the central piece of firmware the factory writes, and its correctness, its debounce behaviour and its reporting discipline are what separate a sensor that a controller trusts from one that spams or stalls. The SDK gives the scaffolding; the factory fills in the behaviour: when a reed switch opens, what attribute changes, after what debounce, and with what confirmation. That is product behaviour, and it is owned by whoever writes the source.
The RTOS and why it decides battery life
A real-time operating system such as Zephyr or FreeRTOS decides how the device sleeps, how fast it wakes to report, and how much RAM and flash the firmware consumes, and for a battery contact or PIR those three numbers set the difference between a sensor that lasts months and one that lasts years. Idle current, wake latency and the firmware's duty cycle are not afterthoughts; they are designed properties. The RTOS, the SDK configuration and the module's own sleep behaviour are tuned as one system by the factory, not left at tool defaults.
None of this is visible on the product, which is exactly why it is where a builder earns its fee: a sensor that silently dies at month nine has a firmware and power architecture problem, and only the manufacturer that owns the source and the line can find and fix it. A brand specifying a battery sensor should ask for the sleep architecture and the measured idle current, not just a "low power" promise.
Low-power scheduling, OTA and the line
Beyond the cluster server, the factory owns the application loop that reads the sensor, the low-power scheduling that decides when the radio wakes, the over-the-air update client that keeps the device secure after shipment, and the line-side provisioning of device-attestation and secure-boot keys that makes each unit trustworthy. Each of these is firmware the factory writes and programs; none is supplied by the module or the SDK as a finished product behaviour. Over-the-air update in particular is how a fielded device is fixed without a recall, and it is a factory duty, not a cloud feature.
Provisioning is a line discipline, not a setting
Device attestation credentials and secure-boot keys are written to each unit during manufacturing, and the integrity of that provisioning — that every device carries its own root of trust and that no unit ships with a duplicated or missing credential — is a factory line discipline, not a software feature a brand can add later. Shenan Yangguang builds and certifies the Matter security hardware we produce and treats provisioning as a measured, end-of-line-verified step. A relabeller inherits whatever the original line did; a builder controls it.
Why firmware architecture shows up in certification
Certification tests behaviour, not source code, but the behaviour under test — attribute reporting, subscription handling, commissioning flow and device attestation — is exactly what the firmware implements, so a cluster implemented wrongly or a device that wakes too slowly to finish commissioning fails the test plan. In other words, the firmware and the certification scope are the same project viewed from two sides: one written, one verified. A factory that owns the firmware can fix a failing test by changing code; a relabeller waits for the original manufacturer.
The practical consequence for a brand is that firmware ownership and certification ownership should travel together: if you want to change how a sensor reports, you need the firmware, and if you have the firmware you can steer the certification. That is the structural reason a build relationship beats a relabel relationship for any security product that will evolve.
What a brand should specify
A brand should specify the firmware behaviours that decide field trust — the cluster and event model, the report and debounce rules, the sleep and wake budget, the OTA policy and the attestation provisioning — and ask the factory how each is implemented and verified, rather than accepting a generic "Matter firmware" label. The questions that separate a builder from a relabeller are the same every time: who owns the source, who characterises the unit, and who verifies the line. Battery-life and wake-latency figures are confirmed per project after evaluation, not promised from a generic spec. If you are scoping a Matter contact, PIR or combined sensor, send us the device type and the reporting behaviour you need; we will show you the SDK stack, the RTOS choice and the verification plan that turn silicon into a trusted report.