Attribute control method and device of internet of things equipment and electronic equipment

Abstract

The present disclosure provides a property control method and device of an Internet of Things equipment and an electronic device. The method comprises: receiving a property setting request for a target device; in a case where the property setting request cannot be issued to the target device in real time, storing the property setting request as a to-be-compensated record; detecting an online state change of the target device; in a case where the target device is detected to switch from offline to online, acquiring a to-be-compensated property setting request from the to-be-compensated record according to a preset timing strategy; and sending a property setting message to the target device according to the acquired to-be-compensated property setting request. According to the scheme of the present disclosure, the loss of control intention in an offline scenario is avoided, and a property control mechanism capable of maintaining state consistency in a device disconnection scenario is provided.

Description

Technical Field

[0001] This disclosure relates to the field of Internet of Things (IoT) technology, and in particular to a method, apparatus, and electronic device for controlling the attributes of IoT devices in offline scenarios. Background Technology

[0002] In scenarios such as smart homes, industrial IoT, and edge device management, platforms need to continuously configure device attributes, such as on / off status, operating mode, threshold parameters, and configuration options. The platform typically assumes that once attribute settings are issued, the device will automatically enter the target state. However, in actual operation, devices may be offline, in reconnection mode, in weak network conditions, have no subscribers in the message broker, or experience momentary link jitter, causing attribute setting messages to not be received by the device in a timely manner. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, storage medium, and computer program product for attribute control in offline scenarios of Internet of Things (IoT) devices.

[0004] According to one aspect of this disclosure, a method for controlling the attributes of an Internet of Things (IoT) device is provided, comprising: Receive a request to set attributes for the target device; In cases where it is impossible to send attribute setting requests to the target device in real time, the attribute setting requests will be stored as records to be compensated. Detect changes in the online status of the target device; When the target device is detected to switch from offline to online, the attribute setting request to be compensated is obtained from the record to be compensated according to the preset timing strategy; Based on the obtained attribute setting request to be compensated, an attribute setting message is sent to the target device.

[0005] According to another aspect of this disclosure, an attribute control device for an Internet of Things (IoT) device is provided, comprising: a request receiving module for receiving an attribute setting request for a target device; The cache storage module is used to store attribute setting requests as records to be compensated when it is not possible to send attribute setting requests to the target device in real time. The status detection module is used to detect online status changes of the target device; The compensation scheduling module is used to retrieve the attribute setting request to be compensated from the record to be compensated according to a preset timing strategy when the target device is detected to have switched from offline to online. The message delivery module is used to send attribute setting messages to the target device based on the obtained attribute setting request to be compensated.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform any of the methods described in the present disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0009] The method provided in this disclosure converts failed attribute setting requests into records to be compensated, and automatically compensates and distributes them according to a timing strategy after the device comes back online. This avoids the loss of control intent in offline scenarios and provides an attribute control mechanism that can maintain state consistency in device disconnection scenarios.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments provided according to this disclosure and should not be construed as limiting the scope of this disclosure.

[0012] Figure 1 This is a flowchart illustrating the attribute control method for IoT devices provided according to embodiments of this disclosure; Figure 2 This is a schematic diagram of the architecture of an attribute-controlled cache compensation system provided in an embodiment of this disclosure; Figure 3 This is a timing diagram of the attribute-controlled cache compensation process provided in the embodiments of this disclosure; Figure 4 This is a flowchart illustrating the attribute control process of an Internet of Things (IoT) device according to another embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an attribute control device for an Internet of Things (IoT) device according to an embodiment of the present disclosure; Figure 6This is a block diagram of an electronic device used to implement embodiments of the present disclosure. Detailed Implementation

[0013] The present disclosure will now be described in further detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0014] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0015] In related technologies, IoT device attribute control schemes often employ simple approaches such as returning an error upon failure, performing a fixed number of retries within a short period, or relying entirely on the user to re-initiate settings. While this method performs adequately in simple scenarios like brief device disconnections or momentary network fluctuations, it becomes problematic in complex scenarios such as prolonged device offline times or multiple devices simultaneously operating in weak network environments. The lack of a persistent mechanism for storing control intentions and an automated ability to detect changes in device online status leads to issues like control commands being easily discarded, fixed retries wasting significant communication resources during prolonged device offline times, and the inability to automatically synchronize the platform's expected state after the device reconnects. Furthermore, in attribute query scenarios, each request is sent to the device in real-time, rather than prioritizing the most recently reported value already held by the platform, resulting in slow query responses and the inability to return results in offline scenarios. Traditional solutions easily lead to long-term inconsistencies between the platform's expected state and the actual device state, severely impacting the reliability and availability of the IoT control system.

