Panels, readers, and door I/O
Readers, lock outputs, door contacts and requests to exit report different information. Track access decisions, relay state and door state separately.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Architecture and semantics only; no live wiring values, key material, credential capture, relay actuation, or door commissioning procedure.
On this page
Overview#
The field controller enforces local access logic and drives/senses door hardware. Reader, lock output, door contact, request to exit (RTE), lock monitor, tamper, power, and emergency inputs are separate channels with distinct meaning.
Typical door topology#
credential <-> reader/peripheral <-> controller/panel
|- lock/output
|- door-position input
|- RTE input
|- lock monitor/tamper
`- emergency/fire interface (approved boundary)
The exact design may use intelligent locks/readers, distributed I/O, wireless gateways, elevator modules, or nested controllers. Inventory which component decides, caches policy, timestamps, and stores events.
Reader channel#
SIA's OSDP page describes bidirectional supervised panel/peripheral communication, Secure Channel, smart card/biometric support, current SIA edition 2.2.2, and OSDP Verified. IEC 60839-11-5:2020 is the international OSDP publication.
For new supported designs prefer OSDP Secure Channel with per deployment key management, device identity/installation process, correct RS485 topology, supervision, and verified interoperability. “OSDP capable” doesn't prove secure mode is enabled, default keys were replaced, or all features interoperate.
Legacy Wiegand/Clock and Data typically transfers identifier bits without modern bidirectional supervision or cryptographic protection. Contain it physically, shorten exposure, monitor tamper, avoid using low assurance identifiers for high risk access, and plan migration. Don't capture or replay live credential traffic.
Door state semantics#
Keep independent:
- access decision and reason;
- lock output command/electrical state;
- lock monitor state if installed;
- door position contact;
- RTE/egress input;
- forced/held/open too long logic;
- passage/occupancy inference;
- tamper, power, battery, bus, and controller health.
Door open while output is secure may be forced, mechanically keyed, emergency released, miswired, or stale; context is required. A “normal” contact can't prove latch engagement.
Timing and failure#
Define unlock duration, door open/held timers, RTE timing, debounce, reader feedback, re lock conditions, and behaviour on controller/bus/power loss using approved system design. Software integrations should request a named high level operation, not toggle a raw relay.
After an ambiguous command timeout, query controller and independent input state before any retry. Bound unlock/relay commands and require site/resource authorisation, reason, audit, and where appropriate dual control.
Power and supervision#
Readers, locks, panels, I/O, batteries, and PoE/DC supplies have different load and outage behaviour. Monitor AC/DC/battery, bus faults, open/short/tamper where supported, enclosure, temperature, and clock. Don't infer electrical supervision from application heartbeats.
All live wiring/termination/contact values and emergency interfaces require exact manuals, approved drawings, qualified personnel, and local code review.
Return to Access control systems.