Door Controller Wiring Documentation (Not Code Advice)

What this article is (and what it is not)

Some people have to draw and schedule an access-controlled door, the same way they already draw signal flow and schedule cables. For them, this is a documentation method. It treats the opening as a set of devices with ports and power, and gives each one a place on a diagram and a row on a schedule.

That is the whole job here: capture what a qualified professional specified so the paperwork matches the real door.

If you already document AV systems, none of this is new craft: a door is just another cluster of devices wired back to a hub, and the discipline that makes a good AV signal-flow diagram (port-to-port connections, stable IDs, a derived schedule) is exactly the discipline that makes a door legible to the next tech.

The devices at a door, as things you document

A single opening is a small system. Documented well, each device is one element with two facts attached: which controller port it lands on, and where it gets power.

Nothing more exotic than that.

• Access controller (panel): the hub every other device wires back to. Document its location and model, the ports/inputs you actually use, plus its power feed. A managed controller is also a network host, so it earns a row on the IP schedule.
• Credential reader (card reader, keypad, biometric): document the card reader wiring back to its reader port on the controller. Note the cable type and run, plus its power source.
• Lock hardware (electric strike, maglock, electrified latch): document which controller output drives it and where it gets power. The type and its behavior are specified by the licensed professional; you only record what they chose.
• Door position switch (DPS): document the door position switch wiring back to a monitor input on the controller, plus the cable run. It reports whether the opening is open or closed.
• Request-to-exit (REX) device: document the REX wiring back to its controller input and the device type as specified. REX device documentation records the connection; placement and behavior are the licensed professional's and AHJ's call.
• Power supply (PSU): document which supply and circuit feeds each device, and which devices share a supply. A networked controller may draw PoE from a switch instead of a local PSU.

What you document vs. what the licensed pro decides

Keep the line bright between recording a fact and choosing a spec: you own the columns on the left, and a qualified professional and the AHJ own the column on the right.

Draw a per-door access control wiring diagram

The core artifact is one small access control wiring diagram per opening: the controller in the middle, each device drawn back to the specific port it uses. Draw it port to port. Not box to box. A line from Reader to Controller records an intention. A line from RDR-101 · data to ACP-2 · reader port 1 records a buildable, traceable fact, and it exposes a missing input or a doubled-up port while it is still cheap to fix.

Same method as a signal-flow drawing. So the same tools apply. In a port-aware diagram tool you place the controller as a device. Add the reader, lock, DPS and REX as devices (custom devices if they are not in the library). Then connect each to a real controller port.

See connecting devices and ports and port-to-port documentation for the mechanics, and adding devices and library for building door hardware you reuse across sites.

1. Identify the opening and give it a door ID that matches the floor plan (Door 101, not "front door").
2. List every device on that opening: controller (or the shared controller and its port), reader, lock hardware, DPS, REX, and the power supply feeding them.
3. Draw each device back to its controller port, port to port, the way you would a signal-flow diagram.
4. Label every cable with an ID and what it carries (reader data, lock power, DPS contact, REX contact).
5. Add one row per opening to the door schedule and copy the controller, reader, lock, DPS, REX, and power facts into it.
6. For a networked controller, add its IP/VLAN row to the IP schedule and note its PoE or PSU source in the power documentation.

The door schedule: one row per opening

Wiring for one door is what the diagram shows; the door schedule indexes every door at once: one row per opening, columns for door ID and location, controller and port, reader, lock hardware, DPS, REX, and power source, plus the fields a qualified professional specifies.

Service techs scan the schedule first; it is the fastest way to see that opening 114 never got its power source recorded.

You do not have to invent the columns. There is a free door-schedule CSV on the templates page with exactly these fields, so you can start filling instead of formatting.

Keep the schedule and the diagrams in sync: every device on a diagram is a fact in the row, and every row points at a drawn opening.

Naming doors and devices so the diagram and schedule agree

Naming keeps the drawing and the schedule and the physical label on the cable all pointing at the same thing, so give each opening a stable door ID that matches the floor plan, then name each device by its door and role so anyone can read an ID and know where to stand.

• Opening: Door 101, keyed to the architectural door number, never a nickname that changes with tenants.
• Devices: role plus door number, RDR-101 (reader), LCK-101 (lock), DPS-101, REX-101, feeding back to a controller port like ACP-2 · port 4.
• Cables: a unique, permanent ID printed on both ends, matching the diagram and the schedule row.

Document power and the network for every door

Half of access-control troubleshooting is really a power question, so document power as deliberately as you document data: for every door device record which supply and circuit feeds it and which devices share that supply, so a single dead PSU maps instantly to the openings it takes down.

Networked controllers often draw PoE from a switch instead of a local supply, and when they do, that draw is part of your switch budget like any other powered device. Account for it in your PoE budget instead of discovering it when the switch trips its power limit.

A managed controller is a network host. Full stop. Give it a row on your IP schedule: an address, a VLAN, the switch port it lands on. Document that row next to your AV and control devices rather than in a separate silo nobody updates.

That way the access-control panel shows up when someone traces the network instead of surfacing as a mystery MAC on the switch.

Frequently asked questions

Is this a guide to wiring a door for code?

No. It is a documentation method: how to draw and schedule an access-controlled door so the paperwork matches reality. Hardware selection, egress, fail-safe versus fail-secure operation, fire-alarm interface, and all code compliance are the licensed installer's and the AHJ's decisions. Use this to record what they specify.

How do I document fail-safe versus fail-secure?

Record it as a single field on the door schedule, using the value your licensed installer or AHJ specifies for that opening. This article does not tell you which to use or when; it only gives the value a consistent home so the documentation is complete and unambiguous.

What is the difference between the per-door diagram and the door schedule?

One opening's devices wire back to the controller, port to port; that is what the diagram shows. The schedule is the tabular index, one row per opening across the whole site. Same underlying data, two views, exactly like a signal-flow diagram and its cable schedule.

Do networked door controllers belong on my IP schedule?

Yes. A managed access controller is a network host, so it gets an IP schedule row: address, VLAN, switch port. Add a note of whether it is powered by PoE or a local supply. Documenting it beside your AV devices keeps one source of truth for the network.

Can I document access-control doors in an AV diagramming tool?

Yes. An opening is just devices with ports wired back to a controller. That is what a port-aware diagram tool already models: place custom devices, connect them port to port, then derive a schedule from the drawing. The craft transfers directly from AV and network documentation.

Build this diagram in WireFlow

Port-aware devices, validated connections, and exports your crew can read on site. Free plan includes three editable diagrams, no credit card.

Start a free diagram · Explore the sample show first