[0016] To at least partially address one or more of the aforementioned problems and other potential issues, this disclosure proposes an attribute control caching compensation scheme for offline IoT devices. By transforming failed attribute setting requests into persistent target attribute cache records and triggering compensation based on device online events, a dual-caching convergence system of "target attribute cache + reported attribute cache" ensures that control intent is not lost during device offline periods. This method significantly improves the accuracy of compensation timing and query response efficiency, and enhances the system's state awareness in offline scenarios through a cache-first query mechanism, achieving a unified improvement in control reliability, state consistency, and query efficiency.

[0017] This disclosure provides a method for controlling the attributes of an Internet of Things (IoT) device. This method can be applied to an attribute control device for IoT devices. The attribute control device is located within an electronic device. The electronic device includes, but is not limited to, fixed devices and / or mobile devices. For example, fixed devices include, but are not limited to, servers, which may be cloud servers, general-purpose servers, or distributed data processing nodes. Mobile devices include, but are not limited to, smart terminals, operation management terminals, etc. In some possible implementations, the attribute control method can also be implemented by a processor calling computer-readable instructions stored in memory.

[0018] The following describes in detail the implementation methods of this disclosure in conjunction with application scenarios and examples.

[0019] Figure 1 This is a flowchart illustrating the attribute control method for IoT devices provided according to embodiments of this disclosure. Figure 1 As shown, the method includes at least the following steps: S110, Receive a request to set attributes for the target device.

[0020] In this embodiment of the disclosure, an attribute setting request is a control instruction issued by the platform to a device to set a target value for a specific attribute. This request can originate from a calling terminal, such as a smart home control panel, an industrial monitoring system interface, or an automation orchestration engine. The attribute setting request includes at least a device identifier and an attribute object identifier, used to uniquely identify the target device to be controlled and the attribute item to be written. The request may further include information such as the target attribute value, Message Service Quality of Service (QoS) level, and message retain flag.

[0021] In one possible implementation, after receiving the attribute setting request but before real-time delivery to the target device, the device control service can query the current attribute status value of the target device from the reported attribute cache. If the current attribute status value in the cache is the same as the target attribute value to be set, the delivery can be skipped to avoid repeatedly setting an already effective attribute value. If the current attribute status value in the cache is different from the target attribute value or the cache does not exist, the subsequent real-time delivery steps continue.

[0022] In one example, a user switches the operating mode of a thermostat to "energy-saving mode" via a smart home app. The app, acting as the calling terminal, generates an attribute setting request. The device identifier is the thermostat's unique serial number, the attribute object identifier is "operating mode," and the target attribute value is "energy-saving mode." For instance, in an industrial scenario, an automation orchestration engine issues a threshold modification command to a temperature sensor, and the target attribute value in the attribute setting request is the new temperature threshold value.

[0023] S120. In the event that the attribute setting request cannot be sent to the target device in real time, the attribute setting request is stored as a record to be compensated.

[0024] In this embodiment of the disclosure, after receiving an attribute setting request, the device control service first attempts to assemble the attribute setting request into an attribute setting message through the message publishing component and send it to the message topic corresponding to the target device. If the message publishing result shows that the device is offline, the message broker has no subscribers, the link times out, or other preset failure conditions, it is determined that real-time delivery is not possible. At this time, the device control service does not discard the request, but converts it into a record to be compensated and writes it to persistent storage.

[0025] A record to be compensated can be understood as a data entry that stores the device identifier (iotId), the device triplet identifier (thingId), the target attribute value, the message service quality level (QoS), and the message retention flag (retain). This record can be stored in various types of storage systems.

[0026] The Message Service Quality Level (QoS) controls the reliability guarantee level of message delivery. In one implementation, QoS can be 0, 1, or 2: QoS 0 indicates that the message is delivered at most once, with no guarantee of delivery, suitable for scenarios with high real-time requirements but where a small amount of loss is acceptable (e.g., high-frequency sampling values ​​from temperature sensors); QoS 1 indicates that the message is delivered at least once, guaranteeing delivery but potentially allowing duplicates, suitable for scenarios requiring guaranteed instruction execution but allowing for repeated processing (e.g., device mode switching instructions); QoS 2 indicates that the message is delivered exactly once, guaranteeing both delivery and non-duplication, suitable for critical operations that cannot be repeated (e.g., firmware upgrade instructions or security certificate updates). In one example, when the platform issues a temperature threshold adjustment instruction as compensation, if the original request uses QoS 1, the compensation message is also issued with QoS 1, ensuring that the device receives the threshold instruction at least once.

