Gladys alarm system

Feature requests
1

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

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

2

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 :+1:

3

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

4

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.

25939
259391440×3120 378 KB

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