MatterODM by Shenan Yangguang
Request a Quote
Home › Insights › How a Matter Security Sensor Reports
Matter · Data Model · Smart Home Security

How a Matter Security Sensor Reports: Attributes, Events, Subscriptions and Reporting Cadence

Published 2026-11-01 · 9 min read · By Shenan Yangguang engineering

"It's a Matter sensor, so it just works" is true only at the level of interoperability. Under the hood, a door contact or PIR is a small, carefully designed data source: it reports state, raises events, and decides — with real engineering judgement — how often to talk. If you source or brand security hardware, understanding that data model is the difference between a sensor that feels instant and one that lags, drains batteries, or misses the moment that matters.

Key takeaways

  • An attribute is steady state — the open/closed value of a contact — while an event records that something happened at a moment in time; security sensors rely on both.
  • A subscription lets a controller be pushed a change instantly instead of polling, which is what makes an alarm near-real-time and keeps a battery sensor asleep between events.
  • Reporting cadence — minimum interval, maximum interval and deadband — is the tuning that balances prompt alarms against battery life.
  • The data model (clusters, attributes, events, policy) is a firmware and certification decision owned by the manufacturer that builds the product.
  • Choosing the right clusters and tuning the reporting is factory engineering, not something a relabelled third-party device can be expected to fit to your use case.

Why the data model is a product decision

The Matter data model is the set of clusters, attributes, events and reporting policies a device exposes — and for a security sensor it is a product decision, not an afterthought, because it decides how fast an alarm travels, how long the battery lasts, and what a controller can actually do with the device. Two sensors can both be "Matter certified" and still behave very differently in the field: one pushes a door opening the instant it happens, the other only updates when asked. The certificate proves conformance; it does not prove the model was tuned for security.

Matter organizes behaviour into clusters — reusable definitions of a capability such as a BooleanState for a contact or OccupancySensing for a PIR — and a security sensor is really a curated selection of these clusters with sensible attributes and events attached. The selection and tuning is where a factory earns its keep. Shenan Yangguang designs this model into the firmware of the Matter security sensors we build, using standard CSA-certified connectivity modules and engineering the data model on top of them.

Attributes: the steady state

In Matter, an attribute is a piece of readable or writable state on a device — for a contact sensor the open-or-closed value is an attribute of the BooleanState cluster, and for a PIR the occupied-or-not value is an attribute of the OccupancySensing cluster. Attributes are the facts a controller reads: the door is closed, the battery is at 82 percent, the tamper flag is clear. They describe the present, not the past.

For a security brand the practical point is that attributes alone can be misleading if read carelessly. A polled attribute tells you the current state but may miss a brief change that already settled. That is why a good sensor pairs its attributes with events — the attribute says "now closed," the event says "opened at 02:14 and closed at 02:14." Both have a place.

Events: the moment something happened

An event in Matter is a record a device generates when something occurs that controllers may want to know about — such as a latching change or a tamper — and it carries a timestamp, which is why events matter for security logging and for catching changes a polled attribute would miss. A forced door, a PIR trip during an armed period, a tamper switch pressed: these are events. They are the audit trail a monitoring bridge or a homeowner app uses to answer "what happened, and when."

A sensor that only updates attributes can still be useful, but a security sensor that emits meaningful events is materially more trustworthy. The factory decides which events to generate and how to de-bounce them so a single physical disturbance does not produce a storm of identical records.

Subscriptions: how the alarm becomes instant

A subscription is a controller's standing request to be told when specific attributes or events change, instead of polling the device continuously — and for a security sensor this push model is what makes an alarm near-instant while letting a battery device sleep between changes. Without subscriptions, the controller would have to ask every sensor "anything?" on a loop, burning radio time and battery. With a subscription, the sensor stays asleep until something actually changes, then wakes, sends the change, and goes back to sleep.

