Methods, devices, cloud servers, systems, and storage media for updating device status.

Abstract

This application relates to a method, apparatus, cloud server, system, and storage medium for updating device status. It is applied to a cloud server that communicates with a master device in a multi-connector system. The multi-connector system includes a master device and at least one sub-device. The method includes: upon receiving a status data packet for a sub-device sent by the master device, obtaining the current status of the corresponding sub-device currently recorded; if the status represented by the status data packet is inconsistent with the current status, obtaining a timestamp contained in the status data packet and obtaining a status timestamp corresponding to the current status currently recorded; comparing the timestamp and the status timestamp, and updating the current status and status timestamp of the sub-device currently recorded based on the comparison result. This enables more accurate acquisition of sub-device status information, improving user experience.

Description

Technical Field

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

[0002] With the rapid development of the Internet of Things (IoT), multi-split air conditioning systems have been widely used in smart homes, air conditioning control, and other fields. A multi-split system typically consists of a master device and multiple slave devices. The master device communicates with cloud services via the MQTT (Message Queuing Telemetry Transport) protocol, while the slave devices do not directly connect to the MQTT service. Therefore, the application (APP) cannot obtain the online and offline status of the slave devices in real time through the cloud server.

[0003] In this case, the master device typically obtains the operating status of the sub-devices and then sends the operating status of each sub-device to the cloud server. However, in practical applications, when sub-devices in a multi-device system frequently go offline, network conditions may cause the frequently sent status data packets to overlap, for example, offline status packets may overwrite online status packets. This can lead to the app incorrectly displaying all sub-devices as offline when receiving device status information, resulting in inaccurate acquisition of sub-device status information and impacting user experience. Summary of the Invention

[0004] This application provides a method, apparatus, cloud server, system, and storage medium for updating device status, in order to solve the technical problem in the prior art where, when sub-devices in a multi-connected system frequently go offline, the frequently sent status data packets may be overwritten due to network environment influences, resulting in the inability to accurately obtain the status information of the sub-devices and affecting the user experience.

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

[0006] Upon receiving a status data packet for the sub-device sent by the master device, the current status of the corresponding sub-device is obtained from the current record.

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

[0008] Compare the timestamp with the status timestamp, and update the current status and status timestamp of the currently recorded sub-device based on the comparison result.

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

[0010] Determine the sub-device identifier of the sub-device;

[0011] The current state corresponding to the sub-device identifier is obtained by searching a preset database based on the sub-device identifier.

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

[0013] Update the current state and state timestamp of the sub-device currently recorded in the database based on the comparison result;

[0014] The method further includes:

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

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

[0017] If the comparison result indicates that the timestamp is later than the status timestamp, the current status and the status timestamp of the currently recorded sub-device are updated according to the status data packet.

[0018] The method further includes:

[0019] If the comparison result indicates that the timestamp is earlier than the state timestamp, the current state and the state 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, wherein the offline status packet indicates that the corresponding sub-device is in an offline state, and the online status packet indicates that the corresponding sub-device is in an online state;

[0021] The inconsistency between the state represented by the state data packet and the current state is determined by the following method:

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

[0023] or,

[0024] If 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] Determine the timestamp difference between the current timestamp and the previous timestamp;

[0028] If 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 executed.

[0029] As an optional implementation, the status data packet may also include the server identifier of the server corresponding to the master device;

[0030] The step of updating the currently recorded current state and the state timestamp of the sub-device based on the state data packet includes:

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

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

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

[0034] If it is determined that the state represented by the state data packet is consistent with the current state, the timestamp contained in the state data packet is obtained, and the state timestamp corresponding to the current state recorded is obtained.

[0035] Determine whether the timestamp is later than the status timestamp;

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

[0037] As an optional implementation, the master device detects the status of the sub-device in the following way:

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

[0039] If a heartbeat packet is received from the sub-device within a preset time period, the sub-device is determined to be in an online state.

[0040] If no heartbeat packet is received from the sub-device within a preset time period, a query request is sent to the sub-device.

[0041] If no response is received from the sub-device for the query request within the preset query time, the sub-device is determined to be in an offline state.

[0042] As an optional implementation, the master device detects the status of the sub-device in the following way:

[0043] At preset time intervals, query requests are sent to the sub-devices periodically.

[0044] If a response to the query request is received from the sub-device within a preset query duration, the status of the sub-device is determined to be online.

