Hallo,
Nach einigen Tagen der Nutzung möchte ich mein Feedback zur Alarmverwaltung in Gladys geben.
Ich verwende mehrere Sensoren und Geräte für mein Alarmsystem:
- etwa 15 Tür-/Fensterkontakte
- 4 Zigbee-Bewegungsmelder
- 1 Zigbee-Tastatur (Frient KeyZB-110)
- 4 Kameras
- 1 Aqara FP2 direkt über HomeKit
Derzeit ist es möglich, ein Alarmsystem in Gladys zu erstellen, indem Szenen, Auslöser und Sensoren kombiniert werden.
Allerdings finde ich, dass Gladys heute eine echte Schicht fehlt, die speziell für die Verwaltung eines Alarmsystems gedacht ist.
Das aktuelle System wirkt sehr jung und verbesserungsfähig.
Das Hauptproblem ist, dass der Alarm derzeit aus mehreren unabhängigen Automatisierungen besteht
In Gladys kann man Szenen erstellen für:
-
Aktivierung des Alarms im Abwesenheitsmodus;
-
Teilweise Aktivierung des Alarms;
-
Deaktivierung des Alarms;
-
Auslösen einer Sirene oder einer Aktion, wenn ein Sensor etwas erkennt;
-
Senden einer Benachrichtigung;
-
Eventuelle Verwaltung einer Ein- oder Ausstiegsverzögerung.
Das funktioniert, aber die gesamte Logik muss manuell aufgebaut werden: Es ist langwierig, mühsam und möglicherweise fehleranfällig.
Das System hat keine echte dedizierte Logik.
Wie bei Alarmo würde ich gerne über echte Zustände verfügen, die automatisch Aktionen von einer Alarm-Schnittstelle aus verwalten:
-
Deaktiviert
-
Aktivierung läuft
-
Aktiviert (Abwesenheit)
-
Aktiviert (Nacht)
-
Aktiviert (Anwesenheit)
-
Einstiegsverzögerung
-
Alarm ausgelöst
Dieser Unterschied wird wichtig, sobald die Installation mehrere Sensoren oder mehrere Aktivierungsmodi hat.
Wichtig ist, dass es keinen Nachtmodus gibt und dieser Modus mir sehr fehlt ![]()
Die Existenz dieses Nachtalarmmodus in HomeKit fehlt mir auch.
Die verfügbaren Modi sind: Zuhause, Abwesend und Deaktiviert.
Bei Auslösung erhalte ich nur eine Telegram-Benachrichtigung. Ich habe keine dringende Alarmierung mehr in HomeKit.
Sensorverwaltung pro Modus
Ein weiterer sehr praktischer Punkt in Alarmo ist die Möglichkeit, festzulegen, welche Sensoren an jedem Modus teilnehmen.
Zum Beispiel:
Abwesenheitsmodus
-
Türen;
-
Fenster;
-
Bewegungsmelder;
-
Garage.
Nachtmodus
-
Türen;
-
Fenster;
-
Garage;
-
aber keine Innenbewegungsmelder.
Anwesenheitsmodus
- nur bestimmte Öffnungen oder Randbereiche.
In Gladys muss diese Logik in der Regel in mehreren Szenen reproduziert werden.
Das führt schnell zu Duplikaten, macht Änderungen schwieriger und erhöht die Fehleranfälligkeit.
Wenn ich einen Sensor hinzufüge oder das Verhalten eines Bereichs ändere, muss ich mehrere Szenen überprüfen.
Verwaltung von Ein- und Ausstiegsverzögerungen
Für einen echten Alarm sollten bestimmte Sensoren ein spezifisches Verhalten haben können.
Zum Beispiel:
Das Öffnen einer Eingangstür, wenn der Alarm aktiviert ist, sollte nicht unbedingt sofort die Sirene auslösen.
Es sollte eine Einstiegsverzögerung von 30 Sekunden auslösen, die es ermöglicht, einen Code an einer Tastatur einzugeben.
Ebenso sollte beim Aktivieren des Alarms eine Ausstiegsverzögerung möglich sein, bevor die Sensoren aktiv werden.
Diese Logik kann mit Szenen erstellt werden, wird aber schnell komplex.
Verwaltung von Tastaturen
Ich verwende zum Beispiel eine Zigbee-Tastatur, die Folgendes ermöglicht:
-
Vollständige Aktivierung;
-
Nachtaktivierung;
-
Deaktivierung;
-
PIN-Code;
-
RFID-Badge-Lesegerät.
Heute muss die Logik zwischen der Tastatur und Gladys manuell aufgebaut werden, ich habe damit in Node Red begonnen, aber ich bedauere, dass diese Funktion nicht in Gladys integriert ist.
Eine Alarmintegration könnte eine Grundlage bieten:
Tastatur → Alarmsteuerung → Codevalidierung → Zustandsänderung
Die Tastatur wäre dann nur eine von mehreren Schnittstellen.
Man könnte gleichzeitig haben:
-
eine oder mehrere Zigbee-Tastaturen;
-
die Gladys-App;
-
physische Schalter;
-
ein Badge-Leser;
-
Szenen;
-
API;
-
einen Webhook.
Alle würden dasselbe Alarmsystem steuern.
Validierung vor Aktivierung
Ein weiteres sehr nützliches Verhalten wäre die Überprüfung des Sensorzustands vor der Aktivierung des Alarms.
Zum Beispiel:
Alarm kann nicht aktiviert werden: Küchenfenster ist offen.
Mit der Möglichkeit:
-
die Aktivierung abzubrechen;
-
den Sensor vorübergehend zu ignorieren;
-
die Aktivierung zu erzwingen.
Das ist besonders praktisch in einem Haus mit vielen Tür-/Fensterkontakten.
Verwaltung von Zonen
Es wäre auch interessant, den Begriff der Alarmzone einzuführen.
Zum Beispiel:
-
Haus
-
Garage
-
Außenbereich
Jede Zone könnte mehrere Sensoren enthalten.
Dadurch könnte man einfach definieren:
Nachtmodus = Hausumgebung + Garage
oder:
Abwesenheitsmodus = Alle Zonen
Zentralisierung der Konfiguration
Für mich wäre der Hauptvorteil einer dedizierten Funktion, eine Seite zu haben:
Gladys → Alarm
mit zum Beispiel:
Status
-
Deaktiviert
-
Aktiviert
-
Einstiegsverzögerung
-
Ausgelöst
Modi
-
Abwesenheit
-
Nacht
-
Anwesenheit
Sensoren
-
Eingangstür
-
Küchenfenster
-
Bewegungsmelder Wohnzimmer
-
Garagentür
Sirenen
Tastaturen
Verzögerungen
Benachrichtigungen
Benutzercodes
Die gesamte Logik wäre dann zentralisiert.
Die Gladys-Szenen könnten dann einfach die Alarmevents nutzen.
Zum Beispiel:
Wenn der Alarm auf „ausgelöst“ wechselt → Licht einschalten + Sirene starten + Benachrichtigung senden.
Szenen bleiben extrem nützlich
Die Idee wäre nicht, das Szenensystem von Gladys zu ersetzen.
Die Alarmkomponente würde nur die Geschäftslogik verwalten:
-
Zustände;
-
Sensoren;
-
Zonen;
-
Verzögerungen;
-
Validierung;
-
Codes.
Die Szenen würden weiterhin für Aktionen rund um den Alarm verantwortlich sein:
-
Benachrichtigungen;
-
Beleuchtung;
-
TTS;
-
Kameras;
-
zusätzliche Sirenen;
-
Rollladen schließen;
-
usw.
Dadurch könnte die aktuelle Flexibilität von Gladys beibehalten werden, ohne die gesamte Logik einer Alarmzentrale in den Szenen neu aufbauen zu müssen.
Konkrete Beispiel
Heute musste ich für meine Installation einen Teil dieser Logik mit Node-RED erstellen, um mein Zigbee-Tastatur und die verschiedenen Alarmmodi korrekt zu verwalten.
Es funktioniert, aber ich finde es schade, eine externe Lösung für eine Funktion zu benötigen, die mir für eine Smart-Home-Lösung unverzichtbar erscheint.
Idealerweise sollte Node-RED für sehr spezifische Verhaltensweisen verwendet werden, nicht für die Verwaltung des Zustands eines Alarms.
Ich denke, eine Lösung, die von Alarmo inspiriert ist, wäre besonders interessant für Gladys, ohne unbedingt genau dessen Funktionsweise zu reproduzieren.
Das könnte eventuell die Form annehmen:
-
eines neuen Gladys-Dienstes;
-
einer nativen Funktion;
-
oder einer externen Integration zunächst.
Persönlich wäre ich sehr interessiert, an den Überlegungen, Tests und eventuell der Entwicklung einer ersten Integration mitzuwirken.
Ich wäre auch neugierig zu erfahren, wie Sie Ihre Alarmsysteme verwalten.
Verwenden Sie nur Szenen?
Haben Sie Ihre eigene Lösung entwickelt?
Verwenden Sie NodeRed oder ein anderes externes System?
Was halten Sie von dieser „Alarmzentrale“-Funktion in Gladys?
Erscheint Ihnen das nützlich?
Ich danke Ihnen, dass Sie sich die Zeit genommen haben, mir zuzuhören ![]()
