I have a hypothetical (gold certification exam) system of hundreds of sensors, each sensor is assigned operators, when a sensor faults it is supposed to email the operators assigned to it and allow them to acknowledge it.
Right now it is looking like I’d need to create a new roster through the roster management component every time a new sensor is created, Edit a roster through that component any time the assigned operators change, and have a pipeline with an absolutely insanely sized switch block potentially connected to 100’s of notification blocks each tied to a different roster.
This seems like an absurd method to implement/maintain for the scale of the hypothetical use case, full of duplicated effort for the users and lots of room for errors.
Are there programmatic ways to create/edit a roster and/or dynamically change the roster assigned to a notification block?
I’m now looking at getting this done via python script, basically ignoring the notification block altogether.
Utilizing system.net.sendEmail() and a DB call to get the email addresses of all the users assigned to the sensor (eliminating the need for rosters but on the downside also the ‘on-call’/scheduling functionality)
The only concern is the need for them to acknowledge alarms through the email… if those links are randomly generated this falls apart
Ignition 7.8 has pretty much everything you want here, or will soon.
Rosters in the alarm pipeline block are now expressions, so you can dynamically assign which roster to use in the notification block. Two new scripting functions for rosters have also been added (I see we missed getting them into the docs – I’ll fix that today), which are system.alarm.getRosters() and system.alarm.createRoster()
We also have plans to add the ability to modify (add/remove users) rosters through scripting. Not sure where it is in the priority list, but it should make it into an early version of 7.8
[quote=“KathyApplebaum”]Ignition 7.8 has pretty much everything you want here, or will soon.
Rosters in the alarm pipeline block are now expressions, so you can dynamically assign which roster to use in the notification block. Two new scripting functions for rosters have also been added (I see we missed getting them into the docs – I’ll fix that today), which are system.alarm.getRosters() and system.alarm.createRoster()
We also have plans to add the ability to modify (add/remove users) rosters through scripting. Not sure where it is in the priority list, but it should make it into an early version of 7.8[/quote]
this is music to my ears. I was probably the most upset person in the world when the new alerting system dropped. in our industry, being able to handle changing all of the alarm notification settings in the client on the fly is what is needed. I hope these new changes will accommodate that.
Well that’ll be a great feature to have in 7.8 for sure
Any insights into how the “acknowledge alarm” links are automatically generated in the notification emails? It seems like it’s just a random character string (already unsuccessfully tried to check it against the alarm_events eventID column)
[quote=“rhanleyITG”]Well that’ll be a great feature to have in 7.8 for sure
Any insights into how the “acknowledge alarm” links are automatically generated in the notification emails? It seems like it’s just a random character string (already unsuccessfully tried to check it against the alarm_events eventID column)
The only problem is when a new user is created, you have to create a new pipeline for all the new users, you have to explain in the guide how to do it to pass the test. that works for me, good luck.
Hello Kathy,
I was wondering if the ability to add/remove users in rosters through scripting has ever been introduced. I am running 7.9.7 and it would be very useful for our alarming requirements. Any update would be appreciated. Thanks in advance.
Thank-you for the quick reply. I did review the calculated roster prior to posting. Ideally it would be nice be able to change users via script in the fixed rosters, but I can work around it. Cheers.
It would if a script can pass the user to the calculated roster. But adding a user to a roster that is created in a script the same way the roster is created is needed.
I continue to struggle with creating a dynamic roster, and calculated rosters are not useful as I can not pass in a parameter or read a tag value from it. Another useful option would be to allow multiple rosters in the same notification block, which currently allows only a single roster. Has this been revisited recently?
As example, we have 7 separate locations that receive a notification along with a senior operator on duty every day. We have an alarm pipeline that we dynamically pass a roster in to. There are 1 of 3 (or more) dam operators at each location, either on a weekday or weekend basis, and 1 of 6 senior operators on duty on any day. This equates to 252 rosters for just this notification vs. 7 rosters if I could dynamically change it. Alternatively, If we could at least add multiple rosters into the notification block as an expression that would immensely help.
I can’t see anything that would stop you from reading a tag value (gateway tags, not client tags, obviously) from a calculated roster. And system.alarm.getRosters() would allow you to combine multiple rosters in a calculated roster.