[0027] The message retention flag controls whether the message broker retains the last message under a given message topic. When the retain flag is set to "Yes", the message broker will save the last message under that topic. Any newly subscribed device will immediately push this retained message to that device after establishing a connection. In this embodiment, retain is stored as part of the compensation record. This serves the following purpose: when a device comes back online and the message broker already contains the latest retained message for that device's corresponding topic, the platform can compare the content of the retained message with the compensation record, thereby avoiding the duplicate distribution of attribute settings that have been overwritten by the retained message.

[0028] This record can be stored in various types of storage systems. In one implementation, the target attribute cache can be stored in a key-value database (such as Redis), using the device identifier as the key and the attribute setting request list as the value. In another alternative implementation, the record to be compensated can also be stored in a relational database, using a composite primary key composed of the device identifier and attribute identifier. In yet another implementation, the record to be compensated can also be written to a message queue (such as Kafka), leveraging the persistence and ordered consumption characteristics of message queues to process and distribute compensation sequentially.

[0029] Taking a specific application scenario as an example, a user adjusts the set temperature of their air conditioner from 26°C to 22°C at home, but the air conditioner is offline at this time. After attempting to send the setting in real time, the device control service detects that the device is unreachable. Therefore, it converts the attribute setting request into a compensation pending record, which records information such as the air conditioner's device identifier, temperature attribute identifier, and target value of 22°C, awaiting subsequent compensation.

[0030] In another example, if a firmware update command for an industrial device fails due to a link timeout caused by the device being in a weak network environment, the device control service will also write the update command into the compensation cache to ensure that the control intent is not lost due to momentary network fluctuations.

[0031] Specifically, the circumstances under which real-time delivery cannot be determined can include several. In one possible implementation, the target device is offline, meaning the long-lived connection between the device and the server has been broken. In another implementation, the message broker (such as an MQTT Broker) reports that the corresponding device topic has no active subscribers, causing the message to fail to be delivered. In yet another implementation, the network link times out, and the device control service does not receive a message publication confirmation within a preset timeout period.

[0032] S130, Detect changes in the online status of the target device.

[0033] In this embodiment, the platform continuously monitors the online status of the target device through a device status event processing service. The online status can be determined based on various signal sources. In one implementation, the device triggers a connection establishment event when it successfully establishes a connection (e.g., an MQTT CONNECT message), which is reported to the device status event processing service, marking the device as online. In another implementation, the device maintains a long connection by periodically sending heartbeat messages; when the heartbeat resumes, a heartbeat recovery event is triggered, and the device status event processing service updates the device's online status accordingly. In yet another implementation, the platform can also actively probe (e.g., Ping, HTTP Health Check) to confirm device reachability.

[0034] Taking a specific application scenario as an example, a smart gateway that was previously offline due to a power outage reconnects to the network after power is restored and sends an MQTT CONNECT message to the server. The connection layer on the server side detects this connection establishment event, marks the device as online, and triggers the online event callback in the device status event handling service.

[0035] In another example, the online status change event is not limited to switching from offline to online, but may also include switching from online to offline. However, this disclosure embodiment mainly focuses on the positive switching event from offline to online to trigger the subsequent compensation process.

[0036] S140. When the target device is detected to have switched from offline to online, the attribute setting request to be compensated is obtained from the record to be compensated according to the preset timing strategy.

[0037] In this embodiment of the disclosure, when the target device is identified as having come back online, the cache integration service queries all the records to be compensated corresponding to that device based on the device identifier. Multiple records to be compensated may be found, especially when multiple attribute setting requests are initiated during a prolonged period of device offline operation.

[0038] To avoid the impact of receiving a large number of messages during device reconnection, this embodiment of the disclosure resends the records to be compensated according to a preset timing strategy. In one possible implementation, the timing strategy is to send records one by one according to a preset delay time; that is, after the device comes online, one record to be compensated is sent to the device at fixed time intervals (e.g., 5 seconds). In another alternative implementation, the timing strategy is to send records in batches according to a preset delay time; that is, to send records in batches (e.g., 10 records per batch), with a predetermined time interval between each batch. In yet another implementation, the sending order can be determined according to the priority of the attributes to be compensated, with higher priority attributes sent first and lower priority attributes processed later.

