By the SNMP Monitoring team · Reviewed July 2026
Most monitoring stops at the electrons and forgets the physical world, but who opened the rack at 2 a.m. is a real signal — for security, for compliance, and for the next-morning "why did this box reboot?" investigation. A door contact and a motion sensor turn physical access into the same kind of pollable, alertable state as a temperature or a leak. Wire them into an SNMP gateway and an opened cabinet or after-hours movement becomes an event your monitoring can catch, timestamp, and correlate with what happened on the servers inside.
This is the how-to. Parent: environmental monitoring. Siblings: water & leak, smoke & fire.
Contact vs motion sensors
Two devices, two questions:
- Door / contact sensor — usually a reed switch: a magnet on the door, a switch on the frame. When the door opens the magnet moves away and the contact changes state. It answers "is this door open?" — binary, precise, per-door.
- Motion sensor — usually PIR (passive infrared), detecting body heat moving through a space. It answers "is something moving in this area?" — broader, not tied to a specific opening.
They complement each other. A contact sensor tells you a specific rack or room door opened; a PIR tells you someone's in the aisle even if they didn't open a monitored door. For a tight audit trail you want contacts on the doors that matter and motion covering the space between them.
How state is exposed in SNMP
Both are dry-contact devices, so the SNMP mechanics match the leak and smoke sensors covered on their siblings. The contact wires into an SNMP environmental gateway, which publishes the state as an integer enum in its vendor MIB under 1.3.6.1.4.1: one value for closed/no-motion, another for open/motion.
| Sensor | Mechanism | State reported |
|---|---|---|
| Door contact | Reed switch + magnet | Enum: closed / open |
| Motion | PIR (infrared) | Enum: no-motion / motion |
As always with dry contacts, the polarity is vendor-specific — whether 1 means open or closed is defined in the vendor MIB, not by convention. Read the MIB to learn the mapping; guessing it inverts your alert. Exact OIDs are vendor-specific, so describe against the MIB and don't invent leaves.
Reading the sensor
Poll the gateway's door object with a GET (vendor placeholder arc):
snmpget -v2c -c <RO_string> <gateway> 1.3.6.1.4.1.<vendor>.sensors.door.1
enterprises.<vendor>.sensors.door.1 = INTEGER: 0
Check the vendor MIB for what 0 means: if it defines 0 = closed(0) and 1 = open(1), this door is shut. A motion sensor reads the same way — a GET returning the enum's no-motion or motion value. Load the MIB so the value resolves to a name like doorClosed instead of a bare integer, and confirm polarity during commissioning by physically opening the door and watching the value flip. <RO_string> and the <vendor> arc are placeholders; keep live community strings out of committed scripts.
Use cases
Where door and motion monitoring earns its keep:
- After-hours access — a door that opens outside business hours, or motion in an unstaffed room, is worth an immediate look. Normal during the day, suspicious at 3 a.m.
- Change correlation — a server rebooted or a config changed at 02:14; the rack door opened at 02:11. Now you know it was hands-on, not a software fault.
- Audit trail — logging every open/close and motion event gives you a timeline for compliance reviews and incident forensics.
- Tailgating / unexpected entry — motion detected without a corresponding badge/door event can flag someone who followed an authorized person in.
The common thread: physical events become data you can search and cross-reference, instead of something you only learn about when hardware is already missing or broken.
Alerting & correlation
The real power is correlation — a door event on its own is informational, but combined with what happened on the servers it becomes evidence:
- Time-based rules: alert on any door-open or motion event outside defined business hours; stay quiet during the day.
- Correlate a door-open with login activity — an SSH session starting minutes after the rack opened is a coherent story; a login with no physical access might be remote and worth different scrutiny.
- Pair the poll with a trap so an after-hours open pages immediately rather than waiting for the next cycle.
- Feed events into your security posture — see security best practices — so physical and logical access are reviewed together.
Route, threshold and de-duplicate through alerts. Because door/motion is lower-severity than leak or fire, tune it to your environment: a busy daytime data hall doesn't need a page every time the door opens, but an unstaffed closet might.
Reference
This is the door/motion how-to. The environmental section of the full sensor index lists related objects at all sensors. Siblings: water & leak, smoke & fire. Definitions at glossary.
Frequently asked questions
Can SNMP monitor a door sensor?
Yes. A door contact — typically a reed switch — wires into an SNMP environmental gateway as a dry contact, and the gateway reports open/closed as an integer enum in its vendor MIB under 1.3.6.1.4.1. You poll or receive a trap from the gateway and alert on the open state per your rules.
How do I alert on after-hours access?
Set time-based rules that fire on any door-open or motion event outside defined business hours while staying quiet during the day, and pair the poll with a trap so the alert is immediate. Correlating the event with login activity makes it far more actionable than a bare "door opened."
What's the difference between a contact and a motion sensor?
A contact sensor (reed switch) detects a specific door opening — binary and per-door. A motion sensor (PIR) detects movement in an area, catching presence even where no monitored door was opened. Contacts give precise per-door events; motion gives broader area coverage. Most setups use both.
Can SNMP build a physical-access audit trail?
Yes. By logging every door open/close and motion event with timestamps, you get a searchable timeline of physical access that supports compliance reviews and incident forensics — especially when correlated with server-side events like reboots, config changes, or logins.
Key takeaways
- Door contacts (reed switch) and motion sensors (PIR) report an integer enum via a vendor gateway MIB under
1.3.6.1.4.1. - Read the vendor MIB for polarity and confirm by opening the door during commissioning — never guess.
- Biggest value is correlation: tie door/motion events to logins, reboots and config changes.
- Alert on after-hours access with a trap for immediacy; keep daytime noise down.
- It's a physical-security overlay — see security best practices and SSH sessions.
- Full index: all sensors; an off-box external check via external monitoring still pages you if a site-wide incident hits.