Equipment state updating method and device, cloud server, system and storage medium

By adding timestamps to the status packets of multiple online systems and comparing timestamps in cloud servers to update the status of sub-devices, the problem of status packet coverage when sub-devices is frequently offline is solved, and more accurate status information acquisition and better user experience is achieved.

CN119766811AActive Publication Date: 2025-04-04GREE ELECTRIC APPLIANCE INC OF ZHUHAI +1
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202411917212.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-24
Publication Date
2025-04-04
Estimated Expiration
2044-12-24

AI Technical Summary

Technical Problem

In multi-online systems, when sub-device are frequently offline, the network environment affects the status data packets, resulting in the inability to accurately obtain the status information of sub-device and affect the user experience.

Method used

Add a time stamp when obtaining the status in the status packet. When the cloud server receives the status packet sent by the main device, it compares the timestamp with the timestamp of the current status, and updates the current status and status timestamp of the sub-device based on the comparison results.

Benefits of technology

Through the time stamp comparison and update mechanism, the status packet overwrite is avoided, and the status information of the sub-device is obtained more accurately, and the user experience is improved.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119766811A_ABST
    Figure CN119766811A_ABST
Patent Text Reader

Abstract

The invention relates to a device state updating method and device, a cloud server, a system and a storage medium, applied to the cloud server, the cloud server is in communication connection with a main device in a multi-split system, and the multi-split system comprises the main device and at least one sub device. The method comprises the following steps: acquiring a currently recorded current state corresponding to sub-equipment under the condition that a state data packet for the sub-equipment sent by main equipment is received; under the condition that the state represented by the state data packet is inconsistent with the current state, obtaining a timestamp contained in the state data packet, and obtaining a state timestamp corresponding to the current state recorded at present; and comparing the timestamp with the state timestamp, and updating the currently recorded current state of the sub-device and the state timestamp according to a comparison result. Therefore, the state information of the sub-equipment can be obtained more accurately, and the user experience is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of smart home technology, and in particular to a method, device, cloud server, system and storage medium for updating device status. Background Art

[0002] With the rapid development of the Internet of Things (IoT), multi-connection systems have been widely used in smart homes, air conditioning control and other fields. Among them, multi-connection systems usually consist of a main device and multiple sub-devices. The main device can communicate with the cloud service through the MQTT (Message Queuing Telemetry Transport) protocol, while the sub-devices are not directly connected to the MQTT service. Therefore, the application (APP) cannot obtain the online and offline status of the sub-devices in real time through the cloud server.

[0003] In this regard, the main device generally obtains the operating status of the sub-devices and sends the operating status of each sub-device to the cloud server. However, in actual applications, when the sub-devices in the multi-connected system are frequently offline, the network environment may affect the frequently sent status data packets, causing them to be overwritten. For example, the offline status packet overwrites the online status packet, causing the APP to incorrectly display that all the multi-connected sub-devices are offline when receiving the device status information, which in turn makes it impossible to accurately obtain the sub-device status information, affecting the user experience. Summary of the invention

[0004] The present application provides a device status updating method, apparatus, cloud server, system and storage medium to solve the technical problem in the prior art that when sub-devices in a multi-connected system are frequently offline, the network environment may affect the frequently sent status data packets and cause them to be overwritten, resulting in the inability to accurately obtain the status information of the sub-devices, thereby affecting the user experience.

[0005] In a first aspect, the present application provides a method for updating a device status, which is applied to a cloud server, wherein the cloud server is communicatively connected to a master device in a multi-connection system, wherein the multi-connection system includes a master device and at least one sub-device, and the method includes:

[0006] Upon receiving a status data packet for the sub-device sent by the master device, obtaining a current status of the sub-device corresponding to the current record;

[0007] When the state represented by the state data packet is inconsistent with the current state, obtaining the timestamp contained in the state data packet, and obtaining the state timestamp corresponding to the current state currently recorded; wherein, after detecting the state of the sub-device, the master device generates a state data packet containing a timestamp, and sends the state data packet to the cloud server;

[0008] The timestamp is compared with the status timestamp, and the current status and the status timestamp of the sub-device currently recorded are updated according to the comparison result.

[0009] As an optional implementation manner, obtaining the current state of the sub-device corresponding to the current record includes:

[0010] Determine a sub-device identification of the sub-device;

[0011] A preset database is searched according to the sub-device identification to obtain the current state corresponding to the sub-device identification.

[0012] As an optional implementation manner, updating the current state and the state timestamp of the sub-device currently recorded according to the comparison result includes:

[0013] updating the current state and the state timestamp of the sub-device currently recorded in the database according to the comparison result;

[0014] The method further comprises:

[0015] The status data packet is stored in the database.

[0016] As an optional implementation manner, updating the current state and the state timestamp of the sub-device currently recorded according to the comparison result includes:

[0017] When the comparison result indicates that the timestamp is later than the status timestamp, updating the current status and the status timestamp of the sub-device currently recorded according to the status data packet;

[0018] The method further comprises:

[0019] When the comparison result indicates that the timestamp is earlier than the status timestamp, the current status and the status timestamp of the sub-device are not updated.

[0020] As an optional implementation, the status data packet includes an offline status packet and an online status packet, the offline status packet indicates that the status of the corresponding sub-device is an offline status, and the online status packet indicates that the status of the corresponding sub-device is an online status;

[0021] Determine that the state represented by the state data packet is inconsistent with the current state by:

[0022] When it is determined that the status data packet is an offline status packet and the current status is an online status, determining that the status represented by the status data packet is inconsistent with the current status;

[0023] or,

[0024] When it is determined that the status data packet is an online status packet and the current status is an offline status, it is determined that the status represented by the status data packet is inconsistent with the current status.

[0025] As an optional implementation, before obtaining the state timestamp corresponding to the current state of the current record, the method further includes:

[0026] Get the current timestamp corresponding to the current time point;

[0027] determining a timestamp difference between the current timestamp and the timestamp;

[0028] When the timestamp difference is less than a preset difference threshold, the step of obtaining the state timestamp corresponding to the current state of the current record is performed.

