Gladys Alarmsystem

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 :sob:

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 :grinning_face:

Meine Alarmanlage wird seit mehreren Jahren von der Myfox Control-Zentrale verwaltet, die inzwischen von Somfy übernommen wurde. Sie hatte damals die von dir erwähnten Vorteile: einfach zu konfigurieren, mit einer einfachen Überwachungslogik (ein/aus/Nacht). Aber sie bietet wenig Flexibilität, und die Sensoren waren teuer und sind jetzt nur noch gebraucht erhältlich…

Kurz gesagt, ich würde gerne auf eine Überwachung basierend auf Gladys umsteigen. Aber ich hatte den Alarmmodus getestet und war nicht zufrieden, aus ähnlichen Gründen wie du.

Ich unterstütze also deine Anforderung :+1:

Ich denke, du kannst die Kategorie deines Themas in „Funktionsanfrage“ ändern, und ich werde dafür stimmen :wink:

Heute gehe ich über Szenen und Wandtablets.

Für mich ist der Nachtmodus meine Teilalarmanlage, die bei Türöffnungen auslöst, nicht bei Bewegungsmeldern.

Mein Keyboard ist das von Gladys im Tablet-Modus.

Ich habe eine Zeitverzögerung von 15/30 Sekunden nach dem Öffnen einer Tür, um mein System zu deaktivieren. Aber alles wird von Gladys auf meiner Seite verwaltet. Ich bestätige jedoch, dass dies Fehlerquellen bei der Einrichtung sind. Aber ich habe schrittweise getestet.

Ich habe Szenen, die andere aufrufen usw., aber das ist eine Idee davon, was damals gemacht wurde.

Ich stimme Ihnen in einigen Punkten zu.

Ich werde versuchen, die relevanten Feature-Anfragen zu erstellen, und wir werden sie nach Wichtigkeit und Umsetzbarkeit priorisieren.

Könnten Sie diese bitte ergänzen, um den Bedarf genauer zu spezifizieren?

Hallo @cicoub13.
Ich habe Codex gebeten, mir zu helfen, die Anforderungen zu organisieren.
Erfüllt das deine Anfrage nach Präzision?

F01 Zentralisierter Alarmstatus

Aktuelles Problem

Der Status eines komplexen Alarmsystems muss derzeit über Szenen, Variablen oder Zwischenzustände reproduziert werden.

Dies führt zu:

  • einer Duplikation der Logik;

  • Schwierigkeiten, den tatsächlichen Alarmstatus zu kennen;

  • einer Vermehrung der Szenen;

  • Schwierigkeiten bei der Verwaltung der Übergänge;

  • einem Risiko der Inkonsistenz zwischen mehreren Steuerungsmethoden.

Anforderung

Gladys muss über einen zentralisierten Alarmstatus verfügen, der genutzt werden kann durch:

  • die Benutzeroberfläche;

  • die Szenen;

  • die API;

  • die Integrationen.

Vorgeschlagene Zustände

DISARMED
ARMING
ARMED
PENDING
TRIGGERED

Der Armierungsmodus ist vom Status getrennt:

HOME
NIGHT
AWAY

Beispiel:

state = ARMED
mode = NIGHT

Hauptübergänge

DISARMED
    │ arm(NIGHT)
    ▼
ARMING
    │ Verzögerung beim Verlassen beendet
    ▼
ARMED
    │ Sensor ausgelöst
    ▼
PENDING
    │ Verzögerung beim Betreten beendet
    ▼
TRIGGERED
    │ disarm()
    ▼
DISARMED

Eine Erkennung ohne Verzögerung kann direkt von ARMED zu TRIGGERED wechseln.

Erwartete Aktionen

  • Arm

  • Disarm

  • Trigger

  • Cancel pending

Akzeptanzkriterien

  • Ein Alarmsystem hat immer einen eindeutigen Status.
  • Der Status überlebt den Neustart von Gladys.
  • Alle Befehle laufen über dieselbe Logik.
  • Die Übergänge sind für Szenen verfügbar.
  • Die API ermöglicht das Lesen des Status.
  • Die API ermöglicht das Armieren und Deaktivieren.

Abhängigkeit: keine.


F02 Modi Abwesenheit / Nacht / Anwesenheit

Aktuelles Problem

Eine Hausalarmanlage funktioniert nicht nur im Ein/Aus-Modus.

Der Benutzer sollte sein Zuhause unterschiedlich schützen, je nachdem, ob er:

  • abwesend ist;

  • anwesend ist;

  • schläft.

