Gladys alarm system

[quentins33]

Hello,

After a few days of use, here is my feedback regarding the alarm system management in Gladys.

I use several detectors and devices for my alarm system:

• about 15 opening detectors
• 4 Zigbee motion detectors
• 1 Zigbee keypad (the frient keyzb-110)
• 4 cameras
• 1 FP2 aqara directly on HomeKit

Currently, it is possible to create an alarm system in Gladys by combining scenes, triggers, and detectors.
However, after using Alarmo under Home Assistant, I find that Gladys is currently missing a dedicated layer for managing an alarm system.

The current system seems very young and improvable.

The main problem is that the alarm is currently made up of several independent automations

In Gladys, you can create scenes for:

• activating the alarm in absence mode;

• partially activating the alarm;

• deactivating the alarm;

• triggering a siren or an action when a sensor detects something;

• sending a notification;

• possibly managing an entry or exit delay.

This works, but all the logic must be built manually: it’s long, tedious, and potentially error-prone.

The system does not really have dedicated logic.

Like Alarmo, I would like to have real states that would automatically manage actions from an Alarm interface:

• Disarmed

• Arming in progress

• Armed absence

• Armed night

• Armed presence

• Entry delay

• Alarm triggered

This difference becomes important as soon as the installation starts to have several sensors or several arming modes.

An important point, there is no night mode and this mode is terribly missing

The existence of this night mode of the alarm in HomeKit is also missing.
The available modes are: At home, Away and Disabled.

In case of triggering, I only have a Telegram notification. I no longer have an urgent alert on HomeKit.

Sensor management by mode

Another very practical point in Alarmo is the ability to define which sensors participate in each mode.

For example:

Away mode

• doors;

• windows;

• motion detectors;

• garage.

Night mode

• doors;

• windows;

• garage;

• but not the indoor motion detectors.

Presence mode

• only certain openings or peripheral zones.

In Gladys, this logic generally has to be reproduced in several scenes.

This quickly leads to duplication, makes modifications more difficult, and multiplies the risk of errors.

If I add a detector or change the behavior of a zone, I have to check several scenes.

Management of entry and exit delays

For a real alarm, some sensors should be able to have specific behavior.

For example:

An opening of the front door when the alarm is active should not necessarily immediately trigger the siren.

It should be able to launch a 30-second entry delay, allowing a code to be entered on a keypad.

Similarly, when activating the alarm, it should be possible to have an exit delay before the sensors become active.

This logic can be created with scenes, but it quickly becomes complex.

Keypad management

For example, I use a Zigbee keypad that allows:

• full arming;

• night arming;

• disarming;

• PIN code;

• RFID badge reading.

Today, the logic between the keypad and Gladys must be built manually, I started this construction in Node Red but I regret that this function is not integrated into Gladys.

An alarm integration could allow having a base:

Keypad → alarm command → code validation → state change

The keypad would then be just one interface among others.

You could very well have simultaneously:

• one or more Zigbee keypads;

• the Gladys application;

• physical buttons;

• a badge reader

• scenes;

• API;

• a webhook.

All would control the same alarm system.

Validation before arming

Another very useful behavior would be to check the status of the sensors before arming the alarm.

For example:

Impossible to activate the alarm: kitchen window open.

With the possibility of:

• canceling the arming;

• temporarily ignoring the sensor;

• forcing the arming.

This is particularly practical in a house with many opening detectors.

Zone management

It might also be interesting to introduce a notion of alarm zone.

For example:

• House

• Garage

• Exterior

Each zone could contain several sensors.

This would then make it possible to simply define:

Night mode = Peripheral house + Garage

or:

Away mode = All zones

Centralization of configuration

For me, the main advantage of a dedicated feature would be to have a page:

Gladys → Alarm

with for example:

Status

• Disarmed

• Armed

• Entry delay

• Triggered

Modes

• Away

• Night

• Presence

Sensors

• Front door

• Kitchen window

• Living room motion

• Garage door

Sirens

Keypads

Delays

Notifications

User codes

All the logic would thus be centralized.

The Gladys scenes could then simply exploit the alarm events.

For example:

When the alarm goes to « triggered » → turn on the lights + start the siren + send a notification.

Scenes would remain extremely useful

The idea would not be to replace Gladys’s scene system.

