Predictive maintenance & retrofit: make legacy machines IoT-ready

Make legacy machines IoT-ready and maintain them predictively? WZ-IT designs and runs self-hosted predictive maintenance platforms on open-source foundations - on your infrastructure. See our IoT services - IoT platform development

Predictive maintenance by retrofit means: legacy machines without a modern interface get sensors and an edge gateway that captures machine data over OPC-UA or Modbus and forwards it as MQTT to ThingsBoard and Grafana. There, thresholds and anomaly detection enable predictive maintenance - before a bearing overheats or a drive fails. The pragmatic path is self-hosted, open source and without touching the machine firmware. This article walks through the concrete flow from sensor to maintenance decision.

Contents

• What predictive maintenance and retrofit mean
• Retrofitting legacy machines without a modern interface
• Capturing machine data: OPC-UA and Modbus to MQTT
• Analysing data in ThingsBoard and Grafana
• Thresholds and anomaly detection for predictive maintenance
• From dashboard to secure remote maintenance
• What does a self-hosted predictive maintenance stack cost?
• Implement predictive maintenance pragmatically with WZ-IT

---

What predictive maintenance and retrofit mean

Predictive maintenance replaces fixed service intervals and pure reaction with condition-based maintenance: sensors monitor vibration, temperature, current draw or pressure, and the system warns when a fault is emerging. That reduces unplanned downtime and extends service life.

Retrofit is the lever for doing this on existing assets. Many production machines have run reliably for years but expose no data externally, or only over proprietary interfaces. Instead of replacing them, you add sensing and an edge gateway - the machine stays untouched but becomes data-capable. This turns into a concrete use case built on the layered model from IoT architecture in layers.

Retrofitting legacy machines without a modern interface

The retrofit follows three steps:

1. Define measurement points. Which quantity reveals an emerging fault? Typical ones are vibration and structure-borne noise (bearings, gearboxes), temperature (motors, hydraulics), current draw and active power (load, wear), pressure and flow, and rotational speed. A few meaningful points per machine often suffice.
2. Add sensing. For quantities without a controller connection, external sensors are added - for example battery-powered LoRaWAN sensors from vendors such as Milesight for temperature, vibration or energy. Existing values from the controller are tapped directly.
3. Install an edge gateway. An industrial-grade gateway reads the machine protocols, buffers during outages and forwards everything in a unified way as MQTT.

The key point: there is no change to the machine firmware and no replacement of the controller. That keeps effort, risk and downtime low.

Capturing machine data: OPC-UA and Modbus to MQTT

The core of the retrofit is protocol conversion at the edge. Existing controllers mostly speak Modbus (TCP or RTU, common on drives, energy meters and older PLCs) or OPC-UA (newer controllers, MES integration). An edge gateway reads these sources and translates them into MQTT, the platform's lightweight data bus.

In practice the open-source ThingsBoard IoT Gateway (Apache 2.0) works well: it ships ready-made connectors for Modbus, OPC-UA, MQTT, BACnet, CAN bus, BLE, ODBC and REST, maps raw values into a unified format via configurable converters, and buffers telemetry locally if the connection to the platform drops (github.com/thingsboard/thingsboard-gateway, docs). Alternatively or in addition, Node-RED handles flexible flows and local pre-processing.

This yields a single unified data stream, no matter how heterogeneous the machine park is.

Analysing data in ThingsBoard and Grafana

In ThingsBoard the MQTT telemetry arrives as device readings. The platform handles device management, a visual rule engine, alarms and operational dashboards. Current versions (4.x) add calculated fields for derived metrics, maps and SCADA symbols; from 4.2, AI is native in the rule engine. The Community Edition is open source under Apache 2.0 and usable with no device limit - details in What is ThingsBoard? and on our ThingsBoard expertise.

For historical analysis, long-term trends and mixed data sources, Grafana completes the picture. The sensor time-series usually land in InfluxDB, which Grafana reads directly. A concrete step-by-step guide is at Grafana IoT dashboard with InfluxDB. In practice both tools often run together: ThingsBoard for live operation and alarms, Grafana for deeper long-term analysis and central operations monitoring.

Thresholds and anomaly detection for predictive maintenance

Predictive maintenance does not start with AI but with clear rules. ThingsBoard offers alarm rules with two modes:

• Simple: the alarm is created immediately when a threshold is exceeded (e.g. bearing temperature above 80 degrees).
• Duration: the alarm is created only if the condition holds for a period (e.g. vibration above the limit for 5 minutes) - which suppresses false alarms from brief spikes (alarm rules docs).

Calculated fields keep a rolling window of the last values and minutes, delivering trends, moving averages or deltas - the basis for spotting gradual degradation rather than only checking hard limits.

Only on this foundation does AI-based anomaly detection pay off. ThingsBoard can evaluate data patterns via the AI Rule Node and automatically raise an alarm on anomalies; Trendz Analytics additionally offers anomaly-driven alerting (example: AI-based anomaly detection). The pragmatic path: get thresholds right first, then add anomaly detection precisely where fixed limits fall short.

From dashboard to secure remote maintenance

A detected anomaly is only half the journey. Remote maintenance closes the loop: as soon as an alarm shows a fault emerging, technicians inspect, reconfigure or fix from afar - without a site visit. The IoT platform delivers the diagnostic data, and secure remote access provides controlled entry to the machine.

Both stay self-hosted and sovereign. How access to the machine and controller is secured - with WireGuard, ZTNA and audit instead of open ports - is covered in the cross-cluster guide Secure remote maintenance for machines & plants. Predictive maintenance and remote maintenance together form an end-to-end, data-driven maintenance process.

What does a self-hosted predictive maintenance stack cost?

The software layer is open source and usable without a per-device licence. You pay for infrastructure, hardware per machine and operations - not per device and data point as with managed clouds.

ThingsBoard Professional self-managed starts at 10 USD/month in the Maker plan (10 devices) and goes up to 499 USD/month in the Business plan (1,000 devices), with 0.10 USD per extra device beyond that, per the price list (as of 30 Jun 2026, thingsboard.io/pricing). The Community Edition already covers many retrofit scenarios for free; the PE pays off mainly for white-labelling, advanced roles and ready-made integrations.

The comparison with AWS IoT, Azure IoT or Cumulocity is clear: those bill per device and data point, which scales linearly with the number of machines. Self-hosted keeps billing tied to infrastructure - and the data stays in the EU and under your own control.

Implement predictive maintenance pragmatically with WZ-IT

We start with a pilot machine: define measurement points, set up sensing and an edge gateway, convert OPC-UA/Modbus to MQTT and run the data path all the way to the dashboard. Once the base is in place with clean thresholds, we add more machines step by step and - where it makes sense - AI-based anomaly detection. Self-hosted, vendor-neutral, without per-device licences and with honest cost accounting.

See our IoT services - IoT platform development - Book an intro call