[0045] If no response is received from the sub-device for the query request within the preset query time, the sub-device is determined to be in an offline state.

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

[0047] The status data packets are sent at preset time intervals;

[0048] or,

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

[0050] or,

[0051] Obtain the current network status and load information; determine the transmission frequency of the status data packet based on the network status and load information; and transmit the status data packet according to the transmission frequency.

[0052] Secondly, this application provides a device for updating device status, applied to a cloud server, wherein the cloud server is communicatively connected to a master device in a multi-connector system, the multi-connector system including a master device and at least one sub-device, and the device includes:

[0053] The first acquisition module is used to acquire the current state of the corresponding sub-device that is currently recorded when the master device sends a status data packet for the sub-device.

[0054] The second acquisition module is used to acquire, when the state represented by the state data packet is inconsistent with the current state, the timestamp contained in the state data packet and the state timestamp corresponding to the current state recorded; wherein, after the master device detects the state of the sub-device, it generates a state data packet containing a timestamp and sends the state data packet to the cloud server.

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

[0056] Thirdly, this application provides a cloud server, including: 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 computer programs; and the processor is used to implement the device state update method described in any one of the first aspects when executing the computer program.

[0057] Fourthly, this application provides a device status update system, including: a cloud server and a multi-connector system;

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

[0059] The cloud server is communicatively connected to the master device in the multi-connector 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 master device and execute any of the device status update methods in the first aspect.

[0062] Fifthly, this application provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for updating the device state as described in any of the first aspects.

[0063] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application adds a timestamp of the time of obtaining the status to the status data packet. Based on this, when the cloud server receives the status data packet sent by the master device and determines that the status data packet is inconsistent with the recorded current status, it can update the recorded current status of the sub-device by comparing the timestamp of the status data packet with the current timestamp of the current status and updating the current status of the sub-device according to the comparison result. This method can update the current status of the sub-device according to the order of the timestamps of the received status data packets, avoiding updating the status of the sub-device according to the incorrect status information when the status data packet is overwritten, realizing more accurate acquisition of the status information of the sub-device and improving the user experience. Attached Figure Description

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

[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

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

[0068] Figure 2 A flowchart illustrating an embodiment of a device status update method provided in this application;

[0069] Figure 3 A flowchart illustrating an embodiment of another device status update method provided in this application;

[0070] Figure 4 A flowchart illustrating an embodiment of another device status update method provided in this application;

[0071] Figure 5 A flowchart illustrating an embodiment of another device status update method provided in this application;

[0072] Figure 6A flowchart illustrating an embodiment of a device status update method provided in this application;

[0073] Figure 7 A block diagram illustrating an embodiment of a device status update apparatus provided in this application;

[0074] Figure 8 This is a schematic diagram of the structure of a cloud server provided in an embodiment of this application. Detailed Implementation

[0075] 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. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0076] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0077] To address the technical problem in existing multi-device systems where frequent offline status data packets may be overwritten due to network environment factors, leading to inaccurate status information acquisition and impacting user experience, this application provides a device status update method, apparatus, cloud server, system, and storage medium. By adding a timestamp of the status acquisition time to the status data packet, the cloud server, upon receiving a status data packet from the master device and determining that the status data packet is inconsistent with the recorded current status, can update the recorded current status of the sub-device by comparing the timestamp of the status data packet with the current timestamp of the current status. This method updates the current status of the sub-device according to the order of the received status data packets' timestamps, avoiding the updating of the sub-device's status with incorrect status information when status data packets are overwritten. This achieves more accurate acquisition of sub-device status information and improves user experience.

[0078] To facilitate understanding of the device status update method provided in this application, the device status update system involved in this application will be illustrated with an example below.

[0079] See Figure 1 This is a schematic diagram of the structure of a device status update system provided in an embodiment of this application. Figure 1 As shown, the device status update system 10 may include a cloud server 11 and a multi-connector system 12. The multi-connector system 12 may include a master device 121 and at least one sub-device. Figure 1 The example shown uses three sub-devices: sub-device 122, sub-device 123, and sub-device 124.

[0080] The cloud server 11 mentioned above can be a single server or a cluster of multiple servers, and this application embodiment does not limit this.

[0081] The aforementioned multi-split system 12 can 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 (e.g., sub-device 122, sub-device 123, and sub-device 124).

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

