Alarms

An alarm in ThingsBoard Edge is raised and managed locally, with no server connection required. Alarms come from alarm rules, which the Edge evaluates itself, or from the create alarm and clear alarm rule nodes in an Edge rule chain. Alarms are stored in the local database and can be viewed, acknowledged, and cleared from the Edge UI at any time: from the Alarms tab of an entity, or from Monitor > Alarms, whose Alarm list tab shows all alarms of all entities. Alarms are not synchronized automatically; see Alarm synchronization.

The alarm model on Edge is identical to the server: each alarm tracks an originator, type, severity, and lifecycle status. An alarm is unique per originator and type. When the same condition triggers again on an active alarm, the existing alarm is updated rather than duplicated. For alarm properties, severity levels, and the four-state lifecycle (active/cleared × acknowledged/unacknowledged), see Alarms.

There are two ways to raise alarms on Edge:

• Alarm rules: The most common approach. An alarm rule defines the arguments to watch, the trigger conditions with their severity, and an optional clear condition. On Edge and on the server, rules are managed on the Alarm rules tab of Monitor > Alarms, or on the Alarm rules tab of a device, asset, device profile, asset profile, or customer. No rule chain changes are needed to raise the alarm. For details, see Alarm rules.
• Rule engine nodes: For logic driven by the message content, or when the alarm needs custom details, use the create alarm and clear alarm rule nodes in the rule chain. See Alarms via rule chain.

Alarm rules are synchronized between the server and Edge (Edge 4.3.0 and later). A rule created on the server for a device profile, asset profile, or customer is sent to every Edge; a rule for a single device or asset is sent only to the Edges that entity is assigned to. A rule created on Edge is sent to the server. Once synchronized, the Edge evaluates the rule locally, also while offline.

A rule runs where the telemetry arrives. Telemetry that the Edge pushes to the server is evaluated by the server’s rules too. So when a rule exists on both sides, the Edge raises its own alarm and the server raises a separate alarm from the pushed telemetry.

Creating, updating, acknowledging, and clearing an alarm are not synchronized automatically. These events are messages in the rule engine, and they reach the other side only if the rule chain routes them to a push to cloud node (Edge to server) or a push to edge node (server to Edge). Neither default root rule chain does this. To enable it, connect the Message Type Switch node to the push node with the labels Alarm Created, Alarm Updated, Alarm Severity Updated, Alarm Cleared, and Alarm Acknowledged. Each alarm event then travels as a separate message with the full alarm payload: originator, type, severity, and status.

Alarm deletes and alarm comments are synchronized automatically, in both directions.

Acknowledging and clearing follow the push path. When a user acknowledges or clears an alarm on one side, the resulting message is forwarded to the other side only if Alarm Acknowledged and Alarm Cleared are connected to the push node. Both sides then converge to the same state. For the step-by-step setup, see Manage alarms.

When Edge is disconnected from the server, alarm rules and rule chains keep raising and managing alarms locally without interruption. Alarm messages that pass through the push to cloud node accumulate in the cloud events queue and are sent to the server in order once the connection is restored, preserving the alarm timeline.

Notification rules define which alarm events trigger a notification, who receives it, and the delivery channel: web, email, SMS, Slack, Microsoft Teams, or mobile push. They are managed under Monitor > Notifications, on the server and on Edge alike. Edge has its own notification center with the same structure: inbox, sent, recipients, templates, and rules.

For details on configuring notification rules and delivery channels, see Notifications.