Notification scheduler on conditions that uses .removeShorterThan()

[Joel Korpi]

Hello.

As the title states I am curious about the interaction between condtions that have notifications enabled and the .removeShorterThan() formula. 

In this arbitrary example I have a condition that checks if the signal goes above 361,85. With notifications enabled it's scheduled to send me an email every 15 minutes when the condition is true. Here's a comparison image between using simple value search ($signal >= 361.85) as condition, and using ($signal >= 361.85).merge(1min).removeShorterThan(5min) as condition.

 

Does the .removeShorterThan(5min) condition make it so that capsules are only saved after 5 minutes have passed? i.e would I receive an email from when the condition starts to be true, even if it has not reached 5 minutes in duration yet, or is there at least a 5 min delay before I get notified?

Best regards,

Joel

[Dan FR]

Hi Joel, 

Thanks for the question.  Yes, your understanding is correct in that a capsule is only "saved" after it has exceeded the duration specified in the .removeShorterThan() function, 5 minutes in your case.  However there is a bit more nuance here when using Notifications and when capsules are in-progress but not yet completed. 

The .removeShorterThan() function applies to completed capsules only.  This means the function will evaluate and potentially remove capsules based on their duration only after the capsule has completed.  Therefore in progress capsules are not affected by this function until they are completed and their duration can be assessed.

Now layering in Notifications, this means there could be a situation where your condition is true ($signal >= 361.85), and a capsule is in progress but not yet completed, triggering an email notification.  In these cases, Seeq will still trigger an email notification even if the capsule has not yet reached 5 minutes duration, or whatever is specified in .removeShorterThan().  Since the capsule has not been completed, Seeq does not yet know what the total duration will be and will send the notification.  

This scenario can also result in the unintended effect of sending a notification triggered by an in-progress capsule which is then subsequently removed by the .removeShorterThan() function.  

To ensure your email notifications avoid this scenario we can adjust your condition to only include completed capsules.  Try the following example syntax:

$condition = ($signal >= 361.85).merge(1min).removeShorterThan(5min) // Your original condition

$condition.inside(past().move(-1s))

In this example we use .inside() to filter your initial condition to only include capsules which are completed in the past.  The past() function creates a condition with a single capsule that extends until now.  This past capsule will include now(), so I have added the .move(-1s) function to shift it backward in time by 1 second in order to exclude now().  If you wanted to have a 5 minute delay, replace -1s with -5min.

I hope this helps and provides some clarity into how .removeShorterThan() interacts with notifications.  Let me know if I can help with anything else.

Regards, 

Dan

[Joel Korpi]

Hey Dan,

Thanks for the clarification. I will experiment a bit with the condition your provided and see what strikes a good balance!

[Patrick]

Another operator to try is 

certainonly()

which should exclude in-progress capsules.