[0083] In addition, the system may also include a smart terminal 13, which can interact with a cloud server to obtain the status of the main device and each sub-device in the multi-connection system 12. The control terminal 13 can be hardware or software that supports network connectivity to provide various network services. When the control terminal 13 is hardware, it can support various electronic devices with displays, including but not limited to smartphones, tablets, laptops, desktop computers, etc. Figure 1 This example uses a smartphone. When the control terminal 13 is software, it can be installed on the electronic devices listed above. In this embodiment of the invention, the control terminal 13 can establish communication with the cloud server 11 by installing a corresponding application.

[0084] In practical applications, the master device 121 in the multi-unit system 12 can communicate with the cloud server 11, for example, it can communicate with cloud services via the MQTT (Message Queuing Telemetry Transport) protocol. However, its sub-devices do not directly connect to the MQTT service, which means that the application (APP) connecting to the cloud server cannot obtain the online and offline information of the sub-devices in real time.

[0085] Therefore, when cloud server 11 obtains the status information of sub-devices, it generally determines this by sending status data packets from master device 121. Master device 121 can then obtain the operating status of sub-devices and generate corresponding status data packets to send to cloud server 11.

[0086] However, in the prior art, during the process of acquiring the status information of the sub-device, when the sub-device frequently goes online and offline, the master device 121 acquires multiple different status information of the sub-device in a short period of time. For example, it acquires the offline status, online status, and offline status within 1 minute, and generates corresponding status data packets for each, and then sends the status data packets to the cloud server 11.

[0087] Therefore, during the transmission of the aforementioned status data packets, network delays, network instability, and other factors may cause the status data packets to be overwritten. For example, the offline status of a sub-device may overwrite its online status, resulting in inaccurate status information of the sub-device.

[0088] In response, this application provides a method for updating the status of a device. This method updates the current status of a sub-device according to the order of the timestamps of the received status data packets. This avoids updating the status of the sub-device according to the expired status data packets when the status data packets with earlier timestamps overwrite the status data packets with later timestamps. This achieves more accurate acquisition of the status information of the sub-device and improves the user experience.

[0089] This method can be applied to a server in a device status update system, such as server 11 in device status update system 10. This system may include a cloud server and a multi-connection system. The multi-connection system includes a master device and at least one sub-device. The cloud server is communicatively connected to the master device in the multi-connection system. The master device acquires the status of at least one sub-device, generates a status data packet containing a timestamp, and sends the status data packet to the cloud server. After receiving the status data packet from the master device, the cloud server can then execute the device status update method of this application.

[0090] The method for updating the device status provided in this application will be further explained below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this application.

[0091] See Figure 2 This is a flowchart illustrating an embodiment of a device status update method provided in this application. As one embodiment, Figure 2 The illustrated process can be applied to a cloud server that can communicate with the master device in a multi-connector system. This multi-connector system may include a master device and at least one sub-device, for example... Figure 1The cloud server 11 and the multi-server 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 the sub-device sent by the master device, obtain the current status of the corresponding sub-device currently recorded.

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

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

[0095] The aforementioned status data packet refers to a data packet generated by the master device that contains status information of the sub-device.

[0096] The aforementioned current state refers to the current state of the sub-device recorded by the server. It may be the same as or different from the actual state of the sub-device. This application embodiment does not limit this. It may be an online state or an offline state.

[0097] The previous state data packet mentioned above refers to the state data packet received before the current state data packet was received.

[0098] In one embodiment, the executing entity of this application embodiment may be a cloud server connected to a multi-connector system. The multi-connector system may include a master device and at least one sub-device. The master device can communicate with the cloud server via the MQTT protocol, thus the cloud server can obtain the operating status of the master device in real time. However, the sub-devices do not communicate directly with the cloud server; therefore, the cloud server cannot obtain the operating status of the sub-devices in real time, but can obtain the operating status of the sub-devices through the master device.

[0099] Based on this, the master 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. This status data packet can then be sent to the cloud server.

[0100] After receiving the aforementioned status data packet from the master device, the cloud server can obtain the current status of the sub-device corresponding to that status data packet, and thus check whether the currently recorded status in the cloud server is consistent with the status of the sub-device represented in the status data packet. Specifically, to facilitate querying sub-device status changes, the cloud server can record the latest status of the sub-device corresponding to each received status data packet.

