Skip to content
Stand with Ukraine flag
Star
 
Pricing Try it now

IoT Rule Chains

Install ready-made automation logic in one click — alerting, data processing, device lifecycle, and external integrations you plug into your existing rule chain.

Contribute

4 results

Send IoT Device Data to Kafka

Dmytro Shvaika
341

Auto-Link IoT Devices to Assets as Hardware Moves

Dmytro Shvaika
219

Auto-Assign IoT Devices to Customers

Dmytro Shvaika
70

Auto-Group IoT Devices by Type

Dmytro Shvaika
40

Share Your Rule Chain with the Community

Built a useful automation workflow? From a simple alarm recipe to a complex multi-cloud integration — publish it to the IoT Hub. Share it with thousands of ThingsBoard developers.

Contribute a Rule Chain Read the contribution guide

Frequently Asked Questions

Rule chains are visual message processing pipelines. Every message entering ThingsBoard (telemetry, attributes, RPC, lifecycle events) flows through a rule chain. Each node in the chain performs an operation — filtering, enriching, transforming, or acting on the message — and routes it to the next node. ThingsBoard ships with a default Root Rule Chain, and the IoT Hub offers community-contributed chains for specialized automation.
The rule engine is the ThingsBoard component that processes incoming messages in real time. It runs your rule chains — every device message passes through the rule engine, which routes it through the chain's nodes to filter, transform, store, raise alarms, or trigger external actions. Rule chains from the IoT Hub run on this same engine.
Most rule chains work on CE. However, chains using Analytics nodes (Aggregate Latest, Aggregate Stream) or certain Integration nodes require PE. Each chain in the Catalog displays edition badges. Chains using PE-only nodes are clearly marked.
Open the rule chain page and click Install. In the dialog you can import the chain on its own, or set it as the default rule chain for a device or asset profile (with a confirmation if that profile already has one). The chain then appears in your Rule Chains list and starts receiving messages as soon as it's wired in or bound to a profile. You can also download the JSON and import it manually via Rule Chains → Import rule chain.
No. Imported rule chains are always created as new, separate chains. You must explicitly set a chain as the root for a device profile or connect it as a sub-chain. Your existing root chain is never modified by import.
The root rule chain is the entry point for all messages from devices using a given device profile. Sub-chains are reusable modules connected from the root chain (or other sub-chains) via the Rule Chain node. Many IoT Hub rule chains are designed as sub-chains that you plug into your existing root chain without replacing it.
POST_TELEMETRY_REQUEST (sensor data), POST_ATTRIBUTES_REQUEST (attribute updates), RPC_REQUEST (commands), ACTIVITY_EVENT (connect/disconnect), INACTIVITY_EVENT (device timeout), ALARM (alarm lifecycle), and custom message types. Use Message Type Switch to route each type differently.
Seven categories: Filter (route by conditions), Enrichment (add context), Transformation (modify payload), Action (save/alarm/RPC), External (integrate with external systems), Flow (connect sub-chains), and Analytics (aggregate data — PE only).
By Type (CORE for the main server, EDGE for ThingsBoard Edge), by Category (Alerting, Analytics, Automation, Data Processing, Device Connectivity, Integration), and by shared Use Case tags. Browse categories describe what a chain does and are distinct from the node building blocks inside it.
Each rule chain is tagged with shared IoT use cases, so filtering by a use case surfaces matching chains, widgets, dashboards, and devices together. Popular use cases include Asset Tracking, Fleet Tracking, Industrial Automation, Predictive Maintenance, and Smart Farming; the full vocabulary is searchable in the Use Case filter.
Check the IoT Rule Chain Contribution Guide that describes the process of adding rule chains. You can also contact iothub@thingsboard.io for help.
Document all external dependencies (Kafka broker, SMTP server, REST API endpoint, etc.) in your README. The manifest has an externalDependencies field listing required services. Users will need to configure their own credentials/endpoints after import.