Definition
Connection Status shows device statuses such as Online, Offline, and Inactive. It supports offline duration statistics, batch offline alarms, and the configuration of offline threshold automatic alerts.
Status Types and Judgement
Common statuses include: Online — device has established a connection and heartbeat is normal; Offline — no messages received beyond the heartbeat timeout threshold; Inactive — device is registered but has never successfully connected; Disconnected — connection was abnormally disconnected. The judgment logic is usually based on MQTT's Last Will, heartbeat interval, or platform-side timeout configuration, and thresholds should be reasonably set considering network fluctuations and device sleep strategies to avoid false alarms.
Monitoring and Alerting
The platform supports statistics of online rates by product, group, or region, displaying offline device lists and offline durations. Using the Rule Engine, rules such as "offline for more than N minutes" or "batch offline exceeds M devices" can be configured to trigger alerts, which are pushed to operation personnel or the ITSM ticket system. Offline historical trend analysis is supported to assist in identifying network failures or mass device anomalies.
Integration with Device Monitoring
Connection status is one of the core metrics of Device Monitoring, along with device health scores, telemetry data, and alert statistics, which together form the operations dashboard. For critical devices, more detailed online statuses (such as active/idle) can be set, and they can be analyzed in conjunction with other business metrics.
Which signals decide online and offline
Connection status means the platform marks a device online, offline, or not yet activated according to whether the session is still alive. It does not mean the business data is good or bad. Online usually means a transport session exists and a heartbeat, a message, or a keepalive was seen within the agreed time. Offline means those signals are still absent after the timeout, or a disconnect such as a last will was received. Not yet activated means the record exists, but this device has never completed a connection after authentication. The three cannot be inferred from one another. When there is no session, the platform should not keep showing an old reported value in the shadow as “currently online.”
Before use, set the heartbeat interval and the offline timeout per product. The timeout should be clearly longer than the normal reporting cycle, and it should leave room for the network round trip and for reconnecting. A device that is always powered and keeps a long connection, and a device that wakes on a schedule, cannot share one threshold. A last-will message matters only if it was registered successfully when the connection was established. A device that has never connected will not have a last will. State changes should record when they happened, so they can be compared when telemetry stops: whether the link broke first or reporting stopped first leads to different conclusions. A bulk offline alarm should also look at whether these devices are concentrated on the same gateway or the same carrier access point, so a regional network fault is not split into a huge number of single-device alarms.
When a sleeping terminal is counted as a fault
The most common misjudgment is to treat power-saving sleep as an offline fault. A device designed to wake once every several hours will alarm all night if the timeout is set to the few minutes used for a mains-powered device. Another is to show “authentication failed” as ordinary offline. The repair person checks the antenna when the credential has in fact been revoked. A network-address change, or a load balancer moving the session to another node, can also show a short inconsistency if session state is not synchronized: the device is still sending messages, and the console shows offline. If not-yet-activated and long-offline-after-activation are combined into one filter, devices still on the production line and not yet shipped mix into the fault list.
When the device comes back online, do not automatically fill the gap during offline as “normal the whole time.” Desired configuration in the device shadow can continue to be delivered after the device comes online, but the connection status itself should reflect this session, not carry forward the last success from before the offline. If a device with a wrong clock overwrites the disconnect time observed by the platform with the device’s local time, the timeline shifts. After a judgment rule changes, say when the new rule takes effect. Otherwise the historical online statistics and the current list will not match, and it will look as if devices dropped offline in large numbers.
When the session remains but messages have stopped
If connection status looks only at whether the transport session is still attached to an access node, “the channel is still there, the business has already stopped” is shown as healthy and online. Some devices keep a heartbeat while the sensor task has already exited. Some intermediate device remembers a session whose peer is long gone, and the platform does not change the judgment to offline until its own timeout. Besides the session flag, look at whether the business messages this kind of device promised appear inside its own cycle. When the two signals disagree, show online but no data, rather than simply marking it normal. The timeout starts from the last time the platform actually received a message from that device, not from the local time the device itself reports, because the local clock may stall or jump.
A bulk drop should look at the shared path first. If child devices under the same gateway disappear together, present the gateway or that link first, and then let a person expand the child devices. Otherwise the person on duty searches for the cause inside hundreds of single-device alarms. Not yet activated, offline after activation, and authentication rejected must be separate filters. A record that has not left the production line should not enter the fault queue. When status returns from offline, the gap is still a gap. It cannot be backfilled as online the whole time. After a timeout rule is adjusted, the old and new judgments need a boundary time, or the historical curve will show an unexplained step on the day the rule takes effect.