[0101] As an optional implementation, the cloud server can store the correspondence between the sub-device identifier of each sub-device and the current state of that sub-device in a preset database. Based on this, when obtaining the current state corresponding to a sub-device, the cloud server can first determine the sub-device identifier of that sub-device. Then, it can search the preset database based on the sub-device identifier to obtain the current state corresponding to that sub-device identifier. The aforementioned database can be a Redis database, an SQL (Structured Query Language) database, or other databases; this embodiment does not impose any limitations on this.

[0102] Optionally, if the state represented by the state data packet is inconsistent with the current state mentioned above, it indicates that the state of the sub-device may have been updated. Therefore, the current state of the sub-device recorded can be updated by following the steps below.

[0103] As an exemplary implementation, the aforementioned status data packet may include an offline status data packet and an online status data packet. As the names suggest, the offline status data packet is used to indicate that the status of the corresponding sub-device is offline, and the online status data packet is used to indicate that the status of the corresponding sub-device is online.

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

[0105] As another implementation, if it is determined that the above-mentioned status data packet is an online status packet and the current status is an offline status, it can be determined that the status represented by the status data packet is inconsistent with the current status.

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

[0107] Step 202: If the state represented by the above 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 current state recorded above; wherein, after the master device detects the state of the sub-device, it generates a state data packet containing a timestamp and sends the above 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 based on the comparison result.

[0109] The following provides a unified explanation of steps 202 and 203:

[0110] The timestamp mentioned above refers to the timestamp corresponding to the state of the sub-device when the master device detects the state of the sub-device, and it can be represented using a standard time format.

[0111] The aforementioned status timestamp refers to the timestamp currently recorded corresponding to the aforementioned current status. It can represent that the status of the sub-device under this status timestamp is the aforementioned current status. This status timestamp can be the timestamp corresponding to the most recently determined status of the sub-device before receiving the aforementioned status data packet.

[0112] In this embodiment of the 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, and therefore it may be necessary to update the current state of the currently recorded sub-device.

[0113] Based on this, in order to prevent the received status data packets from being expired, and thus to prevent inaccurate updates to the current status of the currently recorded sub-devices based on expired status data packets, the cloud server can perform timestamp verification on the received status data packets, and modify the current status and timestamp of the currently recorded sub-devices after the verification is successful.

[0114] As an optional implementation, after detecting the status of the sub-device, the master device can obtain the corresponding timestamp and generate a status data packet containing that timestamp. The generated status data packet can then 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 it.

[0116] Then, the state timestamp corresponding to the current state recorded above can be obtained, and the timestamp and state timestamp can be compared. Based on the comparison result, the current state and state timestamp of the current sub-device recorded above can be updated.

[0117] As an optional implementation, the cloud server can store the correspondence between the sub-device identifier, the current state of the sub-device, and the state timestamp corresponding to the current state in a pre-defined database. Based on this, when obtaining the current state of a sub-device, the cloud server can first determine the sub-device identifier. Then, it can search the pre-defined database based on the sub-device identifier to obtain the current state corresponding to the sub-device identifier and the state timestamp corresponding to the current state.

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

[0119] Subsequently, in order to facilitate viewing the historical status changes of the sub-devices, the cloud server can store the received status data packets into the aforementioned database.

[0120] The specific details of how the current state and status timestamp of the sub-device are updated based on the comparison results will be explained below, and will not be detailed 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 can be obtained first, as well as the state timestamp corresponding to the current state of the current record.

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

[0123] The technical solution provided in this application, upon receiving a status data packet for a sub-device sent by a master device, obtains the current state of the corresponding sub-device currently recorded. If the state represented by the status data packet is inconsistent with the current state, the solution obtains the timestamp contained in the status data packet and the status timestamp corresponding to the current state currently recorded. Specifically, after detecting the state of the sub-device, the master device generates a status data packet containing a timestamp and sends it to a cloud server. The timestamp and the status timestamp are compared, and the current state and status timestamp of the currently recorded sub-device are updated based on the comparison result. This technical solution, by adding a timestamp of the time when the state is obtained to the status data packet, allows the cloud server, upon receiving a status data packet from the master device and determining that the status data packet is inconsistent with the recorded current state, to update the current state of the recorded sub-device by comparing the timestamp of the status data packet with the current timestamp of the current state. This method updates the current state of the sub-device according to the order in which the timestamps of the received status data packets are received, avoiding updating the sub-device's state with incorrect state information when status data packets are overwritten. This achieves more accurate acquisition of the sub-device's state information and improves the user experience.

