Filter Alarm List by Alarm Response

[rlao]

Hi all,

I am working on a request to implement an alarm list that only shows acknowledged alarms that have no response. The idea is that the operator on shift can easily go through the un-responded alarms and enter responses or follow up with whoever acknowledged the alarm. Initially I thought this would have been fairly simple but ended up getting stuck.

As far as I can see, the alarm list object does not have any filtering options for alarm responses, but happy to be proven wrong on this one.

I tried building an SQL list on CAlarm based off the Response field. This gave me the results I was looking for but the ID field for CAlarm is on the object containing the alarm, not the alarm itself. This means that the pick action on the SQL list row just brings up the object menu rather than the alarm menu. The object menu does not contain an action to respond to the alarm.

Just wondering if there is a way to build a list that shows acknowledged un-responded alarms and provides a pick action to enter a response to the alarm from that list directly?

Thanks

[sbeadle]

Hi, there's no filter string which can operate on the alarm response.

[sbeadle]

Changed to Informational.

[AdamWoodlandToo]

For anyone stumbling across this in the future such as future me, we solved it by:

1. Creating a suitable SQL query (which includes the fullname and condname) on CAlarm to show the active alarms without a response, and showing it as an embedded list on a mimic

2. Creating a script, that runs on click of the list, that just pops up a response menu option

3. That menu option just uses the CurrentRowIdx property of the embedded list, runs a Server.Query with the exact same SQL as the list, pulls out the specific row from the query, selects the relevant fullname and condname columns from the row and then calls SetAlarmResponse

About 10 lines of actual mimic script surrounded by sanity checks, error handling, etc.

Can't use CurrentRowId as possible to have multiple alarms for the same object.

[rlao]

To provide further updates on this: CurrentRowIdx presented issues because alarms could get raised or acknowledged between the initial loading of the list and the re-query on user pick action. This meant the row order would change on the re-query and lead to unrelated alarms getting responded to.

Changing to CurrentRowId resolves this since the re-query will track the object even if the re-queried result set is different to the initial one. Yes, multiple alarms on one object is not handled properly, but in our case that scenario is a rare occurrence given our setup. Unfortunately, I don't believe there is a better way to track the row selection for embedded lists.