Alarm count with highest severity

Who it’s for

Tenant administrators and solution engineers asking “how many alarms are active on this asset right now?” and “what is its highest severity active alarm?” — when the goal is to keep a live alarm summary on the entity itself, so dashboards, entity tables, and downstream rules can read it as ordinary attributes and time series.

What it does

Extends the default ThingsBoard root chain with the alarm-summary flow on the Alarm Created, Alarm Cleared, and Alarm Severity Updated outputs of Message Type Switch:

• Count Alarms By Severity — the Professional Edition alarms count node — recounts the originator’s active alarms, both Active Unacknowledged and Active Acknowledged, and produces one message with six counters: criticalCount, majorCount, minorCount, warningCount, indeterminateCount, and the total alarmCount. Counting also covers the entities the alarm propagates to, so an alarm on a device updates its parent asset in the same pass.
• Calculate Alarm Status picks the highest severity with a non-zero count and emits it as alarmStatus — CRITICAL → MAJOR → MINOR → WARNING → INDETERMINATE, falling back to NORMAL when nothing is active. It also splits the total out as a separate telemetry message. A missing counter is read as zero, so trimming a mapping row cannot force a false status.
• Alarm Summary Type Switch routes those two messages to the writers below.
• Save Alarm Status Attribute writes alarmStatus to Server attributes, and only when the value actually changes — so an entity whose status stays CRITICAL across ten alarm events produces one attribute update, not ten.
• Save Alarm Count Timeseries stores alarmCount as time series, giving you a history of how many alarms were active over time.

Everything else in the chain is stock root-chain processing — telemetry and attribute saving, RPC handling, entity-group duplication — left untouched.

Deleting an alarm does not refresh the counters. They are rewritten on the next alarm event for that entity.

One alarm event updates the entity it was raised on and every entity it propagates to, each with its own counters:

Key	Kind	Where
alarmStatus	Attribute	Server attributes
alarmCount	Time series	Latest telemetry

Requirements

• A source of alarms. Alarm rules on a device or asset profile, or alarms created through rule nodes or the REST API. The flow runs on alarm events only, so nothing is written until the first alarm arrives.
• Alarm propagation enabled on those alarm rules, if you want counters to roll up from devices to their parent assets.

How to set up

1. Click Install to open the install dialog. First, check your device and asset profiles — an alarm goes to the profile’s default rule chain if the profile names one, and to the chain marked as root if it does not. The dialog offers two paths:
   • Bind to a profile — enable Set as profile default rule chain and pick the target device or asset profile. The imported chain becomes that profile’s default rule chain, and every message from that profile flows through it.
   • Install only — leave the toggle off. Afterwards, either set it as the root — it already bundles the default routing plus the alarm-summary flow — or extract the alarm-summary flow into a nested rule chain and connect it to the Alarm Created, Alarm Cleared, and Alarm Severity Updated outputs of the Message Type Switch in every chain that should count — your root chain, and each profile default rule chain you want counters on.
2. Open the Count Alarms By Severity node and review the defaults — no change is required to run it as shipped:
   • Alarms count mappings — six rows, one per severity plus a total. The Status filter on each row is set to Active Unacknowledged and Active Acknowledged; the Type filter is empty, so all alarm types are counted.
   • Count alarms for propagation entities — on. Turn it off if you want counters only on the entity the alarm was raised for.
3. Verify the flow. Trigger an alarm on a device whose messages route through the installed chain — for example by sending telemetry that breaches an alarm rule via Check connectivity. Then open the device, and its parent asset if propagation is on, and confirm that alarmStatus appears under Attributes → Server attributes and alarmCount under Latest telemetry. Clear the alarm and confirm alarmStatus returns to NORMAL.

How to customize

• To count only certain alarm types — on the Count Alarms By Severity node, go to Alarms count mappings and set Type filter to the alarm types you want to include.
• To include cleared alarms in the total — on the Count Alarms By Severity node, go to Alarms count mappings and add Cleared Unacknowledged and Cleared Acknowledged to Status filter.
• To stop counters rolling up to parent assets — turn off Count alarms for propagation entities on the Count Alarms By Severity node.
• To stop tracking a severity you do not use — remove its row from Alarms count mappings on the Count Alarms By Severity node.