Which alarmEvent Properties Work in Ignition filterAlarm?

Scope of filterAlarm and its prerequisites

The Alarm Status table and the Alarm Journal table both expose a filterAlarm extension function. The component calls it once for every alarm event it is about to display. It passes that event as alarmEvent and expects a boolean back. Return True to keep the row and False to hide it. The function only hides rows. It does not change which alarms the gateway evaluates, which pipelines run, or which records the journal stores.

The built-in code snippet shows only a handful of alarmEvent.get('propertyName') calls. Most of the keys it accepts are defined in the Java class CommonAlarmProperties. The alarm objects are not very script-friendly, so get the key list from that class rather than guessing names.

Before anything else, confirm three things:

1. You have Designer access with the Script Console available.
2. The table component already shows alarms with no filter. Leave filterAlarm empty or returning True.
3. At least one test alarm can be forced active, acknowledged, and cleared on demand.

Do not move on until the unfiltered table shows the test alarm in each state.

Property list dump from the Script Console

Run this in the Designer Script Console:

from com.inductiveautomation.ignition.common.alarming.config import CommonAlarmProperties

for p in CommonAlarmProperties.values():
    print p, p.getType()

Printing CommonAlarmProperties.values() on its own returns the whole array on one line. The loop prints one property per line, followed by its Java type. You need the type later when you write comparisons.

Check: the output lists every name in the table in the next section. If the import fails, recheck the package path character by character. com.inductiveautomation.ignition.common.alarming.config is case-sensitive.

alarmEvent property reference

The dump returns the following names, grouped here by what they answer in a filter.

For numeric duration comparisons, prefer the MS variants (activeDurationMS, ackDurationMS). They avoid parsing a duration object.

Value types inside filterAlarm

Many values are Java objects, not Python strings. priority is an enum. source is a path object. The time fields are dates. A comparison such as alarmEvent.get('priority') == 'High' compares an enum to a string, so it silently returns False. Log the real values before you write any logic:

def filterAlarm(self, alarmEvent):
    log = system.util.getLogger('AlarmFilterDebug')
    for key in ['priority', 'state', 'eventState', 'isAcked',
                'isShelved', 'source', 'displayPath', 'activeDurationMS']:
        v = alarmEvent.get(key)
        log.info('%s = %r  type=%s' % (key, v, type(v)))
    return True

1. Save the function, then trigger the test alarm.
2. Read the log output. For Perspective components, look in the gateway logs. For Vision components, look in the client or Designer output console.
3. Record the type and exact text of each value you plan to filter on.

If a string key raises a type error in your component scope, pass the Property object instead. Build a lookup once from the class:

from com.inductiveautomation.ignition.common.alarming.config import CommonAlarmProperties
PROPS = dict((str(p), p) for p in CommonAlarmProperties.values())
# usage: alarmEvent.get(PROPS['displayPath'])

Check: every key you intend to use logs a non-None value for the live test alarm. Remove the debug loop once you have the values. filterAlarm runs per row on every refresh, and logging there floods the log.

Filter logic and recurring pitfalls

Convert values to strings or primitives before comparing them, and guard against None:

def filterAlarm(self, alarmEvent):
    path = alarmEvent.get('displayPathOrSource')
    path = str(path) if path is not None else ''
    if 'Test' in path:
        return False

    if alarmEvent.get('isShelved'):
        return False

    prio = str(alarmEvent.get('priority'))
    if prio in ('Diagnostic', 'Low'):
        return False

    dur = alarmEvent.get('activeDurationMS')
    if dur is not None and dur < 5000:
        return False

    return True

Use the exact priority text strings you recorded in the logging step.

End-to-end verification

1. Force the test alarm active. Confirm it appears or disappears according to each rule, one rule at a time.
2. Acknowledge it. Confirm that rules based on isAcked, state, or ackUser change visibility as expected.
3. Shelve it, where shelvingAllowed is true. Confirm the shelved-row rule hides it, and that it returns when the shelve expires.
4. Clear it. Confirm rules based on isClear and clearTime behave as expected.
5. Open the Alarm Journal table over the same time window. Confirm the historical records obey the same rules and that no row throws a script error.
6. Check the gateway or client log. Confirm the filter wrote no exceptions during steps 1 to 5, then deploy the component.

FAQ