Hi, Is there a way to essentially shelve an alarm in perspective before it occurs or disable an alarm for a user-defined time? The idea is that the customer may be performing maintenance and they want to disable alarms, however, they do not want to forget to re-enable them when they have completed the maintenance. They would like to be able to define a time similar to the way shelving works, but prior to an alarm event.
Regards,
Elizabeth
You can use these two API functions in an action script:
https://docs.inductiveautomation.com/display/DOC80/system.alarm.shelve
https://docs.inductiveautomation.com/display/DOC80/system.alarm.unshelve
Thank you for your response. But, I believe in order to use the built-in shelve code, the alarm needs to be active already. The user wants to suppress the alarm before it even occurs. For example, they know the value is going to go outside of normal range while performing maintenance and they want to suppress the alarm for 5 days from when they start the maintenance, not suppress the alarm for 5 days after it occurs. So there is a total time span of 5 days and if the alarm occurs within those 5 days, it needs to be suppressed until the end of the initial span of 5 days. I had an idea of when the alarm enters a pipeline, a script will check to see if the alarm is suppressed and then grab the amount of time (which would need to be calculated at this point to make up the difference between the alarm event and when the user set the suppression ) and then set the alarm as shelved since I now have an alarm event. Please let me know if you see any holes in this approach. I’m going to implement and test the idea in the meantime. Thanks again!
Doing it that way, I would still expect it to show up as an alarm, even if only briefly in your alarm table. You would also still need to store which alarms are shelved somewhere. If you have a lot tags you want to do this to, I don’t see an easy way to do it. If your tags are broken up into groups, you could look at setting a date in a memory tag. Then running an expression on the enable bit for the alarms in the group that you want to disable, to see if your past that date.
My thought is if you want to do it while it isn’t in alarm, I would do it through the enable bit of the alarm. Unless you want to allow it to trigger a momentary alarm.
Thanks for your reply.
I would too expect a blip of an alarm in the alarm status.
I’m confused by why I need to store shelved alarms if I’m using the built-in shelving script?
Enable/disabling an alarm is fine, and already accessible to the user, however, they want a way to suppress/disable for a defined amount of time so that the user doesn’t need to come back and re-enable the alarm, or worse, forget to re-enable. But, as I’m typing this, I’m not sure shelving the alarm is the way to go because even after it clears and the time expires, I will also have a cleared event in addition to the original blip. So, I guess after disabling the alarm, what I could do is maybe a tag change script where it compares time the user entered and the system time and then re-enables alarm automatically?
I just ran a quick test, and I was able to utilize the alarm.shelve API call to shelve an alarm that was not active.
interesting. I was under the understanding that you needed an alarm path, how do you have an alarm path without the alarm? I must be missing something, but that would certainly make my life easier!
Yeah the format of your source address that you pass in would be (I believe it supports wildcards too):
"prov:tagProvider:/tag:tagPath:/alm:alarmName"
Just replace tagProvider, tagPath, and alarmName to match the alarm you need to shelve. For example, if you were using the default tag provider, a tag in the root directory named “My Tag” with an alarm named “My Alarm”, then you would do something like:
paths=["prov:default:/tag:My Tag:/alm:My Alarm"]
system.alarm.shelve(paths, timeoutMinutes=5)
That all makes sense. Thanks!!
I was going off your note about not being able to shelve alarms while their inactive. Where @wrooney says they can be, that would be your easiest solution. I haven’t tried to do it while they are inactive.
If you can’t shelve them, thats where I figured you would need to store a list of when they alarms could be active again or have a tag that references when they can be active again. This list or tag would then be looked at in the script you mentioned, in the alarm pipeline, to determine if the alarm should be shelved. If you don’t have something to reference though, I don’t know how your script would of known which tag should be shelved and for how long.
My thought for disabling the alarm is having a memory tag that you set a date/time in. You can then do an expression on the enable bit for the alarm using dateIsAfter(memory date tag,now()). You would probably want to set a rate for the now() part but I don’t know how often you would want to check.
I see. My plan was that once the alarm went active, it would be in the active pipeline, at which point, I can capture the source path and get the user defined delay from my memory tags and run the shelving script in the pipeline. But as you said, you’d see an alarm come in for a split second, which is not desirable. Issue solved, I must have read something old that said you can’t shelve an inactive alarm. Should have just tested it anyway! Thanks again!
I finally did some testing and found that while I could shelve the alarm before it became active, when the alarm became active, the alarm still showed up in the status table and a notification was sent. Did you have these results or am I missing something? Thanks
I did notice that when I tried to use wildcards *, but it worked as desired when I specified the exact alarm path.
Edit - Just ran another test to be sure. In my case I ran
paths=["prov:default:/tag:4 High:/alm:Alarm"]
system.alarm.shelve(paths, timeoutMinutes=5)
and observed the entry in the shelved alarms list. I then activated the alarm and it did not come into the alarm summary until I unshelved the alarm.
Again, when using wildcards I was unable to suppress the alarm. However, when running the API call with wildcards after the alarm went active I was able to shelve the alarm. So it does indeed look like shelving an alarm before it goes active requires the exact alarm path.
I was also using exact paths, in my case, it makes perfect sense to do so. However, I left out the fact that my tags are from a remote provider. It appears that if the tags are local to the gateway, the API works exactly how you said, but if I try it with my remote tags, it does not work as expected. I am working with tech support on this to see if I may have to do all my alarming locally, but haven’t heard back yet. Do you have an opinion on this as this is the first time I’ve used remote tag providers? I currently have local reference tags to make populating screens much faster in a session, perhaps I need to go one step further and do all my alarming locally as well.
Interesting. I’ve never tried it with a remote tag provider. Depending on what support comes back with, one thing you can try in the meantime is to use system.util.sendMessage to send a message to the remote gateway and provide the tag/alarm that you wish to shelve in the payload. You will have to implement a message handler on the remote gateway that will shelve the alarm for you. If the remote gateway is an Edge gateway I believe you will need the Edge Compute plugin to make this work.