Anforderung

Drei Standardmodi hinzufügen:

Modus Bedeutung
HOME Anwesenheit
NIGHT Nacht
AWAY Abwesenheit

Erwartetes Verhalten

Beim Armieren:

Arm → Away
Arm → Night
Arm → Home

Der zentrale Status wird beispielsweise:

state = ARMED
mode = NIGHT

Benutzeroberfläche

Das Alarm-Widget könnte Folgendes anbieten:

ALARM

● Deaktiviert

[ Anwesenheit ] [ Nacht ] [ Abwesenheit ]

Sobald er aktiviert ist:

ALARM

● Aktiviert
Modus: Nacht

[ Deaktivieren ]

Akzeptanzkriterien

  • Die drei Modi können unabhängig ausgewählt werden.
  • Der aktuelle Modus ist abrufbar.
  • Eine Szene kann den aktiven Modus kennen.
  • Eine Szene kann einen Armierungsmodus anfordern.
  • Die API stellt den Modus bereit.

Abhängigkeit: F01.


F03 Zuweisung von Sensoren zu Modi

Aktuelles Problem

Nicht alle Sensoren sollten den Alarm in allen Modi auslösen.

Ein Bewegungsmelder im Wohnzimmer sollte beispielsweise im Abwesenheitsmodus funktionieren, aber normalerweise nicht im Nachtmodus.

Anforderung

Jeden Sensor einem oder mehreren Modi zuordnen können.

Beispiel

Sensor Anwesenheit Nacht Abwesenheit
Haustür :white_check_mark: :white_check_mark: :white_check_mark:
Wohnzimmerfenster :white_check_mark: :white_check_mark: :white_check_mark:
Bewegungsmelder Wohnzimmer :cross_mark: :cross_mark: :white_check_mark:
Bewegungsmelder Flur :cross_mark: :cross_mark: :white_check_mark:
Garagentor :white_check_mark: :white_check_mark: :white_check_mark:

Geschäftsregel

Sensor ändert Zustand
        │
        ▼
Alarmanlage ARMED?
        │
       Ja
        ▼
Sensor aktiv für den Modus?
        │
       Ja
        ▼
Eindringen behandeln

Andernfalls wird das Ereignis vom Alarmmotor ignoriert.

Akzeptanzkriterien

  • Eine bestehende Gladys-Ausstattung kann zu einem Alarmsensor werden.
  • Ein Sensor kann zu mehreren Modi gehören.
  • Eine Änderung erfordert keine Neuerstellung der Szenen.
  • Ein für den aktuellen Modus deaktivierter Sensor löst den Alarm nicht aus.

Abhängigkeiten: F01 + F02.


F04 Ein- und Ausgangsverzögerungen

Aktuelles Problem

Eine Alarmanlage muss dem Benutzer ermöglichen:

  • das Haus nach dem Armieren zu verlassen;

  • ins Haus zu kommen, bevor er die Alarmanlage deaktivieren muss.

Anforderung

Hinzufügen:

  • Exit delay — Ausgangsverzögerung;

  • Entry delay — Eingangsverzögerung.

Ausgangsverzögerung

Beispiel:

Arm Away
    │
    ▼
ARMING
    │
  30 Sekunden
    ▼
ARMED

Während dieser Verzögerung lösen die Sensoren keine Eindringlinge aus.

Eingangsverzögerung

Die Verzögerung sollte idealerweise pro Sensor definiert werden können.

Sensor Verzögerung
Haustür 30 s
Garagentor 45 s
Fenster Sofort
Bewegungsmelder Wohnzimmer Sofort

Eine zeitgesteuerte Tür verursacht:

ARMED
   │
   ▼
PENDING
   │
 30 s
   ▼
TRIGGERED

Wenn der Benutzer innerhalb von 30 Sekunden deaktiviert:

PENDING → DISARMED

Akzeptanzkriterien

  • Konfigurierbare Ausgangsverzögerung.
  • Konfigurierbare Eingangsverzögerung.
  • Möglichkeit der sofortigen Auslösung.
  • Abbruch des Countdowns bei Deaktivierung.
  • Die Änderungen ARMING und PENDING sind in den Szenen verwendbar.

Abhängigkeiten: F01 + F03.


F05 Überprüfung vor dem Armieren und Bypass

Aktuelles Problem

Es ist möglich, die Aktivierung anzufordern, während eine Tür oder ein Fenster bereits offen ist.

Anforderung

Bevor das Armieren erfolgt, überprüft Gladys alle betroffenen Sensoren.

