Remote wake-up method and system for low-power devices

Abstract

The application provides a remote wake-up method and system of a low-power device, which can trigger the low-power device to re-perform an online registration operation process by actively disconnecting a communication connection after a first remote wake-up failure, thereby overcoming the problem that repeated sending of a wake-up instruction is invalid when the low-power device is in a false active state; and when it is monitored that the low-power device continuously fails to recover to an online state, a remote restart instruction is sent only to a low-power device that meets a restart condition, thereby realizing progressive recovery of different fault levels, avoiding rapid depletion of power by repeatedly performing a restart operation on the low-power device, preventing a dramatic increase in load caused by simultaneous restart in a large-scale cluster, and effectively improving the success rate of remote wake-up.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and more specifically, to a method and system for remotely waking up a low-power device. Background Technology

[0002] Low-power devices (such as battery-powered wireless security cameras) automatically enter sleep mode during non-working hours to save power, so that the low-power devices only resume full-function operation after receiving a remote wake-up command (equivalent to restoring the operating state during working hours).

[0003] Currently, in existing technologies, when an IoT cloud platform needs to remotely wake up the aforementioned low-power devices that are in a dormant state, it typically employs a simple retry strategy of "repeatedly sending wake-up commands to the low-power devices a fixed number of times." If a response to the wake-up command is received from the low-power device, it can be determined that the low-power device has been successfully woken up. However, if no response to the wake-up command is received from the low-power device after a fixed number of attempts, it can be determined that the remote wake-up has failed.

[0004] However, the simple retry strategy used in the above-mentioned prior art has the following drawbacks in practical applications: Defect 1: The simple retry strategy can only deal with the problem of lost wake-up commands caused by instantaneous attenuation of wireless signals or mild network congestion. When the low-power device is in a "falsely active" state (that is, the communication connection between the low-power device and the IoT cloud platform is still maintained at the transport layer, but the low-power device is actually unable to respond normally due to firmware abnormalities, microcontroller crashes, etc.), the repeated sending of wake-up commands is not only meaningless, but also wastes the time and resources of the IoT cloud platform because the low-power device and the IoT cloud platform can no longer communicate normally. Defect 2: The simple retry strategy terminates the wake-up process after a fixed number of wake-up commands have been sent, lacking a progressive recovery strategy. As a result, it cannot cope with remote wake-up failures caused by different levels of faults (e.g., when a low-power device experiences a serious fault such as a microcontroller crash, simply repeatedly sending wake-up commands to the low-power device will not be enough to restore the device's operation). Defect 3: Lack of cooling protection mechanism, and all low-power devices are remotely woken up in the same way. When a low-power device fails to wake up remotely, the existing technology will repeatedly control the low-power device to restart until it returns to normal operation. This can easily cause the low-power device to quickly run out of power due to frequent restart operations, shortening the lifespan of the low-power device. In addition, in a large-scale low-power device cluster, if a large number of low-power devices are restarted due to wake-up failures at the same time, it may also cause the load on the IoT cloud platform to increase sharply in a short period of time, affecting the overall stability of the IoT cloud platform. Summary of the Invention

[0005] In view of this, this application provides a method and system for remote wake-up of low-power devices. After the initial remote wake-up fails, the system can actively disconnect the communication connection to trigger the low-power device to re-execute the registration and online operation process, thereby overcoming the problem that repeated wake-up commands are ineffective when the low-power device is in a false active state. Furthermore, when it is detected that the low-power device has not been restored to the online state, a remote restart command is only sent to the low-power device that meets the restart conditions, thereby achieving progressive recovery for different fault levels. This avoids repeatedly performing restart operations on the low-power device, which would quickly deplete its power, and prevents a surge in load caused by simultaneous restarts in a large-scale cluster, effectively improving the success rate of remote wake-up.

[0006] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings.

[0007] In a first aspect, embodiments of this application provide a remote wake-up method for a low-power device, applied to the server side of an IoT cloud platform, wherein the IoT cloud platform establishes a communication connection with the low-power device, and the low-power device is an IoT device that automatically triggers a sleep state during non-working periods. The remote wake-up method includes: In response to receiving a remote wake-up request for the low-power device, the low-power device is remotely woken up for the first time by sending a wake-up data packet to the low-power device. In response to the failure of the initial remote wake-up, the communication connection between the server and the low-power device is actively disconnected, triggering the low-power device to re-execute the registration and online operation process; In response to the disconnection of the communication connection, the system periodically monitors whether the low-power device has returned to online status according to a preset time period. If the low-power device fails to return to online status after a preset number of preset time periods, it is determined whether the low-power device meets the preset restart conditions based on the device type to which the low-power device belongs and the historical timestamp of the most recent remote restart. In response to the low-power device meeting the restart condition, a remote restart command is sent to the low-power device.

[0008] Secondly, embodiments of this application provide a remote wake-up system for low-power devices. The remote wake-up system includes: an Internet of Things (IoT) cloud platform, a low-power device, and a remote client; wherein the low-power device and the remote client are respectively connected to the IoT cloud platform, and the IoT cloud platform includes: a server and a shared cache database; the low-power device is an IoT device that automatically enters a sleep state during non-working periods. The remote client is used to send a remote wake-up request for the low-power device to the server; The server is used for: In response to receiving a remote wake-up request for the low-power device, the low-power device is remotely woken up for the first time by sending a wake-up data packet to the low-power device. In response to the failure of the initial remote wake-up, the communication connection between the server and the low-power device is actively disconnected, triggering the low-power device to re-execute the registration and online operation process; In response to the disconnection of the communication connection, the system periodically monitors whether the low-power device has returned to online status according to a preset time period. If the low-power device fails to return to online status after a preset number of preset time periods, it is determined whether the low-power device meets the preset restart conditions based on the device type to which the low-power device belongs and the historical timestamp of the most recent remote restart. In response to the low-power device meeting the restart condition, a remote restart command is sent to the low-power device.

[0009] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application provides a method and system for remotely waking up low-power devices. After an initial remote wake-up failure, the system can actively disconnect the communication connection and trigger the low-power device to re-execute the registration and online operation process, thereby overcoming the problem that repeated wake-up commands are ineffective when the low-power device is in a false active state. Furthermore, when it is detected that the low-power device has not been restored to an online state, a remote restart command is only sent to low-power devices that meet the restart conditions, thereby achieving progressive recovery for different fault levels. This avoids repeatedly performing restart operations on low-power devices, which would quickly deplete their power, and prevents a surge in load caused by simultaneous restarts in large-scale clusters, effectively improving the success rate of remote wake-up. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This illustration shows a schematic diagram of the structure of a remote wake-up system for a low-power device provided in an embodiment of this application; Figure 2 The illustration shows a flowchart of a remote wake-up method for a low-power device provided in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0014] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0015] A remote wake-up method for a low-power device according to one embodiment of this application can run in a remote wake-up system for low-power devices, as described above. Figure 1 As shown, Figure 1 This illustration shows a schematic diagram of a remote wake-up system for a low-power device provided in an embodiment of this application. The remote wake-up system includes: an Internet of Things (IoT) cloud platform, a low-power device, and a remote client; the low-power device and the remote client are respectively connected to the IoT cloud platform, which includes: a server and a shared cache database; wherein, the remote wake-up method can be specifically applied to the server within the aforementioned IoT cloud platform.