[0039] In one possible implementation, after loading the attribute setting request to be compensated from the record to be compensated but before sending it to the target device, deduplication can be performed on the record to be compensated. Specifically, when multiple records to be compensated correspond to the same attribute object identifier of the same target device, it indicates that the attribute was set multiple times while the device was offline. In this case, if all intermediate states are sent to the device one by one in chronological order, it will not only increase communication overhead but may also cause the device to experience multiple unnecessary state transitions in a short period of time. Therefore, the device control service can compare the records to be compensated for the same attribute object identifier of the same device based on the target attribute value, and only retain the record to be compensated with the most recent generation time to participate in the compensation distribution, while marking the remaining records to be compensated for intermediate states as expired or deleting them directly. For example, if a smart light's brightness attribute is set to 40%, 70%, and 50% successively while offline, according to the above deduplication logic, only the record to be compensated with the latest target brightness value of 50% will be retained for distribution, while the records with 40% and 70% will no longer participate in the compensation. In one example, if multiple records have the same target attribute value, the earliest record can be retained and subsequent duplicates discarded to reduce meaningless compensation operations. In another example, the deduplication strategy can be enabled based on the type of the attribute object identifier—deduplication can be enabled for progressive attributes such as temperature and brightness that change continuously and only the final value matters, while all records are retained for event-type attributes such as mode switching and firmware updates that have independent semantics in their intermediate states.

[0040] In one example, an environmental monitoring device accumulated six ineffective attribute setting commands while offline, including temperature threshold adjustment, humidity threshold adjustment, sampling frequency modification, alarm switch setting, data reporting cycle adjustment, and calibration parameter update. After the device came back online, the platform sent one attribute setting command to the device every 5 seconds, and the entire compensation process was completed within 30 seconds. The device could process these commands one by one under relatively stable message pressure.

[0041] In another example, for batch devices containing more than 50 records to be compensated, the platform adopts a batching strategy, sending 10 records in each batch with a 10-second interval between batches, thereby effectively reducing the instantaneous load at the beginning of device reconnection.

[0042] S150. Based on the obtained attribute setting request to be compensated, send an attribute setting message to the target device.

[0043] In this embodiment of the disclosure, after the device control service reads the attribute setting request from the record to be compensated, it reassembles it into an attribute setting message and sends it to the corresponding message topic of the target device through the message publishing component. The format of this attribute setting message is consistent with the message format during the initial real-time delivery, including the same device identifier, attribute object identifier, target attribute value, and QoS level.

[0044] In one possible implementation, after the attribute setting message is successfully sent, the device control service notifies the cache integration service to delete the corresponding record to be compensated. In another implementation, if the attribute setting message fails to send, the corresponding record to be compensated is retained, and the number of failed transmissions for that record is recorded. When the number of failed transmissions reaches a preset threshold (e.g., 3 times), the corresponding record to be compensated is moved to the error list, and retransmission attempts for that record are stopped.

[0045] Specifically, after successful delivery and cache deletion, the record to be compensated is removed from the target attribute cache, indicating that the attribute has been synchronized from the platform's expected state to the device's actual state. If delivery fails, the device control service will retry in subsequent compensation cycles until the retry limit is reached. Once the limit is reached, the record is added to an error list, requiring manual intervention or handling through other exception handling procedures.

[0046] In one example, a gateway device located at the edge receives three compensation attribute commands after coming online. The first two execute successfully and delete the corresponding records to be compensated. The third command fails to write due to insufficient device storage space. The device control service records the number of failures for this record and retryes it in the next compensation cycle. If it fails three times consecutively, the record is moved to the error list and will no longer be automatically retried.

[0047] After successfully receiving and executing the attribute setting message, the target device automatically reports the updated actual attribute status value to the platform. Upon receiving this reported data, the platform writes it to the reported attribute cache, replacing the original cached record under that attribute object identifier. Through this automatic write-back mechanism, the reported attribute cache always stores the actual status value of the target device after the most recent successful execution of the attribute setting, thus providing a priority data source for subsequent attribute queries. In one example, after the platform issues a compensatory command to the thermostat to set its energy-saving mode, the thermostat switches to energy-saving mode and actively reports its current mode status. The platform writes the reported status value to the reported attribute cache. Subsequently, when a user queries the thermostat's current operating mode, the platform can directly read and return "energy-saving mode" from the reported attribute cache without needing to send a real-time query request to the thermostat again.

