Connected sensor, wrong reading: how to assess IoT data quality

A sensor stays connected, publishes messages on the expected interval, and appears available on the dashboard. Even so, the information may be wrong.

A reading may remain frozen for hours, drift slowly due to bias, arrive with the wrong unit, or represent a moment much earlier than the time shown by the platform. In all these cases, communication works. The problem is data quality.

That difference matters because many operational decisions depend on measurements produced in the field. If the platform only checks that messages arrive, a silent failure can remain active without any indication.

Communication availability does not prove measurement validity.

Received data and useful data are not the same thing

A message can reach its destination and still show problems at different points in the chain.

The sensor may measure incorrectly. The firmware may apply an inadequate conversion. The gateway may map the value to the wrong equipment. Integration may interpret a unit differently. The platform may display an old reading as if it were current.

Therefore, quality must be assessed in layers.

Does the message have the expected structure? Are the device and variable correctly identified? Is the unit of measure known? Is the observation time available and plausible? Is the value within physically possible limits? Is the variation compatible with the process? Does the reading align or conflict with other evidence from the environment?

A positive answer at one stage does not eliminate the next. A value may respect the format and sit within range but remain frozen for a period incompatible with process behavior.

Main failure patterns

Sensor failures do not always appear as a complete absence of data. A review by Sharma et al. organizes different error types and detection techniques applied to smart environments [1]. In day-to-day operations, several patterns deserve special attention.

Frozen reading

The sensor repeats exactly the same value for a prolonged period. That may indicate lockup, an update failure, or internal communication loss.

However, repetition does not automatically mean defect. A variable may remain stable. The rule must consider instrument resolution, expected process behavior, and related measurements.

Gradual drift

The reading slowly moves away from the real condition. This may come from aging, calibration drift, contamination, or changes in installation conditions.

Because the value keeps changing and may stay within wide bounds, a simple range rule may miss the problem.

Abrupt value or spike

A measurement changes suddenly and returns shortly afterward. The event may be noise, a transient fault, interference, or a real physical condition.

Discarding every spike removes important evidence. Monitoring should flag the behavior and gather context for investigation.

Excessive noise

Readings oscillate more than expected. The cause may be the sensor, power, installation, interference, or the measured process itself.

Scale or unit error

The value may be correct on the device and misinterpreted by integration. Celsius and Fahrenheit, volts and millivolts, percentage and decimal fraction are examples of differences that can produce plausible yet wrong results.

Old data shown as current

A message stored during an outage may arrive after connectivity returns. If the platform uses only the reception time, the reading looks recent.

The W3C SOSA/SSN ontology distinguishes the time an observation applies from the time its result became available [2]. That distinction helps preserve the correct measurement history.

Quality starts with a data contract

Before configuring alerts, the organization must define what each piece of information means.

That contract can include:

Device identifier. Observed variable. Unit of measure. Value type and precision. Physically possible range. Expected operational range. Update frequency. Measurement time. Quality indicators provided by the equipment. Planned handling for missing or invalid values.

Without these definitions, the platform receives numbers without enough context to assess usefulness.

The transport protocol does not solve this alone. The MQTT specification defines how messages are published and delivered, but payload content and format are defined by the application [3]. Two devices may use MQTT and represent the same variable with different names, units, and structures.

Normalizing this data requires explicit mappings and tests per equipment model.

Layered checks reduce rushed conclusions

No single technique detects every problem. A practical approach combines simple checks and process evidence.

Structural validation

Confirms required fields exist, types are correct, and the value can be interpreted. Invalid messages must be separated from valid measurements.

Freshness

Checks observation age. A coherent but old value does not necessarily represent the current state.

Physical range

Compares the reading with limits impossible to exceed under known conditions. Humidity below zero or a percentage above one hundred may indicate scale, unit, or processing error.

Operational range

Compares the value with the range expected for that process. Leaving that range may indicate sensor failure or a real event. The alert must keep that ambiguity visible.

Rate of change

Assesses how much the measurement changed in a given interval. A physically improbable change may indicate noise, conversion error, or instrumentation trouble.

Frozen reading

Observes repetition of the same value. The criterion must consider equipment resolution and the natural stability of the variable.

Comparison with other evidence

Relates nearby sensors, dependent variables, equipment states, and historical data. A temperature reading can be analyzed alongside load, ventilation, or other sensors in the same environment.

These checks should produce evidence, not automatic verdicts. Sharma et al. show detection techniques have different requirements, advantages, and limitations [1]. The choice depends on failure type, available data, and application context.

An unusual value does not mean a defective sensor

An uncommon value may be exactly what the sensor should reveal.

Consider equipment that normally runs at a stable temperature. A rapid rise may indicate sensor failure, but it may also represent real overheating. Replacing or ignoring the reading without context can hide the most important operational event.

Therefore, the platform should distinguish three concepts:

