# Arm the alarm if all opening (and/or) motion detectors are in good position

**URL:** <https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437>\
**Category:** Scènes\
**Created:** [August 3, 2026, 8:15am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437 "2026-08-03T08:15:41Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 3, 2026, 8:15am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/1 "2026-08-03T08:15:41Z")

</div>

trigger: alarm in the process of arming

condition: if all opening detectors are «&nbsp;closed&nbsp;» (and/or) motion detectors are inactive.

inability to see the status of a detector in the if function?

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [August 3, 2026, 8:36am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/2 "2026-08-03T08:36:18Z")

</div>

You can do it with a «&nbsp;Get last state&nbsp;» block + «&nbsp;Condition on variables&nbsp;» 🙂

To make an «&nbsp;AND&nbsp;», you can just put several conditions, it will work!

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 4, 2026, 7:52am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/3 "2026-08-04T07:52:38Z")

</div>

I’m still sorry, it doesn’t work. Let me explain: I create a scene triggered by: alarm in the process of arming, I perform an action: retrieve the last state of the opening detector, then I create a condition on the variable select the opening detector in question if different from Closed then I disarm the alarm, I send an SMS to report the open window otherwise: I send an SMS armed alarm. Result: whether the detector is open or closed, the countdown remains at 0 and nothing happens. It’s still a big problem how can you arm an alarm with an open window or door especially if you want to use the alarm in partial mode.

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 4, 2026, 8:09am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/4 "2026-08-04T08:09:08Z")

</div>

If I set the trigger as: alarm armed at the end of the countdown, the alarm goes into disarmed mode whether the detector is open or closed, and I receive no message. I think I’ll find another solution to replace my alarm, which won’t be useful to me anymore since operators are abandoning 2G. I’m a bit disappointed; I really liked this solution.

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 4, 2026, 8:53am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/5 "2026-08-04T08:53:34Z")

</div>

What an adventure! In fact, I just tried using the values 1 or 0 instead of Open and Closed, and it works with the armed alarm trigger. If I use the alarm arming trigger, it works, but if the window is open, it blocks the countdown at zero but doesn’t arm the alarm. We can say that the problem is largely resolved.

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [August 4, 2026, 6:22pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/6 "2026-08-04T18:22:58Z")

</div>

Well done for finding the solution with 0 and 1! I’ll explain why and how to finish setting up your scenario 🙂

**1. Why « Open » / « Closed » Didn’t Work**

The « Condition on Variables » block compares the **raw value** stored by Gladys, not the label displayed in the interface. For a binary feature, the value is always 0 or 1, and « Open »/« Closed » is just the on-screen translation. Since the comparison is strict, `"Closed"` (text) is never equal to `1` (number): the condition was therefore never validated and the scene stopped silently, hence your « nothing happens ».

The values to use:

| **Sensor Type** | **0** | **1** |
| --- | --- | --- |
| Door Sensor | Open | Closed |
| Motion Detector | No Movement | Movement Detected |

**2. AND or OR?**

A small clarification regarding my previous answer: within **the same** « Condition on Variables » block, conditions are linked by an **OR** (the block passes as soon as one is true). To make an **AND** , you need to add **multiple** « Condition on Variables » blocks: they must then all be validated for the scene to continue. This is reminded directly in the interface since version 4.84.3.

In your case, the OR is exactly what you need: you want to cancel the arming **if at least one** sensor is faulty. So one condition block, with one line per sensor:

- `Front Door - Opening` **=** `0`
- `Living Room Window - Opening` **=** `0`
- `Living Room Detector - Movement` **=** `1`

**3. The Complete Scene**

1. **Trigger** : « Alarm Armed » (end of countdown)
2. « Retrieve Last State »: one block per sensor (they must be **above** the condition block, otherwise the variables do not appear in the dropdown list, this answers your question « impossibility to see the state of a detector in the function if? »)
3. « Condition on Variables » with the lines above
4. « Send a Message »
5. « Change Alarm Mode » → Disarmed

Make sure to send the message **before** disarming.

**4. The Bug You Encountered with « Alarm in the Process of Armament »**

There you encountered a real bug in Gladys, it’s not you: during the countdown, the house is still recorded as « disarmed » in the database (it only goes to « armed » at the end of the delay). Therefore the « Disarm » action does cancel the arming, but it returns an error « the house is already disarmed » before notifying the interface, hence the countdown that remains frozen at 0 while the alarm is not actually armed.

Until I fix this, stick with the « Alarm Armed » trigger: the alarm arms for a fraction of a second then disarms properly, and the interface updates correctly.

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [August 4, 2026, 6:32pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/7 "2026-08-04T18:32:14Z")

</div>

Fix for your issue:

