KNX-native RFID readers — MDT and Gira

KNX RFID card readers are bus-powered devices that mount flush in a standard 55mm wall box. They send KNX telegrams directly on the bus when a card is presented — no separate access controller hardware required for basic door open logic.

Both readers are configured entirely in ETS — no external software required for basic operation. Card UIDs are entered as hex strings in the ETS parameter page, each linked to a KNX group address. When a matching card is presented, the reader sends a binary ON telegram to that group address, which is then linked to a door actuator relay or alarm zone.

How KNX RFID access works — telegram flow

The access event chain from card tap to door open involves KNX telegrams across three device types: the RFID reader, the logic/actuator, and the door strike relay output.

DPT for card readers — binary vs UID string

KNX RFID readers use different data types depending on how the access decision is made — on-device (binary output) or centrally (UID string sent to logic engine).

For most residential and small commercial installations, the binary DPT 1.001 output is sufficient — UIDs are stored in the reader via ETS and the access decision is made locally. Central UID management (string DPT) is used for large installations with many doors and users managed from a database.

Multi-door system — zone table and central logic

For buildings with multiple controlled doors (office floors, apartment common areas, parking), a central KNX logic engine manages zone-based access rules. The KNX IP router (Weinzierl KNX IP Router 751, MDT IP Router SCN-IP100.02) acts as the logic hub when combined with ETS logic functions.

Each door has its own RFID reader group address (input) and relay output group address. The ETS application links these with time function logic blocks. Readers at different doors can share a card UID — the same card works at all authorized doors — or have completely separate card lists per door.

Time schedules — working hours and weekend lock

KNX time functions (available in ETS as logic function blocks, or via Weinzierl BAOS/Gira X1 timer schedules) enable automatic access control based on time of day and day of week.

Logic example — card UID + time-based access

The following logic block example shows how a KNX logic engine (ETS logic function or Weinzierl BAOS scripting) implements time-limited access for a specific card UID.

// ETS Logic Function Block — pseudocode representation
// (implemented as AND logic with time comparator in ETS)

INPUT:
  card_uid_signal   = GA 7/0/1  (binary, DPT 1.001)
                      -- triggered by MDT SCN-RFID55 for card A1B2C3

  time_condition    = GA 8/0/1  (binary, from KNX time schedule)
                      -- ON between 08:00–18:00 Mon–Fri
                      -- OFF outside working hours

LOGIC:
  IF card_uid_signal == TRUE          // card A1B2C3 presented
  AND time_condition == TRUE          // within working hours
  THEN:
    SEND GA 7/1/1 = TRUE             // door strike relay ON
    DELAY 5000 ms
    SEND GA 7/1/1 = FALSE            // door strike relay OFF (relock)
    SEND GA 9/0/1 = TRUE             // access log telegram

  ELSE IF card_uid_signal == TRUE     // card presented but outside hours
  AND time_condition == FALSE
  THEN:
    SEND GA 9/0/2 = TRUE             // access denied log telegram
    SEND GA 7/2/1 = TRUE             // LED: red flash (denied)

// Note: ETS logic blocks implement this as:
// AND gate → card GA + time GA → output → auto-off timer → relay GA

In ETS, this logic is implemented using the Logic Function block from the ETS App store (Thinka, Gira, or manufacturer-specific). The AND gate receives the card telegram and the time schedule output, with the result driving the relay group address. A timer function block handles the 5-second pulse width automatically.

Audit logging — KNX group monitor to InfluxDB

KNX group monitor traffic can be captured and stored for security audit purposes. A Raspberry Pi running Calimero (Java KNX library) or knxd + Python captures all telegrams on the KNX bus and writes access events to InfluxDB.

import asyncio
from xknx import XKNX
from xknx.io import ConnectionConfig, ConnectionType
from influxdb_client import InfluxDBClient, WriteOptions

ACCESS_GAS = {
    "7/0/1": "Main Entrance",
    "7/0/2": "Server Room",
    "7/0/3": "Management Floor",
    "9/0/2": "ACCESS DENIED",
}

influx = InfluxDBClient(
    url="http://localhost:8086",
    token="your_token",
    org="panelcraft"
)
write_api = influx.write_api(write_options=WriteOptions(batch_size=1))

async def telegram_received(telegram):
    ga = str(telegram.destination_address)
    if ga in ACCESS_GAS:
        door_name = ACCESS_GAS[ga]
        point = {
            "measurement": "access_events",
            "tags": {"door": door_name, "ga": ga},
            "fields": {"value": int(telegram.payload.value)},
        }
        write_api.write(bucket="access_log", record=point)
        print(f"{door_name}: access event at {telegram.date_time}")

async def main():
    xknx = XKNX(connection_config=ConnectionConfig(
        connection_type=ConnectionType.TUNNELING,
        gateway_ip="192.168.1.10",
    ))
    xknx.telegram_queue.register_telegram_received_cb(telegram_received)
    await xknx.start()
    await asyncio.sleep(float("inf"))

asyncio.run(main())

This creates a permanent access log in InfluxDB queryable via Grafana. A dashboard showing door access events per day, per card, and per time of day provides both security oversight and operational insight (e.g. detecting after-hours access attempts). Retention policy can be set to 365 days for compliance.

Comparison — KNX RFID vs 2N video intercom vs Nuki smart lock

Panel wiring — door strike and magnetic lock power

All door-locking hardware power supplies and relay outputs must be wired from the distribution panel. This is where PanelCraft panels differ from site-assembled solutions — all door hardware outputs are pre-wired, labeled, and tested in the panel before delivery.

Panel DIN rail — Door Zone 1 (Main Entrance)

[24V PSU] ──── F1 (2A) ──── [KNX relay OUT 1] ──── X1:1 (strike +)
                                  ↑ NO contact      X1:2 (strike –, GND)
[KNX IP Router]
[MDT AKK-04UP]                   D1 (1N4007)       ← across X1:1/X1:2

[KNX binary IN] ─────────────── X2:1 (door sensor A)
                                  X2:2 (door sensor B)

[RFID reader KNX bus] ────────── KNX TP bus terminals

Terminal labels:
X1 = Door strike / maglock power output (PROTECTED)
X2 = Door sensor reed switch input
X3 = KNX TP bus to RFID reader in wall box