Hello Folks,
I have a type of alarms that should send notifications only during working hours, let's say 8am-6pm.
But, if an alarm triggers outside of this time window, it should wait until 8am and then, if the alarm is still active, start sending notifications.
I'm not sure of how to approach that.
Add to that that notifications are tried n times before being escalated to a different pipeline, and ideally the whole thing should be delayed until the day shift starts.
So I'm once again asking your wisdom.
1 Like
Have you tried something like this yet?
Expression:
timeBetween(now(),"8:00:00 am", "6:00:00 pm")
Theoretically it should keep an alarm in pipeline delay limbo until it finally turns 8AM or until it drops out of the pipeline.
I don't know what this would do to performance if there were many alarms trapped like this though.
2 Likes
I'm a bit worried about keeping many pipelines alive like this, to be honest.
But I guess if delay blocks use their own async thread it could be fine ?
Also another thing that has me worried is how messy it will all be when I try integrating that into the rest of the pipeline. Because there's not just one shift, but only one needs to be delayed like this.
I don't know, I guess it's not as difficult as I'm making it to be, but I'm just struggling to make all the pieces of the puzzle fit together.
This would work, except it won't, because Pipelines have a hardcoded max transition count of 1024 (arbitrarily chosen) to prevent an event cycling through infinitely.
If you increased the delay enough you could sneak in under the limit, at the expense of increasing the possible amount of time after 8:00am before it pops out of the delay block and goes to notify.
edit: oops, read it wrong, even 1 minute should be under the 1024 transition limit. Thought it was 1 second.
3 Likes
Would you say it's the way to go ?
Frankly, even if the notifications start popping up at 8:05 or even 8:10 am, it's probably fine.
I can't think of any other solution. It would be a little simpler but conceptually the same if the Delay block accepted an expression for the delay value... alas.
Yes, I found out bitterly that delay blocks can't take parameters.
Any reason they don't ? Possible improvement in the future ?
Could be an enhancement. The only downside I can really see is that it could make troubleshooting and understanding the current possible state of the pipeline a bit more difficult. That's kind of true anywhere you involve an expression though.
Well I'm using a loop on a 5s delay block, with an iteration counter, checking for counter * 5 >= event['delay'], I doubt a delay block with event['delay'] as argument would make debugging harder
1 Like
Just in case you haven't noticed that yet: You can reverse pipeline blocks orientation. Right click on them, you'll find the option there.
1 Like