[0124] See Figure 3 This is a flowchart illustrating an embodiment of another device status update method provided in this application. Figure 3 The process shown is in Figure 2 Based on the illustrated process, the specific steps of updating the current state and status timestamp of the currently recorded sub-device according to the comparison results are described. For example... Figure 3 As shown, the process may include the following steps:

[0125] Step 301: Compare whether the timestamp is later than the timestamp of the current state. If yes, proceed to step 302; otherwise, proceed to step 303.

[0126] Step 302: Update the current status and status timestamp of the currently recorded sub-device based on the status data packet.

[0127] Step 303: Do not update the current status and status timestamp of the sub-device.

[0128] The following provides a unified explanation of steps 301 to 303:

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

[0130] The aforementioned status timestamp refers to the timestamp corresponding to the current status of the sub-device recorded by the cloud server. In other words, the status of the sub-device at this status timestamp is the recorded current status, and this status timestamp is determined by the status data packets received during the historical time period.

[0131] In this embodiment of the application, after receiving the status data packet sent by the master device, the cloud server can compare the timestamp in the status data packet with the status timestamp corresponding to the current status to verify whether the status data packet has expired, so as to determine whether the timestamp is later than the aforementioned status timestamp.

[0132] Optionally, if it is determined that the timestamp is later than the aforementioned status timestamp, it indicates that the currently received status data packet is the latest status data packet generated by the master device, rather than a previously generated and expired status data packet. Therefore, the current status and status timestamp of the currently recorded sub-device can be updated based on the status data packet.

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

[0134] Based on this, when updating the recorded current status and status timestamp according to the status data packet, the cloud server can first obtain the server identifier in the status data packet and the target server identifier pre-recorded in the cloud server. The aforementioned target server identifier is a server identifier pre-recorded in the cloud server, and this target server identifier represents the status data packet of the corresponding server received.

[0135] Then, it can be determined whether the aforementioned server identifier and the target server identifier are consistent. Optionally, if they are consistent, the current status and status timestamp of the currently recorded sub-device can be updated based on the status data packet.

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

[0137] Optionally, if it is determined that the timestamp is earlier than the aforementioned status timestamp, it indicates that the currently received status data packet was generated by the master device before, and may have been delayed in being sent to the cloud server due to network latency, network congestion, or other reasons. Therefore, it is an expired status data packet, and in this case, the current status and status timestamp of the sub-device do not need to be updated.

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

[0139] The technical solution provided in this application compares whether the timestamp is later than the timestamp corresponding to the recorded current state. If so, the current state and timestamp of the currently recorded sub-device are updated according to the state data packet; otherwise, the current state and timestamp of the sub-device are not updated. This technical solution, by comparing the timestamp with the currently recorded state timestamp, updates the recorded current state according to the order of the timestamps. This avoids inaccurate sub-device state information caused by earlier timestamp state data packets overwriting later timestamp state data packets due to network latency or other factors, thus achieving a more accurate determination of the current state of the sub-device.

[0140] See Figure 4This is a flowchart illustrating another embodiment of a device status update method provided in this application. Figure 4 The process shown is in Figure 2 Based on the illustrated process, the specific steps for further verification of the timestamps in the status data packets are described. For example... Figure 4 As shown, the process may include the following steps:

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

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

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

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

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

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

[0147] The following provides a unified explanation of steps 403 to 405:

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

[0149] The aforementioned difference threshold is a pre-set threshold that can be used to characterize the transmission of status data packets within a preset time range, such as 1 minute or 50 seconds.

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

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

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

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

[0154] Optionally, if the timestamp difference is greater than or equal to the difference threshold, it indicates that the status data packet was sent outside the preset time range and may be an expired status data packet. Therefore, it can be determined that the status data packet has expired, and the status timestamp corresponding to the current status 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 based on the comparison result.

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

[0157] The technical solution provided in this application, upon receiving a status data packet for a sub-device sent by a master device, obtains the current status of the corresponding sub-device currently recorded. If the status represented by the status data packet is inconsistent with the current status, the timestamp contained in the status data packet is obtained, the current timestamp corresponding to the current time point is obtained, the timestamp difference between the current timestamp and the aforementioned timestamp is determined, and if the timestamp difference is less than a preset difference threshold, the status timestamp corresponding to the current recorded status is obtained, the timestamp and the status timestamp are compared, and the current recorded status and status timestamp of the sub-device are updated according to the comparison result. This technical solution, 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 a preset difference threshold, preliminarily determines whether the status data packet is an expired data packet based on the current time point, thereby achieving a more accurate determination of the sub-device's status.