[0016] Specifically, the remote client can be an application installed on a mobile terminal, or a web console or command-line management tool running on a computer. Users can use the remote client to initiate a remote wake-up request for low-power devices to the server of the IoT cloud platform.

[0017] Specifically, a low-power device is a low-power IoT device that the user expects to wake up remotely. This low-power device is an IoT device that automatically enters a sleep state during non-working hours (equivalent to the low-power device automatically entering a sleep state to reduce power consumption during non-working hours). Furthermore, the low-power device has the ability to re-execute the registration and online process after receiving a wake-up data packet or detecting a communication connection loss. Based on this, the specific device types of low-power devices may include, but are not limited to, battery-powered wireless security cameras, smart door locks, smoke detectors, etc. This application does not limit the specific device type of low-power devices in any way.

[0018] Specifically, the IoT cloud platform acts as an intermediary layer connecting remote clients and low-power devices, and is responsible for device access management, connection maintenance, and wake-up process control. The server inside the IoT cloud platform is used to execute the remote wake-up method provided in this application embodiment, while the shared cache database inside the IoT cloud platform (e.g., a Redis database) is used to store the online identifier of the low-power device, so that the server can query the online status of the low-power device when needed.

[0019] It should be noted that, based on the above Figure 1 The specific system structure of the remote wake-up system shown in this application embodiment enables the unified implementation of remote wake-up and abnormal recovery of low-power devices on the server side.

[0020] To facilitate understanding of the embodiments of this application, a remote wake-up method and system for a low-power device provided in the embodiments of this application will be described in detail below.

[0021] Reference Figure 2 As shown, Figure 2 This illustration shows a flowchart of a remote wake-up method for a low-power device according to an embodiment of this application. The remote wake-up method is applied to the server side of an IoT cloud platform and includes steps S201-S205. Specifically: S201, in response to receiving a remote wake-up request for the low-power device, the low-power device is remotely woken up for the first time by sending a wake-up data packet to the low-power device.

[0022] Here, after the remote client detects the user's wake-up operation on a low-power device, it can generate a corresponding remote wake-up request and send the remote wake-up request to the server of the IoT cloud platform. After receiving the remote wake-up request, the server can look up the device record of the low-power device in the locally maintained device table according to the low-power device targeted by the remote wake-up request, and then determine the current operating status of the low-power device based on the found device record.

[0023] It should be noted that, in the embodiments of this application, the operating state of the low-power device may include at least: deep sleep state, hibernation state, and normal operation state; wherein, deep sleep state refers to the state in which the low-power device has completely disconnected the communication connection with the server and cannot directly receive wake-up data packets through the communication connection; hibernation state refers to the state in which the communication connection between the low-power device and the server is still maintained, but the processor of the low-power device has entered the low-power operation mode; and normal operation state refers to the state in which the low-power device is in full-function operation during the working period.

[0024] Specifically, if the server determines that the low-power device is currently in a deep sleep state, it can directly return a "device in deep sleep" response message to the remote client to indicate that the low-power device cannot be directly woken up at this time; if the server determines that the low-power device is currently in a hibernation state, it can construct a wake-up data packet in the corresponding format according to the communication protocol version supported by the low-power device, and send the wake-up data packet to the low-power device through the established communication connection to perform the initial remote wake-up.

[0025] In this embodiment of the application, as an optional implementation, when constructing the wake-up data packet, the server can first detect whether the low-power device is a 4G device; wherein, the server can detect whether the device information of the low-power device contains an ICCID (Integrated Circuit Card Identity); if the ICCID of the low-power device is detected to be non-empty, the server determines that the low-power device is a 4G device, and at this time the server can construct a wake-up data packet in the form of a string.

[0026] For example, the server can construct a wake-up data packet in the form of a string as follows: the server encodes the wake-up check word using Base64 and then concatenates it into a wake-up data packet according to a preset format (e.g., concatenating it into the string "M2WQ"+Base64(check Word)+"XXEE").

[0027] Specifically, if the server detects that the low-power device does not have an ICCID or the ICCID is empty, it determines that the low-power device is a non-4G device. At this time, the server can construct a binary format Dev Wake Msg (device wake-up message) structure as the wake-up data packet for the low-power device.

