MatterODM by Shenan YangguangWhat a "combined sensor" means in Matter
A combined Matter sensor — commonly called a multi-sensor — is a single physical device that exposes more than one Matter device type or endpoint, such as a door/window contact, a PIR occupancy sensor and an ambient temperature sensor, each presented to controllers as its own logical device inside one enclosure. The important point is that "combined" is not a software trick layered on top of one device type. The product genuinely contains several Matter endpoints, and each endpoint is addressable, subscribable and certifiable in its own right. A controller that supports the OccupancySensing device type sees a motion sensor; one that supports ContactSensor sees a door sensor; both can live in the same physical unit and report to the same automation.
One enclosure, several endpoints
The reason this works is Matter's endpoint model. A node — the physical device — can host multiple endpoints, and each endpoint maps to a device type and a set of clusters. A combined sensor uses that model to pack functions that would otherwise be three SKUs into one box.
How the endpoint model is laid out
In a combined sensor, endpoint 1 might be the ContactSensor device type, endpoint 2 the OccupancySensing device type, and endpoint 3 a temperature sensor, each carrying the clusters that device type requires plus the shared management clusters every Matter node exposes. The connectivity module — a standard CSA-certified Matter connectivity module — handles the radio and the Matter stack; the application firmware maps each physical transducer (reed switch, pyroelectric element, thermistor) to the correct endpoint and cluster. Getting that mapping right is the core of the design work, and it is where a factory earns its fee.
Which clusters a combined sensor normally carries
A combined sensor typically carries, per endpoint, the functional clusters of its device type — ContactSensor (over a BooleanState foundation), OccupancySensing, and TemperatureMeasurement — plus the clusters every certified node must support: Basic Information (which also carries the Device Attestation Certificate), Identify, PowerSource and the OTA Software Update cluster. The cluster set is the real behaviour contract: a controller decides what a device can do by reading its clusters, so the clusters a combined sensor claims are exactly what it must be tested against. Over-claiming a cluster the firmware does not fully implement is the fastest way to fail certification or, worse, to ship a device that misbehaves inside a real ecosystem.
Why brands ask for a combined sensor
The appeal is concrete, not cosmetic. One housing means one mount instead of three, one battery budget instead of three, one setup code instead of three, and a cleaner install for both the professional channel and the homeowner. For a brand, fewer SKUs also means simpler inventory and a tidier catalogue. For a security line specifically, a contact plus a PIR in one unit is a natural intrusion-detection pair: the door opening and the room motion both report from the same physical location, which simplifies placement and reduces the "which sensor is which" confusion that plagues multi-device installs.
Certification scope for a combined device
In Matter, a combined sensor is certified as a composed device — one certification programme that covers every endpoint the product exposes, so the certificate, the PICS (the conformance self-declaration) and the test plan must list each device type and cluster the product claims. This is the part brands underestimate. A single-function sensor has a small, well-bounded test surface. Add a second and third device type and the test surface grows, because each device type brings its own conformance requirements — its own mandatory clusters, its own behaviour the authorized test lab must exercise. None of this is a reason to avoid the form factor; it is a reason to scope the programme deliberately.
A combined sensor is also distinct from a bridge. A bridge makes non-Matter devices appear as Matter devices and carries its own certification footprint; a combined sensor is native Matter, with every endpoint a real Matter device type on a standard CSA-certified module, so the two are tested under different scopes even though both "look like several devices" to the user. Conflating them in a specification leads to the wrong test plan and the wrong cost estimate.
The BOM and engineering trade-offs
The good news on cost is that one radio module, one MCU and one battery can serve all endpoints, so the per-unit BOM does not scale linearly with the number of functions. The harder news is firmware and power: the application must arbitrate several sensors, manage sleep across them, and keep each endpoint's state coherent, while the shared battery must survive the busiest sensor's duty cycle. The connectivity module you choose sets the flash and RAM headroom for the whole endpoint set, so the module decision — and the standard CSA-certified module's resource budget — is made before the first line of application firmware, not after. A factory that designs the board and the firmware together is in a position to keep that budget honest; one that is assembling a reference design around someone else's module is not.
Factory stance: we design and certify the whole device
Shenan Yangguang designs, prototypes, validates and mass-produces Matter security hardware. We hold and support the certification programmes for the products we build, and we do not relabel a third party's product. For a combined sensor we own the schematic, the firmware state machine across every endpoint, the enclosure, the tooling and the certification as one programme. We tell the brand which clusters are in scope before testing, build the PICS and test plan around the real firmware, and run the endpoints through an end-of-line commissioning check so the unit that ships is the unit that was certified. If a function is not ready to be claimed, we leave it out of the certificate rather than promising a capability the product cannot demonstrate. For the device-type and cluster selection that underpins this, see our security device-type and cluster guide; for how a gateway handles multiple endpoints, our composed-device gateway note covers the larger enclosure case.