@quentins33 thanks for the organizational work — your breakdown from F01 → F10 was directly usable, I was able to start from there rather than starting from scratch.
I created 9 feature requests, one per topic, so we can vote and move forward on each independently. Here is the correspondence with your needs:
| Your need | Request created | Note |
|---|---|---|
| F01 Centralized status | A6 · « Triggered » status and context + A2 · Sensors | Split into two requests, see below |
| F02 Absence / Night / Presence modes | A1 · Night mode | |
| F03 Sensor assignment to modes | A2 · Monitored and active sensors per mode | The core of the project |
| F04 Entry and exit delays | A3 · Entry delay | The exit delay already exists |
| F05 Verification before arming and bypass | A4 · Verification and disable | |
| F06 Integration with scenes | A6 · « Triggered » status and context | |
| F07 Alarm zones | A5 · Zones | |
| F08 User PIN codes | A7 · One code per user | |
| F09 Support for keyboards | A8 · Physical keyboards | |
| F10 Centralized interface | A9 · Dedicated Alarm page |
Why F01 doesn’t have its own topic
Gladys already has a centralized alarm status: it lives on the house, it survives a reboot, and all commands go through it. What is missing is not the status itself, but two different things — a « triggered » status distinct from the panic button (A6), and an engine capable of changing it automatically when a sensor detects something (A2). A « centralized status » request would have been largely already satisfied, difficult to evaluate and vote.
What already exists, for context
Useful to understand why some requests are smaller than others: Gladys already knows how to arm, partially arm, disarm with a code and go into panic; the delay before arming is adjustable; tablets lock when the house is armed; six scene triggers and two actions exist; and the alarm is exposed to HomeKit as a security system — without the night mode, precisely because Gladys doesn’t have it.
What doesn’t exist at all is the link between a sensor and the alarm. This explains why everything has to be rebuilt in the scenes, and why A2 is the heaviest request in the lot.
Two forum requests already opened have been included
Add a « Alarm: code entered » trigger and be able to test multiple modes in a condition are integrated into A6: they go exactly in the same direction.
Where we can start
Four requests do not depend on anything and can be developed in parallel: A1 (night mode), A2 (sensors), A7 (codes) and part of A6. Everything else follows from these. A1 is by far the fastest to deliver and already unlocks the Night button in HomeKit.
What would help now
Each topic ends with a list of questions to decide — these are the points that block the writing of a specification. Your answers, your real uses, and your disagreements on these questions are exactly what we need to move forward. Keeping in mind that the system must remain flexible, but as simple as possible (to be able to develop it easily, maintain it, and so that a user does not need to read a manual).
@quentins33 @StephaneB @spenceur if you see a need poorly translated or a breakdown that seems shaky to you, say so: it’s time to correct it, before development begins.