[0028] Specifically, as an optional embodiment, after sending the aforementioned wake-up data packet to the low-power device, the server can perform the initial remote wake-up of the low-power device according to the following steps a1-a2: Step a1: In response to the sending of the wake-up data packet, start the delay timer.

[0029] In this embodiment of the application, after the server sends a wake-up data packet to the low-power device, it does not immediately determine whether the low-power device has been successfully woken up. Instead, it starts a delay timer and waits for a preset delay time before detecting the wake-up status (equivalent to delaying the verification of whether the low-power device has successfully received the wake-up data packet).

[0030] Specifically, the reason why this application adopts the above-mentioned delayed verification method is that: it usually takes a certain amount of time for a low-power device to recover from the sleep state to the full-function operating state (i.e., the aforementioned normal operating state). If the wake-up status of the low-power device is detected immediately after sending the wake-up data packet, an incorrect failure conclusion may be drawn because the low-power device has not yet completed the wake-up process.

[0031] It should be noted that the specific value of the preset delay time can be configured according to the actual wake-up time of the low-power device, and this application embodiment does not impose a specific limitation on it.

[0032] Step a2: In response to the timing of the delayed timer reaching the preset delay time, detect the wake-up status of the low-power device, and determine the result of the initial remote wake-up based on the wake-up status.

[0033] In this embodiment of the application, after the delay time reaches the preset delay time, the server detects the wake-up status of the low-power device to determine whether the initial remote wake-up was successful.

[0034] Specifically, the server can detect whether the connection instance of the low-power device currently being maintained is the same instance as the connection instance when the wake-up data packet was sent. If they are the same instance, the server can further check whether the wake-up status flag list (last Send Wake Time List) corresponding to the low-power device is empty. If it is empty, it means that the server has received the running status (RPS status) information actively reported by the low-power device, and it can be determined that the low-power device has been successfully woken up.

[0035] Specifically, if the server detects that the connection instance of the currently maintained low-power device has been changed (i.e., the low-power device has re-established a connection), it can further check whether the current connection status parameters of the low-power device meet the preset wake-up success conditions. For example, it can check whether the RPS connection status (rps Connected) of the low-power device is 1, or check whether the running status (status) of the low-power device is in the wake-up state (WAKEDUP). If either of the above conditions is met, it can be determined that the low-power device has been successfully woken up.

[0036] Specifically, if the server determines that the low-power device has been successfully woken up according to the above detection method, it can clear the recovery flag corresponding to the low-power device and exit the current remote wake-up process; if the server determines that the low-power device has not been successfully woken up according to the above detection method, that is, the initial remote wake-up failed, it can continue to execute the recovery operation in the subsequent step S202.

[0037] Specifically, as another optional embodiment, after sending the aforementioned wake-up data packet to the low-power device, the server can also perform an initial remote wake-up of the low-power device according to the following steps b1-b3: Step b1: In response to the sending of the wake-up data packet, detect whether the response result of the low-power device to the wake-up data packet is received within a preset waiting time.

[0038] In this embodiment of the application, after the server sends a wake-up data packet to the low-power device, it can start a timer for a preset waiting time and detect whether it receives a response result from the low-power device in response to the wake-up data packet within the preset waiting time. The response result can be an acknowledgment message returned by the low-power device after successfully receiving the wake-up data packet, or it can be status information actively reported by the low-power device after completing the wake-up. This embodiment of the application does not specifically limit this.

[0039] Step b2: If no response result is received within the preset waiting time, the wake-up data packet is repeatedly sent to the low-power device a preset number of times.

[0040] In this embodiment of the application, if the server does not receive a response from the low-power device for the wake-up data packet within a preset waiting time, it can repeatedly send the wake-up data packet to the low-power device a preset number of times to eliminate the possibility of losing a single wake-up data packet due to instantaneous attenuation of the wireless signal or mild network congestion.

[0041] Step b3: If no response is received after repeatedly sending the wake-up data packet to the low-power device, the initial remote wake-up is determined to have failed.

[0042] In this embodiment of the application, if the server does not receive a response from the low-power device for the wake-up data packet after repeatedly sending the wake-up data packet a preset number of times, it can be determined that the initial remote wake-up has failed, and the recovery operation in the subsequent step S202 can be continued.

[0043] S202, in response to the failure of the initial remote wake-up, actively disconnect the communication connection between the server and the low-power device, and trigger the low-power device to re-execute the registration and online operation process.

[0044] In this embodiment of the application, when the server determines that the initial remote wake-up has failed through the delayed verification method (steps a1-a2) or the fixed number of retries method (steps b1-b3) in step S201, it will no longer continue to repeatedly send wake-up data packets to the low-power device as in the prior art, but will take a more proactive recovery measure (i.e., the server actively disconnects the communication connection with the low-power device).

[0045] It's important to note that in scenarios where a low-power device is in a "falsely active" state, the communication connection between the low-power device and the server remains maintained at the transport layer. That is, the server still sees the connection as active, but the low-power device is actually unable to process any data due to firmware errors, MCU (Microcontroller Unit) crashes, or other reasons. In this situation, if the server continues to send wake-up packets through this failed communication connection, although the wake-up packets may be successfully written to the connection buffer, no substantial response will be received from the low-power device, making it an invalid operation.

[0046] Based on this, the core idea of ​​step S202 is to break the deadlock of "the connection seems normal but communication is actually impossible" when the low-power device is in a false active state by actively disconnecting the communication connection, and force the low-power device to trigger the recovery process on its own from the connection abnormality.

[0047] Specifically, as an optional embodiment, after determining that the initial remote wake-up has failed, the server can execute step S202 in the manner shown in step b1 below: Step b1: Actively close the TCP (Transmission Control Protocol) connection between the server and the low-power device, so that the TCP stack of the low-power device can automatically trigger the registration and online operation process after detecting that the TCP connection is broken.

