MQTT stream dropout during network handover: stale dashboard values

A SAG mill gearbox oil-temperature trend that stops updating is not obviously broken. The line holds flat at 71.4 °C, the last value the broker published before the client lost its session. Nothing turns red. No alarm annunciates, because no configured limit has been crossed. The dashboard is not lying in the sense of showing a wrong number; it is lying by showing an old one as if it were current. This is the specific failure mode worth dismantling: an MQTT stream dropout during network handover that leaves stale values displayed with no indication of staleness.

The mechanism

MQTT is a publish/subscribe protocol running over TCP. A subscriber client — typically a dashboard backend, historian bridge, or edge gateway — maintains a session with a broker. When that client’s host moves between networks, the underlying TCP connection does not survive. The classic case is a tablet or gateway roaming between Wi-Fi access points, or a cellular modem failing over between carriers or between LTE and a private 5G slice. TCP reconnection is not instantaneous: the client must detect the dead socket, re-establish transport, re-authenticate, and re-subscribe.

Two protocol details make the gap invisible. First, MQTT has no built-in notion of “the value you are holding is now stale.” A retained message on a topic is simply the last payload the broker stored; a client that reconnects and re-subscribes receives it and has no way to distinguish a payload published 200 ms ago from one published 40 minutes ago unless the publisher embedded a timestamp and the consumer checks it. Second, if the client set a clean session flag, the broker discards the subscription state on disconnect and the client must re-subscribe from scratch — a window during which it is connected but receiving nothing.

The result is a dashboard that renders the last-known value indefinitely. For a conveyor bearing temperature, a gearbox vibration RMS, or a control valve position feedback, the operator sees a plausible number. The number is not wrong; it is old. Conventional limit alarms cannot detect this, because they evaluate the value, not its age. A high-high alarm on a SAG mill trunnion pressure will not fire on a frozen reading of 40 bar, even if the actual pressure has since climbed.

Why this is a functional-safety question, not an IT question

IEC 61511 frames safety instrumented function performance in terms of dangerous detected and dangerous undetected failures, and requires that diagnostic coverage be estimated and proof tests be defined to reveal what diagnostics miss. The relevant insight here is structural: a stale value is a dangerous undetected failure of the *communication pathway*, and it is undetected precisely because nothing in the default data path tests for it.

The condition-monitoring layer is not a safety instrumented system, and nothing here should be read as claiming it is. But the diagnostic-coverage and proof-test discipline transfers directly. Ask the same questions of the telemetry path that you would ask of a sensor: what fraction of pathway failures does my diagnostic detect, and what test reveals the ones it does not?

Diagnostic coverage for the stream

Three diagnostics are defensible and cheap to implement.

**Heartbeat with age evaluation.** Publish a monotonically increasing sequence number or a UTC timestamp in every payload. The consumer computes message age and raises a distinct “stale data” condition when age exceeds a threshold tuned to the publish interval — for example, three missed intervals. This converts an undetected failure into a detected one. The alarm is on the *pathway*, not the process, and must be annunciated separately so it is not confused with a process alarm.

**Broker-side session and connection monitoring.** MQTT 5.0 exposes a session expiry interval and a will message. Configure the will to publish a client-offline marker on a dedicated topic. A consumer subscribed to both the process topic and the offline topic can distinguish “no new data because the process is steady” from “no new data because the publisher is gone.” On the broker, monitor connected-client count and subscription count per topic; a drop to zero on a critical topic is a pathway diagnostic.

**End-to-end proof test.** IEC 61511 proof testing exists to reveal failures that diagnostics cannot. The telemetry equivalent is a scheduled injection: publish a known test value on a shadow topic, or briefly interrupt the network path in a controlled manner, and verify that the stale-data condition annunciates within the specified time. Do this on a defined interval, record the result, and treat a missed annunciation as a finding. Without this, you are asserting diagnostic coverage you have not measured.

Asset classes where this matters

The failure mode is most consequential where a frozen reading coincides with a slow-developing fault. Gearbox oil temperature on a SAG mill or a large conveyor drive can drift over tens of minutes; a stale trend hides the drift. Control valve position feedback that freezes can mask a valve failing to stroke. Bearing vibration RMS on a critical fan or mill pinion is often trended rather than limit-alarmed, so a frozen trend is doubly invisible. In each case the process hazard is real and the telemetry gap is the reason no one sees it coming.

Getting started

Inventory every dashboard and historian consumer that subscribes to MQTT, and for each one determine whether it evaluates message age. If it does not, it cannot detect a stream dropout during handover, and its displayed values should be treated as unverified. Add a timestamp or sequence number to the payload contract, implement a stale-data condition distinct from process alarms, enable broker will messages and session expiry, and schedule a proof test that deliberately breaks the path and confirms the condition annunciates. Document the diagnostic coverage you actually achieve, not the coverage you assume.

Source: live-verified — “Renascor hits battery-grade purity at Adelaide plant,” Australian Mining, 2026-10-09, https://www.australianmining.com.au/renascor-hits-battery-grade-purity-at-adelaide-plant/.

Grounded in a verified live source: Renascor hits battery-grade purity at Adelaide plant (2026-10-09) — source: live-verified.

Talk to S5 System about your site

S5 System designs and manufactures ultra-low-power industrial IoT sensors for mining, agriculture, infrastructure and utilities.

Discuss your IoT monitoring project — book a call.