@pierre-gilles, creo que he detectado un defecto en el disparador con retraso: He activado la opción ‹ retardo › en un disparador, y me parece que la otra opción ‹ solo si se supera el umbral › ya no se tiene en cuenta correctamente.
Concretamente, estoy monitorizando la temperatura de mi nevera para que no esté demasiado fría. Quiero que Gladys me avise si baja de los 0°, pero solo si esto dura más de 5 minutos, sin repetir la información en cada nueva medición que siga por debajo de 0°.
Acabo de hacer algunas pruebas y parece que funciona correctamente. No logro reproducir un mal funcionamiento.
En tu caso, como las temperaturas oscilan alrededor de 0°C, es posible que un valor vuelva a 0°C y luego vuelva a -0.1°C, lo que reinicia el funcionamiento ya que el umbral se ha vuelto a cruzar.
Tus mensajes no pueden certificar el error, ya que tus mensajes se activan con un « obtener el último estado » que se activa después de los 5 minutos de espera, por lo que no es el mismo valor que el del disparador.
Si quieres que sigamos investigando, tendríamos que extraer de tu base de datos los valores reales recibidos por Gladys y reproducir el mismo escenario, pero bueno, dime si es un comportamiento que sigues viendo o no
@pierre-gilles,
He vuelto a encontrar el problema que no habías logrado reproducir. Por lo tanto, según yo, sigue presente. Mi nueva situación puede ser más fácil de reproducir:
En Gladys, he definido un dispositivo MQTT de tipo « interruptor ».
Un flujo de node-red monitorea mi red cada 5 minutos y envía « 0 » o « 1 » al dispositivo MQTT, según la conexión a internet: ausente o presente.
En Gladys, una escena debería activarse cuando el dispositivo MQTT pasa a 0 y se mantiene así durante al menos 12 minutos. Aquí está su configuración:
Acabo de hacer una prueba con exactamente el comportamiento que me has descrito (pero reduciendo el tiempo de espera a 1 minuto para que sea más fácil de ver)
Gracias por tomarte el tiempo de probar, @pierre-gilles. Pero no estoy seguro de que estemos haciendo exactamente la misma prueba .
He verificado, y mi dispositivo no vuelve a 1 entre dos activaciones. Como es un sensor binario, estoy seguro de ello con el widget gráfico que permite ver los inicios y finales del estado ‹ 0 ›.
Voy a intentar precisar lo que ocurre en mi caso:
antes de las 13h: el dispositivo MQTT está en 1
13h: el dispositivo MQTT pasa a 0. La escena no se activa (pero en segundo plano debe comenzar a verificar el retraso de activación de 12 minutos). Comportamiento correcto.
13h05: el dispositivo MQTT recibe ‹ 0 › nuevamente. No pasa nada. Comportamiento correcto.
13h10: el dispositivo MQTT recibe ‹ 0 › nuevamente. No pasa nada. Comportamiento correcto.
13h12: el dispositivo MQTT no ha recibido nada, pero la escena se activa (12 minutos después de las 13h). Comportamiento correcto.
13h15: el dispositivo MQTT recibe ‹ 0 › nuevamente. No pasa nada (pero es aquí donde sospecho que el activador comienza nuevamente a verificar el retraso de 12 minutos). Pero por ahora, comportamiento correcto.
13h20: el dispositivo MQTT recibe ‹ 0 › nuevamente. No pasa nada. Comportamiento correcto.
13h25: el dispositivo MQTT recibe ‹ 0 › nuevamente. No pasa nada. Comportamiento correcto.
13h27: el dispositivo MQTT no ha recibido nada, pero la escena se activa (12 minutos después de las 13h15). Y es este comportamiento el que no es conforme, ya que el dispositivo MQTT no ha vuelto a 1 desde las 13h12.
¡Y tengo el comportamiento esperado correcto! Lo siento
Si quieres investigar más, en los registros debes tener 2 registros:
2025-05-29T14:40:39+0200 <info> scene.triggers.js:61 (Object.device.new-state) Programando temporizador para verificar el estado de device_feature "mqtt:connexion-internet-perdue" en 60000ms
(Iniciar temporizador)
Y:
2025-05-29T14:41:39+0200 <info> scene.triggers.js:43 (Object.device.new-state) Scene trigger device.new-state: El temporizador para el sensor mqtt:connexion-internet-perdue ha finalizado.
(Fin del temporizador)
En mis pruebas, el temporizador solo se inicia una vez
.