[0048] In this embodiment of the application, the communication connection between the server and the low-power device can be established based on the TCP protocol (that is, the above communication connection can be a TCP connection); wherein, the TCP protocol is a connection-oriented, reliable transport layer communication protocol, and the two communicating parties maintain their respective TCP stack states when establishing a connection, which is used to manage the connection establishment, data transmission and disconnection processes.

[0049] Specifically, when the server actively closes the TCP connection with the low-power device, the TCP stack on the server side will send a connection disconnection indication (such as a FIN or RST message) to the low-power device side; upon receiving the connection disconnection indication, the TCP stack on the low-power device side can immediately detect that the current TCP connection is no longer available.

[0050] Based on this, the firmware of low-power devices can be pre-configured with connection exception handling logic: when the TCP stack on the low-power device side detects that the TCP connection with the server is broken, the connection exception handling logic will automatically trigger the low-power device to re-execute the registration and online operation process, that is, the low-power device actively initiates a new connection establishment request and registration process to the server, so that it has the opportunity to restore normal operation during the re-registration process.

[0051] Specifically, as an optional implementation, while actively closing the TCP connection, the server can also update the forced disconnection counter (disconnect Cnt) corresponding to the low-power device in an atomic increment manner to record the cumulative number of times the low-power device has been forcibly disconnected by the server, which is convenient for subsequent fault analysis and maintenance statistics.

[0052] It should be noted that by actively disconnecting the communication connection in step S202 above, this embodiment of the application can effectively deal with the fault scenario where the low-power device is in a false active state and cannot be restored by repeatedly sending wake-up data packets: even if the low-power device is unable to process wake-up data packets normally due to firmware abnormalities or other reasons, as long as its TCP stack still has basic protocol processing capabilities, it can trigger the re-registration process after detecting the connection disconnection, thereby creating conditions for the server to monitor whether the low-power device has come back online in the subsequent step S203.

[0053] S203, in response to the disconnection of the communication connection, periodically monitor whether the low-power device has returned to online status according to a preset time period.

[0054] After the server actively disconnects the communication connection with the low-power device in step S202, if the low-power device can recover from the false live state, its internal connection exception handling logic will trigger the low-power device to re-initiate the registration and online process with the server. At this time, the server can determine whether the low-power device has restored normal communication capability through re-registration by monitoring whether the low-power device has returned to the online state.

[0055] Specifically, if the low-power device reconnects within the preset monitoring period (i.e., the preset number of preset time periods), it indicates that the forced disconnection operation in step S202 has successfully broken the deadlock of false liveness, the low-power device has returned to normal, and the remote wake-up recovery process can be completed. If the low-power device still does not reconnect after the preset monitoring period, it indicates that the low-power device may have a deeper fault (such as firmware crash, microcontroller unit completely unresponsive, etc.), and further judgment and processing are required in the subsequent step S204.

[0056] Here, the specific implementation of step S203 is not unique. As an optional embodiment, the server can periodically monitor whether the low-power device has returned to online status, as shown in steps c1-c2 below. Specifically: Step c1: According to the preset time period, poll the shared cache database to detect whether there is an online identifier for the low-power device.

[0057] The shared cache database is a cache database deployed within the IoT cloud platform (e.g., it could be a Redis database).

[0058] In this embodiment, a shared cache database is deployed within the IoT cloud platform, visible to all server nodes. When a low-power device re-registers and comes online, the server handling the registration request writes the low-power device's online identifier into the shared cache database; for example, using the low-power device's UUID (Universally Unique Identifier) ​​as the key and the online flag as the value. Thus, regardless of whether the low-power device re-registers on the original server node or on another server node within the IoT cloud platform, its online status is synchronously recorded in the shared cache database.

[0059] Based on the above mechanism, when the server executes step S203, it can poll the shared cache database at preset time intervals to check whether the online identifier of the low-power device exists.

[0060] Specifically, each time the server polls, it sends an existence query command to the shared cache database (for example, when the shared cache database is a Redis database, the EXISTS command can be used). If the returned result indicates that the online identifier exists, it means that the low-power device has been re-registered and is online; if the returned result indicates that the online identifier does not exist, it means that the low-power device has not yet been re-online, and the server waits for a preset time period before polling again.

[0061] It should be noted that when the preset monitoring period is a preset number of preset time periods, the maximum number of polling detections is the preset number.

[0062] Here, as an optional implementation, the preset time period can be set to 3 seconds, and the preset number (i.e., the maximum number of polls) can be set to 5 times, that is, the server performs a maximum of 5 polling checks, and the total monitoring time is about 15 seconds; the preset time period and preset number can also be configured according to the actual application scenario, and this application embodiment does not specifically limit them.

[0063] Step c2: If the polling detection result indicates that the online identifier exists in the shared cache database, then it is determined that the low-power device has resumed the online state.

[0064] In this embodiment, if the server determines in any polling detection that the online identifier of the low-power device exists in the shared cache database, it can be determined that the low-power device has regained its online status, that is, the low-power device has restored its normal communication capability through re-registration. At this time, the server can clear the monitoring flag corresponding to the low-power device and end the current remote wake-up recovery process, without needing to continue executing the judgment and restart operations in subsequent steps S204 and S205.

[0065] Specifically, if the server does not find the online identifier of the low-power device in the shared cache database during the preset number of polling checks, it can be determined that the low-power device has not been restored to the online state within the preset number of preset time periods. At this time, the server can continue to execute the subsequent step S204.

[0066] Here, as another optional embodiment, the server can also periodically monitor whether the low-power device has returned to online status, as shown in steps d1-d2 below. Specifically: Step d1: Receive the heartbeat signal periodically reported by the low-power device; wherein the low-power device reports the heartbeat signal to the server according to the preset time period.