[0158] To further understand the device status update method provided in this application, the following describes how the master device obtains the status of the sub-device and sends status data packets from the perspective of the master device.

[0159] See Figure 5 This is a flowchart illustrating another embodiment of a device state update method provided in this application. As one embodiment, Figure 5 The process shown can be applied to the main equipment in a multi-unit system, such as... Figure 1 The main device 121 is shown. (As shown) Figure 5 As shown, the process may include the following steps:

[0160] Step 501: Determine whether at least one sub-device is online; if yes, proceed to step 502; if no, proceed to step 503.

[0161] Step 502: Generate online status data packets.

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

[0163] The following provides a unified explanation of steps 501 to 503:

[0164] In this embodiment, the master device can periodically or in real time determine whether at least one sub-device is online. Optionally, if the sub-device is determined to be online, an online status data packet can be generated; conversely, if the sub-device is determined to be offline, an offline status data packet can be generated.

[0165] The status data packet may include the following fields: Device Identifier: A string used to uniquely identify the sub-device, distinguishing different sub-devices, such as a device ID, which can be in the form of "device_001". Status Information: Identifies the device's offline or online status, usually a boolean value (true / false) or a status code (e.g., 0 for offline, 1 for online). Timestamp: Records the specific time the sub-device went 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 packet for subsequent verification and traceability.

[0166] In one embodiment, the master device can obtain the status of the sub-device by sending heartbeat packets.

[0167] As an optional implementation, it can be determined whether a heartbeat packet sent by the sub-device has been received within a preset time period. Specifically, the sub-device can send a heartbeat packet to the master device at preset time intervals to notify the master device that its current status is online.

[0168] Optionally, if a heartbeat packet sent by the sub-device is received within a preset time period, the sub-device can be determined to be in an online state.

[0169] Conversely, if no heartbeat packet is received from the sub-device within a preset time period, the master device can send a query request to the sub-device to further determine whether the sub-device is online. This query request is used to request the sub-device to send its current status information.

[0170] Optionally, if no response is received from the sub-device for the query request within the preset query time, the sub-device can be determined to be in an offline state.

[0171] In another embodiment, the master device can determine the status of the sub-device by periodically querying it.

[0172] As an optional implementation, the master device can periodically send query requests to the sub-device at preset time intervals. These query requests are used to request the status information of the sub-device.

[0173] If the sub-device is online, it can send a response message to the master device after receiving the query request.

[0174] Based on this, if the master device receives a response from the sub-device to the query request within a preset query duration, it can determine that the sub-device is online. The aforementioned query duration is a preset maximum duration for the sub-device to provide a response, such as 1 minute or 2 minutes.

[0175] Optionally, if the master device does not receive a response from the sub-device to the query request within a preset query time, the sub-device may be determined to be in an offline state.

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

[0177] In this embodiment, after generating the status data packet, the master device can send the generated status data packet to the cloud server. This status data packet can be an online status data packet or an offline status data packet; this embodiment does not impose any restrictions on this.

[0178] As an optional implementation, the master device can send the generated status data packets at preset time intervals.

[0179] As an alternative implementation, the master device can send the currently generated status data packet to the cloud server if it determines that the status represented by the currently generated status data packet is inconsistent with that represented by the previously sent status data packet. This method can ensure timely updates of the sub-device's status in the cloud server while reducing data transmission volume.

[0180] As another optional implementation, the master device can obtain the current network status and load information, and determine the transmission frequency of status data packets based on this information. Then, the status data packets can be transmitted according to the specified transmission frequency.

[0181] As another optional implementation, the master device can send status data packets at preset time intervals, and before sending each packet, determine whether the status data packet represents a different status than the previously 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 in this application embodiment determines whether at least one sub-device is online through a master device; if so, an online status data packet is generated; otherwise, an offline status data packet is generated and sent to a cloud server. This technical solution, by having the master device obtain the status of the sub-device and generate corresponding status data packets, and by allowing the master device to determine the status of the sub-device using different detection methods and to send the status data packets at different frequencies, improves the accuracy and timeliness of sub-device status detection.

[0183] See Figure 6 The following is a flowchart illustrating an embodiment of a device status update method provided in this application. Figure 6 As shown, the process may include the following:

