Add alarms with your agent

An alarm rule tells ThingsBoard when to create an alarm and when to clear it. You describe the rule to your AI agent in words. The agent writes the alarm rule, checks it, and adds it to your solution. This page gives prompts for the most common alarm rules.

You can ask for alarms in two ways:

• In a new solution: Add the alarm to the prompt that describes your device, like “Alert me when CO2 goes above 1000.”
• On an existing device: Name the device or the device type and the alarm. The agent can ask Just these items, or full solution treatment? Select Just these items to change only the alarm.

The agent saves each alarm rule in the device profile file, in solutions/<name>/device-profiles/. An alarm rule on one device goes to the device file. Nothing reaches ThingsBoard until you approve a deployment, unless your request already asks to deploy or to show the data on a dashboard.

Name the key, the threshold, and the severity:

Add a critical alarm to my freezer sensors when temperature goes above -15 °C.

“My freezer sensors” puts the rule on the device profile, so it applies to all freezers. “My Freezer-3” puts the rule on that one device only.

ThingsBoard clears an alarm when the clear condition is true. If you do not give one, the agent selects it:

• On an existing device, the clear condition is the opposite of the create condition, like “temperature is -15 or less”.
• In a new solution, the agent selects a value below the threshold. This gap (hysteresis) stops the alarm from opening and closing many times when the value stays near the threshold.

To set your own gap, give both values:

Add a HighTemperature alarm to my server room sensor. Create it when temperature goes above 30 °C. Clear it only when temperature drops below 27 °C.

ThingsBoard has five severity levels: CRITICAL, MAJOR, MINOR, WARNING, and INDETERMINATE. One alarm rule can have a different threshold for each level. ThingsBoard checks the highest level first and uses the first level that matches.

For my boiler, add a pressure alarm: warning above 2.5 bar, major above 3 bar, critical above 3.5 bar. Clear it below 2.2 bar.

A duration condition creates the alarm only when the value stays above the threshold for some time. Short peaks do not create an alarm.

Alert me when CO2 in my office stays above 1000 for 10 minutes.

In a new solution, the demo history has one value every 30 minutes, so it cannot show a shorter breach. If you ask for a shorter duration, the agent asks you to keep it or to use 30 minutes. Keep your duration if your device sends data more often: real data triggers the alarm correctly. An alarm on an existing device keeps your duration.

You can also count readings instead of time, like “above 1000 for three readings in a row”.

Each device can have its own threshold. The agent stores the threshold as an attribute of the device. The alarm rule reads the attribute. It can use a default value when the attribute is not set. The agent can add a control to the dashboard to change the threshold.

In my waste management solution, let me set the fill level alarm threshold for each bin on the dashboard. When a bin has no threshold, use 80%.

ThingsBoard uses a new threshold from the dashboard for the next values. You do not deploy again.

The threshold can also come from the customer that owns the device. Say “use the threshold of the customer” in the prompt.

Tell the agent the alarm and the new value:

Change the CO2 alarm threshold in the office solution to 1200.

The agent changes only this alarm rule and keeps its ID. Then it asks to deploy again. To deploy yourself, run this command:

tb push <name>

If someone changed the alarm rule in the ThingsBoard UI, run tb pull --solution <name> first. Otherwise the push overwrites the change.

The agent makes demo data that triggers each alarm. About one device in four of each type gets a constant value above the threshold. With one device, that device triggers the alarm. Ask for more devices, like “four sensors”, to see normal and alarm values together.

Alarm rules check new values when they arrive. To check an alarm:

1. Deploy the solution and write the demo history:

   tb push <name> --run-tasks

2. Send live demo values:

   tb emulator run <name> --duration 10m

   For a duration condition, set --duration longer than the alarm duration, like --duration 40m for a 30-minute alarm.

3. Open the dashboard. The alarm table shows the active alarms. You can acknowledge and clear an alarm there. Users with read-only access see the alarms but cannot acknowledge or clear them.

When you approve Deploy and stream live data, the agent does steps 1 and 2 for you.

If an alarm does not fire, ask the agent:

Why does my HighTemperature alarm never fire?

The agent checks the key names, the conditions, and the thresholds against the real values. It tells you the cause and changes the rule only after you agree.

• Start from a device payload: describe your device data to the agent.
• Alarms: severity, status, and the alarm lifecycle in ThingsBoard.
• Alarm rules: all alarm rule settings, like schedules and propagation.