Every value should carry a quality flag and a timestamp. Show gaps as gaps, hold readings at the edge during outages and never let an old value pose as a fresh one.
The Quiet Failure
When a device stops answering, many systems keep showing the last value. A frozen temperature looks like a stable one, and nobody notices until something is lost. Data quality is about making that failure visible.
Quality Flags
Each reading carries a flag: good when the device answered and the value decoded, stale when the value is older than expected, and bad when the read failed or the value could not be decoded. A failed read still produces a bad reading at that time, so history shows where and when the problem started.
Timestamps That Matter
Record the time the value was read at the source, not the time it reached the server. During an outage the two can differ by hours, and only the source time lines up readings from different protocols.
Store and Forward
An edge gateway holds readings on disk when the uplink drops and sends them in order when it returns. The history then has no hole for the outage, and the readings keep their original timestamps. The gateway should report how much it is holding, so a long outage is noticed.
Showing It Honestly
Dashboards should grey out or flag stale values and draw gaps where data is missing, instead of interpolating across them. Alerts should fire on silence as well as on thresholds. An honest gap is useful information; a repeated old value is a hidden fault.
Common Questions
What does a stale reading mean?
A value that is older than its expected update interval. It may still be correct, but it should be shown as old rather than as current.
Does store and forward lose data during an outage?
Not until the gateway buffer fills. Readings are kept on disk and sent in order when the connection returns, with their original timestamps.