Condition Monitoring vs Predictive Maintenance: Differences, Maturity Path and MQTT Data Flows

Condition monitoring vs predictive maintenance is one of the most confused comparisons in maintenance engineering, and vendors often blur it on purpose. This article separates the two clearly, shows the maturity path that leads from one to the other, and sketches the MQTT data flow you would build for each so you can decide where your plant should invest next.

The Short Answer

Condition monitoring measures the health of an asset and tells you when something is abnormal right now. Predictive maintenance uses that same health data, plus history, to estimate when a failure is likely to happen so you can plan the repair at the best moment.

Condition monitoring is a capability. Predictive maintenance is a strategy built on top of it. You cannot do predictive maintenance without condition monitoring, but you can, and most plants should, run condition monitoring long before you attempt predictions.

Condition Monitoring vs Predictive Maintenance at a Glance

Both approaches sit in contrast to reactive maintenance (fix it when it breaks) and preventive maintenance (fix it on a calendar or counter regardless of condition). The goal of both is the same: stop replacing healthy parts and stop being surprised by failing ones.

What Condition Monitoring Looks Like in Practice

A condition monitoring system continuously or periodically measures a physical quantity that reflects health:

• Vibration on motors, pumps, fans and gearboxes
• Bearing and winding temperature
• Motor current and power
• Oil quality, pressure and flow
• Acoustic emission and ultrasound

Each reading is compared with a limit. When the limit is crossed, someone gets told. That sounds simple, and it is, which is exactly why it delivers value quickly. A vibration sensor with a sensible baseline-relative alarm will catch a loose foot or a failing bearing days or weeks before it seizes. The vibration monitoring sensor tutorial walks through building one.

Condition monitoring data flow with MQTT

The flow is short: sensor to broker to alert logic to people.

sensor/gateway --publish--> acme/plant1/press/line2/hydpump1/condition
                                    |
                     MQTT broker (e.g. ConnectMQ)
                         |                    |
             threshold alert rule      dashboard / topic explorer
                         |
             acme/plant1/press/line2/hydpump1/alert  (retained)

A typical payload carries only current values and units:

{
  "ts": "2026-10-16T08:15:00Z",
  "vib_rms_mm_s": 3.1,
  "bearing_temp_c": 58.4,
  "current_a": 21.7
}

On ConnectMQ, the portal's threshold alert rules can watch fields like these and record every crossing in the alerts log, which is often enough for a first pilot. More nuanced logic, such as baseline-relative limits or requiring several consecutive violations, lives in a small subscriber service.

What Predictive Maintenance Adds

Predictive maintenance asks a harder question: given how this signal has been moving, when will it reach the point where we must act? Answering it requires three things condition monitoring does not:

1. History. Weeks or months of readings per asset, stored in a time-series database.
2. Failure knowledge. Records of what failed, when, and what the signals looked like beforehand. Without this, a model has nothing to learn from.
3. A model. Anything from a straight-line trend extrapolation to a physics-based degradation curve or a trained machine learning model. The predictive maintenance with machine learning article covers the data science side.

The output is not an alarm but a forecast: "Pump 1 bearing vibration is rising about 0.1 mm/s per day and will cross the alarm limit in roughly 12 days." A planner can then schedule the bearing change into an existing stop instead of losing a shift to an unplanned breakdown.

Predictive maintenance data flow with MQTT

The broker remains the transport, but more consumers attach to it:

sensors/gateways --> MQTT broker --> historian subscriber --> time-series DB
                          |                                       |
                          |                              model / trend job
                          |                                       |
                          <------ publish prediction -------------+
                  acme/plant1/press/line2/hydpump1/prediction  (retained)
                          |
                 CMMS integration / planner dashboard

The prediction is published back to the broker as a retained message, so any dashboard or maintenance system that subscribes immediately gets the latest forecast:

{
  "ts": "2026-10-16T09:00:00Z",
  "signal": "vib_rms_mm_s",
  "current": 3.1,
  "alarm_limit": 4.5,
  "slope_per_day": 0.11,
  "days_to_limit": 12.7,
  "confidence": "medium"
}

A Minimal Step from Monitoring to Prediction

You do not need machine learning to take the first predictive step. A rolling linear regression on a daily aggregate already gives a useful "days to limit" estimate. The Python job below reads daily values (from your historian, here a list for clarity) and publishes the forecast with paho-mqtt 2.x to the public test broker.

import json
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

ALARM_LIMIT = 4.5
TOPIC = "connectmq/demo/4c81d2/press/hydpump1/prediction"

# daily median vibration RMS in mm/s, oldest first (normally queried from your historian)
daily = [2.1, 2.1, 2.2, 2.2, 2.3, 2.3, 2.5, 2.5, 2.6, 2.8, 2.8, 2.9, 3.0, 3.1]