[0029] As an optional implementation, the status data packet further includes a server identifier of a server corresponding to the master device;

[0030] The updating of the current state and the state timestamp of the sub-device currently recorded according to the state data packet comprises:

[0031] Obtaining the server identifier in the status data packet and the target server identifier recorded in the cloud server;

[0032] When it is determined that the server identifier is consistent with the target server identifier, the current state and the state timestamp of the sub-device currently recorded are updated according to the state data packet.

[0033] As an optional implementation manner, after obtaining the current state of the sub-device corresponding to the current record, the method further includes:

[0034] When it is determined that the state represented by the state data packet is consistent with the current state, obtaining a timestamp contained in the state data packet, and obtaining a state timestamp corresponding to the current state of the current record;

[0035] determining whether the timestamp is later than the state timestamp;

[0036] In the case where it is determined that the timestamp is later than the status timestamp, the timestamp corresponding to the current status of the sub-device currently recorded is updated from the status timestamp to the timestamp.

[0037] As an optional implementation, the master device detects the status of the slave device in the following manner:

[0038] Determine whether a heartbeat packet sent by the sub-device is received within a preset time period;

[0039] In the case of receiving a heartbeat packet sent by the sub-device within a preset time period, determining that the state of the sub-device is an online state;

[0040] When it is determined that no heartbeat packet sent by the sub-device is received within a preset time period, sending a query request to the sub-device;

[0041] When no response information of the sub-device to the query request is received within the preset query time, it is determined that the state of the sub-device is an offline state.

[0042] As an optional implementation, the master device detects the status of the slave device in the following manner:

[0043] Sending a query request to the sub-device regularly at a preset time interval;

[0044] When receiving a response message from the sub-device to the query request within a preset query time, determining that the state of the sub-device is an online state;

[0045] When no response information of the sub-device to the query request is received within the preset query time, it is determined that the state of the sub-device is an offline state.

[0046] As an optional implementation, the master device sends the status data packet in the following manner:

[0047] Sending the status data packet at a preset time interval;

[0048] or,

[0049] When it is determined that the state represented by the generated state data packet is inconsistent with the state represented by the last sent state data packet, sending the currently generated state data packet to the cloud server;

[0050] or,

[0051] Acquire the current network status and load information; determine the sending frequency of the status data packet according to the network status and the load information; and send the status data packet according to the sending frequency.

[0052] In a second aspect, the present application provides a device status update device, which is applied to a cloud server, wherein the cloud server is communicatively connected to a master device in a multi-connection system, wherein the multi-connection system includes a master device and at least one sub-device, and the device includes:

[0053] A first acquisition module, configured to acquire a current state of the sub-device corresponding to the current record when receiving a state data packet for the sub-device sent by the master device;

[0054] A second acquisition module is used to obtain the timestamp contained in the status data packet and the status timestamp corresponding to the current state of the current record when the state represented by the status data packet is inconsistent with the current state; wherein, after detecting the state of the sub-device, the master device generates a status data packet containing a timestamp and sends the status data packet to the cloud server;

[0055] An updating module is used to compare the timestamp with the status timestamp, and update the current status and the status timestamp of the sub-device currently recorded according to the comparison result.

[0056] In a third aspect, the present application provides a cloud server comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; the memory is used to store a computer program; and the processor is used to implement the device status updating method described in any one of the first aspects when executing the computer program.

[0057] In a fourth aspect, the present application provides a device status update system, including: a cloud server and a multi-connection system;

[0058] The multi-connection system includes a main device and at least one sub-device;

[0059] The cloud server is communicatively connected with the main device in the multi-link system;

[0060] The master device is used to obtain the status of at least one of the sub-devices, generate a status data packet containing a timestamp, and send the status data packet to the cloud server;

[0061] The cloud server is used to receive the status data packet sent by the main device and execute any device status updating method described in the first aspect.

[0062] In a fifth aspect, the present application provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for updating the device status described in any one of the first aspects.

[0063] The above-mentioned technical scheme provided by the embodiment of the present application has the following advantages over the prior art: the method provided by the embodiment of the present application, by adding the timestamp when the status is obtained into the status data packet, based on this, when the cloud server receives the status data packet sent by the main device and determines that the status data packet is inconsistent with the recorded current state, it can compare the timestamp of the status data packet with the current timestamp of the current state, and update the current state of the recorded sub-device according to the comparison result. This method can update the current state of the sub-device in the order of the timestamps of the status data packets received, avoiding updating the state of the sub-device according to erroneous state information when the status data packet is overwritten, achieving more accurate acquisition of the state information of the sub-device and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0065] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0066] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0067] Figure 1 A schematic diagram of the structure of a device status update system provided in an embodiment of the present application;

[0068] Figure 2 A flow chart of an embodiment of a method for updating device status provided in an embodiment of the present application;

[0069] Figure 3 A flowchart of another method for updating device status provided in an embodiment of the present application;

[0070] Figure 4 A flowchart of another method for updating device status provided in an embodiment of the present application;

[0071] Figure 5 A flowchart of an embodiment of another method for updating device status provided in an embodiment of the present application;

[0072] Figure 6A flowchart of an embodiment of a method for updating a device status provided in an embodiment of the present application;

[0073] Figure 7 A block diagram of an embodiment of a device status updating apparatus provided in an embodiment of the present application;

[0074] Figure 8 A schematic diagram of the structure of a cloud server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0075] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0076] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0077] In order to solve the technical problem in the prior art that when sub-devices in a multi-connected system are frequently offline, the frequently sent status data packets may be overwritten due to the influence of the network environment, resulting in the inability to accurately obtain the status information of the sub-devices and affecting the user experience, the present application provides a device status update method, device, cloud server, system and storage medium, which can add a timestamp when the status is obtained in the status data packet. Based on this, when the cloud server receives the status data packet sent by the main device and determines that the status data packet is inconsistent with the recorded current status, it can compare the timestamp of the status data packet with the current timestamp of the current status, and update the recorded current status of the sub-device according to the comparison result. The method can update the current status of the sub-device in the order of the timestamps of the status data packets received, avoiding updating the status of the sub-device according to erroneous status information when the status data packet is overwritten, thereby achieving more accurate acquisition of the status information of the sub-device and improving the user experience.

