Scheduler vs Rule Chain

ThingsBoard Edge has two automation mechanisms that complement each other: scheduler events and rule chains. Knowing when to use each one helps you build reliable automation on the Edge.

Scheduler events run periodic tasks on a time schedule, like telemetry and attribute updates or RPC commands. See the Scheduler and Edge Scheduler documentation.

Rule chains react to incoming data or events. Rule nodes are their building blocks. For example, when a device reports a temperature above a threshold, the rule chain creates an alarm. See Rule chain templates for the Edge-specific details.

Topic	Detail
Rule chain creation	Before Edge 4.0, rule chain templates had to be created on the server and synchronized to the Edge. Starting with Edge 4.0, rule chains can be created and edited directly on the Edge.
Scheduler creation	Scheduler events are created on the server and assigned to the Edge, or created directly on the Edge (4.3+) and pushed to the server.
Execution	Once synchronized, both scheduler events and rule chains run entirely on the Edge, independent of internet connectivity.

Criterion	Scheduler events	Rule chains
Trigger	Time schedule	Incoming message or event
Configuration location	Server (assigned to the Edge), or directly on the Edge (4.3+)	Server, or directly on the Edge (4.0+)
Offline execution	Yes	Yes
Supported actions	RPC commands, telemetry and attribute updates	Alarms, notifications, transformations, external API calls, and more
Logic complexity	Single action per event	Multi-step branching logic
Real-time reaction	No	Yes
Depends on device data	No	Yes

Use scheduler events when:

• A time-based trigger is required.
• The automation is periodic or scheduled, independent of incoming device data.

Use rule chains when:

• You need a real-time reaction to events or telemetry.
• You need complex logic, branching, or external API calls.
• You need to process local data, like attribute updates, alarms, or incoming messages.

Scheduler events and rule chains cover different parts of an automation. A scheduler event fires at a fixed time and injects a message into a rule chain. From there, the rule chain takes over: it reads telemetry, evaluates conditions, and triggers actions like RPC commands, alarms, or attribute updates. Device data can enter the same rule chain independently, so one chain can handle both scheduled and real-time inputs.

Goal: turn off a pump every night at 7 PM and raise an alarm if the pump is still running 10 minutes later. You need two scheduler events, created on the server and assigned to the Edge, and a rule chain on the Edge.

Field	Event 1: stop the pump	Event 2: check the pump status
Event type	Send RPC Request to Device	A custom name you type, for example Check pump
Target	Single entity, type Device, the pump device	Single entity, type Device, the pump device
Method / Message type	Method: action	Message type: a custom name you type, for example CHECK_PUMP_STATUS
Params / Message body	{"action": "stop_pump"}	{"action": "check_pump_status"}
Schedule	Every day at 7:00 PM	Every day at 7:10 PM

The second event runs 10 minutes after the first, which gives the pump time to stop. The Event type and Message type fields accept any name: if the name is not in the list, the field offers the text you typed.

The first event enters the rule chain of the Edge as an RPC Request to Device message. The second has a custom message type, which the message type switch node sends to its Other output. The node routes them:

• RPC Request to Device > rpc call request node. It sends the stop_pump command to the pump. The default Edge root rule chain already has this connection.
• Other > script node (check pump status) > originator telemetry node (Get Latest Pump Status) > script filter node (Check pump status) > create alarm node (PumpFailedToStop). The script node handles messages with the action check_pump_status, the originator telemetry node fetches the latest pumpStatus telemetry of the pump, and the filter passes the message on only if the value is still ON. The alarm node then creates the alarm.

Connect the nodes of the Other branch with the Success label, and the filter node to create alarm with the True label. Click Apply changes.