Invalid value: cannot be interpreted or violates a clear physical rule. Suspicious value: shows unusual behavior and needs context. Operational event: represents a real change that requires response.

This classification improves communication with the team. Instead of claiming the sensor failed, the alert can report that the reading is frozen, that the rate of change exceeded historical behavior, or that related sensors diverge.

Frozen readings require context

Detecting a frozen value seems simple: check whether it changed. In practice, the rule must answer several questions.

What is the sensor resolution? How often does the process usually vary? Does the equipment publish the full value or only when a change occurs? Is there rounding? Are other device indicators still updating?

A presence sensor may remain in the same state for hours without issue. A counter that should increase every cycle may look suspicious after a few minutes without change. Ambient temperature may vary little, while a component under load should track operational changes.

A reliable rule combines time, expected variation, and activity of other metrics for the same asset.

Timestamps must follow the value

An IoT architecture can have multiple clocks: on the sensor, gateway, broker, and platform.

If these times are not preserved, the team loses part of the data history. Transmission delay may also be read as a late process change.

The ideal is to record observation time and reception time. When possible, there should be a policy for clock synchronization and handling devices that send invalid times.

This care is especially important with local storage. After connectivity returns, several measurements may arrive in sequence. The platform must place them on the correct timeline without presenting them as the current state.

How to structure handling of a suspicious reading

A quality incident must provide elements for investigation.

Affected device and variable. Current value and unit. Measurement and reception times. Rule that flagged the data as suspicious. Recent history. Communication state. Power and gateway indicators when available. Comparison with related sensors or variables. Recent configuration or firmware changes.

The team can then confirm the process, compare instruments, review installation, and decide whether recalibration, replacement, or monitoring is needed.

History also reveals patterns. A reading may become unstable only at a certain temperature, during signal loss, or after power changes. These relationships help guide investigation but should not be treated as proven causality without additional evidence.

Artificial intelligence does not remove the need for basic rules

Statistical models and machine learning techniques can support detection of complex behaviors. Microsoft Research, for example, presented a verified telemetry approach to detect IoT sensor faults using auxiliary signals and models of physical behavior [4].

These techniques do not replace correct identification, units, timestamps, physical ranges, and process knowledge. If input data lacks context or the baseline mixes different conditions, a sophisticated model may only produce a hard-to-explain classification.

For many operations, starting with transparent rules delivers value faster. Advanced techniques can be added when historical data, evaluation criteria, and need justify the complexity.

The goal is to preserve trust without hiding real events

IoT data quality must be monitored continuously. A connected device can produce frozen, delayed, inconsistent, or misinterpreted readings.

A consistent strategy starts with a data contract and combines structural validation, freshness, physical limits, rate of change, freeze detection, and operational context.

This deep dive complements the article on IoT device monitoring. The previous article in this series addresses device silence. This text focuses on situations where data exists but its reliability must be investigated.

For managers in IT, telecommunications, infrastructure, and operations, the central point is to keep uncertainty visible. The platform should explain why a reading looks suspicious and provide evidence so the team can separate sensor failure from a real environmental change.

Reliable IoT data depends on both continuous communication and the ability to assess what each measurement means.

About Target Solutions

Target Solutions has spent more than 15 years helping organizations evolve their infrastructure, monitoring, observability, automation, and operational intelligence operations. Across that journey, it has participated in projects in demanding environments such as telecom, technology, government, energy, and large enterprises, helping increase operational efficiency and service reliability.

That experience also includes Internet of Things (IoT) projects, where connectivity, technical integration, and operational follow-up matter to turn connected devices into useful solutions for organizations.

About the author

Paulo Florêncio de Menezes is cofounder of Target Solutions and has spent more than 15 years on projects involving infrastructure, monitoring, observability, automation, and IT and telecom operations.

He holds a degree in data processing from the Federal University of Amazonas (UFAM), an MBA in business management from Fundação Dom Cabral (FDC), and a professional master’s in economics from Fundação Getulio Vargas (FGV).

In his master’s research, he developed the IBEOP-IA (Brazilian Index of Occupational Exposure Potential to Artificial Intelligence), studying the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] SHARMA, Sheetal; GUPTA, Kamali; GUPTA, Deepali; RANI, Shalli; DHIMAN, Gaurav. An Insight Survey on Sensor Errors and Fault Detection Techniques in Smart Spaces. Computer Modeling in Engineering & Sciences, v. 138, n. 3, p. 2029-2059, 2024.

[2] W3C. Semantic Sensor Network Ontology. W3C Recommendation, 19 Oct. 2017.

[3] OASIS. MQTT Version 5.0. OASIS Standard, 7 Mar. 2019.

[4] GUPTA, Tanmaey; HANDA, Shubhankar; NAMBI, Akshay. Verified Telemetry: A General, Easy to Use, Scalable and Robust Fault Detection SDK for IoT Sensors. Proceedings of the 8th ACM/IEEE Conference on Internet of Things Design and Implementation, 2023.