KNX Alarm- und Präsenzüberwachung

Diese Lösung verwandelt ein bestehendes KNX-System in eine leistungsfähige, zuverlässige und datenschutzfreundliche Alarmanlage – ganz ohne klassische, proprietäre Alarmtechnik. Sie nutzt die vorhandene Infrastruktur und erweitert sie um eine intelligente Logik.

  • 🛡️ Sliding-Window-Logik reduziert Fehlalarme drastisch, indem sie erst nach mehreren Sensor-Events in einem definierten Zeitfenster auslöst.
  • 🧠 Arbeitet ausschließlich mit vorhandenen KNX-Sensoren wie Bewegungsmeldern (PIR), Fenster- und Türkontakten, gern auch über Matter Sensoren, wie Hue und Eve, wenn entsprechenede Bridge vorhanden
  • 🔁 DEMO- und MONITOR-Modi, über KNX-Schalter (Webinterface) steuerbar, ermöglichen eine sichere Simulation bzw. eine reine Präsenzüberwachung ohne Alarm.
  • 📩 Direkte Benachrichtigungen per E-Mail für Statusänderungen, Sensor-Auslösungen und Alarme. Optional per Push, SIP-Call, SMS
  • 🖥️ Keine Abhängigkeit von Cloud-Diensten Dritter (außer dem Mail-Provider). Die gesamte Logik läuft lokal auf einem Server (Microcontroller für wenige Euro oder Raspi – ausreichend) im eigenen Netzwerk.

Vorteile

Datenschutzfreundliche Sicherheit ohne Kameras

  • 📵 Keine Kameras nötig – die Überwachung basiert rein auf den Zuständen der Sensorik.
  • 👨‍👩‍👧‍👦 Schutz des Hauses, nicht Überwachung der Familie. Die Privatsphäre bleibt jederzeit gewahrt, da keine Bilder oder Töne aufgezeichnet werden.

Flexible Alarmierung und Integration ins Smart Home

Da die Alarmauslösung über einen Standard-KNX-Datenpunkt erfolgt, sind die Möglichkeiten zur Signalisierung und Integration praktisch unbegrenzt.

  • 🔔 Akustische/Optische Signale: Der Alarm-Datenpunkt kann direkt KNX-Aktoren für Sirenen, Blitzlichter oder das Einschalten der gesamten Beleuchtung ansteuern.
  • 📬 Benachrichtigungsdienste: Neben dem direkten E-Mail-Versand kann ein übergeordnetes System (z. B. Home Assistant, ioBroker) auf die Änderung des Alarm-Datenpunkts reagieren und Nachrichten über Pushover, Telegram, WhatsApp etc. versenden.
  • 🌐 Integration in Drittsysteme: Die Anbindung an Systeme wie Shelly, Philips Hue oder IKEA Trådfri erfolgt über eine zentrale Smart-Home-Instanz, die den KNX-Alarm-Datenpunkt als Trigger nutzt.

Bedienung und Statusanzeige

Das System wird ausschließlich über die Zustände von KNX-Datenpunkten gesteuert. Jede Anwendung oder jedes Gerät, das KNX-Datenpunkte lesen und schreiben kann, kann zur Steuerung und Überwachung der Alarmanlage verwendet werden.

Grundprinzip der Steuerung

  • Scharf/Unscharf setzen: Schreiben von true/false auf den ARMED Datenpunkt (DP 1 im Beispiel).
  • Demo-Modus aktivieren: Schreiben von true auf den DEMO Datenpunkt (DP 99). Der Demo-Modus simuliert Alarme nur im Log, ohne den realen Alarm-Aktor zu schalten. Ideal für Tests.
  • Monitor-Modus aktivieren: Schreiben von true auf den MONITORDatenpunkt (DP 58). In diesem Modus loggt das Skript alle Sensoraktivitäten, auch wenn die Anlage unscharf ist. Nützlich zur reinen Präsenz-Analyse.

Anwendungsbeispiele im Testszenario

Im Testszenario wurden verschiedene Oberflächen zur Steuerung und Visualisierung genutzt:

1. Home Assistant Home Assistant ist ideal für eine vollumfängliche Visualisierung und Steuerung. Durch die Integration des Weinzierl-Gateways werden die KNX-Datenpunkte als Entitäten in Home Assistant verfügbar gemacht.

  • Steuerung: Die Datenpunkte für ARMED, DEMO und MONITOR werden als Schalter (Switches) auf dem Dashboard angelegt. So kann die Anlage mit einem Klick scharf/unscharf geschaltet oder in einen Sondermodus versetzt werden.
  • Statusanzeige: Die Datenpunkte für ALARM und ALARMHISTORY werden als Binärsensoren (Binary Sensors) visualisiert. Man sieht sofort, ob gerade ein Alarm aktiv ist oder ob ein Alarm stattgefunden hat, der bereits quittiert wurde (ALARMHISTORY ist true).
  • Vorteil: Bietet die flexibelste und benutzerfreundlichste Oberfläche mit der Möglichkeit, komplexe Automationen zu erstellen (z.B. “Wenn Alarm, schalte alle Lichter an und sende eine Telegram-Nachricht”).

2. Weinzierl Web-Oberfläche Das Weinzierl 777 Gateway besitzt eine eigene Web-Oberfläche, die für Tests und zur Fehlersuche sehr nützlich ist.

  • Funktion: Über den Menüpunkt “Datapoint Monitor” (oder ähnlich) können die Werte aller konfigurierten Datenpunkte in Echtzeit eingesehen werden.
  • Manuelle Steuerung: Es können manuell Werte auf die Datenpunkte geschrieben werden. Dies ist eine sehr direkte Methode, um die Reaktion des Skripts zu testen, ohne eine zusätzliche Visualisierungsschicht zu benötigen.
  • Vorteil: Direkter, ungefilterter Zugriff auf die KNX-Ebene. Perfekt für die Inbetriebnahme und für technische Überprüfungen.

