Method and system for identifying and recovering false offline of equipment under communication scene of Internet of Things

Abstract

The invention discloses a device false offline identification recovery method and system in an Internet of Things communication scene, the system comprises a server, a plurality of device ends and a front-end node, and the method comprises the following steps: each device end sends a heartbeat packet to the server regularly, the front-end node performs connection detection on each device end regularly to obtain a connection detection result, and the connection detection result is sent to the server; judging the connection state of the equipment end according to the connection detection result; the front-end node records a connection detection result, and when the server detects that a certain device end does not send a heartbeat packet overtime, the server requests the last connection state of the device end from the front-end node; and if the last connection state of the device end is normal, the device end is judged to be in a false offline state, and the server restores the connection of the device end. According to the invention, through dual detection of the front-end node and the server, the connection state of the Internet of Things equipment is determined so as to prevent false offline caused by network fluctuation from influencing normal connection communication, and the problems of low communication efficiency and high processing cost caused by false offline in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method and system for identifying and recovering devices from false offline status in IoT communication scenarios. Background Technology

[0002] In various IoT communication scenarios, terminal devices typically maintain long-term connections with cloud or local servers (brokers) via protocols such as MQTT, CoAP, and HTTP for data reporting, remote control, and status monitoring. When the connection between the device and the broker is lost, the system often classifies it as offline. This type of solution is widely used in smart homes, industrial monitoring, and connected vehicles. However, factors other than device failures, such as network jitter, short-term packet loss, sudden high server load, or LAN switching, can cause connection interruptions, leading to misjudgments as offline. Existing solutions rely on a unified reconnection strategy on the server side, and recovery typically takes tens of seconds to several minutes, affecting device availability. Insufficient automation forces maintenance personnel to manually troubleshoot and restart devices, increasing manpower and the risk of service interruption.

[0003] Therefore, there is a need for a way to avoid the problem of low communication efficiency caused by false offline status. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a method and system for identifying and recovering false offline devices in IoT communication scenarios. By employing dual detection by both front-end nodes and the server, the connection status of IoT devices is determined, thereby preventing false offline events caused by network fluctuations from affecting normal connection and communication. This solves the problems of low communication efficiency and high processing costs caused by false offline events in existing technologies.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for identifying and recovering from false offline device behavior in an IoT communication scenario, comprising a server, several device terminals, and a front-end node, including the following steps: Each device periodically sends a heartbeat packet to the server, and the front-end node periodically performs connection checks on each device to obtain connection check results. Based on the connection check results, the connection status of the device is determined, including normal or unreachable. The front-end node updates the connection status of each device. When the server detects that a device has timed out and has not sent a heartbeat packet, it requests the most recent connection status of that device from the front-end node. If the device's most recent connection status was normal, then the device is determined to be in a false offline state, and the server restores the connection to the device.

[0006] Furthermore, the front-end node periodically performs connection checks on each device. The connection checks include: performing ICMP checks, TCP checks, and HTTP checks on the device. Specifically, ICMP checks determine whether the device is reachable and obtain the round-trip time between the front-end node and the device. TCP checks send TCP handshake packets to confirm the availability of the device's listening port. HTTP checks access the device's HTTP check interface to obtain and parse the device's status code and service code.

[0007] Furthermore, the specific implementation of obtaining the connection detection result and determining the device connection status based on the connection detection result includes: when the connection detection result meets one of the following conditions, the connection status is determined to be normal; otherwise, the connection status is determined to be unreachable: ICMP detection shows the device is reachable; TCP detection shows the device's listening port is available; HTTP detection shows the status code or service code is normal.

[0008] Furthermore, each time a connection test is performed on the device, the same connection test is performed multiple times consecutively. The connection status of the device is confirmed after the results of multiple consecutive tests are consistent.

[0009] Furthermore, when the device connection status is determined to be unreachable, the front-end node generates device status change information and reports the device status change information to the server through MQTT or HTTP interface.

[0010] Furthermore, the device status change information includes a timestamp and a device ID, and the server updates the device status based on the device status change information.

[0011] Furthermore, at fixed intervals, the front-end nodes will batch synchronize the device connection status to the server.

[0012] Furthermore, the server calls the reconnection interface, reuses the original connection parameters between the server and the device to reconnect, and performs incremental subscription on the device.

[0013] Furthermore, when the connection detection result is unreachable, the device is determined to be offline, and the server triggers a system alarm. Through the above technical solution, the present invention has the following beneficial effects: it introduces dual-path monitoring of connected heartbeat and independent health detection services, combined with network quality testing, effectively distinguishing between network fluctuations and actual device offline status. Moreover, the present invention is based on a general communication protocol, requiring no modification to the server-side protocol, and only requires the deployment of lightweight modules on the client or edge nodes, reducing system transformation costs. Attached Figure Description

[0014] Figure 1This is a schematic diagram of the overall process of a device false offline identification and recovery method in an Internet of Things communication scenario according to the present invention.