[0078] To facilitate understanding of the device status update method provided by the present application, the device status update system involved in the present application is first illustrated below by way of example.

[0079] See also Figure 1 , is a schematic diagram of the structure of a device status update system provided in an embodiment of the present application. Figure 1 As shown, the device status update system 10 may include a cloud server 11 and a multi-connection system 12. The multi-connection system 12 may include a main device 121 and at least one sub-device. Figure 1 Three sub-devices are shown for illustration: sub-device 122 , sub-device 123 , and sub-device 124 .

[0080] The cloud server 11 may be a single server or a cluster of multiple servers, which is not limited in the embodiment of the present application.

[0081] The multi-split system 12 may be a multi-split system in a smart home, such as a multi-split air conditioning system. The multi-split system 12 may include a main device 121 and at least one sub-device (eg, sub-device 122, sub-device 123, and sub-device 124).

[0082] The main device 121 refers to a device in the multi-connection system 12 that can directly communicate with the cloud server. Figure 1 The multi-split system 12 is taken as an example of a multi-split air-conditioning system, wherein the main device 121 can be a gateway, and the sub-device 122, the sub-device 123, and the sub-device 124 can all be air conditioners.

[0083] In addition, the system may also include an intelligent terminal 13, which can interact with the cloud server to obtain the status of the main device and each sub-device in the multi-connected system 12. The control terminal 13 can be a hardware device or software that supports network connection to provide various network services. When the control terminal 13 is hardware, it can support various electronic devices with display screens, including but not limited to smart phones, tablet computers, laptops, desktop computers, etc. Figure 1 Only a smart phone is used as an example. When the control terminal 13 is software, it can be installed in the electronic devices listed above. In the embodiment of the present invention, the control terminal 13 can establish communication with the cloud server 11 by installing a corresponding application.

[0084] In actual applications, the main device 121 in the multi-connection system 12 can communicate with the cloud server 11, for example, it can communicate with the cloud service through the MQTT (Message Queuing Telemetry Transport) protocol. However, its sub-devices are not directly connected to the MQTT service, which results in the application (APP) connected to the cloud server being unable to obtain the online status and offline information of the sub-devices in real time.

[0085] Therefore, when the cloud server 11 obtains the status information of the sub-device, it is generally determined by sending a status data packet through the main device 121, and the main device 121 can obtain the operating status of the sub-device and generate a corresponding status data packet to send to the cloud server 11.

[0086] However, in the prior art, in the process of obtaining the status information of the above-mentioned sub-devices, when the sub-devices frequently go online and offline, the main device 121 obtains multiple different status information of the sub-devices in a relatively short period of time, for example, the offline status, online status, and offline status are obtained within 1 minute, and corresponding status data packets are generated respectively, and then the status data packets are sent to the cloud server 11.

[0087] Based on this, during the transmission of the above-mentioned status data packets, there may be network delays, network instability, etc., which may cause the status data packets to be overwritten. For example, the offline state of a sub-device overwrites the online state, which results in inaccurate status information of the sub-device.

[0088] In this regard, the present application provides a method for updating the device status, which can update the current status of the sub-device in the order of the timestamps of the received status data packets, thereby avoiding the situation where a status data packet with an earlier timestamp overwrites a status data packet with a later timestamp, and updating the status of the sub-device according to the expired status data packet, thereby achieving more accurate acquisition of the status information of the sub-device and improving the user experience.

[0089] The method can be applied to a server in a device status update system, such as server 11 in device status update system 10, which may include a cloud server and a multi-connection system, the multi-connection system including a main device and at least one sub-device, the cloud server is connected to the main device in the multi-connection system, the main device is used to obtain the status of at least one sub-device, generate a status data packet containing a timestamp, and send the status data packet to the cloud server. Afterwards, the cloud server may execute the device status update method of the present application after receiving the status data packet of the main device.

[0090] The following is a further explanation of the device status updating method provided by the present application with reference to specific embodiments in conjunction with the accompanying drawings. The embodiments do not constitute a limitation on the embodiments of the present application.

[0091] See also Figure 2 , is a flow chart of an embodiment of a method for updating a device status provided in an embodiment of the present application. As an embodiment, Figure 2 The process shown can be applied to a cloud server, which can be communicatively connected to a main device in a multi-connection system. The multi-connection system can include a main device and at least one sub-device, such as Figure 1The cloud server 11 and the multi-connection system 12 are shown. Figure 2 As shown, the process may include the following steps:

[0092] Step 201: upon receiving a status data packet for a sub-device sent by a master device, obtain the current status of the corresponding sub-device currently recorded.

[0093] The above-mentioned main device refers to a device in a multi-split system that can communicate directly with the cloud server, such as an outdoor unit in a multi-split air-conditioning system.

[0094] The above-mentioned sub-devices are devices in the multi-split system that can communicate with the main device but cannot directly communicate with the cloud server, such as the indoor unit in the multi-split air-conditioning system.

[0095] The above-mentioned status data packet refers to a data packet generated by the master device and containing the status information of the slave device.

[0096] The above-mentioned current status refers to the current status of the sub-device recorded by the server, which may be the same as the actual status of the current sub-device, or may be different. The embodiment of the present application does not limit this, and it can be an online state or an offline state.

[0097] The above-mentioned previous status data packet refers to a status data packet received before the currently received status data packet.

[0098] In one embodiment, the execution subject of the embodiment of the present application may be a cloud server connected to a multi-connection system, wherein the multi-connection system may include a main device and at least one sub-device, and the main device may communicate with the cloud server via the MQTT protocol, so the cloud server may obtain the operating status of the main device in real time. However, the sub-device does not communicate directly with the cloud server, so the cloud server cannot obtain the operating status of the sub-device in real time, and it may obtain the operating status of the sub-device through the main device.

[0099] Based on this, the main device can detect the status of at least one sub-device, and after determining the status of the sub-device, generate a corresponding status data packet. Afterwards, the above status data packet can be sent to the cloud server.

