MatterODM by Shenan YangguangOne home versus a deployment program
A Matter fabric is a single, secure shared network of Matter devices, controllers and the commissioning credentials that bind them, and it matters for multi-unit deployment because each logically separate site is normally its own fabric with its own controllers. A homeowner commissions a few sensors into one fabric and forgets about it. A property manager with fifty units is administering fifty fabrics plus an oversight layer, and that administration model has to be designed, not discovered on move-in day. The sensors are identical; the program around them is completely different, and it is the part most brands underestimate when they move from retail boxes to a rollout.
Multi-admin: one device, two trusted parties
Matter multi-admin lets a single device be commissioned into more than one fabric at the same time, so the same contact or PIR can appear in a property manager's monitoring fabric and a resident's own smart-home app without either side owning the other. This is the feature that makes a shared building deployment compatible with residents bringing their own ecosystems instead of being forced onto one app. We design the device and the provisioning so that joining a manager's fabric never removes the resident's own control — the resident stays the primary administrator of their unit, and the manager holds a secondary fabric for oversight. That separation is what keeps a rollout from feeling like surveillance to the people living there.
Why this beats a single shared account
A single shared account spanning every unit is brittle and privacy-hostile, whereas per-unit fabrics with their own administrators let each resident keep control of their own space while a manager joins only the devices it is entitled to monitor. When a resident leaves, their fabric is theirs to reset; the manager's oversight fabric can be updated independently. The design question is not "how do we control everything from one login" but "how many fabrics do we need and who administers each" — and the answer drives the commissioning plan from the first unit.
Onboarding many units without one master account
Each unit is commissioned as its own fabric using its own setup code and its own administrator, so no single account has to span every door in the building; multi-admin then lets a managing party join specific devices into a separate oversight fabric without removing them from the resident's control. The setup-code-to-device binding is a factory responsibility — every unit ships with a unique setup code and a unique attestation credential baked in during production. At scale, that provisioning discipline is what prevents a box of identical sensors from becoming a tangle of unidentifiable devices. We treat the unique-per-device credential as a line process, not a paperwork step, because a rollout of hundreds of units has no time for manual matching.
Batch commissioning tooling
Batch commissioning is the set of tools and procedures that let a technician bring many devices and many units online efficiently, normally by scanning setup codes and assigning devices to the correct fabric per a deployment plan. A brand or installer rolling out a building should ask early whether the supplier supports this, because commissioning one sensor at a time does not scale to a floor of apartments. The wireless link itself rides on a standard CSA-certified Matter connectivity module we integrate, but the commissioning workflow is the operational layer that decides whether a rollout takes a weekend or a month.
Local control is the security feature
Matter is designed so local control and automations run inside the home or unit network, so a door opening can trigger a local siren or notification without the cloud being available; the internet is needed mainly for remote access from outside. For a security deployment this local-first behaviour is the part that keeps alerts working during an outage, which is exactly when they matter most. We design around on-premises control and bindings rather than cloud-only logic, and we are candid that a purely cloud-dependent alarm is the wrong architecture for security. The brand's app and white-label cloud stack remain useful for remote access and history, but the alert path should not depend on a data centre being reachable.
Compliance does not disappear at scale
Every unit in a rollout still carries the same market-access obligations — CE, FCC, UKCA, RoHS and the relevant security and radio marks — because certification travels with the device, not with the building. A deployment across the EU and UK also inherits GPSR, WEEE and battery-regulation duties, and the honest split between factory and brand that applies to a single product applies to ten thousand of them. We supply the certified hardware and the documentation; the brand or installer handles the per-market placement and the waste and registration duties at scale. The marks do not change because the volume is higher — if anything, the paper trail matters more.
Factory stance: we build for the program, not just the product
Shenan Yangguang designs, prototypes, validates and mass-produces these sensors; we are the factory, and for a deployment we engineer the device to be manageable at scale, not merely to work on a bench. That means unique-per-device setup codes and attestation provisioned on the line, support for multi-admin, and documentation a rollout team can actually use. We do not relabel a third party's product and present it as our own program. Where a deployment needs a specific commissioning or oversight model we have not built for, we say so and propose the work rather than nodding along — because a rollout that discovers its administration model too late is an expensive mistake. The right time to design the fabric is in the RFQ, not after the pallets arrive.
For the underlying mechanics, see our notes on onboarding and multi-admin and local automations, and for the compliance side the EU/US channel and compliance guide.