[0048] In one possible implementation, the attribute control method also includes an attribute query caching priority mechanism that works in conjunction with the attribute setting compensation process, including: Receive attribute status values ​​reported by the target device; Write the reported attribute status value into the reported attribute cache.

[0049] In this embodiment of the disclosure, the attribute query process and the attribute setting compensation process are not two independent processes, but rather form a closed-loop association through the reported attribute cache: when an attribute is set and the device executes it successfully, the device automatically reports the updated attribute status value, which is captured and written into the reported attribute cache; when a subsequent attribute query request is initiated, the platform prioritizes reading from the reported attribute cache, thereby skipping the real-time query link and accelerating the query response.

[0050] In one possible implementation, the attribute control method also includes a cache priority mechanism for attribute queries.

[0051] S210, Receive an attribute query request for the target device.

[0052] In this embodiment of the disclosure, the query request is initiated by the calling terminal and includes at least the device identifier of the target device and the identifier of the attribute object to be queried. Unlike attribute setting requests, the goal of an attribute query request is to obtain the current actual attribute state of the device, rather than modifying the device's operating state.

[0053] S220. Prioritize querying the reported attribute cache, where the reported attribute cache is used to store the attribute status of the target device in the most recent report.

[0054] In this embodiment of the disclosure, after receiving an attribute query request, the platform does not immediately send a real-time read instruction to the device, but first queries the reported property cache. The reported property cache stores the attribute status value that the device has most recently reported. This cache is updated synchronously whenever the device actively reports its status or responds to an attribute setting.

[0055] In one implementation, the platform determines whether the corresponding attribute value exists in the reported attribute cache and meets the preset freshness requirement. Freshness is an indicator for evaluating the timeliness of cached data—if the attribute information in the cache is within a preset period (e.g., 1 month), the data is considered to have sufficient freshness and can be directly returned as a query result; conversely, if the cached data has not been updated for more than 1 month, it is considered to have insufficient freshness and the latest attribute information needs to be obtained from the device.

[0056] In one example, a user queries the current brightness value of a smart light bulb. The platform retrieves the bulb's brightness attribute value of 80% from the reported attribute cache. This value was reported 3 days ago, meeting the 1-month freshness requirement. Therefore, the platform directly returns the cached 80% as the query result, without needing to send a real-time query request to the light bulb.

[0057] In another example, if a user queries an older device that went offline 45 days ago and hasn't reported any data since, the data in the reported attribute cache is not fresh enough, and the platform will send a real-time attribute read request to the device. If the device is still offline, the platform can return the most recent valid value in the cache with a timestamp, indicating that the value may be outdated.

[0058] In another implementation, differentiated freshness thresholds can be set based on device type or attribute type. For example, a shorter freshness period can be set for attributes that change frequently, such as temperature and humidity, while a longer freshness period or even no freshness limit can be set for static attributes such as device firmware version and serial number.

[0059] In one possible implementation, after the attribute setting message is successfully sent to the target device, the device control service can also send an attribute query request to the target device. It will first read the current reported value of the attribute from the reported attribute cache to verify whether the device has successfully switched to the target state. If the attribute value returned in the cache matches the target attribute value, the attribute setting is confirmed to be effective. If they do not match or the cache is not updated within a preset time, an exception handling process for the attribute setting can be triggered or a verification exception log can be recorded. In one example, after the platform sends a command to the air conditioner compensation to set the temperature to 22°C, it reads the reported value of the current temperature of the air conditioner from the reported attribute cache every 5 seconds. If the reported value is 22°C, the setting is confirmed to be successful. If the reported value is still 26°C and exceeds the preset waiting time, the compensation record for the air conditioner is marked as pending confirmation, prompting maintenance personnel to pay attention.

[0060] According to the scheme of this disclosure, by converting failed attribute setting requests into records to be compensated, the problem of loss of control intent during device offline is avoided, and the inherent defect of traditional schemes that discard control commands once they fail to be issued is solved. By triggering compensation based on device online events instead of conventional fixed-time retries, the accuracy of compensation timing is significantly improved, and invalid message communication overhead is reduced. By introducing a preset timing strategy for resending messages one by one or in batches, the impact of message surges at the moment of device reconnection is alleviated, and the instantaneous load pressure on the device side is reduced. By establishing a dual-caching system of target attribute cache (expected state) and reported attribute cache (actual state), the platform can continuously promote the gradual convergence of the two states, optimize the efficiency of attribute query, reduce unnecessary real-time link requests, and shorten query response time.

