Anomaly detection has a glamorous reputation, and vendors are happy to sell it as an AI feature you switch on. In practice, most useful anomaly detection on sensor data starts with arithmetic you could do in a spreadsheet. The hard part is not the algorithm. It is deciding what “unusual” means for a given sensor and what anyone will do when it fires.

Define the Failure You Care About

An anomaly is only interesting if it maps to an action. Before choosing a method, write one sentence: “I want to know when X happens so that someone can do Y.” If you cannot finish that sentence, you are building a curiosity, not a monitor.

Different sentences lead to different detectors. “A freezer door was left open” is a sustained rise in temperature. “A bearing is wearing” is a slow drift in vibration. “A sensor has failed” is a flat line or an impossible value. Each looks different in the data, and one method will not catch all three.

Level One: Fixed Limits and Sanity Checks

The simplest detector is a fixed range. A refrigerator should not read above a certain temperature, and no outdoor air sensor should report a value outside what is physically plausible. These checks are cheap, explainable and catch a surprising share of real problems, especially sensor faults.

Add a few more cheap ones:

• Stuck value: the reading has not changed at all for longer than the sensor normally allows.
• Missing data: no readings for several expected intervals.
• Rate of change: the value moved faster than the physical process can.

Rate of change deserves attention. A tank cannot lose most of its contents in a few seconds, so a rapid drop usually means a faulty sensor, not an event.

Level Two: Baselines That Move

Fixed limits fail where “normal” changes over time. A building’s energy draw is different at night and in the afternoon, and different on weekends. Comparing a reading to a single global threshold either fires constantly or never.

A rolling baseline fixes this. Compute the typical value and the typical spread over a recent window, ideally for the same time of day or day of week, and flag readings that sit far outside it. The spread matters as much as the average: a noisy sensor needs a wider tolerance than a calm one.

Two practical tips. First, use robust measures such as the median, which are not dragged around by the very outliers you are hunting. Second, require the deviation to persist for a few consecutive readings before alerting. A single odd sample is usually noise.

Level Three: Compare Peers

When you have many similar devices, compare each one to the others. If a machine’s temperature is high, is it high for everyone, because the weather changed, or only for this unit? Peer comparison removes shared influences and isolates the device that has actually changed.

This is often the best return on effort in fleets, because it needs little tuning and tolerates drift in conditions. The catch is that it requires comparable devices operating in comparable situations, so group them sensibly by model and environment.

When Machine Learning Earns Its Place

Learning-based detectors can help when relationships involve many variables at once, such as a motor whose current, vibration and temperature only look abnormal in combination. They can also help when normal behavior has complex patterns that a simple baseline cannot capture.

But they carry costs: you need clean historical data, ideally with examples of what a real problem looked like; they are harder to explain to the person receiving the alert; and they need monitoring themselves, because they degrade when equipment or conditions change. A good rule is to adopt one only after a simpler method has been in production long enough to show specifically where it falls short.

Method Selection at a Glance

Method	Catches	Weakness	Effort
Fixed limits	Out-of-range values, sensor faults	Ignores context and time of day	Low
Stuck and missing checks	Dead sensors, lost data	Says nothing about the process	Low
Rolling baseline	Deviations from recent norm	Can adapt to slow drift and hide it	Medium
Peer comparison	One device differing from similar ones	Needs comparable devices	Medium
Learned multivariate model	Complex combined patterns	Needs data, explanation, upkeep	High

A Hypothetical Example

A team monitors air-handling units across several buildings. Their first idea is a learned model. Instead, they begin with a sensible limit on supply temperature, a stuck-value check, and a peer comparison within each building. Within weeks, the peer check flags one unit whose fan current is consistently higher than its siblings. It turns out to be a clogged filter.

Later, they notice the rolling baseline masks a slow decline because it keeps adjusting. They add a second, long-window comparison against a fixed reference period. Still no machine learning, and the alerts are explainable to the technician who has to climb up and look.

Keeping Alerts Useful

False alarms kill detection systems. Tune on historical data first: replay a few weeks of readings through your rules and see what would have fired. Count how many alerts you would have received and how many led to a real action.

Give each alert context: the reading, the baseline, the recent trend, and the device identity. A bare “anomaly detected” message makes people dismiss it.

Also, keep a feedback loop. When someone dismisses an alert as false, record why, and use that to adjust thresholds. Detectors that never learn from their misses get ignored.

Frequently Asked Questions

Do I need labeled failure data to start? No. Fixed limits, rolling baselines and peer comparisons need none. Labeled examples become important mainly if you later move toward learned models.

How do I avoid alerting on every spike? Require the deviation to persist across several readings, and compare against context such as time of day. Single-sample spikes are often electrical noise.

Should detection run on the device or in the cloud? Simple checks such as range and rate of change can run on the device or gateway to save bandwidth. Fleet-wide comparisons need cloud-side data.

Why does my baseline keep adapting to a real problem? Rolling windows follow slow drift. Add a long-term reference for comparison so gradual degradation does not become the new normal.

Is a vendor’s built-in anomaly feature enough? It can be a good starting point. Test it on your own historical data before trusting it, and make sure you can see why it fired.

Next Step

Choose one sensor type that matters to operations, write the “so that someone can do Y” sentence for it, and implement just the range, stuck-value and missing-data checks. Run them silently for two weeks and review what they would have caught.