trigger: alarm in the process of arming
condition: if all opening detectors are « closed » (and/or) motion detectors are inactive.
inability to see the status of a detector in the if function?
You can do it with a « Get last state » block + « Condition on variables » 
To make an « AND », you can just put several conditions, it will work!
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.
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.
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.
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=0Living Room Window - Opening=0Living Room Detector - Movement=1
3. The Complete Scene
- Trigger: « Alarm Armed » (end of countdown)
- « 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? »)
- « Condition on Variables » with the lines above
- « Send a Message »
- « 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.
Fix for your issue:
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:
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?
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
- Trigger: « Scheduled Trigger », type « Interval », for example every 5 minutes
- Action « HTTP Request »: method GET, your URL
Important point: click the « Try » 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:
{"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 « Send a value to a device », select the feature of your MQTT device, switch the selector from « Simple » to « Calculated », then type
{{and choose the variabledata.temperature - Text value: the action above only accepts numbers. Use the action « Send an MQTT message » instead, on the topic
gladys/master/device/YOUR_DEVICE_ID/feature/YOUR_FEATURE_ID/text, with the message{{thendata.status. Gladys listens to this topic and will record the value in the feature
Step 4: Display It
On your dashboard, add a « Devices » box (or « Devices in a Room ») and select the feature. If it’s a numerical value with history, you can also put it in a « Graph » or « Gauge » 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.
hello thanks for this information that allowed me to make what I wanted work
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?
Hi @bob,
I agree, I have the same issue at home 
I made a PR to fix the issue:
It will be fixed in the next version of Gladys! Thanks for the feedback!