[0100] After receiving the above-mentioned status data packet sent by the main device, the cloud server can obtain the current status of the sub-device corresponding to the status data packet currently recorded, so as to check whether the status currently recorded in the cloud server is consistent with the status of the sub-device represented in the status data packet. In order to facilitate the query of the status change of the sub-device, the cloud server can record the latest status of the sub-device corresponding to the status data packet every time it receives a status data packet of a sub-device.

[0101] As an optional implementation method, the cloud server may store the correspondence between the sub-device identification of each sub-device and the current state of the sub-device in a preset database. Based on this, the cloud server may first determine the sub-device identification of the sub-device when obtaining the current state corresponding to the sub-device. Afterwards, the preset database may be searched according to the sub-device identification to obtain the current state corresponding to the sub-device identification. Among them, the above-mentioned database may be a Redis database, or a SQL (Structured Query Language) database, or other databases, and the embodiments of the present application do not limit this.

[0102] Optionally, when it is determined that the state represented by the state data packet is inconsistent with the above current state, it means that the state of the sub-device may be updated at this time, so the current state of the sub-device currently recorded can be updated through the following steps.

[0103] As an exemplary implementation, the above-mentioned status data packet may include an offline status data packet and an online status data packet. As the name implies, the above-mentioned offline status data packet is used to characterize that the status of the corresponding sub-device is an offline state, and the above-mentioned online status data packet is used to characterize that the status of the corresponding sub-device is an online state.

[0104] Based on this, as an implementation mode, when it is determined that the above-mentioned status data packet is an offline status packet and the current state is an online state, it can be determined that the state represented by the status data packet is inconsistent with the current state.

[0105] As another implementation, when it is determined that the state data packet is an online state packet and the current state is an offline state, it may be determined that the state represented by the state data packet is inconsistent with the current state.

[0106] Optionally, when it is determined that the state represented by the state data packet is consistent with the current state, it means that the state of the sub-device has not been updated at this time, so the current state of the currently recorded sub-device may not be updated.

[0107] Step 202: When the state represented by the above-mentioned state data packet is inconsistent with the current state, obtain the timestamp contained in the state data packet, and obtain the state timestamp corresponding to the above-mentioned current state currently recorded; wherein, after detecting the state of the sub-device, the main device generates a state data packet containing a timestamp, and sends the above-mentioned state data packet to the cloud server.

[0108] Step 203: Compare the timestamp and the status timestamp, and update the current status and status timestamp of the currently recorded sub-device according to the comparison result.

[0109] The following is a unified description of step 202 and step 203:

[0110] The above timestamp refers to the timestamp corresponding to the state of the sub-device when the master device detects the state of the sub-device, which can be expressed in a standard time format.

[0111] The above-mentioned status timestamp refers to the currently recorded timestamp corresponding to the above-mentioned current state, which can indicate that under this status timestamp, the state of the sub-device is the above-mentioned current state. The status timestamp can be the timestamp corresponding to the state of the sub-device most recently determined from the current time point before receiving the above-mentioned status data packet.

[0112] In an embodiment of the present application, when the cloud server obtains the current state of the currently recorded sub-device and determines that the state represented by the received state data packet is inconsistent with the current state, it indicates that the state of the sub-device may have changed at this time, and therefore the current state of the currently recorded sub-device may need to be updated.

[0113] On this basis, in order to prevent the received status data packet from being an expired packet, thereby preventing the current status of the currently recorded sub-device from being updated inaccurately based on the expired status data packet, the cloud server can perform a timestamp check on the received status data packet, and modify the current status and timestamp of the currently recorded sub-device after the check passes.

[0114] As an optional implementation, after detecting the status of the sub-device, the main device can obtain the corresponding timestamp and generate a status data packet containing the timestamp. Then, the generated status data packet can be sent to the cloud server.

[0115] Based on this, after receiving the status data packet, the cloud server can obtain the timestamp contained in the status data packet by parsing.

[0116] Afterwards, the state timestamp corresponding to the current state currently recorded may be obtained, so that the timestamp and the state timestamp may be compared, and the current state and the state timestamp of the sub-device currently recorded may be updated according to the comparison result.

[0117] As an optional implementation, the cloud server may store the correspondence between the sub-device identification of each sub-device, the current state of the sub-device, and the state timestamp corresponding to the current state in a preset database. Based on this, the cloud server may first determine the sub-device identification of the sub-device when obtaining the current state corresponding to the sub-device. Afterwards, the preset database may be searched according to the sub-device identification to obtain the current state corresponding to the sub-device identification and the state timestamp corresponding to the current state.

[0118] Based on this, when the cloud server updates the current state and state timestamp of the sub-device currently recorded according to the comparison result, it can update the current state and state timestamp of the sub-device currently recorded in the above database according to the comparison result.

[0119] Afterwards, in order to facilitate viewing of historical status changes of the sub-device, the cloud server may store the received status data packets in the above database.

[0120] As for how to update the current state and state timestamp of the sub-device currently recorded according to the comparison result, it can be explained below and will not be described in detail here.

[0121] In addition, when it is determined that the state represented by the state data packet is consistent with the current state, the timestamp in the state data packet may be obtained first, and the state timestamp corresponding to the current state of the current record may be obtained.

[0122] Afterwards, it can be determined whether the timestamp is later than the state timestamp. Optionally, if it is determined that the timestamp is later than the above state timestamp, it means that the state data packet is the latest state data packet generated by the master device, and because the state represented by the state data packet is consistent with the current state, it is not necessary to update the recorded current state, but in order to synchronize the state timestamp of the current state, the timestamp corresponding to the current state of the sub-device can be updated from the above state timestamp to the timestamp in the state data packet.

