The Last Reading Does Not Prove a Sensor Is Online

Offline sensor detection cannot rely on whether a dashboard still shows a number. The application may retain the last stored reading after new measurements have stopped, so a plausible value does not prove that the monitoring point is still active.

An actionable status needs several pieces of evidence: when the measurement occurred, when the server received it, whether the device or gateway still sends a heartbeat, and whether the sensor channel reports a healthy condition. One online indicator cannot represent the entire path.

A last reading does not show whether the sensor is still active

Suppose the last water-level reading is 1.42 metres. That value may remain stored when the sensor stops sampling, the RS485 link fails, the logger no longer runs its measurement task, or the network path to the server disappears. Without data age and a status reason, an operator sees only the last result, not the current condition.

A dashboard should therefore show measurement time and record age beside the value. Timestamps exchanged between systems also need an explicit time-zone offset or relationship to UTC so sensor, logger, server, and state-transition times can be compared without ambiguity. RFC 3339 defines an Internet timestamp format that includes this relationship.

Old data is also different from poor-quality data. The Argatech article on sensor data quality explains record-level QC states such as pass, suspect, fail, and missing. Freshness asks whether a record is recent enough; a quality flag asks whether it passed the configured checks. The two should remain separate.

Separate data age, heartbeat, and connection state

Each signal answers a different question. Collapsing them into one green or red light makes the source of a fault harder to locate.

Evidence	Question it answers	Interpretation limit
Measurement time	Is the channel producing records on its expected schedule?	A new record does not guarantee that the full path will remain available
Server receipt time	Has the record reached the central application?	The record may be delayed or part of a backlog after recovery
Application heartbeat	Is the device or application reporting under its status contract?	A device heartbeat does not prove that every sensor channel is healthy
Connection state	Is the transport session or communication path still detected as active?	An active connection does not prove that the measurement task is running
Channel diagnostics	Does the sensor, field interface, or read process report a fault?	Meaning depends on the selected equipment and integration

Microsoft Azure IoT Hub documentation illustrates why a platform connection state and a custom heartbeat are separate approaches. This example does not show that Fortuna Argatech uses Azure or a particular heartbeat pattern; it is useful because it separates the operational questions.

The public GEOVOS 1000 data logger page verifies a context that includes RS485, 4G, local storage, a monitoring platform, dashboards, and notifications. It does not publish the protocol, heartbeat, status fields, or offline-state algorithm, so those details must be confirmed for the project configuration.

Offline sensor detection needs more than one signal

A team can begin with a two-axis matrix: whether the measurement is fresh and whether the device or gateway heartbeat is still arriving. Connection events, channel diagnostics, quality flags, and server receipt time then provide supporting evidence. The labels below are a working model, not a universal status standard.

Fresh data with an available heartbeat can be shown as active. Stale data while the heartbeat continues is better described as degraded because the device responds but the channel is not updating. When both data and heartbeat exceed their project limits, an offline state has stronger support. Conflicting evidence should produce an unknown state instead of being forced into online.

The state should also retain a reason, transition time, and evidence source. Notifications can then say that a measurement exceeded its freshness limit or a heartbeat was missed rather than sending the generic message “sensor problem.”

Set stale and offline limits from the response requirement

There is no single timeout that fits every installation. Limits should be derived from the sensor read interval, logger storage interval, transmission schedule, heartbeat interval, tolerated missed cycles, network delay, and the time within which the operating team needs to respond.

Start by documenting the intervals that are actually configured. The guide to choosing data logger intervals explains why read, store, and send timing should not be treated as one value. Then define when a record is late, when it becomes stale, and what additional evidence is required before marking a device offline.

Faster detection is not automatically better. A more frequent heartbeat increases traffic and may cause unstable state changes on a weak network. A limit that is too generous delays notification. The design should follow the required response and connectivity conditions instead of copying a number from another platform.

MQTT Keep Alive is not an application heartbeat

Where an implementation uses MQTT, Keep Alive helps identify an inactive or half-open connection. The OASIS MQTT 5.0 standard defines protocol behaviour between a client and server, including closing a connection when packets are not received under specified conditions.

That mechanism still does not show whether the sensor produced a new measurement, one RS485 channel stopped, or the received value passed quality checks. An application heartbeat may provide different liveness evidence, but its format, interval, retries, and time source must be designed as part of the project architecture. This article does not claim that GEOVOS or the Argatech dashboard uses MQTT or a particular heartbeat.

Test each failure layer before go-live

The status logic becomes credible only after controlled failure-path tests. Use methods that are safe and approved for the project, then record event time at the field device, logger, server, dashboard, and notification layer.

1. Freeze or stop one sensor input without disconnecting the gateway, then confirm that the channel becomes stale or degraded while the heartbeat remains visible.
2. Interrupt an approved field interface and check that the status reason points to the channel rather than immediately blaming the cellular network.
3. Restart the logger or gateway and verify transition order, recovery time, and whether the retained value shows the correct age.
4. Simulate a network loss and distinguish connection status from local retention. The guide to data logger storage explains why a backlog delivered after recovery is not the same as live data.
5. Restore connectivity and inspect delayed records. Do not let an old measurement become fresh merely because the server received it recently.
6. Confirm that notifications use the same status rules as the dashboard and do not repeat alerts without a meaningful evidence change.

AWS IoT lifecycle-event documentation warns that connection events on that platform can be duplicated or arrive out of order. This is not evidence that Argatech uses AWS, but it demonstrates why acceptance tests should cover ordering, deduplication, and an unknown state while evidence remains inconsistent.

Bring the status contract to the integration review

Before implementation, agree on fields, timestamp sources, intervals, delay tolerance, transition rules, status reasons, notifications, and recovery evidence. Also decide whether each status applies to a sensor, channel, logger, gateway, or site; one level does not automatically represent another.

Fortuna Argatech works with telemetry, remote monitoring, data loggers, and dashboard integration. Offline sensor detection should be reviewed against the actual devices, network, database, and operating requirements selected for the project rather than inferred from a general article. To discuss the status contract and appropriate acceptance scenarios, contact the Fortuna Argatech team.