Beispiel:

Alarmanlage kann nicht aktiviert werden

2 offene Öffnungen erkannt:

• Küchenfenster
• Garagentor

[ Abbrechen ]
[ Erneut versuchen ]
[ Offene Sensoren ignorieren ]

Bypass

Ein ignorierter Sensor wird vorübergehend:

BYPASSED

Der Bypass verschwindet automatisch bei der nächsten Deaktivierung.

Sicherheit

Der Bypass muss deutlich sichtbar sein:

ALARM

● Aktiviert — Abwesenheit

⚠️ 1 Sensor ignoriert

Küchenfenster

Akzeptanzkriterien

  • Überprüfung vor dem Armieren.
  • Liste der problematischen Sensoren.
  • Möglichkeit, das Armieren abzulehnen.
  • Möglichkeit eines vorübergehenden Bypasses.
  • Löschen des Bypasses bei Deaktivierung.
  • Bypass-Ereignis für Szenen und Protokoll verfügbar.

Abhängigkeiten: F01 + F03.


F06 Vollständige Integration mit Gladys-Szenen

Ziel

Der Alarmmotor muss die Sicherheit verwalten und dann Gladys-Szenen die Konsequenzen entscheiden lassen.

Vorgeschlagene Auslöser

  • Alarm: Armierung angefordert

  • Alarm: armiert

  • Alarm: Eingangsverzögerung gestartet

  • Alarm: ausgelöst

  • Alarm: deaktiviert

  • Alarm: Sensor umgangen

Mit kontextuellen Informationen:

modus
sensor
raum
zeitstempel
benutzer

Vorgeschlagene Aktionen

In einer Szene:

Alarmanlage → Armieren → Abwesenheit
Alarmanlage → Armieren → Nacht
Alarmanlage → Armieren → Anwesenheit
Alarmanlage → Deaktivieren

Beispiel

WENN
    Alarmanlage ausgelöst

DANN
    Modus = Abwesenheit

ALORS
    → Sirene aktivieren
    → Licht einschalten
    → Benachrichtigung senden
    → Kameraszene starten

Akzeptanzkriterien

  • Jeder wichtige Übergang kann eine Szene auslösen.
  • Eine Szene kann armieren/deaktivieren.
  • Der Modus ist im Kontext verfügbar.
  • Der Sensor, der das Ereignis ausgelöst hat, ist identifizierbar.
  • Kein Sirene/TTS/Kamera-Verhalten wird vom Motor erzwungen.

Abhängigkeit: F01.


F07 Alarmzonen

Problem

Die individuelle Konfiguration mehrerer Dutzend Sensoren wird schnell schwierig.

Anforderung

Sensoren in logische Zonen gruppieren können.

Beispiel

Perimeter
├── Haustür
├── Küchenfenster
└── Wohnzimmerfenster

Innenbereich
├── Bewegungsmelder Wohnzimmer
└── Bewegungsmelder Flur

Garage
├── Garagentor
└── Bewegungsmelder Garage

Die Modi können dann die Zonen verwenden:

Zone Anwesenheit Nacht Abwesenheit
Perimeter :white_check_mark: :white_check_mark: :white_check_mark:
Innenbereich :cross_mark: :cross_mark: :white_check_mark:
Garage :white_check_mark: :white_check_mark: :white_check_mark:

Akzeptanzkriterien

  • Erstellung/Änderung/Löschung einer Zone.
  • Hinzufügen mehrerer Sensoren.
  • Eine Zone kann von mehreren Modi verwendet werden.
  • Der genaue Ursprung eines Eindringens bleibt identifizierbar.

Abhängigkeit: F03.


F08 Benutzer-PIN-Codes

Ziel

Unabhängige Authentifizierung vom verwendeten Gerät ermöglichen.

Der PIN gehört also Gladys / dem Benutzer und nicht der Zigbee-Tastatur.

Beispiel

Quentin
PIN: ••••

Rechte:
✓ Armieren
✓ Deaktivieren
Gast
PIN: ••••

Rechte:
✓ Deaktivieren

Gültigkeit:
08/09 → 15/09

Funktionen

Vorgesehen:

  • Individuelle PIN;

  • Aktivierung/Deaktivierung;

  • Eventuell ein Gültigkeitsdatum;

  • Identifikation des Benutzers, der die Alarmanlage deaktiviert hat;

  • Mögliche zukünftige unterschiedliche Berechtigungen.

Sicherheit

:warning: Die PINs dürfen niemals im Klartext gespeichert oder protokolliert werden.