[0061] Figure 2 This is a schematic diagram of the architecture of an attribute-controlled cache compensation system provided according to embodiments of this disclosure. Figure 2As shown, the system includes a calling terminal, a device control service, a message publishing component, a target attribute cache, a reported attribute cache, a device status event processing service, and terminal devices. The calling terminal is responsible for initiating attribute setting requests and attribute query requests, and serves as the entry point for system interaction with users or upper-layer business logic. The device control service is the core scheduling unit of the entire system, responsible for real-time distribution of attribute setting requests, failure determination of distribution, and compensation scheduling decisions.

[0062] The message publishing component is responsible for delivering attribute setting messages to the corresponding message topic on the terminal device and providing feedback on the delivery result. The target attribute cache stores compensation records that have been converted due to real-time delivery failures. These records contain key information such as device identifier, attribute object identifier, and target attribute value, serving as a persistent carrier of control intent during device offline periods. The reported attribute cache stores the most recently reported attribute status value from the terminal device, acting as the primary data source for attribute queries. The device status event handling service monitors changes in the online status of the terminal device and triggers compensation logic when the device transitions from offline to online. After re-entering the network, the terminal device receives and executes the compensation attribute message. Upon completion, it writes the actually reported attribute status back to the reported attribute cache, thus forming a closed-loop convergence between the expected and actual states.

[0063] Figure 3 This is a timing diagram illustrating the attribute-controlled cache compensation process provided in an embodiment of this disclosure. For example... Figure 3 As shown, the sequence diagram contains three branch paths: normal delivery branch, failure compensation branch, and query branch. In the normal delivery branch, the calling terminal initiates an attribute setting request to the device control service, and the device control service delivers the attribute setting message to the terminal device through the message publishing component. In the failure compensation branch, when real-time delivery fails, the device control service does not discard the request but writes it to the target attribute cache; subsequently, when the device status event processing service detects that the terminal device has come back online, it queries the target attribute cache for all records to be compensated for the device and hands the records over to the device control service for compensation scheduling; the device control service resends the attribute setting message to the terminal device one by one or in batches through the message publishing component according to a preset timing strategy; after receiving and executing the message, the terminal device reports the latest actual attribute status to the reported attribute cache. In the query branch, the calling terminal initiates an attribute query request to the device control service. The device control service first queries the reported attribute cache. If a match is found, the query result in the cache is returned directly. If no match is found or the freshness requirement is not met, the service initiates a real-time attribute read to the terminal device through the message publishing component and updates the reported attribute cache with the returned result.

[0064] Figure 3 This is a timing diagram illustrating the attribute-controlled cache compensation process provided in an embodiment of this disclosure. For example... Figure 3As shown, the sequence diagram contains three branch paths: normal delivery branch, failure compensation branch, and query branch. In the normal delivery branch, the calling terminal initiates an attribute setting request to the device control service, and the device control service delivers the attribute setting message to the terminal device through the message publishing component. In the failure compensation branch, when real-time delivery fails, the device control service does not discard the request but writes it to the target attribute cache; subsequently, when the device status event processing service detects that the terminal device has come back online, it queries the target attribute cache for all records to be compensated for the device and hands the records over to the device control service for compensation scheduling; the device control service resends the attribute setting message to the terminal device one by one or in batches through the message publishing component according to a preset timing strategy; after receiving and executing the message, the terminal device reports the latest actual attribute status to the reported attribute cache.

[0065] In the query branch, the calling terminal initiates an attribute query request to the device control service. The device control service first queries the reported attribute cache. If a match is found, the query result in the cache is returned directly. If no match is found or the freshness requirement is not met, the service initiates a real-time attribute read to the terminal device through the message publishing component and updates the reported attribute cache with the returned result.

[0066] Figure 4 This is a flowchart illustrating the attribute control process of an Internet of Things (IoT) device according to another embodiment of this disclosure. Figure 4 As shown, the method includes two parallel processing paths: an attribute setting compensation process and an attribute query process.

[0067] The attribute setting compensation process includes the following steps: S401, The caller initiates a property setting request.

