Lecteurs RFID natifs KNX – MDT et Gira

Les lecteurs de cartes RFID KNX sont des appareils alimentés par le bus, montés en encastrement dans un boîtier mural standard de 55 mm. Ils envoient des télégrammes KNX directement sur le bus lorsqu'une carte est présentée – aucun contrôleur d'accès séparé n'est requis pour la logique de base d'ouverture de porte.

Les deux lecteurs sont entièrement configurés dans ETS – aucun logiciel externe n'est requis pour le fonctionnement de base. Les UID des cartes sont saisis sous forme de chaînes hexadécimales dans la page de paramètres ETS, chacun lié à une adresse de groupe KNX. Lorsqu'une carte correspondante est présentée, le lecteur envoie un télégramme binaire ON à cette adresse de groupe, qui est ensuite liée à un relais d'actionneur de porte ou à une zone d'alarme.

Comment fonctionne l'accès KNX RFID – flux de télégrammes

La chaîne d'événements d'accès, du passage de la carte à l'ouverture de la porte, implique des télégrammes KNX entre trois types de dispositifs : le lecteur RFID, le module logique/actionneur et le relais de sortie de gâche.

DPT pour lecteurs de cartes — binaire vs chaîne UID

Les lecteurs RFID KNX utilisent différents types de données selon que la décision d'accès est prise sur l'appareil (sortie binaire) ou centralement (chaîne UID envoyée au moteur logique).

Pour la plupart des installations résidentielles et petits commerces, la sortie binaire DPT 1.001 est suffisante – les UID sont stockés dans le lecteur via ETS et la décision d'accès est prise localement. La gestion centralisée des UID (string DPT) est utilisée pour les grandes installations avec de nombreuses portes et utilisateurs gérés depuis une base de données.

Système multi-portes – table des zones et logique centrale

Pour les bâtiments avec plusieurs portes contrôlées (étages de bureaux, parties communes d'appartements, parkings), un moteur logique KNX central gère les règles d'accès basées sur les zones. Le routeur IP KNX (Weinzierl KNX IP Router 751, MDT IP Router SCN-IP100.02) agit comme hub logique lorsqu'il est combiné avec les fonctions logiques ETS.

Chaque porte possède sa propre adresse de groupe de lecteur RFID (entrée) et adresse de groupe de sortie relais. L'application ETS relie ces dernières à des blocs logiques de fonction temporelle. Les lecteurs à différentes portes peuvent partager un UID de carte – la même carte fonctionne à toutes les portes autorisées – ou avoir des listes de cartes complètement séparées par porte.

Plannings horaires – heures de travail et verrouillage week-end

Les fonctions horaires KNX (disponibles dans ETS sous forme de blocs de fonctions logiques, ou via les plannings horaires Weinzierl BAOS/Gira X1) permettent un contrôle d'accès automatique basé sur l'heure et le jour de la semaine.

Exemple de logique — UID de carte + accès basé sur le temps

L'exemple de bloc logique suivant montre comment un moteur logique KNX (fonction logique ETS ou script Weinzierl BAOS) implémente un accès limité dans le temps pour un UID de carte spécifique.

// 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

Dans ETS, cette logique est implémentée à l'aide du bloc Fonction logique de la boutique d'applications ETS (Thinka, Gira ou spécifique au fabricant). La porte ET reçoit le télégramme de carte et la sortie du planning horaire, le résultat pilotant l'adresse de groupe du relais. Un bloc fonction temporisateur gère automatiquement la largeur d'impulsion de 5 secondes.

Journalisation d'audit – Moniteur de groupe KNX vers InfluxDB

Le trafic du moniteur de groupe KNX peut être capturé et stocké à des fins d'audit de sécurité. Un Raspberry Pi exécutant Calimero (bibliothèque KNX Java) ou knxd + Python capture tous les télégrammes sur le bus KNX et écrit les événements d'accès dans 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())

Cela crée un journal d'accès permanent dans InfluxDB interrogeable via Grafana. Un tableau de bord affichant les événements d'accès aux portes par jour, par carte et par heure de la journée fournit à la fois une supervision de sécurité et un aperçu opérationnel (par exemple, détection des tentatives d'accès après les heures ouvrables). La politique de conservation peut être définie sur 365 jours pour la conformité.

Comparaison – RFID KNX vs interphone vidéo 2N vs serrure connectée Nuki

Câblage du tableau – alimentation de la gâche électrique et de la serrure magnétique

Toutes les alimentations et sorties relais pour les composants de verrouillage de porte doivent être câblées depuis le tableau de distribution. C'est là que les tableaux PanelCraft diffèrent des solutions assemblées sur site – toutes les sorties pour la quincaillerie de porte sont précâblées, étiquetées et testées dans le tableau avant livraison.

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