MatterODM by Shenan YangguangWhat a Matter door lock actually is
A Matter door lock is a device type defined in the Matter specification that represents a lockable door or similar barrier and exposes a standard set of clusters so any Matter controller can lock, unlock and read its state without a proprietary app or cloud account. The device type is the whole point: a lock from one brand becomes controllable from a controller made by another, which is the core Matter promise applied to the device that physically guards an entry. For a security brand this is the difference between "our lock only works in our app" and "our lock works in every Matter home". We treat the lock device type as a first-class product line, not as a sensor with a motor bolted on, because the behaviour and the certification expectations are genuinely different.
Why a lock is a harder certification than a sensor
A lock carries more test attention than a simple sensor because it is a safety-relevant mechanical device, so certification examines lock and bolt state behaviour, user-code handling, failure modes and the security of remote unlock, making the test plan and the firmware discipline heavier than for a contact or PIR. A contact sensor can fail safe by simply reporting "open"; a lock that fails must fail in a known, safe direction and must never silently report "locked" when it is not. The connectivity portion — pairing, attestation, commissioning — rides on a standard CSA-certified Matter connectivity module we integrate, so the radio certification is not the brand's burden, but the lock behaviour itself is scrutinised. We plan the certification programme around the lock clusters from the first schematic, because retrofitting correct lock-state reporting into firmware late is expensive.
The clusters a brand should know
The Matter door-lock device type centres on the Door Lock cluster, which carries commands such as LockDoor and UnlockDoor and attributes for lock state, bolt state and operating mode, and it is commonly paired with supporting clusters for user codes, keypad input and door-position reporting. The exact cluster set a product exposes should be chosen deliberately: a deadbolt retrofit needs different attributes than a latch or a gate, and a brand that wants audit-friendly access logs will care about which user-code and credential attributes it surfaces. Our job in the design phase is to map the brand's feature list onto the cluster set the controllers will actually understand, and to flag the features Matter does not standardise so the brand knows what must live in its own app rather than in the Matter layer.
Battery and the mechanical actuation
Battery life in a smart lock is dominated by the mechanical actuation — the motor current and how often the bolt moves — rather than by the radio, so the lock mechanism choice drives the battery budget more than the connectivity module does. A gear-motor deadbolt, a solenoid latch and a retrofit ring each have a different energy signature, and the firmware's decision about when to re-check or auto-relock matters as much as the cell chemistry. A brand should confirm a realistic battery figure per design rather than quoting a generic number, because the dominant load is the moving metal, not the wireless link — and that is a mechanical-engineering question first.
Local control is the security argument
A Matter lock is designed for local control, so the lock and unlock action happens on the local network through the Matter controller and does not depend on an internet connection or a cloud account to function; a white-label app and cloud stack may add remote access and notifications, but the local lock action is independent of it. For a security brand this is the headline: a door that will not unlock because a server is down is a liability, and a lock that forwards every entry event to a cloud by default is a privacy question. With Matter the local path is primary and the cloud is optional, which lets a brand offer remote convenience without making the lock hostage to a connection. We scope the white-label app and cloud stack as an add-on layer, never as the thing the lock depends on to do its job.
Where a lock fits in a security system
Because Matter exposes a standard lock state, a Matter controller can use a lock's locked or unlocked event to arm or disarm a security scene locally, and the lock can sit alongside door-contact and PIR sensors as another input to the same automation. A door that unlocks at the recognised user can quietly disarm the perimeter; a door forced open against the lock can trigger the same alert a contact sensor would. The degree of integration depends on what the controller and the brand's app choose to expose, but the raw capability — lock state as a security input — is native to the spec. This is why a lock is not a standalone gadget for a security brand; it is a node in the same fabric as the sensors, and the value compounds when they share one controller.
Factory stance: what we build, what the brand owns
Shenan Yangguang designs, prototypes, validates and mass-produces these locks; we do not relabel a third party's product. We own the mechanical design, the electronics, the firmware for the lock clusters, the integration of a standard CSA-certified Matter connectivity module, and the certification programme through to the certificate. The brand owns the user-facing identity, the app experience built on the white-label app and cloud stack, and the go-to-market. We confirm the cluster set, the battery budget and the rated environmental figures per project rather than quoting a generic lock, and where a requested feature sits outside what Matter standardises, we say so and propose where it should live. A lock is the device a customer trusts with their front door — we treat the build and the certification with the weight that trust deserves.
For the sensor side of the same door, our contact-sensor design note explains how the magnetic half reports open and closed, and our device-type and cluster guide maps out the broader Matter security set.