[0015] Figure 2 This is a schematic diagram of the structure of a device false offline identification and recovery system in an IoT communication scenario according to an embodiment of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] Example 1 See Figure 1 A method for identifying and recovering devices from false offline status in an IoT communication scenario, comprising a server, several device terminals, and a front-end node, including the following steps: Each device periodically sends a heartbeat packet to the server, and the front-end node periodically performs connection checks on each device to obtain connection check results. Based on the connection check results, the connection status of the device is determined, including normal or unreachable. The front-end node updates the connection status of each device. When the server detects that a device has timed out and has not sent a heartbeat packet, it requests the most recent connection status of that device from the front-end node. If the device's most recent connection status was normal, then the device is determined to be in a false offline state, and the server restores the connection to the device.

[0019] Specifically, the device end is an IoT device terminal, which maintains a long connection with the server and conducts data communication through protocols such as MQTT, CoAP, and HTTP; the server is a backend server, which is a cloud or local message middleware that forwards messages and maintains connection status; the front-end node is a third-party health detection service front-end application or a local edge node, deployed on a browser, mobile terminal, or local gateway, which subscribes to device status topics through the same protocol to monitor and handle false offline situations.

[0020] In an optional embodiment, the front-end node periodically performs connection checks on each device. The connection checks include: performing ICMP checks, TCP checks, and HTTP checks on the device. Specifically, ICMP checks determine whether the device is reachable and obtain the round-trip time between the front-end node and the device. TCP checks send TCP handshake packets to confirm the availability of the device's listening port. HTTP checks access the device's HTTP check interface to obtain and parse the device's status code and service code.

[0021] ICMP testing is primarily used to test network reachability and latency, helping to identify overall network status and basic connectivity issues; TCP testing establishes TCP connections to verify whether the target host's ports are open, thereby assessing service availability and connectivity; HTTP testing focuses on the application layer, sending HTTP requests and analyzing response status to confirm the normal operation of web services and their performance metrics.

[0022] Optionally, the test may also include a DNS resolution test to test whether the device has normal domain name resolution capabilities.

[0023] Each connection check will generate one of the following states: Normal: Connection successful, round-trip latency <300ms, status code normal.

[0024] High latency: Connection is successful but round-trip latency >500ms, or a timeout occurs and retry is performed.

[0025] Unreachable: Connection failed or response error.

[0026] When the detection result is normal or the latency is high, the device is determined to be in a false offline state; when the detection result is unreachable, the device is determined to be truly offline.

[0027] In an optional embodiment, obtaining the connection detection result and determining the device connection status based on the connection detection result is specifically implemented as follows: when the connection detection result meets one of the following conditions, the connection status is determined to be normal; otherwise, the connection status is determined to be unreachable: ICMP detection shows the device is reachable; TCP detection shows the device's listening port is available; HTTP detection shows the status code or service code is normal.

[0028] When the test results meet one or more of the above conditions, it indicates that there is no disconnection problem on the device side. This proves that the device side and the server have lost some data due to network fluctuations, which is a false offline state. No disconnection or other operations are required to avoid network redundancy.

[0029] In an optional embodiment, each time a connection test is performed on the device, the same connection test is performed multiple times consecutively. The connection status of the device is confirmed after the results of the multiple consecutive tests are consistent.

[0030] Specifically, each test is performed three times consecutively. If the results of the three consecutive tests are consistent, the device status is confirmed, thus avoiding misjudgments caused by network jitter.

[0031] In an optional embodiment, when the device connection status is determined to be unreachable, the front-end node generates device status change information and reports the device status change information to the server via MQTT or HTTP interface.

[0032] Ensure that the server-side status is consistent with the front-end / edge nodes to avoid false alarms or business interruptions caused by inconsistencies between the front-end and back-end statuses.

[0033] In an optional embodiment, the device status change information includes a timestamp and a device ID, and the server updates the device status based on the device status change information.

[0034] All reported information includes a timestamp and device ID. The server uses version numbers to ensure idempotency of updates and avoids data pollution caused by network retries.

[0035] In one optional embodiment, the front-end node synchronizes the device connection status to the server in batches at fixed intervals.

[0036] After caching its state locally, the device can quickly respond to user requests. When communicating with the server, it only needs to periodically synchronize its state, avoiding delays caused by relying on the real-time network center for every operation. When the server loses its connection with a device, it can directly determine whether the device is in a false offline state by reading the device state synchronized to the server from the front-end node, without having to request data from the front-end node multiple times for confirmation, thus improving the efficiency of false offline determination.

[0037] In an optional embodiment, the server calls the reconnection interface, reuses the original connection parameters between the server and the device to reconnect, and performs incremental subscription on the device.

[0038] Incremental subscription is a data subscription model primarily used in scenarios with frequent data updates or large data volumes. It reduces the amount of data transmitted and improves system efficiency by incrementally acquiring new data. When the data source changes, incremental subscription can transmit only the changed data, rather than transmitting the entire dataset each time. This significantly reduces the burden of data transmission, and by processing only newly added or modified data, incremental subscription can significantly improve system performance, reduce latency, and decrease network bandwidth consumption, which is especially important for mobile devices or environments with limited network conditions.

