Perspective Alarm Status Filtering

We have the alarm status on popups for the different devices. The alarm status table is in a tab strip container, as an embedded view. One of the params that is passed to the alarm view is the tag to filter on in the table. We are using the filters.active.conditions.source to filter the alarms.

What is happening is when the tab containing the alarm view is clicked, all the active alarms are shown, and then the filter is applied. Is this supposed to be happening that way? Any way we can get it to apply the filter when it is shown on the first update of the alarms?

We are in development on this stuff so there isn’t a ton of alarms but for the future site this could be a big deal.

See gif:
Alarm Status Perspective

1 Like

We had the same behaviour and it was fixed in 8.1

I still see this in 8 1.0,and sometimes the filter doesn’t apply at all…

I’m on 8.1.1 nightly and seeing this… so I’m not sure it’s totally fixed yet.

Following. Seeing the same on 8.1 on linux.

It will read this value upon initialization and then proceed to listen for changes to the property. Setting a binding to persistent is the recommend way to ensure that the value is saved with the component config and loaded upon component initialization.

You could try using the new filterAlarm extension function that is available for both alarm tables, but I’m not sure how useful that would be since there seems to be a delay between when the filter is updated via params.

I’d might suggest adjusting the refreshRate of the alarm table to decrease the delay and improve the experience. Changing the refreshRate changes the interval in which the backend of the component queries alarms. When a difference is detected between the previous data set, the backend will send the data to the front end to process and display.

On initial load though, it should apply the alarm filter right away, not wait for the refresh period to apply, no? Or is this not possible?

That’s what I would assume it would do as well @nminchin.

By making props.filters.active.conditions.source and props.filters.active.conditions.provider to persistent as @ynejati suggests it does help. My situation is that those are dynamic based on the popup, so I’ve set them to be something very unusual and set for persistent. So now the alarm list is empty until a refreshEvent happens.

2 Likes

Same as me re popups. That sounds like the best solution at the moment, rather than showing all alarms briefly and then filtering. Ill give it a go, cheers!

If you come up with a better solution let me know. This is the best that we can do right now. It is annoying because I’ve got it in a tab container, so everytime the tab is switched off the alarm tab and then back it re-does the filtering. Again not as clean as Vision but better than showing 100s of alarms.

Okay, I see what you guys are saying. We will look into this in hopes of making the experience better. Thanks.

2 Likes

Hi Everyone,

i'm on 8.1.2 and when setting the filter to persistent the problem of seeing the all list of alarms and that filter sometime doesn't apply is solved.

By the way in 8.1.3 the alarm status and journal will support translations terms.
Glad to see that when you ask a functionality gentlly you got it :slight_smile:

I ran into this issue this week. What I noticed is I can add a button and script:

self.getSibling("AlarmStatusTable").refreshBinding("props.filters.active.conditions.source")

When I click the button the table immediately refreshes with the filter. But, running this in a change script or onStartup script doesn’t seem to have any effect. I know the script is working as I’m printing to console.

I feel refreshing would be a good workaround, if it worked correctly. Clicking the button obviously isn’t a solution. Any suggestions on getting the refresh binding to work besides in a button?

I have also just ran into this issue.
Did anyone figure out a solution here?