Paxton Net2 is the dominant access control system in the UK commercial market — used in offices, schools, healthcare and light industrial facilities. Integration with KNX building automation allows door access events to trigger lighting scenes, HVAC occupancy modes, and energy management actions. This guide covers the ACU relay output wiring to KNX binary inputs, ETS6 event mapping, emergency unlock via KNX relay output, and the newer Paxton10 IP-based controller.

Paxton Net2 system architecture

Net2 consists of: (1) Net2 Pro server software (Windows PC/server, SQL Server database, manages all access events, cardholders, time zones, doors — typically installed on office server rack). (2) Net2 Plus ACU (Access Control Unit) — DIN-rail controller, RS-485 daisy chain from server (up to 500 ACUs per server at 115200 baud). (3) Proximity readers (RFID 125kHz EM4100 or Mifare 13.56MHz) connected to each ACU via Wiegand interface (D0/D1 twisted pair). (4) Door hardware: electric strike (fail-secure 12V/24V DC) or magnetic lock (fail-open) connected to ACU lock relay output. Each ACU controls 1 door (2-reader in/out configuration). RS-485 wiring: daisy-chain from server RS-485 port (USB-RS485 adapter or serial card), max 1200m total cable, 120Ω termination at furthest ACU.

ACU auxiliary relay output to KNX binary input

Each Paxton Net2 Plus ACU has 2 auxiliary relay outputs (normally open, change-over contacts, 2A/30V DC or 1A/125V AC) in addition to the door lock relay. These auxiliary relays can be configured in Net2 Pro to activate on access events: (1) Door granted → relay 1 closes for configurable pulse time (0.5–30 seconds). (2) Door denied → relay 2 closes briefly. (3) Door forced open → relay 1 latches. (4) Door held open → relay 2 latches. Wiring to KNX: ACU aux relay 1 (NO and COM terminals) → MDT/ABB 2-channel KNX binary input module (terminal IN1 and GND). When relay closes, binary input detects a voltage-free contact closure (dry contact input) and sends a KNX telegram (DPT 1.001, value 1) to linked group address. Cable: standard 2-core 0.5mm² from ACU to nearest KNX binary input module — max 100m for dry contact signal.

ETS6 group address mapping for automation

KNX group addresses for access events — functional 3-level structure: Main 13 = Access Control. Example GA table: 13/1/0 = Reception Door Granted (DPT 1.001), 13/1/1 = Reception Door Denied, 13/1/2 = Server Room Door Granted, 13/1/3 = Fire Exit Forced. ETS6 logic using MDT Logic Module or ABB logic module: 13/1/0 (Reception Door Granted, value 1) → Stairwell Lighting GA 5/1/0 (DPT 1.001, send 1, 10 second delay-off timer). For HVAC: 13/2/0 (Office Door Granted, first access of day) → HVAC occupancy GA 7/1/0 (DPT 1.001, send 1 = occupied) → HVAC starts pre-conditioning. ETS6 timer: Monday–Friday schedule via KNX time module, but access event overrides schedule for weekend or out-of-hours access — energy saving when building is not occupied.

Emergency unlock via KNX relay output

EN 54 fire alarm integration (see blog post: bosch-fpa-fire-alarm-knx): on fire alarm activation, all access-controlled doors in the evacuation path must unlock immediately. Implementation: KNX binary output module relay (MDT BJ65-AB08.01 or similar) → connected to Paxton Net2 ACU auxiliary input (ACU has 2 supervised inputs for exit button and door monitor). Wiring: KNX relay output NO terminal → ACU REX (Request-to-Exit) input. On fire alarm, KNX sends DPT 1.001 value 1 to relay GA → relay closes → ACU REX input activated → ACU unlocks door relay (as if someone pressed the exit button). This is software-based and non-latching — must be confirmed with fire authority whether acceptable (some jurisdictions require hardware interlock). Alternative: dedicated fire alarm system relay output directly to ACU power supply interrupt (cuts 12V DC to door strike → door fails-safe = unlocked). KNX should only be supplementary to this hardware interlock.

Paxton Net2 software event scripting

Net2 Pro has a built-in scripting engine (Paxton Net2 API, .NET, available to customers). With Net2 API: (1) Subscribe to access events from Net2 COM server (INet2Server interface). (2) On access granted event: extract door ID, time, cardholder. (3) Send HTTP POST to Home Assistant REST API or directly to KNX IP gateway (KNXnet/IP programming via open-source knxd or ETS6 API). This allows richer integration than dry-contact relay: door name in energy report, per-cardholder lighting scenes (VIP visitor → conference lighting scene), access time logging in BMS. Tools: Paxton.Net2.OpenProtocol.dll available from Paxton partner portal. Requires Windows server with .NET 4.8.

Paxton10 IP-based controller comparison

Paxton10 is Paxton's newer PoE-based platform (2020+). Key differences from Net2: (1) ACU is PoE-powered (single Cat6 cable from PoE switch — no RS-485 wiring, no separate PSU). (2) Each ACU has Ethernet/IP connection directly to server (no daisy chain, IP addressing). (3) Paxton10 app (Android tablet recommended) for configuration — web-based interface. (4) Integration: Paxton10 has native REST API (JSON over HTTP) — no need for auxiliary relays, access events can be sent directly as HTTP webhooks to Home Assistant or KNX IP gateway scripting. (5) Auxiliary relay: still present on Paxton10 ACU for hardware integration (fire relay, electric strike) — same KNX binary input wiring applies. Recommended for new-build projects; Net2 Pro for refurbishments where RS-485 infrastructure already exists.

Commissioning sequence and testing

Typical 20-door office building: (1) Install Net2 Pro server, configure SQL database. (2) Wire ACU RS-485 daisy chain — terminate final ACU with 120Ω resistor across A and B. (3) For each door: configure Net2 Pro > Doors > add door > assign ACU, set unlock time 3 seconds, door held 30 seconds. (4) Configure auxiliary relay: Net2 Pro > Doors > door name > Input/Output > Auxiliary Output 1 = Access Granted > pulse 5 seconds. (5) Wire ACU aux relay to KNX binary input module (per room/zone). (6) ETS6: assign GAs to binary input, download. (7) Test: present access card → confirm Net2 log shows granted event → confirm KNX group address receives telegram → confirm lighting scene activates. (8) Test denied: present invalid card → confirm denied telegram to KNX (no automation should trigger). (9) Test emergency unlock: activate fire alarm → confirm KNX relay fires → confirm door unlocks. Document test results for client handover.