[0039] After determining that the device is in a false offline state, the data lost during the false offline process is retransmitted through incremental subscription to resynchronize the communication between the device and the server. This effectively stabilizes the connection between the device and the server without reducing communication efficiency. At the same time, it skips exponential backoff and random jitter, bypasses the delay strategy in the original communication protocol's automatic reconnection mechanism, and improves connection efficiency.

[0040] In an optional embodiment, when the connection detection result is unreachable, the device is determined to be offline, and the server triggers a system alarm.

[0041] When a device is determined to be truly offline, an alarm will be pushed to the user via system notification, email, or SMS to remind the user of the device's offline status in real time and to address the offline device issue promptly.

[0042] Example 2 See Figure 2 A device false offline identification and recovery system for IoT communication scenarios includes: The connection detection module is used to enable each device to periodically send heartbeat packets to the server. The front-end node periodically performs connection detection on each device, obtains the connection detection results, and determines the connection status of the device based on the connection detection results. The connection status includes normal or unreachable. The offline detection module is used to enable the front-end node to update the connection status of each device. When the server detects that a device has timed out and has not sent a heartbeat packet, it requests the latest connection status of the device from the front-end node. Offline detection module: When the connection status is normal, the device is determined to be in a false offline state, and the server restores the connection to the device.

[0043] The embodiments disclosed in this specification are merely illustrative of one aspect of the invention, and the scope of protection of the invention is not limited to these embodiments. Any other functionally equivalent embodiments fall within the scope of protection of the invention. Those skilled in the art can make various other corresponding changes and modifications based on the technical solutions and concepts described above, and all such changes and modifications should fall within the scope of protection of the claims of this invention.

Claims

1. A method for device false offline identification recovery in an Internet of Things (IoT) communication scenario, characterized in that, The application relates to a device connection state detection method and device, and a server, a plurality of device ends and a front-end node are included, and the method comprises the following steps: Each device end periodically sends a heartbeat packet to a server, and a front-end node periodically performs connection detection on each device end to obtain a connection detection result, and a device end connection state is determined according to the connection detection result, wherein the connection state comprises normal or unreachable; The front-end node updates the connection state of each device end, and when the server detects that a device end does not send a heartbeat packet in a timeout period, the server requests the latest connection state of the device end from the front-end node; If the latest connection state of the device end is normal, the device end is determined to be in a false offline state, and the server restores the connection of the device end. 2.The method of claim 1, wherein, The front-end node periodically performs connection detection on each device end, and the connection detection comprises ICMP detection, TCP detection and HTTP detection on the device end, wherein the ICMP detection judges whether the device end is reachable and obtains the round-trip delay between the front-end node and the device end, the TCP detection sends a TCP handshake packet to confirm the availability of a listening port of the device end, and the HTTP detection accesses an HTTP detection interface of the device end to obtain and parse a status code and a business code of the device end. 3.The method of claim 2, wherein, The connection detection result is obtained, and the device end connection state is determined according to the connection detection result, and the specific implementation mode comprises the following steps: when the connection detection result satisfies one of the following conditions, the connection state is determined to be normal, otherwise the connection state is determined to be unreachable: The ICMP detection result shows that the device end is reachable; the TCP detection result shows that the listening port of the device end is available; and the HTTP detection result shows that the status code or the business code is normal.

4. The method of claim 2, wherein, Each time the connection detection is performed on the device end, the same connection detection is continuously performed for multiple times, and the connection state of the device end is confirmed after the results of the multiple times of detection are consistent.

5. The method of claim 1, wherein, When the device end connection state is determined to be unreachable, the front-end node generates device end state change information, and the front-end node reports the device end state change information to the server through an MQTT or HTTP interface.

6. The method of claim 5, wherein, The device end state change information comprises a timestamp and a device ID, and the server updates the state of the device end according to the device end state change information.

7. The method of claim 1, wherein, Every fixed time, the front-end node synchronizes the connection states of the device ends to the server in batches. 8.The method of claim 1, wherein, The specific implementation of the step of determining that the device end is in a false offline state and restoring the connection of the device end comprises the following steps: the server calls a reconnection interface, reuses original connection parameters of the server and the device end to reconnect, and performs incremental subscription on the device end.

9. The method of claim 1, wherein, When the connection detection result is unreachable, the device end is determined to be in an offline state, and the server triggers a system alarm.

10. A device offline identification recovery system in an Internet of Things communication scenario, characterized in that, The application relates to a device connection state detection method and device, and a server, a plurality of device ends and a front-end node are included, and the method comprises the following steps: A connection detection module is used for periodically sending a heartbeat packet to a server by each device end, periodically performing connection detection on each device end by a front-end node, obtaining a connection detection result, and determining a device end connection state according to the connection detection result, wherein the connection state comprises normal or unreachable; An offline detection module is used for updating the connection state of each device end by the front-end node, and requesting the latest connection state of a device end from the front-end node when the server detects that the device end does not send a heartbeat packet in a timeout period. Offline determination module; when the connection state is normal, it is determined that the device end is in false offline state, and the server restores the connection of the device end.

Images