déclencheur : alarme en cours d’armement
condition: si tous les détecteurs d’ouverture sont « fermés » (et ou) de mouvement sont inactifs.
impossibilité de voir l’état d’un détecteur dans la fonction si ?
Tu peux le faire avec un bloc « Récupérer le dernier état » + « Condition sur variables » 
Pour faire un « ET », tu peux juste mettre plusieurs conditions, ça marchera !
encore désolé ça ne marche pas. j’explique:je fais une scène déclenchée par: alarme en cours d’armement, je fais une action: récupérer le dernier état du détecteur d’ouverture ensuite je fais une condition sur variable sélectionne le détecteur d’ouverture en question si différent de Fermé alors je passe l’alarme en désarmée , j’envoie un sms pour signalé la fenêtre ouverte sinon: j’envoie un sms alarme armée. résultat: que le détecteur soit sur ouvert ou fermé le compte à rebours reste sur 0 et il ne se passe rien. c’est quand même un gros problème comment peut on armer une alarme avec une fenêtre ou une porte ouverte d’autant plus si on veut utiliser l’alarme en mode partiel.
si je mets comme déclencheur : alarme armée en fin de compte à rebours l’alarme passe en mode désarmée que se soit détecteur ouvert ou fermé et je ne reçois aucun message. je crois que je vais trouver une autre solution pour remplacer mon alarme qui ne va plus m’être utile vu que les opérateurs abandonnent la 2G. je suis un peux déçu, cette solution me plaisait bien.
quelle aventure, en fait je viens d’essayer avec les valeurs 1 ou 0 à la place de Ouvert et Fermé et ça marche avec le déclencheur alarme armée. si je prends comme déclencheur alarme en cous d’armement ça fonctionne mais si la fenêtre est ouverte ça bloque le compte à rebours sur zéro mais ça n’arme pas l’alarme. on peut dire que le problème est en grande partie résolu.
Bien joué d’avoir trouvé avec 0 et 1 ! Je t’explique le pourquoi, et comment finir de faire marcher ton scénario
1. Pourquoi « Ouvert » / « Fermé » ne marchait pas
Le bloc « Condition sur variables » compare la valeur brute stockée par Gladys, pas le libellé affiché dans l’interface. Pour une fonctionnalité binaire, la valeur est toujours 0 ou 1, et « Ouvert »/« Fermé » n’est que la traduction affichée à l’écran. La comparaison étant stricte, "Fermé" (texte) n’est jamais égal à 1 (nombre) : la condition n’était donc jamais validée et la scène s’arrêtait silencieusement, d’où ton « il ne se passe rien ».
Les valeurs à utiliser :
| Type de capteur | 0 | 1 |
|---|---|---|
| Détecteur d’ouverture | Ouvert | Fermé |
| Détecteur de mouvement | Pas de mouvement | Mouvement détecté |
2. ET ou OU ?
Petite précision par rapport à ma réponse précédente : à l’intérieur d’un même bloc « Condition sur variables », les conditions sont reliées par un OU (le bloc passe dès qu’une seule est vraie). Pour faire un ET, il faut ajouter plusieurs blocs « Condition sur variables » : ils doivent alors tous être validés pour que la scène continue. C’est rappelé directement dans l’interface depuis la 4.84.3.
Dans ton cas, le OU est justement ce qu’il te faut : tu veux annuler l’armement si au moins un capteur est en défaut. Donc un seul bloc condition, avec une ligne par capteur :
Porte d'entrée - Ouverture=0Fenêtre salon - Ouverture=0Détecteur salon - Mouvement=1
3. La scène complète
- Déclencheur : « Alarme armée » (fin du compte à rebours)
- « Récupérer le dernier état » : un bloc par capteur (ils doivent être au-dessus du bloc condition, sinon les variables n’apparaissent pas dans la liste déroulante, c’est ce qui répond à ta question « impossibilité de voir l’état d’un détecteur dans la fonction si ? »)
- « Condition sur variables » avec les lignes ci-dessus
- « Envoyer un message »
- « Changer le mode de l’alarme » → Désarmée
Mets bien l’envoi du message avant le désarmement.
4. Le bug que tu as rencontré avec « Alarme en cours d’armement »
Là tu es tombé sur un vrai bug de Gladys, ce n’est pas toi : pendant le compte à rebours, la maison est encore enregistrée comme « désarmée » en base (elle ne passe à « armée » qu’à la fin du délai). Du coup l’action « Désarmer » annule bien l’armement, mais elle renvoie une erreur « la maison est déjà désarmée » avant d’avoir prévenu l’interface, d’où le compte à rebours qui reste figé à 0 alors que l’alarme n’est en réalité pas armée.
En attendant que je corrige ça, reste sur le déclencheur « Alarme armée » : l’alarme s’arme une fraction de seconde puis se désarme proprement, et l’interface se met bien à jour.
Correctif pour ton souci :
J’ai fait 2 améliorations pour toi :
- Correctif sur le bug de désarmement
- Dans les scènes, la condition sur variable affiche les valeurs possibles plutôt que de faire deviner à l’utilisateur 0 et 1
Tous les deux sont live dans la 4.84.4 :
ok j’ai trouvé tout fonctionne comme tu me la expliqué.
j’ai une autre question: j’envoie une demande HTTP GET à un module WiFi perso. ça fonctionne j’envoie le status par sms c’est ok. j’aimerais l’afficher sur le dashboard est ce possible ?
Super, content que ça marche !
Pour ta question : le dashboard ne sait afficher que des appareils, pas des variables de scène. La réponse de ta requête HTTP n’existe que le temps de l’exécution de la scène, donc pour l’afficher il faut d’abord la stocker quelque part. La solution, c’est de créer un appareil dans Gladys et d’y écrire la valeur.
Étape 1 : créer l’appareil
Va dans Intégrations, MQTT. Si tu n’as pas encore de broker, Gladys peut t’en installer un en un clic. Ensuite, dans l’onglet Appareils de l’intégration MQTT, crée un appareil à la main, avec une fonctionnalité correspondant à ce que renvoie ton module :
- une valeur numérique (température, tension, compteur…) : choisis la catégorie qui correspond, par exemple Capteur de température, ou Nombre si c’est une valeur générique
- un statut en toutes lettres : choisis la catégorie Texte
Note bien l’ID externe de l’appareil et celui de la fonctionnalité, ils te serviront à l’étape 3.
Étape 2 : la scène qui interroge ton module
- Déclencheur : « Déclenchement programmé », type « Intervalle », par exemple toutes les 5 minutes
- Action « Requête HTTP » : méthode GET, ton URL
Point important : clique sur le bouton « Essayer ». Si ton module répond du JSON (avec l’en-tête Content-Type: application/json), Gladys lit la réponse et te crée automatiquement une variable par champ. S’il renvoie du texte brut, aucune variable ne sera disponible et tu ne pourras rien réutiliser. Donc si ce n’est pas déjà le cas, fais-lui renvoyer quelque chose comme :
{"status": "ok", "temperature": 21.5}
Étape 3 : écrire la valeur dans l’appareil
Toujours dans la même scène, après la requête HTTP :
- valeur numérique : action « Envoyer une valeur à un appareil », sélectionne la fonctionnalité de ton appareil MQTT, bascule le sélecteur de « Simple » vers « Calculée », puis tape
{{et choisis la variabledata.temperature - valeur texte : l’action ci-dessus n’accepte que des nombres. Utilise à la place l’action « Envoyer un message MQTT », sur le topic
gladys/master/device/TON_ID_APPAREIL/feature/TON_ID_FONCTIONNALITE/text, avec comme message{{puisdata.status. Gladys écoute ce topic et enregistrera la valeur dans la fonctionnalité
Étape 4 : l’afficher
Sur ton dashboard, ajoute une boîte « Appareils » (ou « Appareils dans une pièce ») et sélectionne la fonctionnalité. Si c’est une valeur numérique avec historique, tu peux aussi la mettre dans une boîte « Graphique » ou « Jauge ».
Une alternative plus simple si tu peux modifier le code de ton module
Plutôt que Gladys qui interroge ton module toutes les X minutes, fais publier ton module directement en MQTT sur le topic gladys/master/device/TON_ID_APPAREIL/feature/TON_ID_FONCTIONNALITE/state (avec juste la valeur en payload, ou /text pour du texte). Tu crées l’appareil comme à l’étape 1, et c’est tout : plus besoin de scène, la valeur remonte toute seule dès que le module l’envoie, avec l’historique et les graphiques qui vont avec. Sur un ESP, la bibliothèque PubSubClient fait ça en quelques lignes.
bonjour merci pour ces infos qui m’ont permis de faire fonctionner ce que je voulais
encore un problème qui est apparu; les détecteurs affichent dans le dashboard mouvement détecté quand ils ont été déclenché ce qui est normal mais ensuite affiche le temps depuis qu’ils ont été déclenchés alors qu’auparavant ils affichaient non actif au bout de quelques minutes. comment revenir sur le fonctionnement précédent , qu’est ce qui a changé le fonctionnement originel ?
Salut @bob,
Je suis d’accord j’ai le même problème chez moi 
J’ai fais une PR pour corriger le souci :
Ça sera corrigé dans la prochaine version de Gladys ! Merci du retour !
bonjour , j’ai encore une observation. sur deux scènes je m’aperçois que la condition si- sinon ne fonctionne pas . exemple: je déclenche une scène par réception d’une requête HTTP GET cette scène à pour but de contrôler si tourtes les ouvertures sont fermées avant de passer en mode alarme armée. je fait une récupération du dernier état de toutes les ouvertures je fait un si sinon dans la partition si je fais des conditions sur variables si l’une d’entre elles est sur ouvert je passe le mode alarme en désarmé sinon je passe l’alarme sur armée. la scène ne tient pas compte de la position ouverte d’une des ouvertures , elle passe directement sur le sinon et arme l’alarme alors qu’une fenêtre est ouverte. j’ai aussi eu le même problème avec une autre scène avec une seule condition. que puis-je faire avec ce problème ? je précise je fait des ou dans la partie si.
désolé après recherche de ce qui pouvait se passer , j’ai compris qu’il fallait relancer la page d’accueil de Gladys pour que les élément de conditions soit pris en compte , c’est ce que j’ai fait et tout a fonctionné . bon à savoir quand une scène est récalcitrante le fait de relancer Gladys peut débloquer la situation.