Overview
ThingsBoard is a fully-featured open-source IoT platform developed by a Ukrainian team. It provides end-to-end capabilities including device management, asset management, rule engine, data visualization, alerts, and multi-tenancy. It supports protocols such as MQTT, CoAP, HTTP, and LwM2M, comes with a variety of built-in charts, maps, and widgets, allowing for rapid construction of IoT monitoring dashboards and applications. Built on a Java/Spring tech stack, it supports cluster deployment and is suitable for the rapid implementation of small to medium-scale IoT projects. It offers a Community Edition (Apache 2.0) and a Professional Edition (commercial support, advanced features).
ThingsBoard has a different positioning compared to EMQX and Home Assistant: EMQX focuses on MQTT access, ThingsBoard is a complete platform; Home Assistant focuses on smart homes, while ThingsBoard is more general-purpose. ThingsBoard is suitable for B2B scenarios such as industrial monitoring, smart agriculture, energy management, and device operations, and can interface with industrial protocols like Modbus and OPC-UA (via gateway conversion). In IoT solutions, SimtoLink can use ThingsBoard as a platform for rapid deployment, combined with IoT SIM cards, EMQX, and other components.
Core Functions
Device and Asset Management
Multi-level organization of devices, assets, tenants, and customers. Devices support attributes, telemetry, and RPC. Assets can be associated with devices to enable grouping and permission management. Supports device credentials, pre-configuration, and bulk import.
Rules engine and alarms
Visual rule chains: message filtering, transformation, alarms, forwarding. Supports alarm rules, alarm acknowledgment, and alarm notifications. Can forward to external systems such as Kafka, RabbitMQ, HTTP, etc. Interacts with device telemetry, attributes, and events.
Dashboards and multi-tenancy
Drag-and-drop dashboards with various charts, maps, and widgets. Supports real-time data, historical curves, and alarm lists. Multi-tenant architecture, supporting SaaS and white-label. Tenants can create customers, and customers can manage devices and assets.
Use Cases
Industrial monitoring, smart agriculture, energy management, equipment operation and maintenance, smart buildings. Suitable for small to medium-scale (thousands to tens of thousands of devices) IoT projects for rapid deployment. Can connect to various devices when used with EMQX, Modbus gateways, etc. Active community, comprehensive documentation, making it a popular choice for open-source IoT platforms.
How telemetry and attributes differ in the entity model
Devices, assets, and customers in three layers
The platform splits connected objects into layers. A tenant is the isolation boundary, a customer is the party using the system under that tenant, an asset is used to group things, and a device is the endpoint that reports telemetry and receives calls. An asset can be related to devices, to say which endpoints a pump station contains. The asset itself is not a connection session. If the gateway and the child devices behind it are all created as devices with no relation between them, authorization cannot follow the field structure later, and there is no way to explain why the child devices disappear together when the gateway goes offline.
Telemetry is a series of measurements with a time. It suits values that keep being appended, such as temperature, energy, and location. Attributes are split into values reported by the client, values written by the server, and configuration shared with the device. They suit a current setting that is not played back over time, such as a reporting period or an installation address. A remote procedure call is the platform asking the device to perform one action and waiting for a reply. Mixing the three distorts storage and the screen together. Temperature written every second as an attribute has no source for a history curve. An address that rarely changes, written as telemetry, fills queries with points that carry no new meaning.
When a rule chain should take a telemetry message
A rule chain suits a single message that has already entered the platform: filter by device type, change a field, judge a threshold, create an alarm, then forward to an external queue or interface. It holds up when the message rate and the complexity of the rules match what that chain can process, and when calls the chain makes to the outside have a timeout and a way out on failure. Correlation across a large number of devices in a window becomes hard to maintain inside the chain. Put that computation in dedicated stream processing, and let the rule chain receive only the conclusion.
A chain needs a definite end. If a message returns to the root rule and enters the same chain again, it forms a loop. Processor use rises, and the business gains no new state. While debugging, look at the nodes one message walked, and confirm the alarm node lights only when the condition is met. With more than one tenant, first check which tenant the chain and the device belong to. A rule a tenant administrator can see does not automatically apply to devices of another tenant.
Attributes written by mistake, mixed tenants, and a wrong alias
Writing high-rate telemetry into attributes, or writing a one-off debug switch into telemetry, is the most common mismatch when the model is built. Retention usually applies only to telemetry, while an attribute keeps an expired switch. After a device reconnects it reads the old shared attribute and takes the experimental configuration back to the field. A change to a shared attribute should carry a version or a time, and the device must be able to reject configuration that is clearly out of date.
A dashboard decides which device or which group of assets it watches through an entity alias. If the alias still points at a deleted device, or at an asset of the same name under another customer, the panel is blank, or it shows data that does not belong to the current customer. Before publishing, open it once with the target customer's account. Do not reuse a device token across tenants. When a token is copied into another tenant, data is written to a device that was not intended. If devices are gathered through Eclipse Mosquitto and then connected, the mapping from topic to token must stay fixed. It cannot follow the display name. Curves on a panel consume only telemetry that has already been stored. Bucket width and the handling of gaps when reading the chart are the same as in Data Visualization. Which devices can be seen is still cut by the customer's permissions.
If telemetry is kept for less time than the dashboard's default query span, the history curve shows a blank stretch, while the rule chain is still raising alarms for new messages. An investigation then takes this for collection having stopped. Retention should cover the time the panel needs to look back, and the time an alarm needs for tracing. Once the access method in the device configuration is changed, access tokens already written into devices do not move with it, and every old token fails authentication. Before switching a batch, walk one test device through registration, reporting, and a remote call. The direction between asset and device is also easy to draw backwards. If it is recorded as the asset belonging to the device, filtering by asset returns an empty list, while the data is already on the device.