Industrial IoT Monitoring Dashboards with ThingsBoard
Custom ThingsBoard dashboards for device telemetry, industrial sensor measurements, equipment status, operational trends and alerts.
Project status: In development
Most industrial sites already produce plenty of data, yet it rarely reaches the people who need it. Values stay on a local HMI, reports are compiled by hand, and a failing pump is often noticed only after production has stopped. Industrial monitoring means collecting that data continuously, with reliable timestamps, in one place.
I design and implement monitoring systems from the sensor and PLC level up to ThingsBoard dashboards: choosing protocols and data paths, modelling assets, defining alarms and escalation, and building views that work in the control room as well as on a technician's phone.
Industry challenges
Siloed data sources
Each machine comes with its own protocol, software and data format, so there is no consolidated view of a line or site.
Alarm fatigue
Static thresholds and noisy alarms train operators to click messages away, and the critical one gets lost.
KPIs nobody agrees on
Runtime, downtime and energy figures are calculated manually and defined differently from shift to shift.
No secure remote access
Managers and maintenance staff either cannot see data off-site or reach it through improvised, insecure paths.
Uncontrolled data growth
Without retention and aggregation rules, the time-series database grows quickly and historical queries slow down.
Technical solutions
Telemetry acquisition
Connecting PLCs, sensors and meters via Modbus, OPC UA, MQTT or LoRaWAN to an edge gateway with timestamping and local buffering.
Asset modelling
A clear site, line, machine and sensor hierarchy in ThingsBoard, so dashboards and rules follow the real plant structure.
ThingsBoard dashboards
Role-based views for the control room, shift supervisors and maintenance, with drill-down from overview to individual equipment.
Alarms and escalation
Rule Engine alarms with severity levels, delays and hysteresis, plus notifications by email, SMS or messenger according to on-call schedules.
Operational KPIs
Runtime, stop counts, specific energy consumption or OEE, calculated from documented and reviewable definitions.
Retention and archiving
TTL for raw telemetry, hourly and daily aggregates for long-term analysis, and regular backups of configuration and data.
How I approach a monitoring project
A monitoring system only pays off when operators trust it. That is why I start with the question "which decision should this data support?" rather than with a list of sensors. A typical engagement follows these steps:
- Process and measurement points: site visit, review of drawings and existing PLC/SCADA tag lists, and selection of the key variables per machine.
- Data path design: protocols, gateways and transport network; sampling rates, and which values are sent periodically versus on change.
- Data and asset model: device profiles, attributes and an asset hierarchy in ThingsBoard with consistent naming.
- Dashboards and alarms: role-based views and alarm rules defined together with operators, not just from datasheets.
- Testing, documentation and handover: testing the data path under network outages, documenting the configuration and training key users.
Alarms and KPIs: fewer, but sharper
An alarm that fires ten times a day for no reason will soon be ignored. When designing alarms I follow a few principles:
- Severity levels (info, warning, critical) with a clear owner for each
- Delays and hysteresis to suppress flapping alarms
- Automatic escalation if an alarm is not acknowledged in time
- Alarm history for periodic review and removal of useless rules
KPIs such as runtime or OEE are only useful when their definition is written down and shared, for example whether planned stops count as downtime. I describe dashboard structure in more detail in the article industrial monitoring with ThingsBoard.
Data retention and secure access
| Data type | Typical approach |
|---|---|
| Raw telemetry | Short-term retention with TTL for troubleshooting |
| Aggregates | Hourly and daily min/max/average for long-term analysis |
| Alarms and events | Longer retention for audits and root-cause analysis |
Remote access is provided through VPN or an HTTPS reverse proxy with role-based user accounts. Data between gateway and platform is usually transferred via MQTT with TLS encryption.
Frequently asked questions
Do existing PLCs or machines need to be replaced?
Usually not. Data is typically read through existing interfaces such as Modbus or OPC UA, and equipment without digital outputs can be retrofitted with additional sensors.
Why ThingsBoard?
ThingsBoard is a mature platform for device management, dashboards, rule processing and alarms, and it can run on your own servers. If you already use another platform, I design around it.
Where is the data stored?
I prefer deployment on your own infrastructure or a hosting provider you choose, so data ownership stays with you. Retention and backup policies are defined during design.
Can we start with a single line or machine?
Yes, and I recommend it. A focused pilot shows which signals are genuinely useful, and the data model and alarm rules can be refined before scaling out.
