desencadenante: alarma en curso de armado
condición: si todos los detectores de apertura están « cerrados » (y/o) los de movimiento están inactivos.
¿imposibilidad de ver el estado de un detector en la función si?
Puedes hacerlo con un bloque « Obtener el último estado » + « Condición sobre variables » 
Para hacer un « Y », solo tienes que poner varias condiciones, ¡funcionará!
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 Cerrado entonces paso la alarma a desarmada, envío un sms para señalar la ventana abierta sino: envío un sms alarma armada. resultado: que el detector esté en abierto o cerrado el temporizador se queda en 0 y no pasa nada. es un problema grave cómo se puede armar una alarma con una ventana o una puerta abierta, más aún si se quiere usar la alarma en modo parcial.
si pongo como desencadenante: alarma armada al final de la cuenta atrás, la alarma pasa a modo desarmado tanto si el detector está abierto como cerrado y no recibo ningún mensaje. Creo que voy a buscar otra solución para reemplazar mi alarma que ya no me será útil, ya que los operadores abandonan la 2G. Estoy un poco decepcionado, esta solución me gustaba.
¡Qué aventura! De hecho, acabo de probar con los valores 1 o 0 en lugar de Abierto y Cerrado, y funciona con el disparador de alarma armada. Si uso como disparador alarma en curso de armado, funciona, pero si la ventana está abierta, bloquea la cuenta regresiva en cero, pero no activa la alarma. Podemos decir que el problema está en gran parte resuelto.
¡Bien jugado al encontrar con 0 y 1! Te explico el porqué y cómo terminar de hacer funcionar tu escenario
1. ¿Por qué « Abierto » / « Cerrado » no funcionaba
El bloque « Condición sobre variables » compara el valor bruto almacenado por Gladys, no el texto mostrado en la interfaz. Para una funcionalidad binaria, el valor siempre es 0 o 1, y « Abierto »/« Cerrado » es solo la traducción mostrada en pantalla. Al ser la comparación estricta, "Cerrado" (texto) nunca es igual a 1 (número): la condición nunca se validaba y la escena se detenía silenciosamente, de ahí tu « no pasa nada ».
Los valores a usar:
| Tipo de sensor | 0 | 1 |
|---|---|---|
| Detector de apertura | Abierto | Cerrado |
| Detector de movimiento | Sin movimiento | Movimiento detectado |
2. ¿Y o O?
Pequeña precisión con respecto a mi respuesta anterior: dentro de un mismo bloque « Condición sobre variables », las condiciones están conectadas por un O (el bloque pasa tan pronto como una sola es verdadera). Para hacer un Y, hay que añadir varios bloques « Condición sobre variables »: entonces todos deben ser validados para que la escena continúe. Esto se recuerda directamente en la interfaz desde la 4.84.3.
En tu caso, el O es justo lo que necesitas: quieres cancelar el armado si al menos un sensor está en defecto. Por lo tanto, un solo bloque de condición, con una línea por sensor:
Puerta de entrada - Apertura=0Ventana de la sala - Apertura=0Detector de la sala - Movimiento=1
3. La escena completa
- Disparador: « Alarma armada » (fin del temporizador)
- « Recuperar el último estado »: un bloque por sensor (deben estar encima del bloque de condición, de lo contrario las variables no aparecen en la lista desplegable, esto responde a tu pregunta « imposibilidad de ver el estado de un detector en la función si? »)
- « Condición sobre variables » con las líneas anteriores
- « Enviar un mensaje »
- « Cambiar el modo de la alarma » → Desarmada
Pon bien el envío del mensaje antes del desarme.
4. El error que encontraste con « Alarma en proceso de armado »
Allí te encontraste con un error real de Gladys, no eres tú: durante el temporizador, la casa aún está registrada como « desarmada » en la base (solo pasa a « armada » al final del plazo). Por lo tanto, la acción « Desarmar » cancela el armado, pero devuelve un error « la casa ya está desarmada » antes de haber notificado a la interfaz, de ahí el temporizador que se queda congelado en 0 mientras que la alarma no está armada en realidad.
Mientras tanto, quédate con el disparador « Alarma armada »: la alarma se arma una fracción de segundo y luego se desarma correctamente, y la interfaz se actualiza correctamente.
Solución para tu problema:
He hecho 2 mejoras para ti:
- Corrección del error de desarme
- En las escenas, la condición sobre la variable muestra los valores posibles en lugar de hacer adivinar al usuario 0 y 1
Ambas están en vivo en la 4.84.4:
vale, lo encontré todo funciona como me lo explicaste.
tengo otra pregunta: envío una solicitud HTTP GET a un módulo WiFi personal. Funciona, envío el estado por SMS, está bien. Me gustaría mostrarlo en el panel de control, ¿es posible?
¡Genial, funciona!
Para tu pregunta: el panel solo puede mostrar dispositivos, no variables de escena. La respuesta de tu solicitud HTTP solo existe durante la ejecución de la escena, por lo que para mostrarla primero debes almacenarla en algún lugar. La solución es crear un dispositivo en Gladys y escribir el valor en él.
Paso 1: crear el dispositivo
Ve a Integraciones, MQTT. Si aún no tienes un broker, Gladys puede instalar uno por ti con un clic. Luego, en la pestaña Dispositivos de la integración MQTT, crea un dispositivo manualmente, con una funcionalidad que corresponda a lo que devuelve tu módulo:
- un valor numérico (temperatura, voltaje, contador…): elige la categoría que corresponda, por ejemplo Sensor de temperatura, o Número si es un valor genérico
- un estado en texto: elige la categoría Texto
Anota el ID externo del dispositivo y el de la funcionalidad, los necesitarás en el paso 3.
Paso 2: la escena que consulta tu módulo
- Disparador: « Disparo programado », tipo « Intervalo », por ejemplo cada 5 minutos
- Acción « Solicitud HTTP »: método GET, tu URL
Punto importante: haz clic en el botón « Probar ». Si tu módulo responde con JSON (con el encabezado Content-Type: application/json), Gladys lee la respuesta y te crea automáticamente una variable por campo. Si devuelve texto sin formato, no habrá variables disponibles y no podrás reutilizar nada. Por lo tanto, si no es así, haz que devuelva algo como:
{"status": "ok", "temperature": 21.5}
Paso 3: escribir el valor en el dispositivo
Siempre en la misma escena, después de la solicitud HTTP:
- valor numérico: acción « Enviar un valor a un dispositivo », selecciona la funcionalidad de tu dispositivo MQTT, cambia el selector de « Simple » a « Calculada », luego escribe
{{y elige la variabledata.temperature - valor de texto: la acción anterior solo acepta números. Usa en su lugar la acción « Enviar mensaje MQTT », en el tema
gladys/master/device/TU_ID_DISPOSITIVO/feature/TU_ID_FUNCIONALIDAD/text, con el mensaje{{luegodata.status. Gladys escucha este tema y registrará el valor en la funcionalidad
Paso 4: mostrarlo
En tu panel, añade una caja « Dispositivos » (o « Dispositivos en una habitación ») y selecciona la funcionalidad. Si es un valor numérico con historial, también puedes ponerlo en una caja « Gráfico » o « Medidor ».
Una alternativa más simple si puedes modificar el código de tu módulo
En lugar de que Gladys consulte tu módulo cada X minutos, haz que tu módulo publique directamente en MQTT en el tema gladys/master/device/TU_ID_DISPOSITIVO/feature/TU_ID_FUNCIONALIDAD/state (con solo el valor en el payload, o /text para texto). Crea el dispositivo como en el paso 1, y listo: no necesitas escena, el valor se actualiza automáticamente tan pronto como el módulo lo envía, con el historial y los gráficos correspondientes. En un ESP, la biblioteca PubSubClient hace esto en pocas líneas.
hola, gracias por esta información que me ha permitido hacer funcionar lo que quería
otro problema que ha surgido: los detectores muestran en el panel de control ‹ movimiento detectado › cuando se activan, lo cual es normal, pero luego muestran el tiempo transcurrido desde que se activaron, mientras que antes mostraban ‹ inactivo › después de unos minutos. ¿cómo volver a la funcionalidad anterior? ¿qué ha cambiado la funcionalidad original?
Hola @bob,
Estoy de acuerdo, tengo el mismo problema en mi casa 
He hecho una PR para corregir el problema :
¡Se corregirá en la próxima versión de Gladys! ¡Gracias por el comentario!
hola, tengo otra observación. En dos escenas me doy cuenta de que la condición si-sino no funciona. Por ejemplo: activo una escena al recibir una solicitud HTTP GET. El propósito de esta escena es verificar si todas las aperturas están cerradas antes de pasar al modo alarma armada. Recupero el último estado de todas las aperturas. En la parte si-sino de la partición, hago condiciones sobre variables. Si alguna de ellas está abierta, pongo el modo alarma en desarmado. Si no, pongo la alarma en armada. La escena no tiene en cuenta la posición abierta de una de las aperturas, pasa directamente al sino y arma la alarma aunque una ventana esté abierta. También he tenido el mismo problema con otra escena con una sola condición. ¿Qué puedo hacer con este problema? Aclaró que hago operaciones OR en la parte si.
disculpa, después de investigar qué podía pasar, entendí que había que volver a cargar la página de inicio de Gladys para que los elementos de las condiciones se tuvieran en cuenta. Es lo que hice y todo funcionó. Bueno saber que cuando una escena es rebelde, volver a cargar Gladys puede desbloquear la situación.