How to only send alarms via pipeline during business hours if non-critical?

Ignition
1

I’m a bit stumped, but how would I delay sending an alarm notification out that’s outside of business hours until the start of the next day?

There are two ways I can see to do this, but both seem extremely hacky/dodgy and not intuitive especially for someone with less experience:

  1. Use a script to check the timestamp of the alarm and just do a time.sleep(start_of_business - alarm_timestamp) (psuedocode)

or by using lots of CPU:

  1. Use the delay block to delay by something like 1min and keep checking if the current time is within business hours before proceeding (as this block doesn’t accept a binding on its delay time)

With the script sleep method, what happens to the thread running the sleep if the alarm clears before the start of business? does it just keep running until the sleep ends, or does the thread get canned?

Is there any better way to do this?

2

Alarm already logged in your DB, you can query your Table and get all required alarming based on the required time then activate the pipeline to send a notification based on your flow.
using system.alarm.queryJournal will help to get the required alarms outside Bussiness Hours.

https://docs.inductiveautomation.com/display/DOC81/system.alarm.queryJournal

3

I won’t need to retrospectively send notifications for alarms that occur outside of business hours that aren’t still active start business hours resume; I only want to send those that are still active when back in business hours again.

4

let’s say starting Business hour at 8 AM morning,
Yesterday outside business hours means before 8 am, there was10 Alarms still active.
you need to send these alarms Only.
my idea, if I understand the question righ :smirk:t I will creat gateway script run at 8 Am daily at the beginning of the Business Hours To filter all alarms with eventtype=0 [Active] then send a notification to the users.

5

I don’t think the delay 1 minute - loop method actually would consume a lot of CPU. There’d be a small amount of memory kept active as the pipeline is kept alive, but it’s not going to be very significant, I’d wager. The CPU involved is miniscule - just waking up the thread for a time check, then continuing to delay.

6

I’m thinking more when scaling the architecture out and we have 10’s of thousands of potential alarms. I mean, worst case there still most likely wouldn’t be that many active all at once so maybe I’m thinking too much into it :man_shrugging:
I’ll see how the delay 1min goes, otherwise, so you know about the scripted time.sleep method if the thread will be halted if the alarm is cleared?

7

I would expect Thread.sleep to have significantly worse performance implications. I don’t know offhand how alarming notifications execute, but I would expect that it’s basically a queue of worker threads. If you use delays, then a worker simply has to grab the pipeline, check the condition, then put it away. If you use Thread.sleep, then you’re explicitly telling the thread that it must stay active (on your task) and can’t be used for anything else.

1 Like
8

Awesome, that solves that then. Delays it is! Cheers.

Also @tamerplc, while I could also use a separate gateway timer script to check active alarms and manually notify users, this would also mean duplicating the same business logic as in my pipelines. This would become an issue when someone coming new to the project looks at it years later, as they wouldn’t expect this to be done outside of the alarm pipelines. Thus the logic would become stale and out of sync with the logic in the pipelines until someone eventually picks up on it.