Alarms Count

Use this node to count alarms matching configured criteria and write the count as telemetry — for example, maintaining a real-time activeAlarmCount metric on a device asset that increments when new alarms are created and decrements when they are cleared, or tracking how many critical alarms occurred in the last 24 hours.

Configuration

Output message type — type of the messages the node generates with the counts. Defaults to POST_TELEMETRY_REQUEST.
Count alarms for propagation entities — when enabled, counts alarms not only for the message originator but also for all entities to which those alarms are propagated.
Propagation entity types — shown when the option above is enabled. Counts alarms only for propagated entities of the selected types, like assets or customers. Leave empty to count for all propagated entities. The originator is always counted.

Alarms count mappings

A table where each row defines one alarm count metric:

Field	Description
Target telemetry	Key name on the entity where the alarm count is stored
Status filter	Restrict to alarms with specific statuses (e.g., `ACTIVE_UNACK`). A mix such as `ACTIVE_UNACK` and `CLEARED_ACK` counts alarms of every status. Leave empty to include all statuses.
Severity filter	Restrict to alarms with specific severities (e.g., `CRITICAL`, `MAJOR`). Leave empty for all severities.
Type filter	Restrict to alarms of specific types. Leave empty for all types.
Specify interval	When enabled, only count alarms created within a configured time interval.

Message processing algorithm

Receive an alarm-related message: ALARM, ALARM_CREATED, ALARM_UPDATED, ALARM_SEVERITY_UPDATED, ALARM_ACK, ALARM_CLEAR, or ENTITY_CREATED / ENTITY_UPDATED about an alarm.
For each mapping row, execute an alarm count query against the originator entity (and propagated entities if configured), applying the status, severity, type, and time interval filters.
For each counted entity, generate one message of the configured Output message type (POST_TELEMETRY_REQUEST by default) with that entity as the originator and the counts as data.
Route generated messages via Success. If any count query fails, the node sends no count messages for any entity and routes the incoming message via Failure.

Output connections

Connection	Condition
`Success`	Generated message (`POST_TELEMETRY_REQUEST` by default) with the alarm counts, one per counted entity; the incoming alarm message itself isn’t forwarded. Messages that aren’t alarm-related pass through unchanged.
`Failure`	A count query failed. The incoming message is routed with the error, and no count messages are sent.

JSON schema

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "TbAlarmsCountNodeV2Configuration",
  "type": "object",
  "additionalProperties": true,
  "properties": {
    "outMsgType": { "type": "string" },
    "countAlarmsForPropagationEntities": { "type": "boolean" },
    "propagationEntityTypes": { "type": "array", "items": { "type": "string" } },
    "alarmsCountMappings": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "target": { "type": "string" },
          "statusList": { "type": "array", "items": { "type": "string" } },
          "severityList": { "type": "array", "items": { "type": "string" } },
          "typesList": { "type": "array", "items": { "type": "string" } },
          "latestInterval": { "type": "integer", "description": "Interval in milliseconds; 0 counts alarms of any age." }
        }
      }
    }
  }
}

Was this helpful?