IoT anomaly detection means automatically spotting sensor readings or patterns that do not match normal behavior, early enough to act. This guide compares the main families of detectors, shows where each one should run relative to your MQTT broker, and gives you a reference architecture for publishing anomaly events that dashboards and people can trust.
What Counts as an Anomaly in IoT Data
Not all anomalies look the same, and the type you care about decides the method.
- Point anomalies. A single reading far outside the normal range: a temperature of 140 degrees on a sensor that never exceeds 80.
- Contextual anomalies. A value that is normal in one context and abnormal in another: 30 degrees is fine at noon in summer and suspicious at 3 a.m. in a cold room.
- Collective anomalies. A pattern over time: vibration that is within limits on every sample but whose spectrum slowly shifts toward a bearing fault frequency.
- Multivariate anomalies. Each signal is normal on its own, but the combination is not: high motor current with low flow suggests a blocked pump.
There is also a category that is not about the process at all: data quality anomalies such as a flatlined sensor, a stuck value, a sudden unit change or timestamps arriving out of order. In practice these are among the most common alerts, and catching them first keeps your process detectors from raising false alarms.
Families of IoT Anomaly Detection Methods
| Family | Examples | Good for | Needs training data | Runs on microcontroller |
|---|---|---|---|---|
| Rules and thresholds | Fixed limits, rate-of-change limits | Known failure modes, safety limits | No | Yes |
| Statistical | Z-score, IQR, EWMA, rolling windows | Single signals with stable baseline | A short history | Yes |
| Classical machine learning | Isolation Forest, One-Class SVM, Local Outlier Factor | Multivariate tabular features | Normal data, unlabeled | Sometimes |
| Deep learning | Autoencoders, LSTM or 1D-CNN predictors | Waveforms, spectra, complex time patterns | Large normal dataset | Small models only |
| Forecast residual | Seasonal models, gradient boosting forecasts | Seasonal signals such as energy load | History with seasons | Rarely |
Statistical Detectors
Start here. A rolling mean and standard deviation, or a median and interquartile range, catch a surprising share of real problems with almost no engineering. EWMA (exponentially weighted moving average) adapts to slow drift without storing a window. These methods are explainable, cheap and easy to tune. The details and code are in sensor data outlier detection with Z-score, IQR and EWMA.
Machine Learning Detectors
When anomalies hide in the relationship between signals, train an unsupervised model on normal operation. Isolation Forest is a practical default: fast to train, robust to irrelevant features and it does not need labels. You engineer features per window (mean, RMS, peak, slope per signal) and the model scores how isolated each window is. A full walkthrough is in Isolation Forest for sensor data.
Deep Learning Detectors
For raw waveforms such as vibration and sound, autoencoders learn to reconstruct normal patterns; a high reconstruction error flags something new. They need more data and compute, and they are harder to explain, so use them when simpler features genuinely fail. Machine sound is a good example, covered in audio anomaly detection for machines.
Where Detectors Run Relative to the Broker
MQTT gives you a clean separation: devices publish data, detectors subscribe, and detectors publish results back as new messages. The MQTT broker sits in the middle and does not need to know what any detector does. That leaves three placement options.
On the Device
Run thresholds, rate-of-change checks and tiny models directly on the sensor node. Benefits: immediate reaction, no dependence on connectivity, and you can send only summaries plus anomaly events instead of raw high-rate data. Limits: small models, harder updates and no cross-device context.
At the Edge Gateway
A gateway or industrial PC subscribes to local machines, runs heavier models such as Isolation Forest or autoencoders, and publishes scores. This is the sweet spot for multivariate detection within one machine or line, and it keeps high-frequency data on site.
In the Cloud
A cloud service subscribes to many sites at once. It can compare similar machines across plants, run expensive models and combine process data with business context. Latency is higher and it depends on the uplink, so it is the wrong place for anything safety-related.
Most real systems combine all three: limits on the device, ML at the edge, fleet comparisons in the cloud, all communicating through topics.
A Reference Topic Architecture
connectmq/site1/area2/line1/pump3/telemetry raw or aggregated readings
connectmq/site1/area2/line1/pump3/anomaly detector output per asset
connectmq/site1/alerts confirmed alerts for people
connectmq/site1/area2/line1/pump3/detector/status retained: model, version, health
A detector output message should be self-explanatory:
{
"ts": "2026-10-16T09:12:30Z",
"asset": "pump3",
"detector": "iforest-v3",
"score": 0.71,
"threshold": 0.62,
"isAnomaly": true,
"features": {"currentA": 18.4, "flowLpm": 41.0},
"reason": "high current with low flow"
}
Including the threshold, the detector version and the top contributing features turns an opaque red light into something a technician can check.
A Minimal Detector Loop
The heart of any streaming detector fits in a few lines. This rolling z-score scorer is the pattern that the full real-time anomaly detection in Python tutorial expands into a complete MQTT service:
from collections import deque
import statistics
window = deque(maxlen=120)
def score(value, k=3.5):
if len(window) < 30:
window.append(value)
return None
mean = statistics.fmean(window)
std = statistics.pstdev(window) or 1e-9
z = (value - mean) / std
if abs(z) < k:
window.append(value) # only learn from normal values
return z
Notice the last detail: anomalous values are not added to the baseline, so a long fault does not slowly become the new normal.
Reducing False Alarms
False alarms kill anomaly detection projects faster than missed detections, because operators stop looking. A checklist that helps:
- Filter data quality first. Flag stuck, missing and out-of-range values separately from process anomalies.
- Use context. Ignore readings during startup, cleaning and changeovers, which you can detect from a state topic.
- Require persistence. Raise an alert only after N anomalous windows in M, not on a single sample.
- Add hysteresis. Clear the alert at a lower threshold than the one that raised it, to stop flapping.
- Separate score from alert. Publish raw scores continuously and decide alerting in a separate step you can tune.
- Review weekly. Mark each alert as useful or noise, and adjust thresholds based on that log.
- Version detectors. Put the detector version in every message so you can compare before and after a change.
Running the Messaging Layer
Detectors, dashboards, historians and alerting tools all hang off the same broker, so its reliability matters. For experiments, the free public MQTT broker that ConnectMQ runs at broker.connectmq.com is enough to wire up a simulator, a detector and a dashboard in minutes. For real plant data you want a private, TLS-secured cloud MQTT broker with per-device credentials.
ConnectMQ provides exactly that layer: MQTT 3.1.1 and 5.0 on TLS and secure WebSocket, a devices view organized by ISA-95 levels, a live topic explorer to watch scores in real time, and threshold alert rules with an alerts log for simple numeric limits. The detection models themselves run in your services, which keeps you free to use any library.
For how anomaly detection fits with forecasting, computer vision and LLM assistants, read the AI and IoT guide.
Build Your Anomaly Pipeline on ConnectMQ
Create a broker on the free Serverless plan at app.connectmq.com with no credit card, publish simulated readings, and run a detector that publishes scores back. You will see raw values and anomaly events side by side in the topic explorer within minutes.
Frequently Asked Questions
Which anomaly detection method should I start with?
Start with thresholds and a rolling z-score or EWMA on each important signal. Move to Isolation Forest or autoencoders only when you have evidence that relationships between signals or waveform shapes carry the anomalies.
Do I need labeled failure data?
No. Most IoT anomaly detection is unsupervised: models learn normal behavior and flag deviations. Labels become valuable later for evaluating and tuning alerts.
Should anomaly detection run on the edge or in the cloud?
Run fast, safety-relevant checks on the device or edge, and fleet-wide comparisons in the cloud. MQTT lets you move a detector between locations without changing the devices.
How do I publish anomaly results?
Publish a JSON message per asset on a dedicated anomaly topic including the score, threshold, detector version and contributing features. Keep confirmed alerts for people on a separate topic.
