I've mentioned, in almost everything I've written about building for the physical world, that sensors lie — and then promised to come back to it properly. This is me keeping that promise, because handling dishonest sensor data isn't a footnote to building an IoT platform. It's the bulk of the real work, the difference between a demo that dazzles and a system you can actually trust. Tutorials give you clean, honest, well-behaved data. Reality gives you sensors that drop offline, get stuck, report the impossible, and turn up late with an hour of backdated readings. Your platform's real job is to stay trustworthy anyway.

Let me lay out the ways sensors lie, and how to cope with each, because once you can name the failure modes you can design for them instead of being ambushed by them.

The catalogue of lies

Real sensors deceive you in a small number of recognisable ways, and learning to recognise them is half the battle:

  • The dropout. The sensor goes silent — dead battery, network blip, a person unplugging it to charge their phone. For a while, no data. The lie here is one of omission, and it's dangerous because "no reading" can be silently mistaken for "nothing happening," when actually it means "we don't know."
  • The stuck value. The sensor keeps reporting, but it's frozen — the same reading, over and over, long past when anything real would have changed. A temperature sensor insisting it's exactly 21.0°C for six hours isn't reporting the temperature; it's reporting that it's broken, in a voice that sounds exactly like healthy data.
  • The impossible spike. A sudden, physically absurd value — a room at 500°C, an occupancy count of negative four. Obvious to a human, and yet it flows into your averages and alarms as though it were real unless something stops it.
  • The slow drift. The insidious one. The sensor isn't broken, exactly — it's just gradually, quietly wrong, reading a degree or two off and drifting further over months. No single reading looks alarming. The whole trend is a lie, and it's the hardest to catch because nothing ever looks wrong.
  • The late and out-of-order arrival. The sensor comes back from a dropout and dumps its backlog all at once — readings stamped an hour ago, arriving now, in whatever order they please. I've written about this from the streaming side; from the data-quality side it's the lie of time itself being unreliable.

Every one of these will happen. Not might — will, routinely, in any real deployment. So the platform has to assume them.

The governing principle: distrust, then verify

The single most important shift in building for real sensors is a posture change: treat every reading as guilty until proven innocent. Clean-data thinking assumes the reading is true and handles errors as exceptions. Real-sensor thinking inverts that — the reading is a claim that has to survive scrutiny before you let it into anything that matters. That distrust, baked in at the boundary, is what separates a robust platform from a fragile one.

Concretely, that distrust becomes a set of defences:

  • Validate at the door. Before a reading is allowed anywhere near your aggregates and alerts, check it against what's physically possible. A room cannot be 500°C; occupancy cannot be negative. Bounds-checking at ingestion catches the impossible spikes before they can poison anything downstream. It's cheap and it's the highest-value thing you can do.
  • Detect the stuck by watching for the unnaturally unchanging. Real-world signals wobble; they have noise. A value that is perfectly constant for a long stretch is, paradoxically, suspicious — reality is rarely that still. Flagging "this hasn't moved at all in a way real data never does" catches the frozen sensor that would otherwise masquerade as calm.
  • Treat absence as its own state. A gap in data must mean "unknown," never "zero" and never "unchanged." The dropout is only dangerous if your system silently fills the silence with an assumption. Make missing data explicit — a known unknown — so downstream logic can handle "we don't know" honestly rather than inventing a comforting number.
  • Handle the late arrivals by trusting event time, not arrival time. When the backlog floods in, place each reading where it belongs by its own timestamp, not where it happened to land in the queue. This is the streaming lesson and the data-quality lesson meeting: the reading's honest home is its event time.

The hard one: catching the slow drift

The defences above catch the loud lies. The slow drift is the quiet one, and it needs a different tactic, because no single reading ever trips a bound. Drift is only visible in relationships — comparing a sensor against its peers, against its own history, against physical reality.

If one temperature sensor slowly diverges from the three others in the same space that used to agree with it, none of them individually looks wrong, but the disagreement is the signal. Catching drift means watching how sensors relate to each other over time, not just checking each one in isolation. It's more work, and it's the difference between finding a miscalibrated sensor in a week versus discovering, months later, that a season's worth of conclusions rested on a reading that was quietly two degrees off the whole time. Where you can, cross-check against something independent; where you can't, at least watch the herd for the animal that's wandering.

Why this is the actual craft

Here's the reframe I want to leave you with, because it changed how I see this whole discipline. When I started, I thought the hard, impressive part of an IoT platform was the architecture — the streaming, the scale, the clever pipelines. Those matter. But they're the known part; they're what the tutorials teach. The part that actually determines whether anyone can trust your system — the part that is the craft — is everything you do to cope with the fact that your data source is a pile of cheap physical devices that fail in a dozen mundane ways.

A sensor is not a data source. It's a witness of variable reliability, and your platform is the process that decides how much to believe it. Build as though every reading is honest and you'll build something beautiful that's confidently, continuously wrong.

The dashboards and the streams are the glamorous 10%. The patient, unglamorous 90% is making a system that stays honest when its inputs don't — validating, cross-checking, treating absence as absence and stuckness as failure, and never, ever taking a reading's word for it just because it arrived looking like data. Get that right and the building can talk to you truthfully. Skip it and it will lie to you fluently, in the exact tone of voice you were hoping to trust.