Counting Ignition Active Alarms with queryStatus()

A call to system.alarm.queryStatus returns a list of alarm event objects, so the count of active alarms is len() of that list. No method on the alarm event object is needed. If you want a gateway-wide total with no script at all, add two gateway system tags instead.

Which method returns the active alarm count?

Two approaches produce the number. They differ in scope, filtering, and where the work runs.

Recommendation: use the tags when the requirement is a gateway-wide active total on a display or in an expression. Use len() on queryStatus when the count must be scoped to a source or display path, or when the script also needs the alarm details.

Why does queryStatus show rows in a table but give no count?

The table component renders the query result for display. It never hands the script a number. The script-side return value is a plain list with one element per alarm event, and Jython's built-in len() reports the element count of any list. The methods on the alarm event object describe a single alarm (its properties and state), not the collection, so searching them for a count method finds nothing. The object's methods are thinly documented, which is why the count is easy to miss.

How does each count travel from the alarm engine to your script?

Both paths originate at the gateway alarm journal and status engine. They differ in what crosses the client-to-gateway link.

The consequence: a broad queryStatus call moves one object per alarm just to produce a single integer. With a large active-alarm population, the tag path carries the same answer as one value per state.

How do I count active alarms in a script?

1. Decide the scope. Whole gateway: skip to the tag method below. Subset: build the source and/or display path filter for the call. Check the function's signature in the scripting reference for the exact filter argument names.
2. Query with both active states so acknowledged and unacknowledged alarms are both included:

   alarms = system.alarm.queryStatus(state = ["ActiveAcked", "ActiveUnacked"])
   print len(alarms)

3. Add the source or display path filter arguments to the same call when the count must be limited to one area.
4. Use len(alarms) wherever the number is needed (label text, tag write, conditional logic).

Tag method for the gateway-wide total: browse System/Gateway/Alarming/ in the tag browser and read the four state counters: Active and Acked, Active and Unacked, Clear and Acked, Clear and Unacked. Active alarms on the gateway equal the first two added together. Confirm the exact tag names in your tag browser before writing expressions against them.

What makes the count wrong?

• No state filter. A query without the two active states returns alarms in other states as well, so len() overstates the active total. Pass state explicitly.
• Summing all four tags. The four counters cover active and clear alarms. Only the two Active counters give the active total.
• Comparing different scopes. A filtered queryStatus count is a subset. It matches the gateway tags only when no source or display path filter is applied.
• Snapshot timing. The list is the alarm state at call time. An alarm that changes state after the call is not reflected until the next query.
• Python 2 syntax. The example uses Jython, where print len(alarms) is valid. Use print(len(alarms)) if you prefer the parenthesized form.

How do I verify the count is correct?

1. Run the unfiltered active query and print len(alarms) in the script console.
2. Read Active and Acked and Active and Unacked under System/Gateway/Alarming/ and add them. The sum must equal len(alarms).
3. Acknowledge one active alarm. Active and Unacked must drop by one and Active and Acked must rise by one, while the sum and a re-run len(alarms) stay unchanged.
4. Add your source or display path filter and confirm the filtered len() matches the number of rows the same query shows in the table.