[0067] In this embodiment, when the low-power device is in a normal online state, it will periodically report a heartbeat signal to the server according to a preset time period to indicate that it is still online. The server can determine whether the low-power device has returned to the online state by whether it receives the heartbeat signal on time.

[0068] Specifically, after the server disconnects the communication connection and triggers the low-power device to re-register, it can start listening to the heartbeat signal reported by the low-power device; if the low-power device successfully re-registers and returns to online, it will resume reporting the heartbeat signal.

[0069] Step d2: In response to the time interval between the current moment and the last historical moment when the heartbeat signal was received being greater than or equal to a preset time interval, it is determined that the low-power device has not resumed the online state.

[0070] In this embodiment of the application, the server can record the historical moment when the heartbeat signal of the low-power device was last received; wherein, during the monitoring process, the server periodically compares the time interval between the current moment and the historical moment.

[0071] Specifically, if the time interval is greater than or equal to the preset time interval, it indicates that the low-power device has not reported a heartbeat signal within the preset time interval, and it can be determined that the low-power device has not yet returned to the online state; conversely, if the server receives the heartbeat signal reported by the low-power device again within the preset time interval, it can be determined that the low-power device has returned to the online state.

[0072] Here, as another optional embodiment, the server can also periodically monitor whether the low-power device has returned to online status, as shown in step e1 below. Specifically: Step e1: Periodically acquire the real-time device status of the low-power device according to the preset time period; wherein the device status is online or offline.

[0073] In this embodiment of the application, the server can also monitor the online status of low-power devices by periodically and proactively querying them.

[0074] Specifically, the server can periodically query the device management module or device status table for the real-time device status of the low-power device according to a preset time period (the device status is used to characterize the online or offline status of the low-power device at the communication connection layer), which is information of a different dimension from the aforementioned working mode of the low-power device (such as deep sleep mode, hibernation mode).

[0075] Specifically, if the query result indicates that the low-power device is online, it is determined that the low-power device has been restored to online status; if the query result indicates that the low-power device is offline, it is determined that the low-power device has not yet been restored to online status, and the system will continue to wait for the next preset time period to query again.

[0076] It should be noted that, through any of the periodic monitoring methods mentioned above in step S203, the server can promptly ascertain whether the low-power device has come back online after the communication connection is disconnected, providing a basis for determining whether a remote restart needs to be performed in step S204.

[0077] S204, in response to the low-power device failing to return to online status after a preset number of preset time periods, it is determined whether the low-power device meets the preset restart conditions based on the device type to which the low-power device belongs and the historical timestamp of the most recent remote restart.

[0078] Here, in step S203, the server has periodically monitored whether the low-power device has returned to online status according to a preset time period; if the low-power device still has not returned to online status after a preset number of preset time periods, it indicates that although the forced disconnection operation in step S202 has been executed, the low-power device has failed to restore normal communication capability by re-registering and going online.

[0079] At this point, the low-power device may face deeper-level faults, such as firmware crashes, complete unresponsiveness of the microcontroller unit, or abnormal internal device status. Simply disconnecting the communication connection and waiting for the device to automatically reconnect is no longer sufficient to resolve the issue. Therefore, the server needs to determine whether the low-power device meets the preset restart conditions before performing a remote restart operation to avoid performing invalid or even harmful restart operations on unsuitable devices.

[0080] Specifically, as an optional embodiment, the server can determine whether the low-power device meets the preset restart conditions according to the following steps f1-f3: Step f1: Determine whether the low-power device is a token device verified through the token center service, based on the device type to which the low-power device belongs.

[0081] In this embodiment of the application, the IoT cloud platform can be connected to TCS (Token Center Service) for remote management capability verification of low-power devices.

[0082] Specifically, the token center service maintains a list of verified token devices, which records the device token and device identifier corresponding to each token device. Token devices usually have relatively complete remote management capabilities and can respond to remote restart commands issued by the server through the device management interface. Non-token devices do not have this capability, and even if the server sends a remote restart command to a non-token device, the command cannot be effectively executed.

[0083] Here, when the server determines whether a low-power device meets the preset restart conditions, it can first determine whether the low-power device belongs to the token device based on the device type to which it belongs.

[0084] Specifically, the server can query the device attribute information of the low-power device, such as whether the device type tag (IsToken Device) is true; or, the server can also send a verification request to the token center service to confirm whether the low-power device is in the token device list.

[0085] Specifically, if the low-power device is a token device, the cooling window determination in subsequent step f2 will continue; if the low-power device is not a token device, it indicates that the low-power device does not have remote restart capability, and the server should not send a remote restart command to it.

[0086] Step f2: If it is determined that the low-power device belongs to the token device, then obtain the historical timestamp of the low-power device at the most recent remote restart, and determine whether the time difference between the current time and the historical timestamp is greater than or equal to the preset cooling threshold.

[0087] In this embodiment of the application, in order to prevent low-power devices from being frequently restarted remotely due to faults, which would cause the device power to be quickly depleted or the device lifespan to be shortened, the server needs to set up a cooling window protection mechanism.

[0088] Specifically, after each successful remote restart, the server records the historical timestamp of the most recent remote restart of the low-power device; this historical timestamp can be stored in the server's local memory for subsequent cooling window determination.

[0089] Here, once the server determines that the low-power device belongs to the token device, it obtains the historical timestamp of the low-power device's most recent remote restart and calculates the time difference between the current moment and the historical timestamp.

[0090] Specifically, if the time difference is greater than or equal to the preset cooling threshold, it indicates that a sufficiently long time has passed since the last remote restart of the low-power device, and performing a remote restart again will not cause the device to restart frequently due to the short time interval; if the time difference is less than the preset cooling threshold, it indicates that the low-power device is within the cooling window protection period and it is not advisable to perform a remote restart operation again.