def linear_fit(values):
    n = len(values)
    xs = range(n)
    mx, my = (n - 1) / 2, sum(values) / n
    sxx = sum((x - mx) ** 2 for x in xs)
    sxy = sum((x - mx) * (y - my) for x, y in zip(xs, values))
    slope = sxy / sxx
    return slope, my - slope * mx

slope, intercept = linear_fit(daily[-14:])
current = daily[-1]
days_to_limit = (ALARM_LIMIT - current) / slope if slope > 0 else None

forecast = {
    "ts": datetime.now(timezone.utc).isoformat(timespec="seconds"),
    "signal": "vib_rms_mm_s",
    "current": current,
    "alarm_limit": ALARM_LIMIT,
    "slope_per_day": round(slope, 3),
    "days_to_limit": round(days_to_limit, 1) if days_to_limit else None,
}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="pdm-job-4c81d2")
client.connect("broker.connectmq.com", 1883)
client.loop_start()
client.publish(TOPIC, json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print(forecast)

This is deliberately simple. It assumes the degradation is roughly linear over the last two weeks, which is often good enough for slowly developing faults and useless for sudden ones. That limitation is the honest summary of predictive maintenance in general: it extends your warning time for gradual failures, while condition monitoring still has to catch the abrupt ones.

The Maintenance Maturity Path

Most plants move through these stages in order. Skipping steps is the most common reason predictive projects stall.

1. Reactive. Run to failure. No data.
2. Preventive. Time or counter based tasks. Data lives in the CMMS as work orders.
3. Connected. Machines publish basic state and counters. This is where an MQTT backbone usually appears, often for machine downtime tracking first.
4. Condition monitoring. Health signals on critical assets with alerts. Value arrives within weeks.
5. Condition based maintenance. Work orders are triggered by condition alerts instead of the calendar for the assets you monitor.
6. Predictive maintenance. Trend and model outputs schedule work ahead of threshold crossings.
7. Prescriptive. The system also recommends the action and the best time, considering production plans and spare parts.

Measure progress with reliability metrics rather than with the number of sensors installed. MTBF and MTTR calculation gives you a baseline before you start and a way to prove improvement afterwards.

Choosing Where to Invest

Start with condition monitoring when:

• You have critical assets with no health data at all.
• Failures are expensive but you have few historical failure records.
• You need visible results within a quarter.

Invest in predictive maintenance when:

• Condition data has been collected consistently for months on the same assets.
• You have documented failures with matching sensor history.
• Planning flexibility exists, meaning an earlier warning would actually change when work happens.

In both cases the infrastructure decision is the same: get the signals onto a reliable, well-named MQTT backbone once, and let monitoring, historians and models subscribe independently. A cloud MQTT broker makes that backbone reachable from the plant, from a data team in another location and from a maintenance planner's laptop without custom point-to-point integrations. The smart manufacturing guide describes that backbone and the ISA-95 topic structure in detail.

Common Pitfalls

1. Buying prediction before monitoring. A model trained on a few weeks of data with no recorded failures will not predict anything useful.
2. Fixed thresholds from catalogues. Every machine has its own normal. Learn baselines per asset.
3. No feedback loop. Technicians must record what they found when they respond to an alert, otherwise you can never validate or improve the logic.
4. Data in silos. If the vibration system, the CMMS and the historian cannot see each other's data, prediction stays a slide in a presentation.
5. Ignoring sudden failures. Prediction helps with gradual wear. Keep fast condition alarms in place for everything else.

Build Your Monitoring Backbone on ConnectMQ

ConnectMQ is a fully managed MQTT service with MQTT 5, TLS, retained messages, a live topic explorer and built-in threshold alert rules, so you can run condition monitoring today and attach historians and prediction jobs later as ordinary MQTT clients. Create a broker on the free Serverless plan at app.connectmq.com, no credit card required.

Frequently Asked Questions

Is condition monitoring the same as predictive maintenance?

No. Condition monitoring detects abnormal health now, while predictive maintenance uses condition data and history to forecast when intervention will be needed. Predictive maintenance depends on condition monitoring.

Which should a plant implement first?

Condition monitoring. It delivers value quickly and builds the data history that any predictive approach requires later.

Do I need machine learning for predictive maintenance?

Not necessarily. Trend extrapolation on well-chosen signals already gives useful time-to-limit estimates for gradual failures. Machine learning helps when you have rich history and many recorded failures.

What role does MQTT play in either approach?

MQTT is the transport that moves sensor readings, alerts and predictions between devices, dashboards, historians and maintenance systems. Using one broker for all of them avoids point-to-point integrations.