ThingsBoard for Industrial Monitoring: From Data Model to Dashboard

What is ThingsBoard?

ThingsBoard is an open-source IoT platform for collecting, processing, storing and visualizing device data. In industrial IoT projects it is used to monitor equipment, energy consumption, environmental conditions and the status of production lines. The platform is available in two main editions:

The exact feature split changes between releases, so check the official documentation of the current version before deciding.

Data model: devices, assets, telemetry and attributes

Understanding the data model is the foundation of any industrial monitoring solution built on ThingsBoard.

• Device: any data source, such as a sensor, meter or gateway. Each device has its own connection credentials.
• Asset: a logical entity such as a site, hall, production line or machine that devices belong to.
• Relation: a link between entities, for example "Hall 2 contains Line A". Relations reproduce the hierarchy of a plant or mine and are used for data aggregation and dashboard navigation.
• Device and asset profiles: shared settings for a group of entities of the same type, including transport protocol, default rule chain and alarm rules.

Data for each entity is stored in two categories:

A simple rule: anything that changes over time and whose trend matters is telemetry; anything that describes state or configuration is an attribute.

In practice, it pays to design the asset hierarchy before connecting the first device. A structure such as site, area, line and machine, with sensors attached to the machine they observe, makes it possible to aggregate values per line, filter alarms by area and reuse dashboards across sites. Consistent naming conventions for devices and telemetry keys, for example always using the same key for motor current across all machine types, avoid costly cleanup later.

Data ingestion and gateways

ThingsBoard natively supports MQTT, HTTP and CoAP, and current versions also provide LwM2M and SNMP. In industrial environments MQTT is the most common choice because it is lightweight, keeps persistent connections and follows a publish/subscribe pattern.

Many industrial devices cannot connect to the platform directly. In that case a gateway acts as the intermediary:

• ThingsBoard IoT Gateway: open-source software that uses connectors to read Modbus, OPC UA, BACnet, CAN and other protocols and forwards the data via MQTT.
• Standalone industrial gateways: hardware that collects PLC data and sends it via MQTT or HTTP.
• LoRaWAN network server: wireless sensor data is forwarded from the network server to the platform. Whether the network is private or public is decided per project.

For sites with unreliable connectivity, such as mines, ThingsBoard Edge allows local processing and visualization with later synchronization to the central server.

Payload format deserves early attention. Sensors often send compact binary payloads that must be decoded into named values with units. Decoding can happen in the network server, the gateway or a converter on the platform; what matters is that it happens in one defined place and is versioned.

Rule engine and alarms

The rule engine is the core of data processing in ThingsBoard. Incoming messages pass through rule chains made of filter, enrichment, transformation and action nodes. Typical uses include:

• unit conversion or derived values, for example power from voltage and current;
• enriching messages with attributes of the parent asset for line-level analysis;
• forwarding data to external systems via REST, MQTT or Kafka;
• creating and clearing alarms.

Custom logic is written in script nodes using JavaScript or TBEL. Alarms can be defined directly in the device profile with conditions based on thresholds, duration or repetition. Each alarm has a severity (including CRITICAL, MAJOR, MINOR and WARNING) and a lifecycle of active, acknowledged and cleared. To avoid alarm fatigue, set thresholds based on the actual behavior of the equipment and add time delays for transient conditions.

Dashboards and design practice

ThingsBoard dashboards are built from widgets: time-series charts, gauges, tables, maps, alarm tables and control widgets. Entity aliases let one dashboard serve many similar machines or sites, and dashboard states enable navigation from overview to detail. Good ThingsBoard dashboards usually follow these principles:

1. One dashboard per audience: operators, maintenance and management need different information.
2. Clear hierarchy: site overview, then line or machine, then sensor detail.
3. Exceptions first: abnormal states and active alarms must be visible at a glance.
4. Meaningful color: reserve alarm colors for alarm states only.
5. Explicit units and time ranges: every chart states its unit and time window.
6. Performance: limit the number of widgets and the data volume per query, and use aggregation for long time ranges.

Deployment, scaling and security

ThingsBoard can be deployed as a monolithic server or as a microservices architecture. For pilots and smaller projects a single server with PostgreSQL is usually sufficient. As telemetry volume grows, hybrid storage with Cassandra or TimescaleDB for time series and Kafka as the message queue improve scalability and resilience. Key points:

• Estimate the number of devices, reporting intervals and data retention before choosing an architecture.
• Define retention policies (TTL) and regular backups from the start.
• Encrypt all connections with TLS and use unique credentials per device, such as access tokens or X.509 certificates.
• Restrict user access through the tenant and customer model with least-privilege roles, and enable two-factor authentication.
• Keep the platform server separate from the industrial control network and design data flows to be one-directional through gateways.
• Apply security updates on a schedule and after testing in a staging environment.

Conclusion

With its flexible data model, rule engine and configurable dashboards, ThingsBoard is a solid basis for industrial monitoring, provided the asset model, alarm rules, deployment architecture and security are designed carefully from the start. More details are available on the industrial monitoring and industrial IoT service pages. To discuss a specific project, use the contact page.