[0123] The technical solution provided by the embodiment of the present application is to obtain the current state of the corresponding sub-device currently recorded when receiving a state data packet for the sub-device sent by the main device, obtain the timestamp contained in the state data packet when the state represented by the state data packet is inconsistent with the current state, and obtain the state timestamp corresponding to the current state currently recorded; wherein, after detecting the state of the sub-device, the main device generates a state data packet containing a timestamp, and sends the state data packet to the cloud server, compares the timestamp and the state timestamp, and updates the current state and state timestamp of the sub-device currently recorded according to the comparison result. This technical solution adds the timestamp when the state is obtained to the state data packet. Based on this, when the cloud server receives the state data packet sent by the main device and determines that the state data packet is inconsistent with the recorded current state, it can compare the timestamp of the state data packet with the current timestamp of the current state, and update the current state of the recorded sub-device according to the comparison result. This method can update the current state of the sub-device in the order of the timestamps of the received state data packets, avoiding updating the state of the sub-device according to the wrong state information when the state data packet is overwritten, and realizing more accurate acquisition of the state information of the sub-device, thereby improving the user experience.

[0124] See also Figure 3 , which is a flow chart of an embodiment of another method for updating device status provided in an embodiment of the present application. Figure 3 The process shown in Figure 2 Based on the process shown in FIG. 1 , it describes how to update the current state and state timestamp of the sub-device currently recorded according to the comparison result. Figure 3 As shown, the process may include the following steps:

[0125] Step 301 , compare whether the timestamp is later than the state timestamp corresponding to the recorded current state; if so, execute step 302 ; if not, execute step 303 .

[0126] Step 302: Update the current state and state timestamp of the currently recorded sub-device according to the state data packet.

[0127] Step 303: The current state and state timestamp of the sub-device are not updated.

[0128] The following is a unified description of steps 301 to 303:

[0129] The above-mentioned timestamp refers to the timestamp contained in the status data packet received by the cloud server. When the main device in the multi-connected system obtains the status of the sub-device, it can generate a status data packet containing the status and the timestamp corresponding to the status, and send the status data packet to the cloud server.

[0130] The above-mentioned status timestamp refers to the timestamp corresponding to the current status of the sub-device recorded by the cloud server, that is, the status corresponding to the sub-device at the status timestamp is the recorded current status, and the status timestamp is determined by the status data packet received in the historical time period.

[0131] In an embodiment of the present application, after receiving a status data packet sent by the main device, the cloud server may compare the timestamp in the status data packet with the status timestamp corresponding to the current state in order to verify whether the status data packet is expired to determine whether the timestamp is later than the above status timestamp.

[0132] Optionally, when it is determined that the timestamp is later than the above-mentioned status timestamp, it means that the currently received status data packet is the latest status data packet generated by the main device, rather than the previously generated and expired status data packet. Therefore, the current status and status timestamp of the currently recorded sub-device can be updated according to the status data packet.

[0133] As an optional implementation method, in a distributed system, a master device may correspond to multiple servers. If multiple servers generate status data packets at the same time, data consistency may not be achieved and the data may be easily tampered with. Therefore, in order to ensure the security and consistency of the status data packet, the master device can obtain the server identifier of the current corresponding server when generating the status data packet, and generate a status data packet based on the server identifier.

[0134] Based on this, when the cloud server updates the recorded current state and state timestamp according to the state data packet, it can first obtain the server identifier in the state data packet and the target server identifier pre-recorded in the cloud server. The above-mentioned target server identifier is the server identifier pre-recorded in the cloud server, and the target server identifier represents the received state data packet of the corresponding server.

[0135] Afterwards, it can be determined whether the server identifier and the target server identifier are consistent. Optionally, if they are consistent, the current state and state timestamp of the currently recorded sub-device can be updated according to the state data packet.

[0136] As an exemplary implementation, the recorded current state may be updated to the state recorded in the state data packet, and the state timestamp corresponding to the current state may be updated to the timestamp in the state data packet.

[0137] Optionally, when it is determined that the timestamp is earlier than the above-mentioned status timestamp, it means that the currently received status data packet is a status data packet previously generated by the main device, which may be delayed in being sent to the cloud server due to network delays, network congestion, etc. Therefore, it is an expired status data packet. At this time, the current status and status timestamp of the sub-device may not be updated.

[0138] In addition, in order to record the historical status of the sub-device, the status data packet can be saved in a preset database.

[0139] The technical solution provided by the embodiment of the present application compares whether the timestamp is later than the status timestamp corresponding to the recorded current state; if so, the current state and status timestamp of the sub-device currently recorded are updated according to the status data packet; if not, the current state and status timestamp of the sub-device are not updated. This technical solution compares the timestamp with the current recorded status timestamp, so that the recorded current state can be updated in the order of the timestamps, thereby avoiding the inaccurate status information of the sub-device caused by the status data packet with an earlier timestamp overwriting the status data packet with a later timestamp due to network delays and other conditions, thereby more accurately determining the current state of the sub-device.

[0140] See also Figure 4, which is a flow chart of an embodiment of another method for updating device status provided in an embodiment of the present application. Figure 4 The process shown in Figure 2 Based on the process shown in FIG. 1 , the following describes how to further verify the timestamp in the status data packet. Figure 4 As shown, the process may include the following steps:

[0141] Step 401: upon receiving a status data packet for a sub-device sent by a master device, obtain the current status of the corresponding sub-device currently recorded.

[0142] Step 402: When the state represented by the state data packet is inconsistent with the current state, obtain the timestamp contained in the state data packet.

[0143] For a detailed description of step 401 and step 402 , please refer to the description of step 201 and step 202 , which will not be repeated here.

[0144] Step 403: Get the current timestamp corresponding to the current time point.

[0145] Step 404: Determine the timestamp difference between the current timestamp and the above timestamp.

[0146] Step 405: When the timestamp difference is less than a preset difference threshold, obtain a state timestamp corresponding to the current state of the current record.

[0147] The following is a unified description of steps 403 to 405:

[0148] The above current time point refers to the time point when the cloud server receives the above status data packet.

[0149] The above difference threshold is a preset threshold, which can be used to indicate that the status data packet is sent within a preset time range, such as 1 minute, 50 seconds, etc.

[0150] In an embodiment of the present application, before obtaining a status timestamp corresponding to a current status, the cloud server may first verify whether the status data packet is sent within a preset time range.

[0151] As an optional implementation, a current timestamp corresponding to the current time point may be obtained, and a timestamp difference between the current timestamp and the timestamp in the status data packet may be determined.

[0152] Thereafter, it may be determined whether the timestamp difference is less than a preset difference threshold.