[0184] (1) The offline status packet is a formatted information packet sent to the cloud service by the multi-connector after detecting that a sub-device is offline. Its structure should include the following fields: Device ID: A string that uniquely identifies the sub-device and is 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 (e.g., 0 indicates offline, 1 indicates online). Timestamp: Records the specific time when the sub-device went 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 packet for subsequent verification and traceability. Generation of the offline packet. When the multi-connector detects that a sub-device is offline, it generates an offline packet containing the following information: sub-device ID, offline status identifier, timestamp, and server information.

[0185] (2) When the master device in a multi-connector system detects that a sub-device is offline, the system will automatically trigger the generation and transmission of an offline packet. The specific process is as follows: Detect offline status: The online status of the sub-device is checked periodically through a heartbeat mechanism or timed query. Generate offline packet: If the sub-device is detected to be offline, an offline packet containing the above fields is generated. Send offline packet: The offline packet is sent to the cloud service via the MQTT protocol. After receiving the offline packet, the server stores it in the Redis database. The master device can dynamically adjust the sending frequency of the offline packet according to network conditions and device load to avoid unnecessary network traffic.

[0186] (3) 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 methods and avoid offline information overwriting online information. Online Status Query Process When the cloud service receives the online status data packet of the master device, it will perform the following steps: Query online status: Query the current status of the current sub-device recorded in the cloud service by 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 packet to ensure that it is within a reasonable time range. For example, the timestamp is later than the status timestamp corresponding to the current online status recorded by the cloud server, and the difference between the timestamp and the current timestamp is less than a preset difference threshold (e.g., 1 minute). Server information verification: Verify the server information recorded in the offline packet and compare it with the server information of the currently processed request to ensure data consistency.

[0187] (4) The cloud server stores the following information in Redis: Sub-device ID: used 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 processed the request, ensuring the accuracy of the information source. Through Redis's efficient read and write capabilities, the system can quickly respond to the APP's status query requests.

[0188] (5) Data storage and updates: Redis is used as the storage medium for state information to ensure high read and write performance. Expired state information is cleaned up regularly to maintain the real-time nature and accuracy of the data.

[0189] The technical solution provided in this application ensures the validity of offline status information by retaining offline messages, timestamps, and server information when the master device sends offline packets. Based on this, an online status verification mechanism is added. When processing device status, this mechanism first determines whether the device is truly online. If online, it retrieves the sub-device information from Redis and verifies the time and server information. This technical solution effectively solves the problem of inaccurate online status of sub-devices in multi-connector systems, improving user experience and device management efficiency.

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

[0191] The first acquisition module 71 is used to acquire the current state of the corresponding sub-device that is currently recorded when the master device sends a status data packet for the sub-device.

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

[0193] The update module 73 is used to 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.

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

[0195] Memory 83 is used to store computer programs;

[0196] In one embodiment of this application, when the processor 81 executes a program stored in the memory 83, it implements the device state update method provided in any of the foregoing method embodiments. This method can be applied to a cloud server, which is communicatively connected to a master device in a multi-connector system. The multi-connector 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, the current status of the corresponding sub-device is obtained from the current record.

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

[0199] Compare the timestamp with the status timestamp, and update the current status and status timestamp of the currently recorded sub-device based on the comparison result.

[0200] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the device state update method provided in any of the foregoing method embodiments.

[0201] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0202] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0203] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0204] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily 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 invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded 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, wherein the cloud server is communicatively connected to a master device in a multi-connector system, the multi-connector system including a master 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, the current status of the corresponding sub-device is obtained from the current record. If the state represented by the state data packet is inconsistent with the current state, the timestamp contained in the state data packet is obtained, and the state timestamp corresponding to the current state recorded is obtained; wherein, after the master device detects the state of the sub-device, it generates a state data packet containing a timestamp and sends the state data packet to the cloud server; Compare the timestamp with the status timestamp, and update the current status and status timestamp of the currently recorded sub-device based on the comparison result; The step of updating the current state and the state timestamp of the currently recorded sub-device according to the comparison result includes: when the comparison result indicates that the timestamp is later than the state timestamp, updating the current state and the state timestamp of the currently recorded sub-device according to the state data packet; The status data packet also includes the server identifier of the server corresponding to the master device; updating the current status and status timestamp of the currently recorded sub-device according to the status data packet includes: obtaining the server identifier in the status data packet and the target server identifier recorded in the cloud server; if it is determined that the server identifier is consistent with the target server identifier, updating the current status and status timestamp of the currently recorded sub-device according to the status data packet. Before obtaining the state timestamp corresponding to the current state of the current record, the method further includes: obtaining the current timestamp corresponding to the current time point; determining the timestamp difference between the current timestamp and the timestamp; and if the timestamp difference is less than a preset difference threshold, performing the step of obtaining the state timestamp corresponding to the current state of the current record.

