IoT Sensor Fusion | mysimulator.uk

A sensor network is mostly a messaging problem

An IoT deployment — a smart building, a farm, a factory floor — might have thousands of battery-powered nodes, each reporting temperature, vibration, occupancy or humidity every few seconds over an unreliable wireless link. The hard part is rarely the physics of the sensor; it is moving that data reliably without draining the battery in a week or flooding the network. That is why almost every IoT stack is built on MQTT (Message Queuing Telemetry Transport), a publish/subscribe protocol designed in 1999 for oil pipeline telemetry over expensive, unreliable satellite links — exactly the low-bandwidth, high-latency conditions IoT still faces today.

live demo · nodes reporting to a broker● LIVE

Publish, subscribe, and three levels of "I promise"

In MQTT, a sensor never talks to a dashboard directly. It publishes a small message to a named topic, such as building/floor3/room12/temp, on a central broker; anything that has subscribed to that topic — or a wildcard like building/floor3/+/temp — receives it instantly. Publisher and subscriber never need to know about each other, which is what lets you add a hundred new dashboards without touching a single sensor.

QoS 0  "at most once"   fire and forget, no acknowledgement — cheapest
QoS 1  "at least once"  broker acks, sender retries until confirmed — may duplicate
QoS 2  "exactly once"   a four-step handshake guarantees single delivery — costliest

A vibration sensor streaming every 200 ms uses QoS 0 — a dropped sample is meaningless, and retrying it would just waste airtime. A fire alarm trigger uses QoS 1 or 2, because losing that one message is not an option. This tunability, plus a small binary header and a persistent TCP connection that avoids reopening handshakes, is why MQTT sips battery compared with polling a REST API every few seconds.

Edge computing: filter before you transmit

Sending every raw reading to a cloud data centre does not scale. A gateway or microcontroller at the "edge" — physically near the sensors — instead does three things before anything leaves the building: it aggregates (min/max/average over a window instead of every sample), it filters (drop values that fail a sanity check), and it fuses multiple sensors into one better estimate. Only the fused result, or an anomaly worth flagging, goes upstream. This also cuts the loop latency for anything that must react locally — a motor cutting off because of an overheat reading cannot wait on a round trip to a data centre on another continent.

The Kalman filter: combining measurements optimally

Individual sensors are noisy and sometimes disagree — a cheap accelerometer-based inclinometer drifts, a temperature probe near a doorway spikes when it opens. The Kalman filter (Rudolf Kálmán, 1960) is the standard tool for combining a noisy prediction with a noisy measurement into a single estimate that is provably better than either alone, for linear systems with Gaussian noise. It runs in two steps, repeated every time a new reading arrives:

PREDICT (using the system's motion/behaviour model)
  x_pred = F * x_prev              // project the state forward
  P_pred = F * P_prev * F^T + Q    // grow the uncertainty by process noise Q

UPDATE (fold in the new measurement z)
  K = P_pred * H^T / (H * P_pred * H^T + R)   // Kalman gain, weighs trust
  x_new = x_pred + K * (z - H * x_pred)       // pull estimate toward z
  P_new = (I - K * H) * P_pred                // uncertainty shrinks

R is the sensor's known measurement noise variance and Q is how much the true state is expected to drift between updates. When R is small (a precise sensor), the gain K is close to 1 and the filter trusts the new reading heavily; when R is large (a noisy sensor), K shrinks and the filter leans on its own prediction instead. Fusing two independent sensors of the same quantity — say a barometric and an ultrasonic height sensor — this way yields an estimate whose variance is always less than or equal to the better of the two inputs alone, which is the entire point of sensor fusion.

Frequently asked questions

What does MQTT actually do that plain HTTP does not?

MQTT is publish/subscribe rather than request/response, so a sensor publishes one message to a topic and any number of subscribers receive it without the sensor knowing who they are or how many there are. It keeps a persistent connection open instead of opening a new one per message, supports three delivery guarantees (at most once, at least once, exactly once), and lets a broker hold a last will message that fires automatically if a device disconnects unexpectedly. All of that costs far less bandwidth and battery than HTTP polling.

Why not just send every raw sensor reading to the cloud?

Bandwidth, latency and battery. A vibration sensor sampling at a few kilohertz would saturate a cellular link in seconds if it streamed raw data continuously, and round-tripping to a data centre before an actuator can react adds tens to hundreds of milliseconds a safety system cannot afford. Edge computing filters, aggregates and runs Kalman fusion locally, sending the cloud only summaries, anomalies and fused estimates — often two to three orders of magnitude less data.

Why does the Kalman filter trust some sensors more than others?

Because the Kalman gain weights every measurement by its known noise variance. A sensor with a small, well-characterised noise variance pulls the fused estimate toward its reading strongly; a noisy or drifting sensor is down-weighted automatically. The filter is not guessing which sensor to trust — it is solving, at every step, the exact weighting that minimises the variance of the combined estimate, given the noise statistics you fed it.

Try it live

Everything above runs in your browser — open IoT Sensor Network and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.

▶ Open IoT Sensor Network simulation

IoT Sensor Networks: MQTT, Edge Computing and the Kalman Filter