Can users opt-out of specific alarm notifications?

Ignition
,
1

I would like to include a way for each individual user of a system to opt-out of specific alarms.

The opt-outs must be configurable through the HMI (Vision or Perspective)
Ie. The configuration changes can be made without using the Designer or Gateway UI.

For example, Bill only wants to receive alarms for Pump Station 1, and John only wants to receive alarms for Pump Station 2

Bill would go into an “Alarm Configuration” page and disable the Pump Station 2 alarms for himself, then disable Pump Station 1 alarms for John

When an alarm at Pump Station 1 goes active, only Bill will be notified, and vice-versa with John at Pump Station 2

Is this natively possible with Ignition, or are there any third-party libraries that provide enhancements like this to the alarming system?

2

Hi, this functionality can be achieved in both Vision and Perspective by modifying the On-Call Rosters that the alarm notifies. A user can modify rosters in Vision with the Roster Management component. This can be done in Perspective via scripting with the system.alarm functions.

1 Like
3

I don't think using rosters for the level of customisation requested here is the way to go. In the example, there would need to be rosters created for every single device which could be a maintenance nightmare. I think what might be a better approach, without thinking about it too hard, is to use a table to store a list of tagPaths to ignore for particular users, and then look this up in the pipelines.

Edit: this might all be a brain fart since all users in a roster are notified as opposed to being able to single out individual users

4

From what I can see, the roster is basically just a collection of users with no direct association with alarms. When an alarm enters the pipeline, how do I leverage the rosters to know which roster needs to receive the notification? Keeping in mind, this has to be scalable with X amount of alarms and Y amount of users.

5

That's what I was thinking as well, adding an additional layer of configuration via a table. Of course the common caveat there, relying on tag paths, is if the tag is moved from one folder to another then associated configurations are corrupted.