> <https://github.com/GladysAssistant/Gladys/pull/2774>
>
> \### Description
> 
> While a house is arming, its alarm mode stays \`disarmed\` in DB …until the arming delay is over (it only switches to \`armed\` inside the \`setTimeout\` callback). Disarming during that window cleared the pending timeout, but then threw a \`ConflictError\` ("House is already disarmed") before emitting anything — so neither the \`alarm disarmed\` scene trigger nor the \`alarm.disarmed\` websocket event were sent. The alarm was effectively not armed anymore, but the UI stayed stuck on the arming countdown at 0.
> 
> This is what a user hit on the forum: a scene triggered by "alarm is arming" that disarms the house when an opening sensor is still open. The arming was correctly cancelled, but the countdown never went away.
> 
> Changes:
> 
> \- \`house.disarm\` now succeeds when there is a pending arming to cancel, and emits the usual \`ALARM.DISARM\` trigger + \`ALARM.DISARMED\` websocket event. It still throws \`ConflictError\` when the house is genuinely already disarmed.
> \- \`house.disarmWithCode\` no longer returns early when the house is arming — entering the alarm code on a tablet during the countdown now cancels the arming, instead of silently resolving and letting the house arm anyway.
> 
> \## Forum
> 
> Forum: \`\`https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position\`\`/10437
> 
> \### Checklist
> 
> \- \[x\] Tests pass: \`cd server && npm run coverage\` (Codecov requires 100% coverage on changed lines) and Cypress (\`npm run cypress:run\`) if the UI changed
> \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`)
> \- \[x\] No undocumented breaking change
> 
> Tests run locally: \`test/lib/house\`, \`test/controllers/house\` and \`test/lib/scene\` are green (297 passing). No UI change, so Cypress was not run.
> 
> New/updated tests:
> \- \`house.disarm\`: cancelling an arming resolves and emits the disarm trigger + websocket event, and the house is still disarmed after the delay would have elapsed.
> \- \`house.disarmWithCode\`: entering the code during the countdown cancels the pending arming.
> 
> \---
> \_Generated by \[Claude Code\](https://claude.ai/code/session\_013A5enXXRuGRnwayS8TYJ2X)\_
> 
> 
> 
> \## Summary by CodeRabbit
> 
> \* \*\*Bug Fixes\*\*
> \* Fixed disarming during an active arming delay.
> \* Disarm requests now cancel pending arming operations and complete successfully.
> \* Prevented a house from arming after its pending arming delay has been canceled.
> \* Ensured disarm notifications are sent when cancellation occurs.

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [August 4, 2026, 7:30pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/8 "2026-08-04T19:30:43Z")

</div>

I made 2 improvements for you:

- Bug fix for the disarm bug
- In scenes, the condition on variable displays the possible values instead of making the user guess 0 and 1

Both are live in 4.84.4:

> [@Gladys Assistant 4.84.4: OAuth over HTTPS and value selector in scenes](https://community.gladysassistant.com/t/gladys-assistant-4-84-4-oauth-en-https-et-selecteur-de-valeurs-dans-les-scenes/10450):
>
> Hi everyone! A small evening release, following directly from yesterday’s feedback: the real Spotify OAuth fix (via HTTPS), the alarm bug during arming, and some very concrete UX improvements smileyExternal Integrations: OAuth2 via [my.gladysassistant.com](http://my.gladysassistant.com) Spotify (and modern OAuth providers in general) no longer accept a redirect\_uri in HTTP on a local IP (http://192.168.x.x). Result: most self-hosted installs were getting a redirect\_uri: Not matching configuration. This is fixed: Gladys n…

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 5, 2026, 1:10pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/9 "2026-08-05T13:10:54Z")

</div>

ok I found it all works as you explained it to me.

I have another question: I send an HTTP GET request to a personal WiFi module. It works, I send the status by SMS, it’s ok. I would like to display it on the dashboard, is that possible?

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [August 5, 2026, 5:41pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/10 "2026-08-05T17:41:12Z")

</div>

Super, glad it works!

For your question: the dashboard can only display **devices** , not scene variables. The response to your HTTP request only exists for the duration of the scene’s execution, so to display it, you first need to store it somewhere. The solution is to create a device in Gladys and write the value to it.

**Step 1: Create the Device**

Go to Integrations, MQTT. If you don’t have a broker yet, Gladys can install one for you with a single click. Then, in the Devices tab of the MQTT integration, create a device manually, with a feature corresponding to what your module returns:

- a numerical value (temperature, voltage, counter…): choose the category that matches, for example Temperature Sensor, or Number if it’s a generic value
- a status in plain text: choose the Text category

Note the device’s external ID and the feature’s ID, you’ll need them in step 3.

**Step 2: The Scene That Queries Your Module**

1. Trigger: «&nbsp;Scheduled Trigger&nbsp;», type «&nbsp;Interval&nbsp;», for example every 5 minutes
2. Action «&nbsp;HTTP Request&nbsp;»: method GET, your URL

Important point: click the «&nbsp;Try&nbsp;» button. If your module responds with JSON (with the header `Content-Type: application/json`), Gladys reads the response and automatically creates a variable for each field. If it returns raw text, no variables will be available and you won’t be able to reuse anything. So if that’s not already the case, make it return something like:

```auto
{"status": "ok", "temperature": 21.5}