3. 1Home App Der Dienst 1Home agiert als Brücke zwischen KNX und mobilen Smart-Home-Plattformen wie Apple HomeKit.

  • Funktion: Die relevanten KNX-Datenpunkte (ARMED, ALARM etc.) werden in der 1Home-Konfiguration Geräten in Apple HomeKit (oder Google/Alexa) zugeordnet.
  • Steuerung und Status: Die Anlage kann danach direkt über die Apple Home App auf dem iPhone, iPad oder der Apple Watch gesteuert und ihr Status eingesehen werden. Dies ermöglicht auch die Steuerung per Sprachbefehl (“Hey Siri, schalte die Alarmanlage scharf”).
  • Vorteil: Nahtlose Integration in das mobile Ökosystem und Ermöglichen von Fernzugriff und Sprachsteuerung.

Technische Dokumentation

Anforderungen

  • Hardware: Ein Server oder Mini-PC (z. B. Raspberry Pi) für den Dauerbetrieb.
  • Software: Node.js (Version ≥ 18) und ein Prozessmanager wie pm2 zur Überwachung des Skripts.
  • KNX-Gateway: Weinzierl 777 IP Interface mit aktivierter REST-API.
  • KNX-Infrastruktur: Vorhandene und konfigurierte Sensoren (z. B. PIR-Melder, Magnetkontakte).

Kernfunktionen des Skripts

  • KNX-Kommunikation: Zyklisches Auslesen der Sensor-Datenpunkte und Schreiben auf Aktor-Datenpunkte über die Weinzierl REST-API.
  • Sliding-Window-Logik: Kombinierte Auslösung bei Erreichen einer definierten Anzahl von Sensor-Events (sliding_events) innerhalb eines Zeitfensters (sliding_window).
  • Status-Management: Dynamisches Auslesen der Zustände für ARMED, DEMO und MONITOR direkt von KNX-Datenpunkten.
  • E-Mail-Versand: Direkter SMTP-Versand über einen konfigurierten Mail-Dienst (im Skript aktuell ZeptoMail).
  • Live-Konfiguration: Die Konfigurationsdatei creds.json wird bei jedem Hauptzyklus neu eingelesen, sodass Änderungen ohne Neustart des Skripts wirksam werden.

Konfigurationsdatei creds.json

Diese Datei enthält alle sicherheitsrelevanten Daten und die Logik-Parameter. Sie muss im selben Verzeichnis wie das Skript liegen.

JSON

{ "System_name": "Haus-Alarm KW19", "ip": "192.168.2.244", "username": "admin", "password": "xxx", "ARMED": 1, "ALARM": 4, "ALARMHISTORY": 49, "DEMO": 99, "MONITOR": 58, "intervall": 100, "waiting_time": 6000, "sliding_window": 60000, "sliding_events": 2, "mail_armed": true, "mail_sensor": true, "mail_alarm": true, "datapoints": [ { "id": 16, "name": "Büro" }, { "id": 13, "name": "Wohnzimmer" }, { "id": 10, "name": "Küche" }, { "id": 7, "name": "Flur unten" } ], "emails": [ "name1@beispiel.de", "name2@beispiel.com" ] }

Besonderheiten und Modi

  • DEMO: Ist dieser KNX-Datenpunkt true, wird ein Alarm im Log simuliert, es wird aber kein realer Alarm-Datenpunkt gesetzt. Ideal zum Testen der Sensorkette.
  • MONITOR: Ist dieser KNX-Datenpunkt true, läuft das Skript auch im unscharfen Zustand (ARMED ist false) weiter und loggt Sensoraktivitäten. Dies kann zur reinen Präsenz- oder Aktivitätsüberwachung genutzt werden, ohne einen Alarm auszulösen.

Alarm-Auslösung und Integration (Beispielpfad)

Das Skript selbst sendet keine direkten Befehle an Shelly, Matter oder andere Systeme. Es agiert als Gehirn innerhalb von KNX.

  1. Erkennung: Das Node.js-Skript erkennt eine Alarmbedingung (z. B. 2 Sensoren in 60 Sekunden).
  2. KNX-Trigger: Das Skript setzt den KNX-Datenpunkt ALARM (ID 4 im Beispiel) auf den Wert true.
  3. Aktion im Smart Home: Ein Aktor im KNX-System (z. B. für eine Sirene) oder eine übergeordnete Logik-Engine (Home Assistant, ioBroker, 1HOME MatterBridge etc.) reagiert auf die Zustandsänderung des ALARMDatenpunkts und führt die gewünschten Aktionen aus.

Zentrales Logging

Unabhängig von der verwendeten Oberfläche schreibt das Skript ein ausführliches, zentrales Log auf dem Server, auf dem es läuft. Dieses Log ist die maßgebliche Quelle zur Analyse aller Ereignisse.

  • Zugriff: Am einfachsten lässt sich das Log live über den Befehl pm2 logs <script_name> in der Konsole des Servers verfolgen.
  • Inhalt: Es protokolliert jeden Statuswechsel (scharf/unscharf), jede Sensor-Auslösung, die Berechnungen des Sliding Windows, auftretende Fehler und natürlich jeden ausgelösten Alarm mit exaktem Zeitstempel.