[0068] S402, The device control service attempts to send attribute setting messages to the target device in real time through the message publishing component.

[0069] S403. Determine if the real-time distribution was successful; if successful, end the normal distribution process for this attribute setting.

[0070] S404. If real-time delivery fails, the attribute setting request will be written to the target attribute cache.

[0071] S405, Device Status Event Handling Service continuously monitors the online events of the target device.

[0072] S406. When the target device comes back online, load all the records to be compensated for the device from the target attribute cache.

[0073] S407. Send the attribute setting messages to be compensated to the target device according to the preset timing strategy (one message at a time or in batches).

[0074] S408. Determine whether the resent attribute setting message has been successfully sent.

[0075] S409. If the distribution is successful, delete the corresponding record to be compensated, and the compensation process set for this attribute ends.

[0076] S410. If the transmission fails, retain the record to be compensated and record the number of transmission failures. When the number of failures does not reach the preset threshold (e.g., 3 times), return to S406 and wait for the next compensation cycle to try again. When the number of failures reaches the preset threshold, move the record to be compensated to the error list and stop automatic retransmission.

[0077] The attribute query process includes the following steps: S411, The caller initiates an attribute query request.

[0078] S412, Prioritize querying the reported attribute cache.

[0079] S413. Determine whether the query result is a hit and meets the preset freshness requirement; if so, directly return the query result in the reported attribute cache.

[0080] S414. If the target device is not found or the freshness requirement is not met, a real-time attribute read request is sent to the target device through the message publishing component.

[0081] S415. Update the reported attribute cache with the real-time read attribute status and return the query results.

[0082] Figure 5 This is a schematic diagram of the structure of an attribute control device for an Internet of Things (IoT) device provided according to an embodiment of this disclosure. For example... Figure 5 As shown, the attribute control device 500 of the Internet of Things device includes: The request receiving module 501 is used to receive attribute setting requests for the target device. The cache storage module 502 is used to store the attribute setting request as a record to be compensated when it is impossible to send the attribute setting request to the target device in real time. The status detection module 503 is used to detect online status changes of the target device; The compensation scheduling module 504 is used to obtain the attribute setting request to be compensated from the record to be compensated according to a preset timing strategy when the target device is detected to switch from offline to online. The message sending module 505 is used to send an attribute setting message to the target device based on the obtained attribute setting request to be compensated.

[0083] In one possible implementation, the cache storage module 502 is specifically used to determine the circumstances under which real-time delivery is not possible, including at least one of the following: device offline, message broker without subscribers, or link timeout.

[0084] In one possible implementation, the record to be compensated stored in the cache storage module 502 includes at least: device identifier, attribute object identifier, target attribute value, message service quality level, and message retention flag.

[0085] In one possible implementation, the compensation scheduling module 504 is specifically used to send compensation attribute setting requests one by one according to a preset delay time, or to send them in batches according to a preset delay time.

[0086] In one possible implementation, the status detection module 503 is specifically used to detect whether the target device has switched from offline to online via a connection establishment event or a heartbeat recovery event.

[0087] In one possible implementation, the message delivery module 505 is also used to delete the corresponding record to be compensated after the attribute setting message is successfully sent.

[0088] In one possible implementation, the message delivery module 505 is also used to retain the corresponding compensation record when the attribute setting message fails to be sent; The cache storage module 502 is also used to record the number of times the record to be compensated failed to be sent.

[0089] In one possible implementation, the cache storage module 502 is also used to move the corresponding record to be compensated into the error list and stop retransmission when the number of transmission failures reaches a preset threshold.

[0090] In one possible implementation, the request receiving module 501 is also configured to receive an attribute query request for the target device; The cache storage module 502 is also used to prioritize querying the reported attribute cache, whereby the reported attribute cache is used to store the attribute status most recently reported by the target device.

[0091] In one possible implementation, when the cache storage module 502 prioritizes querying the reported attribute cache, it specifically performs the following: if the corresponding attribute value exists in the reported attribute cache and meets the preset freshness requirement, then it retrieves the query result from the reported attribute cache and returns it.

[0092] In one possible implementation, the cache storage module 502 is also used to trigger the message delivery module 505 when the corresponding attribute value does not exist in the reported attribute cache or the preset freshness requirement is not met. The message delivery module 505 is also used to send real-time attribute reading requests to the target device.