```

**Step 3: Write the Value to the Device**

Still in the same scene, after the HTTP request:

- **Numerical value** : action «&nbsp;Send a value to a device&nbsp;», select the feature of your MQTT device, switch the selector from «&nbsp;Simple&nbsp;» to «&nbsp;Calculated&nbsp;», then type `{{` and choose the variable `data.temperature`
- **Text value** : the action above only accepts numbers. Use the action «&nbsp;Send an MQTT message&nbsp;» instead, on the topic `gladys/master/device/YOUR_DEVICE_ID/feature/YOUR_FEATURE_ID/text`, with the message `{{` then `data.status`. Gladys listens to this topic and will record the value in the feature

**Step 4: Display It**

On your dashboard, add a «&nbsp;Devices&nbsp;» box (or «&nbsp;Devices in a Room&nbsp;») and select the feature. If it’s a numerical value with history, you can also put it in a «&nbsp;Graph&nbsp;» or «&nbsp;Gauge&nbsp;» box.

**A Simpler Alternative If You Can Modify Your Module’s Code**

Instead of Gladys querying your module every X minutes, have your module publish directly to MQTT on the topic `gladys/master/device/YOUR_DEVICE_ID/feature/YOUR_FEATURE_ID/state` (with just the value in the payload, or `/text` for text). You create the device as in step 1, and that’s it: no need for a scene, the value updates automatically as soon as the module sends it, with the history and graphs that come with it. On an ESP, the PubSubClient library does this in a few lines.

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 13, 2026, 9:05am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/11 "2026-08-13T09:05:30Z")

</div>

hello thanks for this information that allowed me to make what I wanted work

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 13, 2026, 3:32pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/12 "2026-08-13T15:32:26Z")

</div>

another issue that has appeared; the detectors display in the dashboard motion detected when they have been triggered which is normal but then display the time since they have been triggered whereas before they displayed inactive after a few minutes. how to go back to the previous operation, what has changed the original operation?

---

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [August 14, 2026, 8:45am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/13 "2026-08-14T08:45:23Z")

</div>

Hi @bob,

I agree, I have the same issue at home 😃

I made a PR to fix the issue:

> <https://github.com/GladysAssistant/Gladys/pull/2871>
>
> \### Description
> 
> On the "Devices in room" dashboard box, a motion sensor with no… current motion displayed a relative time ("2 minutes ago") based on \`last\_value\_changed\`. That timestamp is refreshed by \`device.saveState\` on \*\*every\*\* state report — including repeated "no motion" reports or re-published states — so it does not represent the time of the last motion, and users read it as "last motion 2 minutes ago".
> 
> This PR replaces the misleading relative time with an explicit "No motion" badge (\`badge-secondary\`), keeping:
> 
> \- "Motion detected" badge when \`last\_value\` is truthy (unchanged)
> \- "No value recorded" when no value was ever received
> \- The existing \`NoRecentValueBadge\` behavior for outdated values (unchanged, handled upstream in \`SensorDeviceFeature\`)
> 
> New i18n key \`dashboard.boxes.devicesInRoom.noMotionDetected\` added in \`en\` ("No motion"), \`fr\` ("Pas de mouvement") and \`de\` ("Keine Bewegung").
> 
> \## Forum
> 
> Forum: \`\`https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position\`\`/10437/10
> 
> \### Checklist
> 
> \- \[x\] Tests pass: no server change; front component change only, no Cypress test relies on the previous display
> \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`, \`npm run compare-translations\` on front)
> \- \[x\] No undocumented breaking change
> 
> \---
> \_Generated by \[Claude Code\](https://claude.ai/code/session\_013vznXc1Csb73D3gVxoY37t)\_

It will be fixed in the next version of Gladys! Thanks for the feedback!

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 19, 2026, 5:27pm UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/14 "2026-08-19T17:27:37Z")

</div>

hello, I have another observation. On two scenes, I notice that the if-else condition does not work. Example: I trigger a scene upon receiving an HTTP GET request. This scene is intended to check if all openings are closed before switching to armed alarm mode. I retrieve the last state of all openings. I do an if-else in the partition. If I make conditions on variables, if one of them is open, I set the alarm mode to disarmed. Otherwise, I set the alarm to armed. The scene does not take into account the open position of one of the openings; it directly goes to the else and arms the alarm while a window is open. I also had the same problem with another scene with a single condition. What can I do about this problem? I specify that I use OR in the if part.

---

<div class="post-metadata">

**Author:** ![bob](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/b/ea666f/32.png) [@bob](https://community.gladysassistant.com/u/bob)\
**Post date:** [August 20, 2026, 5:51am UTC](https://community.gladysassistant.com/t/armer-lalarme-si-tous-les-detecteurs-douverture-et-ou-de-mouvement-sont-en-bonne-position/10437/15 "2026-08-20T05:51:42Z")

</div>

sorry, after researching what could happen, I realized that I needed to reload Gladys’s home page for the condition elements to be taken into account. That’s what I did, and everything worked. good to know when a scene is stubborn, restarting Gladys can unblock the situation.