This push behaviour is the reason a Matter door contact can feel instantaneous yet still run for years on a coin cell: the device is woken by the event, not by the controller's curiosity. The factory sets up the subscription support correctly in firmware so any compliant controller can subscribe; getting it wrong produces the classic failure of "it works but only after a long delay," which is unacceptable for a security product.

Reporting cadence: the tuning that protects battery life

Reporting cadence is the timing policy — a minimum reporting interval, a maximum reporting interval and a deadband — that decides how often a changing value is actually sent, and it is the main dial that balances prompt alarms against battery life. For a simple contact, the policy is close to "report on change, with a short de-bounce to swallow contact bounce"; for a sensor reporting a continuous or noisy value, the cadence prevents a flood of near-identical reports.

The factory tunes these intervals per product so that an intrusion is reported without delay while the battery budget stays measured in years — the two goals pull against each other, and the right balance is an engineering choice, not a default. Shenan Yangguang tunes reporting cadence per sensor type during development and re-validates it during end-of-line testing, because a cadence that looks fine in the lab can misbehave in a real home with real radio conditions.

Who designs the model, and why it should be the factory

The manufacturer that builds the product designs the data model — the clusters, attributes, events and reporting policy — because it owns the firmware and the certification, and the certification is judged against that model; a brand cannot tune what it does not control. This is the crux of the factory-versus-relabeller distinction. A brand that relabels a third party's finished device inherits whatever model that device happens to have, whether or not it fits the brand's alarm logic or its monitoring bridge.

Shenan Yangguang designs the data model for the Matter security sensors we produce, choosing the clusters a security brand needs and tuning the reporting so behaviour matches what the controller and any monitoring bridge expect — we do not relabel a third party's device and hope its model fits your use case. If you are specifying a sensor line, the useful question to your manufacturer is not "is it Matter" but "what clusters, what events, and what reporting cadence did you design, and how did you validate it." Send us your intended alarm logic and we will specify the model to match.

Frequently asked

What is an attribute in a Matter sensor?

In Matter, an attribute is a piece of readable or writable state on a device — for a contact sensor the open-or-closed value is an attribute of the BooleanState cluster. Attributes are what a controller reads to learn the current state; they are the steady facts, such as 'the door is closed' or 'battery is 82 percent'. The factory sets which attributes a sensor exposes and how accurately they are updated.

What is a Matter event and when is it used?

An event in Matter is a record a device generates when something happens that controllers may want to know about — such as a latching change or a tamper that a merely polled attribute might miss. Events capture the moment something occurred with a timestamp, which is why they matter for security: a door forced open at 02:14 is an event worth logging even if the attribute settles back. A well-designed sensor emits both the attribute state and the meaningful events.

What is a subscription and why does it matter for alarms?

A subscription is a controller's standing request to be told when specific attributes or events change, instead of polling the device continuously. For a security sensor this is what makes an alarm near-instant: the controller is subscribed to the contact and PIR clusters, so an opening or detection is pushed to it the moment it happens. Subscriptions also save battery, because a sleeping sensor is woken only to send a change rather than to answer constant polls.

What is reporting cadence and why tune it?

Reporting cadence is the timing policy — a minimum interval, a maximum interval and a deadband — that decides how often a changing value is actually sent. For a door contact the cadence is simple (report on change, with de-bounce); for a sensor emitting a continuous value the cadence controls traffic and battery life. The factory tunes these intervals per product so alarms are prompt while battery life stays measured in years, not weeks.

Who designs the data model for a white-label sensor?

The manufacturer that builds the product designs the data model — the clusters, attributes, events and reporting policy — because it owns the firmware and the certification, and the certification is judged against that model. Shenan Yangguang designs the data model for the Matter security sensors we produce, choosing the clusters a security brand needs and tuning the reporting so behaviour matches what the controller and any monitoring bridge expect. We do not relabel a third party's device and hope its model fits your use case.

Want a sensor model built for your alarm logic?

Send your intended behaviour — what fires, when, and what the controller or bridge must receive. We specify the clusters, events and reporting cadence and validate them on the line.

Request a Quote