[0093] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0094] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of the present disclosure. Figure 6 As shown, the electronic device includes a memory 610 and a processor 620. The memory 610 stores a computer program that can run on the processor 620. There can be one or more memories 610 and processors 620. The memory 610 can store one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods provided in the above-described method embodiments. The electronic device may also include a communication interface 630 for communicating with external devices and performing data exchange and transmission.

[0095] If the memory 610, processor 620, and communication interface 630 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0096] Optionally, in a specific implementation, if the memory 610, processor 620, and communication interface 630 are integrated on a single chip, then the memory 610, processor 620, and communication interface 630 can communicate with each other through an internal interface.

[0097] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0098] Further, optionally, the aforementioned memory may include read-only memory and random access memory, and may also include non-volatile random access memory. The memory may be volatile or non-volatile, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct RAMBUS RAM (DR RAM).

[0099] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line, DSL) or wireless (e.g., infrared, Bluetooth, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)). It is worth noting that the computer-readable storage media mentioned in this disclosure can be non-volatile storage media; in other words, it can be non-transient storage media.

[0100] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0101] In the description of the embodiments of this disclosure, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0102] In the description of the embodiments disclosed herein, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0103] In the description of embodiments of this disclosure, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more.

[0104] The above description is merely an exemplary embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

Claims

1. A method for controlling the attributes of an Internet of Things (IoT) device, comprising: Receive a request to set attributes for the target device; In the event that the attribute setting request cannot be sent to the target device in real time, the attribute setting request will be stored as a record to be compensated. Detect changes in the online status of the target device; When the target device is detected to have switched from offline to online, the attribute setting request to be compensated is obtained from the record to be compensated according to a preset timing strategy; Based on the obtained attribute setting request to be compensated, an attribute setting message is sent to the target device.

2. The method according to claim 1, characterized in that, The situation where the attribute setting request cannot be sent to the target device in real time includes at least one of the following: Device offline, message broker has no subscribers, link timeout.

3. The method according to claim 1, characterized in that, The records to be compensated include at least: Device identifier, attribute object identifier, target attribute value, message service quality level, and message retention flag.

4. The method according to claim 1, characterized in that, The preset timing strategy includes: The attribute setting requests to be compensated may be sent one by one according to a preset delay time, or sent in batches according to a preset delay time.

5. The method according to claim 1, characterized in that, The detection of changes in the online status of the target device includes: The target device is detected to have switched from offline to online by a connection establishment event or a heartbeat recovery event.

6. The method according to claim 1, characterized in that, After sending the attribute setting message to the target device, the method further includes: If the attribute setting message is sent successfully, the corresponding record to be compensated is deleted.

7. The method according to claim 6, characterized in that, Also includes: If the attribute setting message fails to be sent, the corresponding record to be compensated is retained, and the number of times the record to be compensated fails to be sent is recorded.

8. The method according to claim 7, characterized in that, Also includes: When the number of failed transmissions reaches a preset threshold, the corresponding record to be compensated is moved to the error list, and retransmission is stopped.

9. The method according to claim 6, characterized in that, After sending the attribute setting message to the target device, the method further includes: Receive the attribute status values ​​reported by the target device; Write the reported attribute status value into the reported attribute cache.

10. The method according to claim 1, characterized in that, Also includes: Receive an attribute query request for the target device; Prioritize querying the reported attribute cache, which is used to store the attribute status of the most recently reported attribute by the target device.

11. The method according to claim 10, characterized in that, The priority query has been reported to the attribute cache, including: If the corresponding attribute value exists in the reported attribute cache and meets the preset freshness requirement, then the query result is retrieved from the reported attribute cache and returned.

12. The method according to claim 10, characterized in that, The priority query that has been reported to the attribute cache also includes: If the reported attribute cache does not contain the corresponding attribute value or does not meet the preset freshness requirement, a real-time attribute reading request is sent to the target device.

13. An attribute control device for an Internet of Things (IoT) device, comprising: The request receiving module is used to receive attribute setting requests for the target device; The cache storage module is used to store attribute setting requests as records to be compensated when it is not possible to send attribute setting requests to the target device in real time. The status detection module is used to detect online status changes of the target device; The compensation scheduling module is used to retrieve the attribute setting request to be compensated from the record to be compensated according to a preset timing strategy when the target device is detected to have switched from offline to online. The message delivery module is used to send attribute setting messages to the target device based on the obtained attribute setting request to be compensated.

14. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-12.

Images