Akzeptanzkriterien

  • Mehrere PINs möglich.
  • Eine PIN entspricht einem Benutzer.
  • Zentralisierte Überprüfung durch Gladys.
  • PIN widerrufbar.
  • Vorläufig temporäre PIN möglich.
  • Keine PINs im Klartext in den Logs.

Abhängigkeit: F01.


F09 Unterstützung für Alarmanlage-Tastaturen

Ziel

Erlaubt es physischen Zigbee-/Zigbee2MQTT-Tastaturen, die Alarmanlage zu steuern.

Zum Beispiel:

Frient KEYZB-110

Architekturprinzip

Die Tastatur enthält keine Geschäftslogik.

Tastatur
   │
   ▼
Zigbee2MQTT
   │
   ▼
Gladys
   │
   ▼
Alarm Service

Sie überträgt zum Beispiel:

ARM_HOME
ARM_NIGHT
ARM_AWAY
DISARM
PIN

Gladys entscheidet dann, ob die Aktion erlaubt ist.

Rückmeldung an die Tastatur

Wenn das Gerät dies zulässt, sollte Gladys in der Lage sein, Folgendes zu übertragen:

  • Erfolgsmeldung bei der Aktivierung;

  • Ablehnung der Aktivierung;

  • Falsche PIN;

  • Erfolgsmeldung bei der Deaktivierung;

  • Auslösung des Alarms.

Möglicherweise mit einer Rückmeldung:

  • Akustisch;

  • LED;

  • Visuell.

Erweiterbarkeit

Die Architektur sollte nicht spezifisch für Frient sein.

Ein Gerät sollte standardisierte Funktionen bereitstellen können:

alarm-arm
alarm-disarm
alarm-code
alarm-status

Akzeptanzkriterien

  • Eine Tastatur kann die Aktivierung anfordern.
  • Eine Tastatur kann die Deaktivierung anfordern.
  • Die PIN wird von Gladys validiert.
  • Mehrere Tastaturen können denselben Alarm steuern.
  • Das System bleibt ohne Tastatur funktionsfähig.
  • Die Integration ist nicht an ein bestimmtes Modell gebunden.

Abhängigkeiten: F01 + F02 + F08.


F10 Zentralisierte Alarmanlage-Schnittstelle

Diese Funktion fasst alles andere für den Benutzer zusammen.

Ziel

Erstellen Sie in Gladys eine dedizierte Seite:

Einstellungen
└── Alarm

oder ein äquivalenter Dienst.

Hauptbildschirm

HAUSAUSRÜSTUNG

Status
● Deaktiviert

Modi
○ Anwesenheit
○ Nacht
○ Abwesenheit

Sensoren
18 konfiguriert
✓ 17 OK
⚠️ 1 offen

[ Konfigurieren ]

Konfiguration

Vorgeschlagene Abschnitte:

  1. Allgemein

  2. Modi

  3. Zonen

  4. Sensoren

  5. Verzögerungen

  6. Benutzer/Codes

  7. Tastaturen

  8. Verlauf

Dashboard

Ein Gladys-Widget würde auch Folgendes ermöglichen:

┌─────────────────────────┐
│ 🛡️ Hausalarm        │
│                         │
│ ● Deaktiviert              │
│                         │
│ Anwesenheit   Nacht         │
│ Abwesenheit                 │
└─────────────────────────┘

Bei einem Einbruch

🚨 ALARM AUSGELÖST

Garagentor
19:42

[ Deaktivieren ]

Auch die Übertragung von Einbrüchen in HomeKit in Form einer dringenden Benachrichtigung vorsehen, wenn die Integration dies zulässt.

Akzeptanzkriterien

  • Sofortige Statusüberprüfung.
  • Aktivierung/Deaktivierung.
  • Modusauswahl.
  • Anzeige der offenen Sensoren.
  • Anzeige der umgangenen Sensoren.
  • Konfiguration ohne manuelle Erstellung von Szenen.
  • Benutzeroberfläche auf Mobilgeräten nutzbar.

Abhängigkeiten: Ideal F01 bis F09.

@quentins33 Danke für die Organisation — deine Aufteilung in F01 → F10 war direkt nutzbar, ich konnte davon ausgehen, anstatt bei Null anzufangen.

Ich habe 9 Funktionsanfragen erstellt, eine pro Thema, damit wir für jede einzeln abstimmen und unabhängig voneinander vorankommen können. Hier die Entsprechungen zu deinen Anforderungen:

