In homes with both a smart lock and a contact sensor on the same door, two devices report the state of one object, and they regularly disagree. The sensor says open while the lock says closed. The automation built on the sensor fires while the automation built on the lock waits. Neither device is broken. They are measuring different things, and the discrepancy is where both security gaps and phantom automations are born.
What each device actually measures
A contact sensor measures two magnets: reed switch closed means the two halves are within a few centimeters, nothing more. A smart lock reports the state of its own mechanism: bolt extended, bolt retracted, motor busy, jam detected. A door can be closed but unlocked, locked but ajar by a millimeter the magnet still tolerates, or shut hard with the bolt thrown and the sensor reading fine. Every disagreement between the two is a real physical state that a single-source model cannot represent. The first step to sanity is accepting that the two readings are not redundant. They are orthogonal.
The classic failure: lock while open
The dangerous state is the one each device hides from the other. The lock can throw its bolt with the door resting on the strike lip and not fully latched: the lock reports secured, the door drifts open an hour later, the sensor, if anyone looks, reports open to a system configured as "armed." The reverse is the annoyance: the door is firmly closed and locked, but the sensor's magnet alignment drifted with seasonal swelling, so the app shows a door that never closed, and the "turn off the hallway light when the door closes" automation never runs. One is a security event; the other is a support ticket. Both come from trusting a single sensor as ground truth.
Automations need a defined rule for disagreement
The platforms that handle this well expose both states and force the automation author to choose a policy. Sensor open takes precedence, because an open door invalidates every lock state. Lock event used as the trigger and sensor used as the condition, so "goodnight" runs the lock only if the sensor says closed, and warns instead of acting when they disagree. What does not work is treating the two as interchangeable: two automations, each triggered by one device, will eventually run in the wrong order and lock a door that is ajar or close a scene on a door the lock never saw. The design work happens once, in the automation definition, and it pays off every night after.
Installation is where the disagreement starts
Most sensor-versus-lock discrepancies are physical, not logical. The sensor's gap tolerance, typically a centimeter or so, shrinks with weather, hinge wear, and a strike plate that was moved once. On doors where the lock is a motorized deadbolt, the bolt's travel can physically move the frame slightly, enough to toggle a marginally aligned sensor. The install fix is boring and effective: mount the sensor with the actual lock operating, watch the readings through several lock cycles, and shim until the sensor's state is stable across the bolt's full travel. A five-minute alignment check at installation prevents the intermittent phantom that otherwise takes months to diagnose.
What this means for a fleet or a product line
For an installer, the two devices should be commissioned together, as one door, with a recorded alignment check, because the pairing of states is what the customer actually experiences. For a manufacturer, the opportunity is explicit: a lock that exposes bolt state, jam state, and door position as separate signals, and a sensor whose gap tolerance is documented in millimeters rather than implied. Products that publish both signals let the platform above them build the arbitration logic. Products that report a single derived "door secure" boolean hide exactly the information the discrepancy logic needs.
What to ask the supplier
The useful questions are few and concrete. Does the lock report bolt state and door position as separate signals, or one derived status. What is the contact sensor's rated gap tolerance, in millimeters, and how is it specified across the family. Can the platform above them express conditions across both devices in one automation. And is there a commissioning procedure that verifies alignment under real lock operation. Vendors who answer those have built doors, not just devices.
In our sensor and alarm range on the store, the gap tolerance of each contact sensor model is part of the model listing, and the same door can carry sensor and lock from one commissioning flow. On the B2B side, a contact sensor built for a distribution brand is specified with its gap tolerance and its signal model in the requirements document, because the arbitration logic above it can only be as good as the signals it receives.
Both the consumer line and the specification details behind the state model are covered across XingLiao, and door questions for a specific deployment can go straight to our contact page before the order, which is the cheapest possible time to ask them.
Top comments (0)