Hello
One of our clients has expressed concern about alarm status loading times. On the perspective alarm status table they can take over 10 seconds to load.
Upon investigation it seems that the alarm status table was returning all alarms, including cleared-acked ones. This meant to display the e.g. 3 active / unacknowledged alarms we actually care about Ignition was pulling around 570 pages of alarms.
Currently we use the props.filters.active.conditions.{source,provider} for filtering, which according to the documentation (and network traffic) are handled on the gateway, and these are relatively quick. On the other hand, the props.filters.active.states filters which we use to filter out clear-acked alarms seem to only take place on the client (based on HTTP/WS network traffic), which would explain why so many alarm events are being fetched.
In order to try filtering on the gateway I had used a filterAlarm script on the status table - however it did not seem to be any faster. It did reduce the payload size from ~10MB to ~20KB which would imply that it was doing what I wanted - just no faster than before. I imagine that running a Python script around 10,000 times (for each alarm) isn’t particularly fast?
Is there any way to filter based on the alarm state on the gateway side for the alarm status?
Thanks