Dein Bedarf Erstellte Anfrage Hinweis
F01 Zentralisierter Status A6 · Status „ausgelöst“ und Kontext + A2 · Sensoren Aufgeteilt in zwei Anfragen, siehe unten
F02 Modi Abwesenheit / Nacht / Anwesenheit A1 · Nachtmodus
F03 Zuweisung der Sensoren zu den Modi A2 · Überwachte und aktive Sensoren pro Modus Das Herzstück der Arbeit
F04 Ein- und Auslöseverzögerungen A3 · Einlöseverzögerung Die Auslöseverzögerung existiert bereits
F05 Überprüfung vor dem Scharfen und Bypass A4 · Überprüfung und Deaktivierung
F06 Integration mit den Szenen A6 · Status „ausgelöst“ und Kontext
F07 Alarmzonen A5 · Zonen
F08 Benutzer-PIN-Codes A7 · Ein Code pro Benutzer
F09 Unterstützung von Tastaturen A8 · Physische Tastaturen
F10 Zentralisierte Oberfläche A9 · Dedizierte Alarmanzeige

Warum F01 kein eigenes Thema hat

Gladys hat bereits einen zentralisierten Alarmstatus: Er lebt im Haus, überlebt Neustarts, und alle Befehle laufen über ihn. Was fehlt, ist nicht der Status selbst, sondern zwei verschiedene Dinge — ein „ausgelöster“ Status, der vom Panikknopf getrennt ist (A6), und ein Motor, der ihn automatisch ändern kann, wenn ein Sensor etwas erkennt (A2). Eine Anfrage „zentralisierter Status“ wäre größtenteils bereits erfüllt gewesen, schwer zu bewerten und zu abstimmen.

Was bereits existiert, zur Einordnung

Nützlich, um zu verstehen, warum einige Anfragen kleiner sind als andere: Gladys kann bereits scharfstellen, teilweise scharfstellen, mit einem Code entschärfen und in den Panikmodus wechseln; die Verzögerung vor dem Scharfstellen ist einstellbar; die Tablets sperren sich, wenn das Haus scharfgestellt ist; sechs Szenenauslöser und zwei Aktionen existieren; und der Alarm ist in HomeKit als Sicherheitssystem freigegeben — ohne den Nachtmodus, genau weil Gladys ihn nicht hat.

Was überhaupt nicht existiert, ist die Verbindung zwischen einem Sensor und dem Alarm. Das erklärt, warum alles in den Szenen neu aufgebaut werden muss, und warum A2 die umfangreichste Anfrage ist.

Zwei bereits offene Forenanfragen wurden übernommen

Hinzufügen eines Auslösers „Alarm: Code eingegeben“ und mehrere Modi in einer Bedingung testen können sind in A6 integriert: Sie gehen genau in dieselbe Richtung.

Wo wir anfangen können

Vier Anfragen hängen von nichts ab und können parallel entwickelt werden: A1 (Nachtmodus), A2 (Sensoren), A7 (Codes) und ein Teil von A6. Alles andere leitet sich daraus ab. A1 ist bei weitem am schnellsten umsetzbar und entsperrt bereits die Nacht-Taste in HomeKit.

Was jetzt helfen würde

Jedes Thema endet mit einer Liste von offenen Fragen — das sind die Punkte, die die Erstellung einer Spezifikation blockieren. Eure Antworten, eure tatsächlichen Anwendungsfälle und eure Meinungsverschiedenheiten zu diesen Fragen sind genau das, was wir brauchen, um voranzukommen. Wobei das System flexibel bleiben muss, aber so einfach wie möglich (um es leicht entwickeln, warten und so zu halten, dass ein Benutzer kein Handbuch lesen muss).

@quentins33 @StephaneB @spenceur wenn ihr einen falsch übersetzten Bedarf oder eine Aufteilung seht, die euch wackelig erscheint, sagt es: Jetzt ist der Moment, es zu korrigieren, bevor die Entwicklung beginnt.

Gut gemacht, ihr beiden! Das klärt den Bedarf wirklich gut. Alles, was aufgelistet ist, erscheint mir konsistent, und ich sehe keine „Lücken“ im Vergleich zu dem, was ich heute mit meiner Myfox-Alarmanlage machen kann. Und es geht sogar viel weiter, also super!

Ich werde versuchen, mir am Sonntag Zeit zu nehmen, um meine Meinung zu den verschiedenen „offenen Fragen“ zu äußern…

Super, danke für die Erstellung der Feature-Anfragen.
Ich schaue mir jede davon kurz an, um dir Feedback zu geben.