I have an issue with the Alarm Status Table: the shelved tab shows alarms that belong to other projects.
I have no idea how to fix that… I tried the filtering extension function, but it seems to only filter alarms in the active alarms list, not the shelved ones.
The filter properties are not enough, as the user can just get rid of those.
Do I have a misconfiguration somewhere ? Did I miss an option somewhere ?
For now I just filtered the alarms and disabled the option of filtering for the user, but that’s not ideal, especially considering it still shows the number of shelved alarms in the tab title…
Tags are Gateway-scoped, so all projects can see all Tags. If your tags are split into different providers for each project, you could filter on the provider. You could also filter based on the source or Display Path if you happen to have configured your tags in such a way that you can determine which project a tag belongs to by looking at the Source of the tag.
Oh, you’re right - we have not implemented the conditions property for shelved alarms yet. We have an open feature request to provide the same filtering capabilities to both the shelved and active tabs, but it has not been started yet. For now there is no way to filter the shelved tab alarms by provider, source or display path.
Oh… damn.
Any workaround that would provide a bit more flexibility than what I’m doing currently ? Which is imposing a text filter and disabling the option for the user to change that filter…
And an ETA on that feature ?
You could use the filtering present in the extension function: filterAlarm.
Look at the documentation for the Alarm Status Table to learn more about how to use this filter. This could also be modified at runtime if you want to set up some additional components to drive the logic. The downside is this route can impact performance for tag-heavy systems because it executes the logic for all alarms every time the table polls.
I have read that page and did try the filterAlarm extension function, but it seemed to only filter active alarms, not the shelved ones. To make sure of that, I made it return False all the time, and shelved alarms were still showing up.
Did I miss something ?
That sounds like a bug. If that is indeed true, then I'm sorry to say I have no other workarounds for you. I'm not in a position where I can verify the behavior just yet, but I'll try it out first thing when I arrive at the office.
Yes, I was able to replicate it as well. I’ve reached out to Dev to see if this might be expected behavior, because I think shelved alarms might be managed differently and so they might bypass that filtering. I’m waiting to hear back, but regardless, this will not work for you as of right now.
I haven’t gotten a response from the original Dev, so I’ve opened an internal ticket until a determination can be made. If you need to reference this internal ticket at any time (during a Support inquiry, for example), you can supply 2885 as the reference number.
I see that this function is now added with a Extension Function called filterShelvedAlarm
It is documented with some example code.
I struggled a bit working out how to filter on more than one single alarm. Wildcards didnt seem to work. I doubt many are interested in filtering out one specific source string.
# display only shelved alarms from a specific sourcePath:
source = shelvedAlarmEvent.get('sourcePath')
if source == 'prov:default:/tag:myTag/Mode:/alm:myAlarm':
return True
return False
I think it would be smart to update the example to something like this:
# display only shelved alarms containing this sourcePath:
def filterShelvedAlarm(self, shelvedAlarmEvent):
source = shelvedAlarmEvent.get('sourcePath')
if 'prov:myTagProvider:/tag:folder1/folder2/' in source:
return True
return False
It's a jython script, so you can only use what jython knows. It doesn't do wildcards just like that, but you can use regexes. Thought I really wouldn't throw a regex in for this simple case.
They could add examples, but... this is very basic python. They can't just add python courses to the documentation of every function.
Thats a fair point..
Guess I better head over to w3schools and start studying.
They do have an example, and it filters out a single alarm, and I thought that was a bit odd because I don't see any use cases for it.
Started on a post while trying to figure out how to do it. But I found a solution along the way, and decided to post something about how I solved it, incase others were searching the forums for a solution.
There's just one thing you could change: Instead of returning True or False depending on a condition, you could directly return the evaluation of that condition:
return 'prov:myTagProvider:/tag:folder1/folder2/' in source
