Skip to content

Cookie preferences

We use cookies for our own analytics, to see how our campaigns perform and, if you allow it, to load content from other services such as the Google site search. We never sell your data. Necessary cookies keep the site working and cannot be switched off. See our Cookie Policy for details and our Privacy Policy for how we handle personal data.

Security, load balancing and remembering your cookie choice.

Show us which pages people read, how they find the site and where they get stuck, so we can improve it (Google Analytics, Microsoft Clarity).

Show us which of our ad campaigns bring visitors to the site and remember the campaign or partner link you arrived from (Google Ads, LinkedIn, Meta, partner program). We do not use these cookies to build advertising profiles.

Load the site search from Google when you use it. Google sets its own cookies and shows ads in the search results.

© 2026 The ThingsBoard Authors
180 Try for free

ThingsBoard Cloud

Choose your data region

Your data stays in the region you choose, for residency and compliance. No credit card required.

Rather run it yourself? Install on your own servers

Alarms via Rule Chain

Manage alarms directly in the Edge rule chain using three dedicated rule nodes: create alarm, clear alarm, and alarm status filter. This approach gives you full programmatic control over alarm creation and clearing, based on any telemetry condition, attribute value, or custom script logic, entirely on the Edge without a server connection.

For most threshold alarms, use alarm rules. They need no rule chain changes, support multiple arguments, dynamic thresholds from attributes, and duration and repeating conditions, and they are evaluated on the Edge. Use the rule nodes instead when the alarm depends on the content of a message in a way the alarm rule arguments cannot express, or when the alarm needs custom details built by a script.

The standard pattern for a threshold alarm in the rule chain:

Post telemetry → [Script filter: condition?]
├─ True → create alarm → Created → (act on new alarm)
│ → Updated → (alarm already exists, skip)
└─ False → clear alarm → Cleared → (act on cleared alarm)
→ False → (no alarm was active, skip)

This example creates a Critical alarm when temperature > 35 and clears it when the reading drops to or below 35.

  1. On the Edge, go to Data processing > Rule chains and open the Edge Root Rule Chain.
  1. In the node panel, search for Script (under Filter) and drag it onto the canvas.
  2. Set the node name to High Temp?.
  3. Enter the condition:
    return msg.temperature != null && msg.temperature > 35;
  4. Click Add.
  1. Search for create alarm (under Action) and drag it onto the canvas.
  2. Configure:
    • Alarm type: High Temperature
    • Severity: Critical
    • Alarm details builder (optional — records the triggering value):
      return { temperature: msg.temperature };
  3. Click Add.
  4. Connect the True output of High Temp? to this node.
  1. Search for clear alarm (under Action) and drag it onto the canvas.
  2. Set Alarm type to High Temperature (must match exactly).
  3. Click Add.
  4. Connect the False output of High Temp? to this node.

Step 5 — Wire the Script filter to the incoming message

Section titled “Step 5 — Wire the Script filter to the incoming message”
  1. Find the existing Message type switch node in the root rule chain.
  2. Connect its Post telemetry output to the High Temp? Script filter node.
  3. Click Apply changes.
Connection When Message after
Created A new alarm was created Message replaced with alarm object; metadata: isNewAlarm: true
Updated Alarm of the same type already existed Message replaced with alarm object; metadata: isExistingAlarm: true
Failure Script error or invalid severity Original message unchanged
Connection When Message after
Cleared Active alarm was found and cleared Message replaced with alarm object; metadata: isClearedAlarm: true
False No active alarm existed Original message unchanged

After a create alarm or clear alarm node, the message type changes to ALARM and the payload contains the full alarm object. Use the alarm status filter node to branch on the current alarm status before taking further action (for example, only send a notification on a genuinely new unacknowledged alarm).

Add an alarm status filter node after create alarm, configure the status set (e.g., Active Unacknowledged), and connect:

  • True → send notification / RPC / push to cloud
  • False → skip

To apply the same rule chain logic to all Edge instances, configure the rule chain as a rule chain template on the server and assign it to the Edges. An alarm rule created on the server for a device profile does not need a template: it reaches every Edge (4.3.0 and later) automatically.

For step-by-step examples with the alarm rules editor, see Alarm rule tutorials.

For the full alarm management reference, see Manage alarms on Edge.