The Alarm component would only manage the business logic:

• states;

• sensors;

• zones;

• delays;

• validation;

• codes.

Scenes would remain responsible for actions around the alarm:

• notifications;

• lighting;

• TTS;

• cameras;

• additional sirens;

• shutter closing;

• etc.

This would allow keeping all the current flexibility of Gladys while avoiding having to rebuild all the logic of an alarm center in the scenes.

Concrete example

Today, for my installation, I notably had to build part of this logic with Node-RED to correctly manage my Zigbee keypad and the different alarm modes.

This works, but I find it a shame to need an external solution for a function that seems essential to me for a home automation solution.

Ideally, Node-RED should be used for very specific behaviors, not to maintain the state of an alarm.

---

I think a solution inspired by Alarmo would be particularly interesting for Gladys, without necessarily trying to exactly reproduce its operation.

This could eventually take the form:

• a new Gladys service;

• a native feature;

• or an external integration first.

Personally, I would be very interested in participating in the reflections, tests, and possibly the development of a first integration.

I would also be curious to know how you manage your alarm systems.

Do you only use scenes?
Have you developed your own solution?
Do you use NodeRed or another external system?

What do you think of this « alarm center » feature in Gladys?
Does it seem useful to you?

Thank you for taking the time to read me

[StephaneB]

On my side, my alarm system has been managed for several years by the Myfox Control hub, which was later acquired by Somfy. At the time, it had the advantages you mentioned: easy to configure, with a simple on/off/night monitoring logic. But it lacks flexibility, and the sensors were expensive and are now hard to find except second-hand…

In short, I would like to switch to a surveillance system based on Gladys. But I had tested the alarm mode and was not satisfied, for pretty much the same reasons as you.

So I support the request you’re making

[StephaneB]

I think you can change the category of your topic to « feature request », and I’ll vote for it

[spenceur]

Today I go through the scenes and wall tablets.

For me, night mode is my partial alarm that triggers on door openings, not motion sensors.

My keyboard is the one from Gladys in tablet mode.

I have a 15/30 second timing after a door opens to disable my system. But everything is managed by Gladys on my side. I confirm, however, that it is a source of errors during setup. But I was testing as I went along.

I have scenes that call others, etc., but it gives an idea of what was done at the time.

[cicoub13]

I agree with you on some points.

I will try to create the related Feature Requests and we will develop them according to the importance and ease of each request.

Could you complete them to specify the need?

[quentins33]

Bonjour @cicoub13.
I asked Codex to help me organize the requirements.
Does this meet your request for clarification?

F01 Centralized Alarm State

Current Problem

The state of a complex alarm system currently needs to be replicated through scenes, variables, or intermediate states.

This results in:

• duplicated logic;

• difficulty in knowing the real state of the alarm;

• multiplication of scenes;

• difficulty in managing transitions;

• risk of inconsistency between multiple control methods.

Requirement

Gladys must have a centralized alarm state, usable by:

• the interface;

• the scenes;

• the API;

• the integrations.

Proposed States

DISARMED
ARMING
ARMED
PENDING
TRIGGERED

The arming mode is separate from the state:

HOME
NIGHT
AWAY

Example:

state = ARMED
mode = NIGHT

Main Transitions

DISARMED
    │ arm(NIGHT)
    ▼
ARMING
    │ exit delay completed
    ▼
ARMED
    │ sensor triggered
    ▼
PENDING
    │ entry delay completed
    ▼
TRIGGERED
    │ disarm()
    ▼
DISARMED

A detection without delay can go directly from ARMED to TRIGGERED.

Expected Actions

• Arm

• Disarm

• Trigger

• Cancel pending

Acceptance Criteria

• An alarm system always has a single state.
• The state survives a Gladys restart.
• All commands go through the same logic.
• The transitions are available for scenes.
• The API allows reading the state.
• The API allows arming and disarming.

Dependency: none.

---

F02 Away / Night / Home Modes

Current Problem

A home alarm does not work only in an on/off mode.

The user should be able to protect their home differently depending on whether they are:

• away;

• present;

• sleeping.

Requirement

Add three standard modes:

Mode	Meaning
HOME	Presence
NIGHT	Night
AWAY	Away

Expected Behavior

When arming:

Arm → Away
Arm → Night
Arm → Home