[0153] Optionally, if the timestamp difference is smaller than the above-mentioned difference threshold, it may indicate that the status data packet is sent within a normal preset time range, and therefore the status timestamp corresponding to the current status of the current record may continue to be obtained.

[0154] Optionally, if the timestamp difference is greater than or equal to the difference threshold, it means that the status data packet is not sent within the normal preset time range, and it may be an expired status data packet. Therefore, it can be determined that the status data packet is expired, and the status timestamp corresponding to the current state of the current record will no longer be obtained.

[0155] Step 406: Compare the timestamp with the status timestamp, and update the current status and status timestamp of the currently recorded sub-device according to the comparison result.

[0156] For a detailed description of step 406, please refer to the description of step 203, which will not be repeated here.

[0157] The technical solution provided by the embodiment of the present application is to obtain the current state of the corresponding sub-device currently recorded when receiving the status data packet for the sub-device sent by the main device, and obtain the timestamp contained in the status data packet when the state represented by the above status data packet is inconsistent with the current state, obtain the current timestamp corresponding to the current time point, determine the timestamp difference between the current timestamp and the above timestamp, and obtain the state timestamp corresponding to the current state of the current record when the above timestamp difference is less than a preset difference threshold, compare the timestamp with the state timestamp, and update the current state and state timestamp of the sub-device currently recorded according to the comparison result. This technical solution further accurately determines the state of the sub-device by further obtaining the current timestamp corresponding to the current time point, and comparing the timestamp difference between the current timestamp and the timestamp in the status data packet with the preset difference threshold, so as to preliminarily determine whether the status data packet is an expired data packet according to the current time point.

[0158] In order to further understand the device status update method provided in the present application, the following describes from the perspective of the main device how the main device specifically obtains the status of the sub-device and sends a status data packet.

[0159] See also Figure 5 , is a flow chart of another embodiment of a method for updating a device status provided in an embodiment of the present application. As an embodiment, Figure 5 The process shown can be applied to the master device in a multi-connection system, such as Figure 1 The main device 121 shown. Figure 5 As shown, the process may include the following steps:

[0160] Step 501, determine whether the status of at least one sub-device is online; if so, execute step 502; if not, execute step 503.

[0161] Step 502: Generate an online status data packet.

[0162] Step 503: Generate an offline status data packet.

[0163] The following is a unified description of steps 501 to 503:

[0164] In the embodiment of the present application, the main device can determine whether the state of at least one sub-device is online at a scheduled time or in real time. Optionally, when the state of the sub-device is determined to be online, an online state data packet can be generated; conversely, when the state of the sub-device is determined to be offline, an offline state data packet can be generated.

[0165] Among them, the status data packet may include the following fields: Device identification: a string used to uniquely identify a sub-device, used to distinguish different sub-devices, such as a device ID, which can be in the form of "device_001". Status information: identifies the offline or online status of the device, usually a Boolean value (true / false) or a status code (such as 0 for offline and 1 for online). Timestamp: records the specific time when the sub-device goes offline, using a standard time format to ensure the accuracy and comparability of the time information. Server information: records the server identifier that sent the offline package for subsequent verification and tracing.

[0166] In one embodiment, the master device may obtain the status of the slave device by sending a heartbeat packet.

[0167] As an optional implementation, it can be determined whether a heartbeat packet sent by a sub-device is received within a preset time period. The sub-device can send a heartbeat packet to the main device once every preset time period, thereby notifying the main device that the current state is online.

[0168] Optionally, if it is determined that a heartbeat packet sent by the sub-device is received within a preset time period, it can be determined that the status of the sub-device is an online status.

[0169] On the contrary, if it is determined that the heartbeat packet sent by the sub-device is not received within the preset time, in order to further determine whether the sub-device is online, the main device can send a query request to the sub-device. The query request is used to request the sub-device to send current status information.

[0170] Optionally, if no response information of the sub-device to the query request is received within a preset query time, it can be determined that the status of the sub-device is offline.

[0171] In another embodiment, the master device may determine the status of the slave device by periodically querying.

[0172] As an optional implementation, the master device may send a query request to the slave device at a preset time interval, wherein the query request is used to request status information of the slave device.

[0173] If the sub-device is in an online state, it may send a response message to the main device after receiving the query request.

[0174] Based on this, if the master device receives a response message from the slave device to the query request within the preset query time, it can determine that the state of the slave device is online. The above query time is the maximum time for the slave device to feedback the response message, such as 1 minute or 2 minutes.

[0175] Optionally, if the main device does not receive response information sent by the sub-device in response to the query request within a preset query time, it can be determined that the status of the sub-device is offline.

[0176] Step 504: Send the generated status data packet to the cloud server.

[0177] In the embodiment of the present application, after generating the status data packet, the master device may send the generated status data packet to the cloud server. The status data packet may be an online status data packet or an offline status data packet, which is not limited in the embodiment of the present application.

[0178] As an optional implementation manner, the master device may send the generated status data packet at a preset time interval.

[0179] As another optional implementation, the master device can send the currently generated status data packet to the cloud server when it determines that the status represented by the currently generated status data packet is inconsistent with the status represented by the last sent status data packet. This method can ensure that the status of the sub-device in the cloud server is updated in a timely manner and reduce the amount of data transmission.

[0180] As another optional implementation, the master device may obtain the current network status and load information, and determine the sending frequency of the status data packet according to the network status and load information, and then send the status data packet according to the sending frequency.

[0181] As another optional implementation, the master device may send a status data packet at a preset time interval, and before sending it again, determine whether the status represented by the status data packet is different from the status represented by the last sent status data packet. Optionally, if they are different, the status data packet is sent; if they are the same, the status data packet is not sent.

[0182] The technical solution provided by the embodiment of the present application determines whether the status of at least one sub-device is online through the main device; if so, an online status data packet is generated; if not, an offline status data packet is generated and the generated status data packet is sent to the cloud server. This technical solution obtains the status of the sub-device through the main device and generates a corresponding status data packet. The main device can determine the status of the sub-device through different detection methods and send the status data packet at different sending frequencies, thereby improving the accuracy and timeliness of the sub-device status detection.