[0091] Here, as an optional implementation, the preset cooling threshold can be set to 2 hours, meaning that the time interval between two remote restarts of the low-power device must not be less than 2 hours. The preset cooling threshold can also be configured based on factors such as the battery capacity, power consumption level, and importance of the low-power device; this embodiment does not impose specific limitations on this.

[0092] In this embodiment, the determination of the cooling window is based on the historical timestamp stored in the local memory of the server. Its scope is the local memory of a single server and is not shared across servers. That is, in an IoT cloud platform cluster containing multiple server nodes, the same low-power device may maintain its own most recent remote restart historical timestamp on different server nodes.

[0093] It should be noted that although the above design means that the same low-power device may be restarted once by different server nodes in the cluster at most within the cooling window, it is sufficient to prevent the "restart avalanche" problem caused by a large number of low-power devices being restarted at the same time in practical applications. At the same time, it also avoids the additional overhead caused by the need for real-time synchronization of cooling window status between servers.

[0094] Step f3: If it is determined that the time difference is greater than or equal to the preset cooling threshold, then it is determined that the low-power device meets the preset restart condition.

[0095] In this embodiment, when the server determines that the low-power device is a token device, and the time difference between the current moment and the historical timestamp of the low-power device's most recent remote restart is greater than or equal to a preset cooling threshold, it can be determined that the low-power device simultaneously meets the device type condition and the cooling window condition (i.e., meets the preset restart condition). At this time, the server can continue to execute the subsequent step S205 to send a remote restart command to the low-power device.

[0096] Specifically, if the server determines that a low-power device is not a token device, or if it is a token device but the time difference between the current time and the historical timestamp is less than the preset cooling threshold, then the server determines that the low-power device does not meet the preset restart conditions. For low-power devices that do not meet the preset restart conditions, the server will not send a remote restart command to them to avoid invalid operations or unnecessary damage to the device.

[0097] S205, in response to the low-power device meeting the restart condition, a remote restart command is sent to the low-power device.

[0098] Specifically, once the server determines in step S204 that the low-power device meets the preset restart conditions, it can perform a remote restart operation on the low-power device. The purpose of the remote restart operation is to send a restart command to the low-power device through the server, causing the low-power device to perform a complete restart process at the firmware level or microcontroller level, thereby restoring the normal operating state of the low-power device. Since the remote restart command needs to be sent through an interface with device management capabilities, step S205 is only performed on token devices, which is consistent with the token device filtering mechanism in step S204.

[0099] Here, as an optional embodiment, after determining that the low-power device meets the above restart conditions, the server can send a remote restart command to the low-power device according to the method shown in steps g1-g3 below, specifically: Step g1: Obtain the device token of the low-power device and log in to the device management interface using the device token.

[0100] In this embodiment of the application, the device token is the credential information assigned to the low-power device when it registers in the token center service, which is used to prove that the server has the authority to remotely manage the low-power device; wherein, when the server needs to send a remote restart command to the low-power device, it can first obtain the device token of the low-power device from the local device information table or the token center service.

[0101] Specifically, after obtaining the device token, the server uses it as authentication credentials to initiate a login or authentication request to the device management interface. The device management interface is provided by the IoT cloud platform for remote management operations on low-power devices, such as restarting, updating configurations, and querying status. Upon receiving the server's authentication request, the device management interface verifies the validity of the device token; if verification is successful, the server gains permission to perform remote management operations on the low-power device through the device management interface.

[0102] Step g2: In response to successful login to the device management interface, send a remote restart command to the low-power device through the device management interface.

[0103] In this embodiment of the application, after the server successfully logs into the device management interface through the device token, it can send a remote restart command to the low-power device through the device management interface.

[0104] Specifically, the server can call the remote restart function provided by the device management interface, and pass in the device identifier of the low-power device and the remote restart command. After receiving the remote restart command, the device management interface will send the remote restart command to the low-power device through the communication link between the IoT cloud platform and the low-power device.

[0105] Specifically, after receiving a remote restart command, the low-power device will execute a restart operation according to a preset restart procedure. For example, the low-power device can first save its current operating state, then trigger a microcontroller reset or system restart, and finally re-initiate the registration and online process with the IoT cloud platform after the restart is completed.

[0106] Step g3: In response to receiving the restart success indication information from the low-power device, update the historical timestamp of the low-power device at the most recent remote restart according to the current time.

[0107] In this embodiment, after successfully executing a remote restart command, the low-power device can send a restart success indication message to the server. Upon receiving this message, the server confirms that the remote restart operation has been completed and updates the historical timestamp of the low-power device's most recent remote restart based on the current time. The updated timestamp will serve as the basis for subsequent cooling window determination, preventing the low-power device from undergoing another remote restart operation within a preset cooling threshold.

[0108] Furthermore, for low-power devices that are not token devices (i.e., low-power devices do not meet the above restart conditions), the server will not control the low-power devices to restart indiscriminately as in existing technologies. Instead, when it is determined that the low-power device is not a token device (i.e., if it is determined that the low-power device is not a token device), the server will repeatedly send the wake-up data packet to the low-power device a preset number of times.

[0109] In this embodiment, when the server determines in step S204 that the low-power device is not a tokenized device, it indicates that the low-power device does not have the ability to receive remote restart commands through the device management interface. At this time, if the server still sends a remote restart command to the low-power device, the command will not be recognized and executed by the device, constituting an invalid operation. Therefore, the server will not perform a remote restart operation on the non-tokenized device, but will instead revert to a more basic wake-up retry strategy, that is, repeatedly sending wake-up data packets to the low-power device a preset number of times to attempt to restore the device through a conventional wake-up method. This approach avoids performing invalid remote restart operations on non-tokenized devices while retaining the possibility of attempting to restore the device through repeated wake-ups.