The central state becomes, for example:

state = ARMED
mode = NIGHT

Interface

The alarm widget could offer:

ALARM

● Disarmed

[ Home ] [ Night ] [ Away ]

Once armed:

ALARM

● Armed
Mode: Night

[ Disarm ]

Acceptance Criteria

• The three modes can be selected independently.
• The current mode is viewable.
• A scene can know the active mode.
• A scene can request an arming mode.
• The API exposes the mode.

Dependency: F01.

---

F03 Sensor Assignment to Modes

Current Problem

Not all sensors should trigger the alarm in all modes.

For example, a living room motion detector should work in Away mode but generally not in Night mode.

Requirement

Allow each sensor to be associated with one or more modes.

Example

Sensor	Home	Night	Away
Front Door
Living Room Window
Living Room Motion
Hallway Motion
Garage Door

Business Rule

Sensor changes state
        │
        ▼
Alarm ARMED?
        │
       Yes
        ▼
Sensor active for the mode?
        │
       Yes
        ▼
Handle intrusion

Otherwise, the event is ignored by the alarm engine.

Acceptance Criteria

• An existing Gladys device can become an alarm sensor.
• A sensor can belong to multiple modes.
• A modification does not require recreating scenes.
• A sensor deactivated for the current mode does not trigger the alarm.

Dependencies: F01 + F02.

---

F04 Entry and Exit Delays

Current Problem

An alarm must allow the user to:

• leave the house after arming;

• enter the house before having to disarm the alarm.

Requirement

Add:

• Exit delay — exit delay;

• Entry delay — entry delay.

Exit Delay

Example:

Arm Away
    │
    ▼
ARMING
    │
  30 seconds
    ▼
ARMED

During this delay, sensors do not cause an intrusion.

Entry Delay

The delay should ideally be definable per sensor.

Sensor	Delay
Front Door	30 s
Garage Door	45 s
Window	Immediate
Living Room Motion	Immediate

A timed door causes:

ARMED
   │
   ▼
PENDING
   │
 30 s
   ▼
TRIGGERED

If the user disarms during the 30 seconds:

PENDING → DISARMED

Acceptance Criteria

• Configurable exit delay.
• Configurable entry delay.
• Possibility of immediate triggering.
• Cancellation of the countdown on disarm.
• The ARMING and PENDING changes are usable in scenes.

Dependencies: F01 + F03.

---

F05 Pre-Arming Check and Bypass

Current Problem

It is possible to request activation when a door or window is already open.

Requirement

Before arming, Gladys checks all relevant sensors.

Example:

Unable to activate the alarm

2 openings detected:

• Kitchen Window
• Garage Door

[ Cancel ]
[ Retry ]
[ Ignore Open Sensors ]

Bypass

An ignored sensor becomes temporarily:

BYPASSED

The bypass disappears automatically at the next disarm.

Security

The bypass must be clearly visible:

ALARM

● Armed — Away

⚠️ 1 ignored sensor

Kitchen Window

Acceptance Criteria

• Pre-arming check.
• List of problematic sensors.
• Possibility to refuse arming.
• Possibility of temporary bypass.
• Removal of bypass on disarm.
• Bypass event available for scenes and logs.

Dependencies: F01 + F03.

---

F06 Full Integration with Gladys Scenes

Objective

The alarm engine must handle security, then let Gladys scenes decide the consequences.

Proposed Triggers

• Alarm: arming requested

• Alarm: armed

• Alarm: entry delay started

• Alarm: triggered

• Alarm: disarmed

• Alarm: sensor bypassed

With contextual information:

mode
sensor
room
timestamp
user

Proposed Actions

In a scene:

Alarm → Arm → Away
Alarm → Arm → Night
Alarm → Arm → Home
Alarm → Disarm

Example

WHEN
    Alarm triggered

IF
    Mode = Away

THEN
    → activate siren
    → turn on lighting
    → send notification
    → launch camera scene

Acceptance Criteria

• Each important transition can trigger a scene.
• A scene can arm/disarm.
• The mode is available in the context.
• The sensor that triggered the event is identifiable.
• No siren/TTS/camera behavior is imposed by the engine.

Dependency: F01.

---

F07 Alarm Zones

Problem

Configuring dozens of individual sensors quickly becomes difficult.