[0183] See also Figure 6 , is a flow chart of another embodiment of a method for updating device status provided in an embodiment of the present application. Figure 6 As shown, the process may include the following:

[0184] (1) The offline status package is a formatted information package sent by the multi-connection system to the cloud service after detecting that the sub-device is offline. Its structure should include the following fields: Device ID: A string that uniquely identifies the sub-device, used to distinguish different sub-devices. For example, the device ID can be in the form of "device_001". Offline information: Identifies the offline status of the device, usually a Boolean value (true / false) or a status code (such as 0 for offline and 1 for online). Timestamp: Records the specific time when the sub-device goes offline, using a standard time format to ensure the accuracy and comparability of the time information. Server information: Records the server identifier that sends the offline package for subsequent verification and tracing. Generation of offline package. When the multi-connection system detects that the sub-device is offline, it generates an offline package containing the following information: sub-device ID, offline status identifier, timestamp, and server information.

[0185] (2) When the master device in the multi-connection system detects that a sub-device is offline, the system will automatically trigger the generation and sending of offline packages. The specific process is as follows: Detect offline status: Regularly check the online status of the sub-device through the heartbeat mechanism or timed query. Generate offline package: If the sub-device is detected to be offline, generate an offline package containing the above fields. Send offline package: Send the offline package to the cloud service through the MQTT protocol. After the server receives the offline package, it stores it in the Redis database. The master device can dynamically adjust the sending frequency of the offline package according to the network status and device load to ensure unnecessary network traffic.

[0186] (3) In order to ensure that the APP corresponding to the cloud server can accurately display the status of the sub-device, an online status verification mechanism is essential. The goal of this mechanism is to confirm the true online status of the device through effective verification means and avoid the situation where offline information covers online information. Online status query process When the cloud service receives the online status data packet of the main device, it will perform the following steps: Query online status: query the current status recorded by the current sub-device in the cloud service through the device ID to determine whether it is online. Timestamp verification: If the sub-device is determined to be online, further check the timestamp in the received offline status package to ensure that it is within a reasonable time range, for example, the timestamp is later than the status timestamp corresponding to the online status currently recorded by the cloud server, and the timestamp difference between the timestamp and the current timestamp is less than the preset difference threshold (for example, 1 minute). Server information verification: verify the server information recorded in the offline package and compare it with the server information currently processing the request to ensure data consistency.

[0187] (4) The cloud server stores the following information in Redis: Sub-device ID: as the key in Redis. Status information: stores the online or offline status of the device. Timestamp: records the last update time of the status information. Server information: identifies the server that processes the request to ensure the accuracy of the source of the information. Through Redis's efficient read and write capabilities, the system can quickly respond to APP status query requests.

[0188] (5) Data storage and update: Use Redis as the storage medium for status information to ensure efficient read and write performance. Regularly clean up expired status information to maintain the real-time and accuracy of data.

[0189] The technical solution provided by the embodiment of the present application ensures the validity of offline status information by retaining offline messages, timestamps and server information when the main device sends offline packets. Based on this, an online status verification mechanism is added. When processing the device status, it can first determine whether the device is truly online. If it is online, it obtains the sub-device information from Redis and verifies the time and server information. This technical solution can effectively solve the problem of inaccurate online status of multi-connected sub-devices and improve user experience and device management efficiency.

[0190] See also Figure 7 , is a block diagram of an embodiment of a device status update device provided in an embodiment of the present application. As an embodiment, the device can be applied to a cloud server, and the cloud server is communicatively connected to a master device in a multi-connection system, and the multi-connection system may include a master device and at least one sub-device. Figure 7 As shown, the device may include:

[0191] A first acquisition module 71 is configured to acquire the current state of the sub-device currently recorded when receiving a state data packet for the sub-device sent by the master device;

[0192] The second acquisition module 72 is used to obtain the timestamp contained in the status data packet and the status timestamp corresponding to the current state of the current record when the state represented by the status data packet is inconsistent with the current state; wherein, after detecting the state of the sub-device, the master device generates a status data packet containing a timestamp and sends the status data packet to the cloud server;

[0193] The updating module 73 is used to compare the timestamp with the status timestamp, and update the current status and the status timestamp of the sub-device currently recorded according to the comparison result.

[0194] like Figure 8 As shown, it is a schematic diagram of the structure of a cloud server provided in an embodiment of the present application. The cloud server may include a processor 81, a communication interface 82, a memory 83 and a communication bus 84, wherein the processor 81, the communication interface 82, and the memory 83 communicate with each other through the communication bus 84.

[0195] A memory 83, for storing computer programs;

[0196] In one embodiment of the present application, the processor 81 is used to implement the device status update method provided by any of the aforementioned method embodiments when executing the program stored in the memory 83. The method can be applied to a cloud server, wherein the cloud server is communicatively connected to a master device in a multi-connected system, wherein the multi-connected system includes a master device and at least one sub-device. The method includes:

[0197] Upon receiving a status data packet for the sub-device sent by the master device, obtaining a current status of the sub-device corresponding to the current record;

[0198] When the state represented by the state data packet is inconsistent with the current state, obtaining the timestamp contained in the state data packet, and obtaining the state timestamp corresponding to the current state currently recorded; wherein, after detecting the state of the sub-device, the master device generates a state data packet containing a timestamp, and sends the state data packet to the cloud server;

[0199] The timestamp is compared with the status timestamp, and the current status and the status timestamp of the sub-device currently recorded are updated according to the comparison result.

[0200] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the device status updating method provided in any of the aforementioned method embodiments are implemented.

[0201] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0202] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0203] It should be understood that the terms used in the text are only for the purpose of describing specific example embodiments, and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used in the text may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0204] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for updating device status, characterized in that: Applied to a cloud server, the cloud server is communicatively connected to a main device in a multi-connection system, the multi-connection system includes a main device and at least one sub-device, the method includes: Upon receiving a status data packet for the sub-device sent by the master device, obtaining a current status of the sub-device corresponding to the current record; When the state represented by the state data packet is inconsistent with the current state, obtaining the timestamp contained in the state data packet, and obtaining the state timestamp corresponding to the current state currently recorded; wherein, after detecting the state of the sub-device, the master device generates a state data packet containing a timestamp, and sends the state data packet to the cloud server; The timestamp is compared with the status timestamp, and the current status and the status timestamp of the sub-device currently recorded are updated according to the comparison result.

