Bug in the new delayed trigger

[StephaneB]

@pierre-gilles, I think I’ve spotted a bug in the delayed trigger: I enabled this ‹ delay › option on a trigger, and it seems the other option ‹ only if the threshold is exceeded › is no longer being taken into account correctly.

Specifically, I’m monitoring my fridge temperature so it doesn’t get too cold. I want Gladys to warn me if it goes below 0°, only if that lasts for more than 5 minutes, and without repeating the information for every subsequent measurement that is still below 0°.

So I have this as the trigger:

But I observe this in my alerts on Telegram:

And over the same period, here is the temperature curve:

The trigger should therefore have fired only once, at 18:37. But not the two following times.

Is my analysis correct?

[pierre-gilles]

Indeed, that’s not normal

I’ve created a GitHub issue:

Scene: Trigger device.new-state with "threshold_only" and "for_duration" is not working correctly

I’ll get back to you as soon as I’ve had a chance to look; given my schedule it’ll probably be in January 2025! (busy end of year!)

[StephaneB]

OK thanks! It’s not critical, so it can wait a bit…

[pierre-gilles]

Hi @StephaneB

I’ve just run some tests, and the behavior seems correct to me. I can’t reproduce any faulty behavior.

In your case, since temperatures are hovering around 0°C, it’s possible that a value goes back to 0°C, then back to -0.1°C, which resets the process because the threshold has been crossed again.

Your messages cannot attest to the bug, because your messages are triggered with a « retrieve the last state » which itself is triggered after the 5-minute wait, so it’s not the same value as the one in the trigger.

If you want us to push the investigation further, you would need to extract from your database the actual values received by Gladys and replay the same scenario, but it’s up to you to tell me whether this is a behavior you continue to see or not

[StephaneB]

Thanks for trying to reproduce it. I’ll take a closer look and get back to you.

[StephaneB]

@pierre-gilles,
I came back across this issue that you hadn’t been able to reproduce. So in my view it is still present. My new situation may be easier to reproduce:

• In Gladys, I defined an MQTT device of type « switch ».
• A Node-RED flow monitors my network every 5 minutes and sends « 0 » or « 1 » to the MQTT device, depending on the internet connection: absent or present
• In Gladys, a scene is supposed to trigger when the MQTT device goes to 0 and remains so for at least 12 minutes. Here is its config:

The issue, when the internet connection is lost and Node-RED therefore sends a « 0 » every 5 minutes, is the following:

• On the first « 0 » received, the scene detects the transition to OFF, and only notifies me 12 minutes later. That’s okay.
• but after those 12 minutes, a new « 0 » received restarts the trigger which activates the scene again 12 minutes later.
• So in practice, the scene triggers every 15 minutes (whereas only the first trigger matters to me)

With this context, can you reproduce it?

[pierre-gilles]

Hi @StephaneB

I just ran a test with exactly the behavior you described to me (but reducing the wait time to 1 minute so it’s easier to see)

The behavior works perfectly for me, only one message received, 1 minute after the first 0 was received:

In my opinion, on your side, the state returns to 1 between the two 0s.

You can investigate using the « graph » widget on a binary sensor to see when it goes from 0 to 1.

[StephaneB]

Thanks for taking the time to test, @pierre-gilles. But I’m not sure we’re doing exactly the same test .

I checked, and my device doesn’t switch back to 1 between two triggers. Since it’s a binary sensor, I’m certain of this thanks to the graph widget that lets you see the start and end of the ‹ 0 › state.

I’ll try to clarify what’s happening on my side:

• before 1:00 PM: the MQTT device is at 1
• 1:00 PM: the MQTT device switches to 0. The scene does not trigger (but in the background it should start checking the 12-minute trigger delay). Behavior OK.
• 1:05 PM: the MQTT device receives ‹ 0 › again. Nothing happens. Behavior OK
• 1:10 PM: the MQTT device receives ‹ 0 › again. Nothing happens. Behavior OK
• 1:12 PM: the MQTT device hasn’t received anything, but the scene triggers (12 minutes after 1:00 PM). Behavior OK
• 1:15 PM: the MQTT device receives ‹ 0 › again. Nothing happens (but this is where I suspect the trigger starts checking the 12-minute delay again). But for now, behavior OK
• 1:20 PM: the MQTT device receives ‹ 0 › again. Nothing happens. Behavior OK
• 1:25 PM: the MQTT device receives ‹ 0 › again. Nothing happens. Behavior OK
• 1:27 PM: the MQTT device hasn’t received anything, but the scene triggers (12 minutes after 1:15 PM). And this is the behavior that is not correct since the MQTT device hasn’t switched back to 1 since 1:12 PM!

Is that what you reproduced?

[pierre-gilles]

@StephaneB

Is that what you reproduced?

Yes, that’s it, and I get the expected behavior

[pierre-gilles]

I just ran a test even closer to your case, by sending multiple 0s (during the timeout, and after the timeout):

And I observed the expected behavior! Sorry

If you want to investigate further, in the logs you should have 2 log entries:

2025-05-29T14:40:39+0200 \u003cinfo\u003e scene.triggers.js:61 (Object.device.new-state) Scheduling timer to check for device_feature "mqtt:connexion-internet-perdue" state in 60000ms

(Starting the timer)

And:

2025-05-29T14:41:39+0200 \u003cinfo\u003e scene.triggers.js:43 (Object.device.new-state) Scene trigger device.new-state: Timer for sensor mqtt:connexion-internet-perdue has finished.

(End of the timer)

In my tests, the timer only starts once

[StephaneB]

Alright, I’ll take another look at it on Saturday or Sunday, I’ll keep you posted.

[pierre-gilles]

Keep me posted!

[StephaneB]

Well, the trigger works perfectly. And it must be me who’s bugged

Sorry for wasting your time, @pierre-gilles

I’ll take this opportunity to close the topic.