Requirement

Allow grouping sensors into logical zones.

Example

Perimeter
├── Front Door
├── Kitchen Window
└── Living Room Window

Interior
├── Living Room Motion
└── Hallway Motion

Garage
├── Garage Door
└── Garage Motion

Modes can then use the zones:

Zone	Home	Night	Away
Perimeter
Interior
Garage

Acceptance Criteria

• Creation/modification/deletion of a zone.
• Addition of multiple sensors.
• A zone can be used by multiple modes.
• The exact origin of an intrusion remains identifiable.

Dependency: F03.

---

F08 User PIN Codes

Objective

Allow authentication independent of the device used.

The PIN belongs to Gladys / the user, not to the Zigbee keypad.

Example

Quentin
PIN: ••••

Rights:
✓ Arm
✓ Disarm

Guest
PIN: ••••

Rights:
✓ Disarm

Validity:
08/09 → 15/09

Features

To be planned:

• Individual PIN;

• Activation/deactivation;

• Possibly an expiration date;

• Identification of the user who disarmed;

• Future possibility of different permissions.

Security

PINs must never be stored or logged in plain text.

Acceptance Criteria

• Multiple PINs possible.
• One PIN corresponds to one user.
• Centralized verification by Gladys.
• Revocable PIN.
• Temporary PIN possible in the future.
• No PINs in plain text in logs.

Dependency: F01.

---

F09 Support for Alarm Keyboards

Objective

Allow physical Zigbee / Zigbee2MQTT keyboards to control the alarm system.

For example:

Frient KEYZB-110

Architectural Principle

The keyboard contains no business logic.

Keyboard
   │
   ▼
Zigbee2MQTT
   │
   ▼
Gladys
   │
   ▼
Alarm Service

It transmits, for example:

ARM_HOME
ARM_NIGHT
ARM_AWAY
DISARM
PIN

Gladys then decides whether the action is allowed.

Feedback to the Keyboard

When the hardware allows it, Gladys should be able to transmit:

• Successful arming;

• Arm failure;

• Incorrect PIN;

• Successful disarming;

• Alarm triggered.

With possibly a return:

• Audio;

• LED;

• Visual.

Extensibility

The architecture should not be specific to Frient.

A device should be able to expose standardized features:

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

Acceptance Criteria

• A keyboard can request arming.
• A keyboard can request disarming.
• The PIN is validated by Gladys.
• Multiple keyboards can control the same alarm.
• The system remains functional without a keyboard.
• The integration is not tied to a specific model.

Dependencies: F01 + F02 + F08.

---

F10 Centralized Alarm Interface

This feature brings everything together for the user.

Objective

Create a dedicated page in Gladys:

Settings
└── Alarm

or an equivalent service.

Main Screen

HOME ALARM

Status
● Disarmed

Modes
○ Presence
○ Night
○ Away

Sensors
18 configured
✓ 17 OK
⚠️ 1 open

[ Configure ]

Configuration

Proposed sections:

1. General

2. Modes

3. Zones

4. Sensors

5. Delays

6. Users / codes

7. Keyboards

8. History

Dashboard

A Gladys widget would also allow:

┌─────────────────────────┐
│ 🛡️ Home Alarm        │
│                         │
│ ● Disarmed              │
│                         │
│ Presence   Night         │
│ Away                     │
└─────────────────────────┘

In Case of Intrusion

🚨 ALARM TRIGGERED

Garage Door
19:42

[ Disarm ]

Also plan for intrusion reporting in HomeKit as an urgent notification, when the integration allows it.

Acceptance Criteria

• Immediate status consultation.
• Arm/disarm.
• Mode selection.
• View open sensors.
• View bypassed sensors.
• Configuration without manually creating scenes.
• Interface usable on mobile.

Dependencies: Ideally F01 to F09.

[cicoub13]

@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.

[StephaneB]

Bravo to both of you for this work that clearly outlines the need. Overall, everything listed seems coherent to me, and I don’t see any ‹ gaps › compared to what I can do today with my Myfox alarm. In fact, it goes much further, so it’s great!

I’ll try to take the time on Sunday to give my opinion on the different ‹ questions to decide… ›

[quentins33]

Great, thanks for creating the feature requests.
I’ll quickly review each one to give you feedback.