2. The method according to claim 1, characterized in that, The step of obtaining the current state of the corresponding sub-device of the current record includes: Determine the sub-device identifier of the sub-device; The current state corresponding to the sub-device identifier is obtained by searching a preset database based on the sub-device identifier.

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

4. The method according to claim 1, characterized in that, The method further includes: If the comparison result indicates that the timestamp is earlier than the state timestamp, the current state and the state timestamp of the sub-device are not updated.

5. The method according to claim 1, characterized in that, The status data packet includes an offline status packet and an online status packet. The offline status packet indicates that the corresponding sub-device is in an offline state, and the online status packet indicates that the corresponding sub-device is in an online state. The inconsistency between the state represented by the state data packet and the current state is determined by the following method: If it is determined that the status data packet is an offline status packet and the current status is an online status, then it is determined that the status represented by the status data packet is inconsistent with the current status. or, If 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.

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

7. The method according to claim 1, characterized in that, The master device detects the status of the sub-device in the following ways: Determine whether a heartbeat packet sent by the sub-device is received within a preset time period; If a heartbeat packet is received from the sub-device within a preset time period, the sub-device is determined to be in an online state. If no heartbeat packet is received from the sub-device within a preset time period, a query request is sent to the sub-device. If no response is received from the sub-device for the query request within the preset query time, the sub-device is determined to be in an offline state.

8. The method according to claim 1, characterized in that, The master device detects the status of the sub-device in the following ways: At preset time intervals, query requests are sent to the sub-devices periodically. If a response to the query request is received from the sub-device within a preset query duration, the status of the sub-device is determined to be online. If no response is received from the sub-device for the query request within the preset query time, the sub-device is determined to be in an offline state.

9. The method according to claim 1, characterized in that, The master device sends the status data packet in the following manner: The status data packets are sent at preset time intervals; or, If it is determined that the generated state data packet is inconsistent with the state represented by the previously sent state data packet, the currently generated state data packet is sent to the cloud server; or, Obtain the current network status and load information; determine the transmission frequency of the status data packet based on the network status and load information; and transmit the status data packet according to the transmission frequency.

10. A device for updating equipment status, characterized in that, Applied to cloud servers, the cloud servers are communicatively connected to the master device in a multi-server system, the multi-server system including the master device and at least one sub-device, the device comprising: The first acquisition module is used to acquire the current state of the corresponding sub-device that is currently recorded when the master device sends a status data packet for the sub-device. The second acquisition module is used to acquire, when the state represented by the state data packet is inconsistent with the current state, the timestamp contained in the state data packet and the state timestamp corresponding to the current state recorded; wherein, after the master device detects the state of the sub-device, it generates a state data packet containing a timestamp and sends the state data packet to the cloud server. The update module is used to 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; The step of updating the current state and the state timestamp of the currently recorded sub-device according to the comparison result includes: when the comparison result indicates that the timestamp is later than the state timestamp, updating the current state and the state timestamp of the currently recorded sub-device according to the state data packet; The status data packet also includes the server identifier of the server corresponding to the master device; updating the current status and status timestamp of the currently recorded sub-device according to the status data packet includes: obtaining the server identifier in the status data packet and the target server identifier recorded in the cloud server; if it is determined that the server identifier is consistent with the target server identifier, updating the current status and status timestamp of the currently recorded sub-device according to the status data packet. Before obtaining the state timestamp corresponding to the current state of the current record, the method further includes: obtaining the current timestamp corresponding to the current time point; determining the timestamp difference between the current timestamp and the timestamp; and if the timestamp difference is less than a preset difference threshold, performing the step of obtaining the state timestamp corresponding to the current state of the current record.

11. A cloud server, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory is used to store a computer program; the processor is used to execute the computer program to implement the device state update method according to any one of claims 1-9.

12. A system for updating equipment status, characterized in that, include: Cloud servers and multi-server systems; The multi-unit system includes a main unit and at least one sub-unit; The cloud server is communicatively connected to the master device in the multi-connector 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 master device and execute the device status update method according to any one of claims 1-9.

13. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method for updating the state of the device as described in any one of claims 1-9.

Images