2. The method according to claim 1, characterized in that The obtaining of the current state of the sub-device corresponding to the current record includes: Determine a sub-device identification of the sub-device; A preset database is searched according to the sub-device identification to obtain the current state corresponding to the sub-device identification.

3. The method according to claim 2, characterized in that The updating of the current state and the state timestamp of the sub-device currently recorded according to the comparison result includes: updating the current state and the state timestamp of the sub-device currently recorded in the database according to the comparison result; The method further comprises: The status data packet is stored in the database.

4. The method according to claim 1, characterized in that: The updating of the current state and the state timestamp of the sub-device currently recorded according to the comparison result includes: When the comparison result indicates that the timestamp is later than the status timestamp, updating the current status and the status timestamp of the sub-device currently recorded according to the status data packet; The method further comprises: When the comparison result indicates that the timestamp is earlier than the status timestamp, the current status and the status timestamp of the sub-device are not updated.

5. The method according to claim 1, characterized in that The state data packet includes an offline state packet and an online state packet, wherein the offline state packet indicates that the state of the corresponding sub-device is an offline state, and the online state packet indicates that the state of the corresponding sub-device is an online state; Determine that the state represented by the state data packet is inconsistent with the current state by: When it is determined that the status data packet is an offline status packet and the current status is an online status, determining that the status represented by the status data packet is inconsistent with the current status; or, When it is determined that the status data packet is an online status packet and the current state is an offline state, it is determined that the state represented by the status data packet is inconsistent with the current state.

6. The method according to claim 1, characterized in that Before obtaining the state timestamp corresponding to the current state of the current record, the method further includes: Get the current timestamp corresponding to the current time point; determining a timestamp difference between the current timestamp and the timestamp; When the timestamp difference is less than a preset difference threshold, the step of obtaining the state timestamp corresponding to the current state of the current record is performed.

7. The method according to claim 4, characterized in that The status data packet also includes a server identifier of a server corresponding to the master device; The updating of the current state and the state timestamp of the sub-device currently recorded according to the state data packet comprises: Obtaining the server identifier in the status data packet and the target server identifier recorded in the cloud server; When it is determined that the server identifier is consistent with the target server identifier, the current state and the state timestamp of the sub-device currently recorded are updated according to the state data packet.

8. The method according to claim 1, characterized in that After obtaining the current state of the sub-device corresponding to the current record, the method further includes: When it is determined that the state represented by the state data packet is consistent with the current state, obtaining a timestamp contained in the state data packet, and obtaining a state timestamp corresponding to the current state of the current record; determining whether the timestamp is later than the state timestamp; In the case where it is determined that the timestamp is later than the status timestamp, the timestamp corresponding to the current status of the sub-device currently recorded is updated from the status timestamp to the timestamp.

9. The method according to claim 1, characterized in that: The master device detects the status of the slave device in the following manner: Determine whether a heartbeat packet sent by the sub-device is received within a preset time period; In the case of receiving a heartbeat packet sent by the sub-device within a preset time period, determining that the state of the sub-device is an online state; When it is determined that no heartbeat packet sent by the sub-device is received within a preset time period, sending a query request to the sub-device; When no response information of the sub-device to the query request is received within the preset query time, it is determined that the state of the sub-device is an offline state.

10. The method according to claim 1, characterized in that The master device detects the status of the slave device in the following manner: Sending a query request to the sub-device regularly at a preset time interval; When receiving a response message from the sub-device to the query request within a preset query time, determining that the state of the sub-device is an online state; When no response information of the sub-device to the query request is received within the preset query time, it is determined that the state of the sub-device is an offline state.

11. The method according to claim 1, characterized in that: The master device sends the status data packet in the following manner: Sending the status data packet at a preset time interval; or, When it is determined that the state represented by the generated state data packet is inconsistent with the state represented by the last sent state data packet, sending the currently generated state data packet to the cloud server; or, Acquire the current network status and load information; determine the sending frequency of the status data packet according to the network status and the load information; and send the status data packet according to the sending frequency.

12. A device for updating device status, characterized in that: Applied to a cloud server, the cloud server is communicatively connected with a main device in a multi-link system, the multi-link system includes a main device and at least one sub-device, and the device includes: A first acquisition module, configured to acquire a current state of the sub-device corresponding to the current record when receiving a state data packet for the sub-device sent by the master device; A second acquisition module is used to obtain the timestamp contained in the status data packet and the status timestamp corresponding to the current state of the current record when the state represented by the status data packet is inconsistent with the current state; wherein, after detecting the state of the sub-device, the master device generates a status data packet containing a timestamp and sends the status data packet to the cloud server; An updating module is used to compare the timestamp with the status timestamp, and update the current status and the status timestamp of the sub-device currently recorded according to the comparison result.

13. A cloud server, characterized in that: include: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; The memory is used to store a computer program; the processor is used to implement the device status updating method according to any one of claims 1 to 11 when executing the computer program.

14. A device status update system, characterized in that: include: Cloud servers and multi-connection systems; The multi-connection system includes a main device and at least one sub-device; The cloud server is communicatively connected with the main device in the multi-link system; The master device is used to obtain the status of at least one of the sub-devices, generate a status data packet containing a timestamp, and send the status data packet to the cloud server; The cloud server is used to receive the status data packet sent by the main device and execute the device status updating method described in any one of claims 1-11.

15. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for updating the device status described in any one of claims 1 to 11 is implemented.

Citation Information

Patent Citations

  • Method and device for updating state of active Internet of Things equipment in real time

    CN115665186A

  • Information updating method and system

    CN116074760A

  • Updating prompting method and device of ERP system, electronic equipment and storage medium

    CN118642926A

  • Method for Child Wireless Device Activation to Subscriber Account of a Master Wireless Device

    US20170201850A1