@pierre-gilles, ich glaube, ich habe einen Fehler im verzögerten Trigger entdeckt: Ich habe die Option ‹ Verzögerung › bei einem Trigger aktiviert, und es scheint, dass die andere Option ‹ Nur wenn der Schwellenwert überschritten wird › nicht mehr korrekt berücksichtigt wird.
Konkreter Fall: Ich überwache die Temperatur meines Kühlschranks, damit er nicht zu kalt wird. Ich möchte, dass Gladys mich warnt, wenn die Temperatur unter 0°C fällt, aber nur, wenn dies länger als 5 Minuten andauert, ohne die Information bei jeder neuen Messung unter 0°C zu wiederholen.
Ich habe gerade einige Tests durchgeführt, und die Funktion scheint korrekt zu arbeiten. Ich kann kein fehlerhaftes Verhalten reproduzieren.
In deinem Fall, da die Temperaturen um 0°C schwanken, könnte es sein, dass ein Wert wieder auf 0°C zurückkehrt und dann auf -0,1°C, wodurch die Funktion zurückgesetzt wird, da der Schwellenwert erneut überschritten wurde.
Deine Nachrichten können das Problem nicht bestätigen, da deine Nachrichten mit einem „Letzten Zustand abrufen“ ausgelöst werden, der erst nach den 5 Minuten Wartezeit ausgelöst wird. Daher ist es nicht der gleiche Wert wie in dem Auslöser.
Wenn du die Untersuchung vertiefen möchtest, müssten die tatsächlichen Werte, die Gladys erhalten hat, aus deiner Datenbank extrahiert und das gleiche Szenario erneut durchgespielt werden. Aber es liegt an dir zu sagen, ob dies ein Verhalten ist, das du weiterhin beobachtest oder nicht
@pierre-gilles,
Ich bin auf das Problem gestoßen, das du nicht reproduzieren konntest. Daher ist es meiner Meinung nach immer noch vorhanden. Meine neue Situation ist vielleicht einfacher zu reproduzieren:
In Gladys habe ich ein MQTT-Gerät vom Typ „Schalter“ definiert.
Ein Node-Red-Fluss überwacht mein Netzwerk alle 5 Minuten und sendet „0“ oder „1“ an das MQTT-Gerät, abhängig von der Internetverbindung: abwesend oder vorhanden.
In Gladys soll eine Szene ausgelöst werden, wenn das MQTT-Gerät auf 0 wechselt und dies für mindestens 12 Minuten bleibt. Hier ist ihre Konfiguration:
Ich habe gerade einen Test mit genau dem Verhalten gemacht, das du beschrieben hast (aber die Wartezeit auf 1 Minute reduziert, damit es einfacher zu sehen ist)
Danke, dass du dir die Zeit genommen hast, es zu testen, @pierre-gilles. Aber ich bin mir nicht sicher, ob wir genau den gleichen Test durchgeführt haben .
Ich habe überprüft, und meine Vorrichtung schaltet nicht wieder auf 1 zwischen zwei Auslösungen. Da es sich um einen binären Sensor handelt, bin ich mir dessen mit dem grafischen Widget, das den Beginn und das Ende des Zustands ‹ 0 › anzeigt, sicher.
Ich werde versuchen, genau zu beschreiben, was bei mir passiert:
vor 13 Uhr: Die MQTT-Vorrichtung ist auf 1
13 Uhr: Die MQTT-Vorrichtung schaltet auf 0. Die Szene wird nicht ausgelöst (aber im Hintergrund sollte sie beginnen, die 12-Minuten-Auslöseverzögerung zu überprüfen). Verhalten OK.
13:05 Uhr: Die MQTT-Vorrichtung empfängt erneut ‹ 0 ›. Nichts passiert. Verhalten OK
13:10 Uhr: Die MQTT-Vorrichtung empfängt erneut ‹ 0 ›. Nichts passiert. Verhalten OK
13:12 Uhr: Die MQTT-Vorrichtung hat nichts empfangen, aber die Szene wird ausgelöst (12 Minuten nach 13 Uhr). Verhalten OK
13:15 Uhr: Die MQTT-Vorrichtung empfängt erneut ‹ 0 ›. Nichts passiert (aber hier vermute ich, dass der Auslöser erneut beginnt, die 12-Minuten-Verzögerung zu überprüfen). Aber bisher Verhalten OK
13:20 Uhr: Die MQTT-Vorrichtung empfängt erneut ‹ 0 ›. Nichts passiert. Verhalten OK
13:25 Uhr: Die MQTT-Vorrichtung empfängt erneut ‹ 0 ›. Nichts passiert. Verhalten OK
13:27 Uhr: Die MQTT-Vorrichtung hat nichts empfangen, aber die Szene wird ausgelöst (12 Minuten nach 13:15 Uhr). Und genau dieses Verhalten ist nicht konform, da die MQTT-Vorrichtung seit 13:12 Uhr nicht wieder auf 1 geschaltet hat!
Ich habe gerade einen Test gemacht, der noch näher an deinem Fall liegt, indem ich mehrere 0 (während der Wartezeit und nach der Wartezeit) gesendet habe:
Und ich habe das erwartete Verhalten! Entschuldigung
Wenn du weiter untersuchen möchtest, solltest du in den Logs zwei Einträge haben:
2025-05-29T14:40:39+0200 <info> scene.triggers.js:61 (Object.device.new-state) Scheduling timer to check for device_feature "mqtt:connexion-internet-perdue" state in 60000ms
(Start des Timers)
Und:
2025-05-29T14:41:39+0200 <info> scene.triggers.js:43 (Object.device.new-state) Scene trigger device.new-state: Timer for sensor mqtt:connexion-internet-perdue has finished.
(Ende des Timers)
In meinen Tests wird der Timer nur einmal gestartet.
.