[0110] It should be noted that for non-token devices, if the low-power device still does not respond after the server repeatedly sends wake-up packets, the remote wake-up recovery process ends. Since non-token devices lack remote restart capabilities, the server cannot perform further, more complex recovery operations and can only wait for the low-power device to recover through its own mechanisms or require manual intervention. This design reflects a differentiated management strategy for different device types: a complete remote restart recovery pipeline is enabled for token devices, while only regular wake-up retries are performed for non-token devices, thus ensuring recovery effectiveness while avoiding unnecessary system overhead.

[0111] Based on the remote wake-up method for low-power devices provided in the embodiments of this application, after the initial remote wake-up fails, the communication connection can be actively disconnected to trigger the low-power device to re-execute the registration and online operation process, thereby overcoming the problem that repeated wake-up commands are ineffective when the low-power device is in a false active state; and when it is detected that the low-power device has not been restored to the online state, a remote restart command is only sent to the low-power device that meets the restart conditions, thereby realizing progressive recovery for different fault levels, avoiding repeated restart operations on the low-power device and quickly exhausting the power, preventing a surge in load in a large-scale cluster due to simultaneous restarts, and effectively improving the success rate of remote wake-up.

[0112] Based on the same inventive concept, this application also provides a remote wake-up system for a low-power device corresponding to the remote wake-up method for the low-power device described above. Since the principle of solving the problem in the remote wake-up system for the low-power device in this application is similar to that in the remote wake-up method for the low-power device described above, the implementation of the remote wake-up system for the low-power device can refer to the implementation of the remote wake-up method for the low-power device described above, and the repeated parts will not be described again.

[0113] Reference Figure 1 As shown, Figure 1 This illustration shows a schematic diagram of a remote wake-up system for a low-power IoT device according to an embodiment of this application. The remote wake-up system includes: an IoT cloud platform, a low-power device, and a remote client; wherein, the low-power device and the remote client are respectively connected to the IoT cloud platform, and the IoT cloud platform includes: a server and a shared cache database; the low-power device is an IoT device that automatically enters a sleep state during non-working periods. The remote client is used to send a remote wake-up request for the low-power device to the server; The server is used for: In response to receiving a remote wake-up request for the low-power device, the low-power device is remotely woken up for the first time by sending a wake-up data packet to the low-power device. In response to the failure of the initial remote wake-up, the communication connection between the server and the low-power device is actively disconnected, triggering the low-power device to re-execute the registration and online operation process; In response to the disconnection of the communication connection, the system periodically monitors whether the low-power device has returned to online status according to a preset time period. If the low-power device fails to return to online status after a preset number of preset time periods, it is determined whether the low-power device meets the preset restart conditions based on the device type to which the low-power device belongs and the historical timestamp of the most recent remote restart. In response to the low-power device meeting the restart condition, a remote restart command is sent to the low-power device: In one optional implementation, when the low-power device is initially remotely woken up by sending a wake-up data packet to the low-power device, the server is configured to: In response to the sending of the wake-up data packet, a delay timer is started; In response to the delay time reaching a preset delay time, the wake-up state of the low-power device is detected, and the result of the initial remote wake-up is determined based on the wake-up state.

[0114] In one optional implementation, when the low-power device is initially remotely woken up by sending a wake-up data packet to the low-power device, the server is configured to: In response to the transmission of the wake-up data packet, it is detected whether a response result from the low-power device to the wake-up data packet is received within a preset waiting time; If no response is received within the preset waiting time, the wake-up data packet is repeatedly sent to the low-power device a preset number of times. If no response is received after repeatedly sending the wake-up data packet to the low-power device, the initial remote wake-up is determined to have failed.

[0115] In one optional implementation, when the communication connection between the server and the low-power device is actively disconnected, triggering the low-power device to re-execute the registration and online operation process, the server is configured to: Actively close the TCP connection between the server and the low-power device to control the TCP stack of the low-power device to automatically trigger the registration and online operation process after detecting that the TCP connection is broken.

[0116] In one optional implementation, when periodically monitoring whether the low-power device has returned to online status according to a preset time period, the server is used to: The system polls the shared cache database to check for the online identifier of the low-power device according to the preset time period; wherein the shared cache database is a cache database deployed within the IoT cloud platform; and the maximum number of polling checks is the preset number. If the polling detection result indicates that the online identifier exists in the shared cache database, then it is determined that the low-power device has regained its online status.

[0117] In one optional implementation, when periodically monitoring whether the low-power device has returned to online status according to a preset time period, the server is used to: The system receives heartbeat signals periodically reported by the low-power device; wherein the low-power device reports the heartbeat signals to the server according to the preset time period. If the time interval between the current moment and the last historical moment when the heartbeat signal was received is greater than or equal to a preset time interval, it is determined that the low-power device has not resumed the online state. or, According to the preset time period, the real-time device status of the low-power device is periodically acquired; wherein, the device status is either online or offline.

[0118] In one optional implementation, when determining whether the low-power device meets the preset restart conditions based on the device type of the low-power device and the historical timestamp of the most recent remote restart, the server is configured to: Based on the device type to which the low-power device belongs, determine whether the low-power device is a token device verified through the token center service; If it is determined that the low-power device belongs to the token device, then the historical timestamp of the low-power device at the most recent remote restart is obtained, and it is determined whether the time difference between the current time and the historical timestamp is greater than or equal to the preset cooling threshold. If the time difference is determined to be greater than or equal to the preset cooling threshold, then the low-power device is determined to meet the preset restart condition.

[0119] In an optional implementation, after determining whether the low-power device is a token device verified through the token center service, the server is further configured to: If it is determined that the low-power device does not belong to the token device, the wake-up data packet is repeatedly sent to the low-power device a preset number of times.

[0120] In one optional implementation, when sending a remote restart command to the low-power device, the server is configured to: Obtain the device token of the low-power device and log in to the device management interface using the device token; In response to successful login to the device management interface, a remote restart command is sent to the low-power device through the device management interface; In response to receiving a successful restart indication from the low-power device, the historical timestamp of the low-power device at the time of its most recent remote restart is updated according to the current time.

[0121] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0123] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0124] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0126] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for remotely waking up a low-power device, characterized in that, The method for remote wake-up is applied to the server side of an IoT cloud platform, wherein the IoT cloud platform establishes a communication connection with a low-power device, and the low-power device is an IoT device that automatically enters a sleep state during non-working periods. In response to receiving a remote wake-up request for the low-power device, the low-power device is remotely woken up for the first time by sending a wake-up data packet to the low-power device. In response to the failure of the initial remote wake-up, the communication connection between the server and the low-power device is actively disconnected, triggering the low-power device to re-execute the registration and online operation process; In response to the disconnection of the communication connection, the system periodically monitors whether the low-power device has returned to online status according to a preset time period. If the low-power device fails to return to online status after a preset number of preset time periods, it is determined whether the low-power device meets the preset restart conditions based on the device type to which the low-power device belongs and the historical timestamp of the most recent remote restart. In response to the low-power device meeting the restart condition, a remote restart command is sent to the low-power device.

2. The remote wake-up method according to claim 1, characterized in that, The method of performing initial remote wake-up of the low-power device by sending a wake-up data packet to the low-power device includes: In response to the sending of the wake-up data packet, a delay timer is started; In response to the delay time reaching a preset delay time, the wake-up state of the low-power device is detected, and the result of the initial remote wake-up is determined based on the wake-up state.

3. The remote wake-up method according to claim 1, characterized in that, The method of performing initial remote wake-up of the low-power device by sending a wake-up data packet to the low-power device includes: In response to the transmission of the wake-up data packet, it is detected whether a response result from the low-power device to the wake-up data packet is received within a preset waiting time; If no response is received within the preset waiting time, the wake-up data packet is repeatedly sent to the low-power device a preset number of times. If no response is received after repeatedly sending the wake-up data packet to the low-power device, the initial remote wake-up is determined to have failed.

4. The remote wake-up method according to claim 1, characterized in that, The step of actively disconnecting the communication connection between the server and the low-power device, triggering the low-power device to re-execute the registration and online operation process, includes: Actively close the TCP connection between the server and the low-power device to control the TCP stack of the low-power device to automatically trigger the registration and online operation process after detecting that the TCP connection is broken.

5. The remote wake-up method according to claim 1, characterized in that, The step of periodically monitoring whether the low-power device has returned to online status according to a preset time period includes: The system polls the shared cache database to check for the online identifier of the low-power device according to the preset time period; wherein the shared cache database is a cache database deployed within the IoT cloud platform; the maximum number of polling checks is the preset number. If the polling detection result indicates that the online identifier exists in the shared cache database, then it is determined that the low-power device has regained its online status.

6. The remote wake-up method according to claim 1, characterized in that, The step of periodically monitoring whether the low-power device has returned to online status according to a preset time period includes: The system receives heartbeat signals periodically reported by the low-power device; wherein the low-power device reports the heartbeat signals to the server according to the preset time period. If the time interval between the current moment and the last historical moment when the heartbeat signal was received is greater than or equal to a preset time interval, it is determined that the low-power device has not resumed the online state. or, According to the preset time period, the real-time device status of the low-power device is periodically acquired; wherein, the device status is either online or offline.

7. The remote wake-up method according to claim 1, characterized in that, The step of determining whether the low-power device meets the preset restart conditions based on the device type of the low-power device and the historical timestamp of the most recent remote restart includes: Based on the device type to which the low-power device belongs, determine whether the low-power device is a token device verified through the token center service; If it is determined that the low-power device belongs to the token device, then the historical timestamp of the low-power device at the most recent remote restart is obtained, and it is determined whether the time difference between the current time and the historical timestamp is greater than or equal to the preset cooling threshold. If the time difference is determined to be greater than or equal to the preset cooling threshold, then the low-power device is determined to meet the preset restart condition.

8. The remote wake-up method according to claim 7, characterized in that, After determining whether the low-power device is a token device verified through the token center service, the remote wake-up method further includes: If it is determined that the low-power device does not belong to the token device, the wake-up data packet is repeatedly sent to the low-power device a preset number of times.

9. The remote wake-up method according to claim 1, characterized in that, Sending a remote restart command to the low-power device includes: Obtain the device token of the low-power device and log in to the device management interface using the device token; In response to successful login to the device management interface, a remote restart command is sent to the low-power device through the device management interface; In response to receiving a successful restart indication from the low-power device, the historical timestamp of the low-power device at the time of its most recent remote restart is updated according to the current time.

10. A remote wake-up system for a low-power device, characterized in that, The remote wake-up system includes: an IoT cloud platform, low-power devices, and a remote client; wherein, the low-power devices and the remote client are respectively connected to the IoT cloud platform, and the IoT cloud platform includes: a server and a shared cache database; the low-power devices are IoT devices that automatically enter a sleep state during non-working periods. The remote client is used to send a remote wake-up request for the low-power device to the server; The server is used for: In response to receiving a remote wake-up request for the low-power device, the low-power device is remotely woken up for the first time by sending a wake-up data packet to the low-power device. In response to the failure of the initial remote wake-up, the communication connection between the server and the low-power device is actively disconnected, triggering the low-power device to re-execute the registration and online operation process; In response to the disconnection of the communication connection, the system periodically monitors whether the low-power device has returned to online status according to a preset time period. If the low-power device fails to return to online status after a preset number of preset time periods, it is determined whether the low-power device meets the preset restart conditions based on the device type to which the low-power device belongs and the historical timestamp of the most recent remote restart. In response to the low-power device meeting the restart condition, a remote restart command is sent to the low-power device.

Images