Bluetooth remote control switch timing task dynamic scheduling method and system

Abstract

The invention provides a Bluetooth remote control switch timed task dynamic scheduling method and system, is applied to the technical field of intelligent equipment control, and aims to improve the timed task dynamic scheduling efficiency by introducing an expected state and establishing a closed-loop control process from a multi-source control intention to the expected state and then to actual state feedback and instruction execution. The method has the advantages that in a multi-user and multi-source dynamic task concurrent Bluetooth remote control switch control environment, the multi-source control intention can be effectively processed, it is ensured that the equipment state is consistent with the expected state, and the control reliability is improved.

Description

Technical Field

[0001] The present application relates to the technical field of intelligent device control, and particularly to a method and system for dynamically scheduling Bluetooth remote control switch timing tasks. Background Art

[0002] In a modern family or small office environment, intelligent control systems are becoming increasingly popular. Among them, intelligent control networks based on Bluetooth low energy technology are often used to control terminal devices such as lighting equipment and intelligent sockets due to their convenient deployment and relatively low cost. A typical system architecture includes Bluetooth remote control switch / socket devices, user terminals (such as smart phones), and one or more locally deployed Bluetooth gateways. Users can communicate with the gateway through a mobile application to control Bluetooth devices.

[0003] The system usually provides basic automation functions, such as setting fixed timing tasks. Users can set to automatically turn on or off certain devices at specific times, for example, automatically turn on the kitchen lighting at 7:00 in the morning on weekdays and automatically turn off the living room lighting at 10:00 in the evening. Such timing tasks can meet some regular usage needs of users.

[0004] However, the actual usage scenarios of users are diverse and dynamically changing, and in a multi-user shared environment, different users have different control requirements. Relying solely on fixed timing tasks far from meets the needs.

[0005] Therefore, in a Bluetooth remote control switch control environment with multi-user and multi-source dynamic task concurrency, how to ensure the reliable execution of device control instructions and the dynamic scheduling of tasks, so that the system finally reaches the state expected by users? In view of the above problems of the prior art, there is an urgent need for improvement. Summary of the Invention

[0006] In view of the deficiencies of the above prior art, the present application provides a method and system for dynamically scheduling Bluetooth remote control switch timing tasks, which are applied to the technical field of intelligent device control, and have the advantages of being able to effectively process multi-source control intentions, ensuring that the device state is consistent with the expected state, and improving the reliability of control.

[0007] In a first aspect, a method for dynamically scheduling Bluetooth remote control switch timing tasks, the method includes the steps of: S1: Obtain control intentions from at least one task source among timing tasks, user operations, scene triggers, and user rule engines; S2: Convert the control intention into an expected state request, and manage the expected state of the target device according to the expected state request; S3: Receive the device status report of the target device, and manage the current actual state of the target device according to the device status report; S4: When the desired state is inconsistent with the current actual state and the target device is online, generate a control instruction corresponding to the desired state; S5: Obtain the actual state of the target device after executing the control instruction. When the actual state does not reach the desired state, regenerate and execute a control instruction corresponding to the desired state until the actual state is consistent with the desired state.

[0008] A dynamic scheduling method for Bluetooth remote control switch timing tasks proposed in this application, by introducing a desired state and establishing a closed-loop control process from multi-source control intentions to the desired state, and then to actual state feedback and instruction execution, has the advantages of being able to effectively process multi-source control intentions in a Bluetooth remote control switch control environment with multi-user and multi-source dynamic task concurrency, ensuring that the device state is consistent with the desired state, and improving the reliability of control.

[0009] Further, step S2 includes: S21: Convert the control intention into a desired state request including a target device identifier, a desired state, a request source type, and a request priority; S22: Obtain a preset conflict resolution rule; S23: According to the preset conflict resolution rule, use the request source type and the request priority to judge and resolve at least one desired state request for the same target device, and determine the desired state of the target device; wherein, the target device has a unique target device identifier.

[0010] A dynamic scheduling method for Bluetooth remote control switch timing tasks proposed in this application, by using a preset conflict resolution rule to judge and resolve at least one desired state request for the same target device, ensures that at any moment, there is only one determined desired state for a target device, provides a clear goal for subsequent instruction generation and execution, and avoids problems caused by uncertain or conflicting desired states.

[0011] Further, step S23 includes: S231: Receive at least one desired state request for the same target device; S232: Perform a validity judgment on the at least one desired state request, filter out invalid desired state requests, and obtain a set of valid desired state requests; S233: According to the preset conflict resolution rule, and using the request source type, the request priority, and time information of each request in the set of valid desired state requests, select an optimal desired state request from the set of valid desired state requests; S234: Determine the expected state of the optimal expected state request as the expected state of the target device.

[0012] A method for dynamically scheduling timed tasks of a Bluetooth remote control switch proposed in this application solves the problem of how to accurately and reliably determine the final expected state when there are multiple expected state requests for the same device by introducing a validity judgment on the expected state request and a refined decision based on the request source type, priority, and time information, thereby improving the system's ability and accuracy in handling concurrent task conflicts.

[0013] Furthermore, after step S3, the following steps are further included: S31: Determine whether the current actual state satisfies a preset dependency trigger condition; S32: When the current actual state meets the preset dependency trigger condition, continuously monitor the current actual state of the target device; S33: When the current actual state of the target device continuously satisfies the preset dependency triggering condition within a preset monitoring period, the dependency processing module is triggered to process the task with dependency relationship.

[0014] The present application proposes a method for dynamically scheduling timed tasks of a Bluetooth remote control switch, which solves the problem in the existing scheme that dependent tasks between different devices cannot be triggered in conjunction with changes in actual status by adding a step of judging and triggering dependent task processing based on the actual status on the basis of receiving and managing the current actual status of the target device.

[0015] Further, step S33 includes: S331: when the current actual state of the target device continuously satisfies the preset dependency trigger condition within a preset monitoring period, searching for a preset task dependency relationship according to the target device identifier and the preset dependency trigger condition; S332: Determine at least one subsequent task that depends on the current actual state of the target device satisfying the preset dependency trigger condition; S333: For each of the at least one subsequent task, obtain a subsequent target device identifier and a subsequent expected state corresponding thereto; S334: For each of the at least one subsequent task, generate a subsequent expected state request including the subsequent target device identifier, the subsequent expected state, the request source type, and the request priority.

[0016] Further, step S4 includes: S41: when the expected state is inconsistent with the current actual state and the target device is online, acquiring device capability information of the target device; S42: Determine the control operations and operation parameters that the target device needs to execute according to the current actual state, the desired state, and the device capability information; S43: Generate a control instruction that complies with the communication protocol and format requirements of the target device according to the determined control operations and operation parameters.

[0017] Further, step S42 includes: S421: Determine the state gap that needs to be bridged according to the difference between the current actual state and the desired state; S422: Determine one or more control instruction types that can bridge the state gap according to the state gap and the types of control instructions supported in the device capability information; S423: Determine the control operations and operation parameters that the target device needs to execute according to the one or more control instruction types and the corresponding parameter ranges in the device capability information.

[0018] Further, step S5 includes: S51: When obtaining the actual state of the target device after executing the control instruction and the actual state does not reach the desired state, regenerate and execute the control instruction corresponding to the desired state, and continuously monitor the desired state registry of the target device during the execution; S52: When it is monitored that the desired state corresponding to the desired state registry changes, stop the current instruction retry or status query process for the desired state; S53: Obtain the desired state after the desired state registry is updated, and regenerate and send the control instruction corresponding to the updated desired state according to the updated desired state.

[0019] Further, after step S51, it also includes: S54: When it is monitored that the desired state corresponding to the desired state registry does not change, determine whether the target device is online; S55: When the target device is online, according to a preset retry policy, the retry policy is based on a preset retry count limit or time limit, perform at least one of the following operations: Regenerate and send the control instruction corresponding to the desired state; Initiate a status query for the current actual state of the target device; S56: Continuously execute the operations in step S55 until the actual state is consistent with the desired state, or the preset retry count limit or time limit is reached; S57: When the target device is offline, pause the instruction retry or status query process for the target device.

[0020] In a second aspect, a dynamic scheduling system for Bluetooth remote control switch timing tasks is applied to the steps of any of the above methods. The system includes: An acquisition module: acquires control intentions from at least one of task sources such as timing tasks, user operations, scenario triggers, and user rule engines; A first management module: converts the control intention into a desired state request and manages the desired state of the target device according to the desired state request; A second management module: receives the device status report of the target device and manages the current actual state of the target device according to the device status report; An instruction generation module: when the desired state is inconsistent with the current actual state and the target device is online, generates a control instruction corresponding to the desired state; An execution module: acquires the actual state of the target device after executing the control instruction. When the actual state does not reach the desired state, regenerates a control instruction corresponding to the desired state and executes it until the actual state is consistent with the desired state.

[0021] Advantageous effects: A dynamic scheduling method and system for Bluetooth remote control switch timing tasks proposed in this application introduce a desired state and establish a closed-loop control process from multi-source control intentions to the desired state, and then to actual state feedback and instruction execution. In a Bluetooth remote control switch control environment with multi-user and multi-source dynamic task concurrency, it can effectively process multi-source control intentions, ensure that the device state is consistent with the desired state, and improve the reliability of control. Description of the Drawings

[0022] Figure 1 It is a flowchart of a dynamic scheduling method for Bluetooth remote control switch timing tasks proposed in this application.

[0023] Figure 2 It is a structural diagram of a dynamic scheduling system for Bluetooth remote control switch timing tasks proposed in this application.

[0024] Figure 3 It is an architecture diagram of a dynamic scheduling system for Bluetooth remote control switch timing tasks proposed in this application.

[0025] Label description: 201, acquisition module; 202, extraction module; 203, mapping module; 204, detection module; 205, warning module. Detailed Embodiments

[0026] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Components of the embodiments of the present application described and marked in the accompanying drawings here can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application to be protected, but only represents the selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without creative efforts belong to the scope of protection of the present application.

[0027] It should be noted that: similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of the present application, terms such as "first", "second", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0028] In traditional existing intelligent control systems, especially in networks based on Bluetooth low energy technology, fixed timing tasks are usually used to automate the control of devices. However, in a multi-user sharing environment and increasingly complex application scenarios, control requirements are diverse and dynamically changing. Relying solely on fixed timing tasks cannot effectively handle concurrent control intentions generated from user manual operations, scenario linkage triggers, or user-defined rule engines.

[0029] For example, assume that in a smart home environment, a Bluetooth remote control switch controls the main light in the living room. The system sets a timing task to turn off the main light in the living room at 10 pm every night. At the same time, family member A may manually turn on the main light through the mobile application at 9:59 pm, and family member B may trigger a "movie watching mode" scenario at 10:01 pm, which requires the brightness of the main light in the living room to be set to 30%. In addition, a user rule engine may set that when the TV is turned on, the main light in the living room should remain on. Around 10 pm, these control intentions from the timing task, user operations, scenario triggers, and rule engine may occur concurrently and may conflict with each other. The system needs to handle these conflicts, determine the final state (off, on, 30% brightness) that the main light in the living room should be in, and ensure that the control instructions can be reliably sent and executed by the device. If the system cannot effectively coordinate these concurrent intentions and ensure the execution of the instructions, the state of the main light in the living room may not be adjusted according to the user's comprehensive expectations or may stay in an incorrect state.

[0030] In summary, control intentions from different sources may interfere with each other, which may cause frequent fluctuations in the device state or the device may stay in an unexpected state, seriously affecting the user experience and the availability of the system. Especially in the case of communication packet loss or device execution failure, the lack of an effective instruction execution guarantee mechanism will make automated tasks and user control unreliable, reducing the user's trust in the intelligent control system. In addition, complex scenario linkage and user-defined rules will be difficult to achieve their expected effects, limiting the function expansion and intelligent level of the smart home system.

[0031] Therefore, to solve this problem, the present application proposes a dynamic scheduling method and system for Bluetooth remote control switch timing tasks.

[0032] Specifically, please refer to Figure 1 , a dynamic scheduling method for Bluetooth remote control switch timing tasks, the method includes the steps of: S1: Obtain control intentions from at least one task source among timing tasks, user operations, scenario triggers, and user rule engines; S2: Convert the control intention into a desired state request, and manage the desired state of the target device according to the desired state request; S3: Receive the device state report of the target device, and manage the current actual state of the target device according to the device state report; S4: When the desired state is inconsistent with the current actual state and the target device is online, generate a control instruction corresponding to the desired state; S5: Obtain the actual state of the target device after executing the control instruction. When the actual state does not reach the desired state, regenerate the control instruction corresponding to the desired state and execute it until the actual state is consistent with the desired state.

[0033] Among them, the control intention refers to the control requirements or expected results generated for the target device from different task sources (timing tasks, user operations, scenario triggers, user rule engines), which can be implemented in a structured data format, such as a data packet containing device identification, expected action or state, etc. Information, which is mainly used to initially uniformly represent various heterogeneous control inputs.

[0034] The desired state request refers to the conversion of the original control intention into a standardized request representation of the final state of the target device within the system, which can be implemented by a data structure containing fields such as target device identification, desired state value, request source type, request priority, etc. It is mainly used to provide standardized input for subsequent state management and conflict adjudication.

[0035] Managing the expected state of a target device means that the system maintains a data structure or registry that records the state in which each target device is expected to be. This can be implemented using a data table in memory, a database record, or a distributed cache, and is mainly used to provide a clear target reference for device control.

[0036] A device status report refers to the information about the current working state of a target device sent actively or passively to the upper-level system. This can be implemented using data frames that conform to the device communication protocol, such as information including the device switch state, brightness value, color value, etc. It is mainly used to enable the system to obtain the real-time operating conditions of the device.

[0037] Managing the current actual state of a target device means that the system, based on the received device status report, updates and maintains in real time the data record of the actual state of the target device. This can be implemented using a data structure similar to that for expected state management and is mainly used to provide real-time data for checking the consistency between the expected state and the actual state. Generating a control instruction corresponding to the expected state means that the system, based on the difference between the expected state and the current actual state of the target device, as well as the device communication protocol and capabilities, constructs a command that can cause the device to migrate to the expected state. This can be implemented using control messages that conform to a specific Bluetooth communication protocol format and is mainly used to convert the abstract state difference into an operation executable by the device.

[0038] Obtaining the actual state of a target device after executing a control instruction means that after the system sends a control instruction, it obtains the latest state information of the device after the instruction is executed by receiving the device status report or actively querying, etc. This can be implemented by listening to the device-reported messages or sending status query instructions and is mainly used to verify the effect of the instruction execution.

[0039] When the actual state does not reach the expected state, regenerating and executing a control instruction corresponding to the expected state means that when the system detects that the device still does not reach the expected state after the instruction is executed, it does not abandon control but instead regenerates and sends a control instruction based on the current expected state and repeats this process. This can be implemented using loop execution, timed retry, or feedback-based adaptive control logic and is mainly used to improve the reliability of the instruction execution and ensure that the device finally reaches the expected state.

[0040] As a preferred embodiment, the solution of this application is specifically implemented as follows: In a smart home system, there is a Bluetooth smart socket (target device). The user sets a timing task through the mobile application, requiring the socket to be turned off at 10:00 p.m. At the same time, the user may manually turn off the socket through the mobile application at 9:30 p.m. The system receives the control intent of the timing task (turn off at 10:00) and the control intent of the user's manual operation (turn off at 9:30).

[0041] These intentions are converted into desired state requests. For example, a request manually closed by the user may have a higher priority. The system determines that the desired state of the socket becomes "closed" at 9:30 according to the conflict resolution rules (e.g., high-priority requests override low-priority requests).

[0042] At 9:30, the system checks the current actual state of the socket. If the socket is currently "on", it is found that the desired state (closed) is inconsistent with the actual state (on). The system generates a "close" control instruction and sends it to the socket. After the socket executes the instruction, it reports its state as "closed". The system receives the status report and updates the actual state to "closed". At this time, the actual state is consistent with the desired state, and the control process stops. If the socket fails to close successfully after sending the "close" instruction and the reported state is still "on", the system will detect that the actual state (on) is inconsistent with the desired state (closed), and will generate and send the "close" instruction again, repeating this process until the socket state becomes "closed" or the preset retry condition is reached.

[0043] The core innovation of this application lies in introducing the concepts of desired state and current actual state, and constructing an instruction generation based on state difference and a closed-loop retry execution mechanism based on state feedback, so as to realize the reliable execution of control instructions for Bluetooth remote control switch devices and the dynamic scheduling of tasks in an environment of concurrent multi-source dynamic tasks, achieving the effect of ensuring that the device finally reaches the desired state of the user.

[0044] In some of the above embodiments of this application, it is proposed to convert control intentions into desired state requests and manage the desired state of the target device according to the desired state requests to determine the final target state of the target device. However, in an environment of concurrent multi-user and multi-source dynamic tasks, multiple control intentions may be generated for the same target device at the same time. These intentions may come from different task sources and may conflict with each other. In this case, how to effectively process these multiple desired state requests for the same target device and determine a unique and final desired state from them is a problem not detailedly solved by the existing solutions, which may cause the system to be unable to determine the final target state of the device and affect the generation and execution of subsequent instructions.

[0045] Therefore, further, step S2 includes: S21: Convert the control intention into a desired state request including the target device identifier, desired state, request source type, and request priority; S22: Obtain the preset conflict resolution rules; S23: According to the preset conflict resolution rules, use the request source type and request priority to judge and resolve at least one desired state request for the same target device, and determine the desired state of the target device; wherein, the target device has a unique target device identifier.

[0046] Among them, the target device identifier refers to an identifier used to uniquely identify a specific target device in the network.

[0047] The desired state refers to a specific working state or configuration that the target device hopes to achieve, such as the on / off state of a switch device, the brightness value and color value of a light, etc., which can be represented by data types such as enumerated values, numerical values, and strings.

[0048] The request source type refers to the category of the task source that generates the control intention, used to distinguish the nature and importance of the request, which can be represented by predefined enumerated values, such as "timing task", "user operation", "scene trigger", "user rule engine", etc.

[0049] The request priority refers to a numerical value or level used to measure the importance of different requests. When there are multiple requests for the same device, it is one of the bases for conflict resolution, which can be implemented in the form of an integer value, a priority level identifier, etc.

[0050] Among them, the preset conflict resolution rules refer to a set of predefined logics or algorithms used to decide which request's desired state to finally adopt according to the attributes of the requests (such as request source type, request priority, timestamp) when there are conflicts between multiple desired state requests, which can be implemented in the form of a rule engine, decision tree, priority list, or custom function. Judgment and resolution refer to the process of evaluating, comparing, and selecting multiple desired state requests for the same target device according to the preset conflict resolution rules, and finally determining a unique and valid desired state as the current desired state of the target device.

[0051] In practical applications, assume there is a Bluetooth remote control switch device with a target device identifier of "SwitchA". The system may receive control intentions from different task sources at the same time: a timing task intention to set "SwitchA" to the "off" state at 10 pm; a user manually operates through a mobile application to set "SwitchA" to the "on" state; a scene trigger (such as "home mode") intention to set "SwitchA" to the "on" state.

[0052] In step S21, these control intentions are converted into desired state requests, each of which contains the identifier of "SwitchA", the desired state ("off" or "on"), the request source type ("timed task", "user operation", "scene trigger"), and a preset request priority (for example, the user operation has the highest priority, the scene trigger has the second highest priority, and the timed task has the lowest priority).

[0053] In step S22, the system obtains a preset conflict resolution rule. For example, the preset conflict resolution rule stipulates that "the user operation request has a higher priority than the scene trigger request, and the scene trigger request has a higher priority than the timed task request".

[0054] In step S23, the system receives multiple desired state requests for "SwitchA". According to the preset conflict resolution rule, the system compares the request source types and priorities of these requests. If a user operation request and a timed task request arrive simultaneously, since the user operation has a higher priority, the system will adjudicate and determine that the desired state of "SwitchA" is "on".

[0055] If a scene trigger request and a timed task request arrive simultaneously, since the scene trigger has a higher priority, the system will adjudicate and determine that the desired state of "SwitchA" is "on".

[0056] If user operation, scene trigger, and timed task requests arrive almost simultaneously, the system will determine the desired state of "SwitchA" as "on" according to the user operation request with the highest priority.

[0057] In this way, even if there are multiple conflicting requests, the system can determine a unique desired state according to the rules, avoiding state conflicts and uncertainties.

[0058] Furthermore, step S23 includes: S231: Receive at least one desired state request for the same target device; S232: Judge the validity of at least one desired state request, filter out the invalid desired state requests, and obtain a set of valid desired state requests; S233: According to the preset conflict resolution rule, and using the request source type, request priority, and time information of each request in the set of valid desired state requests, select an optimal desired state request from the set of valid desired state requests; S234: Determine the desired state of the optimal desired state request as the desired state of the target device.

[0059] As a specific implementation, the above method can be achieved as follows: The system maintains an expected state request queue for each target device. When a new expected state request is received, it is added to the queue of the corresponding device. Periodically or when the queue changes, the adjudication process is triggered. In the validity judgment step, a validity period can be defined for each request to check whether the timestamp of the request is within the validity period, or to check whether the parameters of the request conform to the preset data type and range constraints. Invalid requests can be directly removed from the queue. When selecting the optimal expected state request, a scoring mechanism or decision tree model can be used. For example, different base scores can be assigned to different request source types, and high-priority requests can get additional points, while the time information can be used to calculate a timeliness score, such as the newer the request, the higher the timeliness score. The conflict adjudication rule can be defined as follows: First, compare the scores corresponding to the request source types, and the one with the higher score takes precedence; if the scores are the same, then compare the priority scores, and the one with the higher score takes precedence; if the priority scores are also the same, then compare the timeliness scores, and the one with the higher score (i.e., the newer one) takes precedence. Finally, the request with the highest total score is selected as the optimal expected state request. After determining the optimal request, its expected state is updated to the state registry of the target device.

[0060] Through the above method, the present application can effectively filter out invalid expected state requests and avoid interference with the adjudication process. At the same time, through the refined adjudication by comprehensively using various factors such as request source type, request priority, and time information, the optimal expected state request can be accurately selected from multiple valid conflicting requests, thereby improving the system's ability and accuracy in handling concurrent task conflicts, and ensuring that the target device can reach the expected state that best conforms to the current control intention.

[0061] In some of the above embodiments of the present application, a method is proposed for managing the current actual state of a target device according to a device state report. Specifically, this may involve receiving information such as the switch state, brightness, and temperature reported by the device and recording it in the device state database of the system. This ensures that the system can understand the true operating state of the device. However, in the process of its implementation, simply understanding the current actual state of the device does not solve the problem of the dependency relationships between devices. That is, a scene mode or user-defined rule may include a series of control instructions that need to be executed in a specific order or at specific time intervals, forming a task sequence. For example, the "high temperature mode" may require that when the ambient temperature is detected to be higher than a certain set threshold and remains higher than this threshold for a certain period of time, the intelligent doors and windows are closed, and finally the cooling device is turned on. In this sequence, the execution of subsequent instructions depends on the completion of previous instructions or the satisfaction of specific conditions. If a subtask in the sequence, such as the instruction to close the intelligent device, fails to execute successfully, the system needs to decide whether to retry the instruction, skip it and continue with the subsequent tasks, or stop the entire task sequence, which increases the complexity of task management.

[0062] Therefore, further, after step S3, the following steps are also included: S31: Determine whether the current actual state meets a preset dependency trigger condition; S32: When the current actual state meets the preset dependency trigger condition, continuously monitor the current actual state of the target device; S33: When the current actual state of the target device continuously meets the preset dependency trigger condition within a preset monitoring period, trigger the dependency processing module to process tasks with dependency relationships.

[0063] The preset dependency trigger condition refers to a device state condition that is pre-configured and used to determine whether a dependency task needs to be triggered. It can be implemented in ways such as regular expressions, state thresholds, and state combinations.

[0064] The preset monitoring period refers to the duration or frequency of continuous monitoring, which is set in advance by technical personnel.

[0065] The dependency processing module refers to a functional unit responsible for processing dependency tasks triggered by changes in device states. It can be implemented in ways such as software modules, services, and processes. Tasks with dependency relationships refer to tasks whose execution depends on a specific device reaching a specific state, and they can be represented in ways such as task lists, task graphs, and rule chains.

[0066] Based on receiving and managing the current actual state of the target device, the technical solution of this application adds steps to judge and trigger the processing of dependent tasks based on this actual state. For example, in a smart home environment, there are a temperature detection device (target device), a smart door and window device (the first target device of the dependent task), and a smart cooling device (the second target device of the dependent task). The preset dependent trigger condition is that "the temperature detection device detects that the ambient temperature is higher than 30°C". The preset monitoring period is 10 minutes. The system receives the status report reported by the temperature detection device. For example, the current state of the temperature detection device is "detects that the ambient temperature is greater than 30°C". The system manages this state as the current actual state and judges that the current actual state meets the preset dependent trigger condition in the "high temperature mode". At this time, the system starts to continuously monitor the current actual state of the temperature monitoring device. Within the next 10 minutes, the system continuously receives the status report of the temperature detection device. If the temperature detected by the temperature detection device has always been higher than 30°C, then after the monitoring period ends, the system triggers the dependent processing module. The dependent processing module generates a desired state request to close the smart door and window according to the preset dependency relationship (close the smart door and window -> turn on the smart cooling device), and sends it to the task scheduling part of the system for subsequent processing. If within these 10 minutes, the state of the temperature detection device changes to "the temperature detection device detects that the ambient temperature is less than 30°C" again, it means that the temperature detection device may have an instantaneous misdetection. Therefore, the continuous monitoring is interrupted and the dependent task is not triggered.

[0067] Further, step S33 includes: S331: When the current actual state of the target device continuously meets the preset dependent trigger condition within the preset monitoring period, search for the preset task dependency relationship according to the target device identifier and the preset dependent trigger condition; S332: Determine at least one subsequent task whose current actual state depending on the target device meets the preset dependent trigger condition; S333: For each of the at least one subsequent task, obtain its corresponding subsequent target device identifier and subsequent desired state; S334: For each of the at least one subsequent task, generate a subsequent desired state request including the subsequent target device identifier, the subsequent desired state, the request source type, and the request priority.

[0068] Among them, the preset dependent trigger condition refers to the device state condition preset for judging whether it is necessary to trigger subsequent tasks, which can be defined by one or more device state attributes and their corresponding values or ranges. For example, it can be that the switch state of a certain device is "on", or the value of a certain sensor is greater than a certain threshold.

[0069] Among them, the preset task dependency relationship refers to a data structure that is pre-configured and describes the association rules between device state changes and subsequent tasks. It can be stored in the form of a mapping table, a rule list, or a graph structure, and is used to associate a specific device identifier and a dependency trigger condition with one or more subsequent task information that needs to be executed.

[0070] Among them, the subsequent task refers to an operation or control instruction that needs to be automatically executed after a specific state of a certain device meets the dependency trigger condition, and it can be described by setting the expected state of another or the same device.

[0071] Among them, the subsequent target device identifier refers to the unique identifier of the target device to be controlled or operated by the subsequent task, and it can be implemented by using the MAC address, UUID, or the ID allocated within the system of the device.

[0072] Among them, the subsequent expected state refers to the target state that the subsequent target device should reach after the subsequent task is executed, and it can be represented by one or more device state attributes and their corresponding values. For example, it can be that the brightness of the light is set to 50%, or the temperature of the air conditioner is set to 26°C.

[0073] Among them, the subsequent expected state request refers to a control request that converts the subsequent task into a standard format that can be uniformly processed by the system, and it can be implemented by using a structured data packet that includes the target device identifier, the expected state, the request source type, and the request priority.

[0074] In a specific embodiment, assume that there is a temperature monitoring device (target device), intelligent door and window devices (first subsequent target devices), and an intelligent cooling device (second subsequent target devices) in the system. The preset dependency trigger condition is set to the current actual state of the temperature sensor "temperature > 30°C", and the preset monitoring period is set to 10 minutes. The preset task dependency relationship is configured as follows: when the state of the temperature sensor with device ID "temp_sensor_001" continuously satisfies "temperature > 30°C" for 10 minutes, trigger the subsequent tasks: set the desired states of the intelligent door and window devices with device IDs "door_001", "door_002", "window_001", "window_002" to "closed", and set the desired state of the intelligent cooling device with device ID "fan_001" to "on". The request source type is "Dependency", and the request priority is 80. When the system receives a report from "temp_sensor_001" that its temperature is 29°C, it determines that the dependency trigger condition is satisfied and starts continuous monitoring. If within the next 10 minutes, the temperature reports of "temp_sensor_001" are always greater than 30°C, then the dependency processing is triggered. The system looks up the preset task dependency relationship based on the device identifier "temp_sensor_001" and the dependency trigger condition "temperature > 30°C" to determine that the subsequent tasks are to control "door_001", "door_002", "window_001", "window_002", and "fan_001". The system obtains the subsequent target device identifiers "door_001", "door_002", "window_001", "window_002" and the subsequent desired state "closed"; the subsequent target device identifier "fan_001", and the subsequent desired state "on". Finally, the system generates a subsequent desired state request for this subsequent task. This request is then submitted to the desired state management module of the system for processing.

[0075] Among them, in practical applications, when the task is executed to close the intelligent door and window devices, the intelligent door and window devices then become the target devices, and the intelligent cooling device is the subsequent target device dependent on the intelligent door and window devices. The monitoring period of the intelligent door and window devices is set to 10 seconds. After the intelligent door and window devices are closed for 10 seconds, the intelligent cooling device is controlled to turn on.

[0076] Further, step S4 includes: S41: When the desired state is inconsistent with the current actual state and the target device is online, obtain the device capability information of the target device; S42: Determine the control operation and operation parameters that the target device needs to execute according to the current actual state, desired state, and device capability information; S43: Generate a control instruction that complies with the communication protocol and format requirements of the target device based on the determined control operation and operation parameters.

[0077] Among them, the device capability information refers to data describing the characteristics of the target device, such as the functions supported by the target device, instruction types, parameter ranges, as well as communication protocol and format requirements. It can be implemented by means of device configuration files pre-configured in the system, actively reported by the device, or the system querying the device.

[0078] Among them, the control operation refers to the specific actions that need to be executed to make the target device reach the desired state from the current actual state. It can include functional operations supported by the device, such as turning on, turning off, setting brightness, setting color, adjusting color temperature, etc. Among them, the operation parameter refers to the specific value or configuration related to the control operation, which can include brightness value, color value (such as RGB value), color temperature value, timing duration, etc., and is used to precisely define the execution details of the control operation.

[0079] Among them, the communication protocol and format requirements refer to the rules and data structures followed by the target device for data exchange. It can include specific service and characteristic definitions in the Bluetooth GATT protocol, custom binary packet structures, specific command string formats, etc.

[0080] By fully considering the device capability information, current actual state, and desired state of the target device when generating the control instruction, the method of the present application can determine more accurate control operations and operation parameters that are more in line with the actual situation of the device. Further, based on these determined operations and parameters, and combined with the communication protocol and format requirements specific to the device, an instruction is generated to ensure that the generated instruction can be correctly parsed and executed by the target device. This effectively solves the problem of invalid instructions or execution failures caused by generating general instructions only based on the desired state, and significantly improves the execution success rate of the control instruction and the accuracy of controlling the state of the target device.

[0081] Further, step S42 includes: S421: Determine the state gap that needs to be bridged according to the difference between the current actual state and the desired state; S422: Determine one or more control instruction types that can bridge the state gap according to the state gap and the control instruction types supported in the device capability information; S423: Determine the control operation and operation parameters that the target device needs to execute according to one or more control instruction types and the corresponding parameter ranges in the device capability information.

[0082] Among them, the state gap refers to the specific differences between the current actual state and the expected state, such as inconsistencies in attributes like the device switch state, brightness level, color value, etc. Device capability information refers to the functions and the set of supported control instructions of the target device, including the type, name of each instruction, and the acceptable parameter range or enumerated values. The control instruction type refers to the specific operation categories that the device can recognize and execute, such as "turn on", "turn off", "set brightness", "set color", etc. The parameter range refers to the set of parameter values allowed for a specific control instruction type. For example, the parameter range of the brightness instruction may be from 0 to 100, and the parameter range of the color instruction may be a specific set of color codes. The control operation refers to the specific actions that the target device needs to execute according to the determined control instruction type and parameters. The operation parameter refers to the specific numerical value or setting associated with the control operation, used to precisely specify the details of the operation.

[0083] This solution provides a systematic method to solve the problem of how to drive the device from the current actual state to the expected state by refining the process of determining the control operation and operation parameters into a series of logical steps. First, by comparing the current actual state with the expected state, the specific differences between the two are clarified, that is, the "state gap" that needs to be bridged. This gap is the direct basis for determining the subsequent control operation because all operations are aimed at eliminating or reducing this gap. Then, using the determined state gap and combining it with the control instruction types actually supported by the device in the device capability information, it is determined which instruction types can effectively bridge this gap. This ensures that the selected instruction types are understandable and executable by the device and are effective for the current state differences. Finally, after determining the instruction types to be used, further refer to the parameter ranges allowed for these instruction types in the device capability information to determine the specific control operation and operation parameters. This makes the generated instructions not only correct in type but also the parameter values within the effective working range of the device, so as to accurately adjust the device to the expected state. Through this series of steps, this solution can accurately and effectively determine the specific control operations and parameters required to drive the device to the expected state according to the device's current state, expected state, and specific capabilities. The combination of this systematic determination process with the aforementioned steps of managing the current actual state according to the device state report and managing the expected state according to the expected state request enables the entire dynamic scheduling method to respond more precisely to state changes, generate more effective control instructions, improve the accuracy and reliability of instruction generation, and thus better achieve the consistency between the device state and the expected state.

[0084] For example, consider a smart bulb as the target device. Assume its current actual state is: the switch state is off and the brightness is 0%. The desired state is: the switch state is on and the brightness is 50%. The device capability information indicates that the bulb supports control instruction types such as "turn on", "turn off", "set brightness", etc., and the parameter range of the "set brightness" instruction is from 0 to 100. First, based on the differences between the current actual state (off, 0% brightness) and the desired state (on, 50% brightness), determine that the state gaps that need to be bridged include: the switch state needs to change from off to on, and the brightness needs to change from 0% to 50%. Then, based on these state gaps and the supported control instruction types in the device capability information ("turn on", "turn off", "set brightness"), determine the control instruction types that can bridge these gaps. To achieve the change from off to on, the "turn on" instruction type is needed; to achieve the change from 0% to 50% brightness, the "set brightness" instruction type is needed. Therefore, the determined control instruction types that can bridge the state gaps include "turn on" and "set brightness". Finally, based on the determined control instruction types ("turn on", "set brightness") and the corresponding parameter ranges in the device capability information (the parameter range of "set brightness" is 0 - 100), determine the control operations and operation parameters that the target device needs to execute. For the "turn on" instruction type, the control operation can be to execute the "turn on" action, usually without parameters or with fixed parameter values; for the "set brightness" instruction type, based on the desired brightness value of 50% and the parameter range of 0 - 100, determine that the control operation is "set brightness" and the operation parameter is 50. The finally determined combination of control operations and operation parameters can be one or more, for example, first execute the "turn on" operation, and then execute the "set brightness" operation with the parameter 50 attached.

[0085] Furthermore, step S5 includes: S51: When obtaining the actual state of the target device after executing the control instruction and the actual state does not reach the desired state, regenerate the control instruction corresponding to the desired state and execute it, and continuously monitor the desired state registry of the target device during the execution process; S52: When it is monitored that the desired state corresponding to the desired state registry changes, stop the current instruction retry or status query process for the desired state; S53: Obtain the desired state after the desired state registry is updated, and regenerate and send the control instruction corresponding to the updated desired state according to the updated desired state.

[0086] This solution introduces a mechanism for continuously monitoring the desired state registry of the target device during the retry process to address the problem that the desired state may change during the retry when the actual state of the device does not reach the desired state after executing the control instruction.

[0087] When the actual state of the device still fails to reach the expected state after the instruction execution, the system will regenerate and execute the control instruction corresponding to the current expected state. Meanwhile, while executing this retry process, the system continuously monitors the expected state registry corresponding to the target device. Continuously monitoring the expected state registry enables the system to perceive in real time whether a new control intention has caused a change in the expected state. When it is found through continuous monitoring that the expected state recorded in the expected state registry has changed, the system will immediately stop the current instruction retry or status query process based on the old expected state. This stop action prevents the system from continuing to execute instructions that do not match the latest expectation, thereby preventing ineffective retries and possible conflicts with the new expectation. After stopping the old retry process, the system obtains the updated latest expected state in the expected state registry. Then, according to this latest expected state, it regenerates the corresponding control instruction and sends it to the target device. This ensures that the system can promptly respond to the latest requirements of the user or the system for the device state, enabling the device to ultimately tend towards the latest and effective expected state, and improving the control accuracy and reliability of the system in a dynamically changing environment.

[0088] Further, after step S51, it further includes: S54: When it is monitored that the expected state corresponding to the expected state registry has not changed, determine whether the target device is online; S55: When the target device is online, according to a preset retry policy, the retry policy is based on a preset retry count limit or time limit, perform at least one of the following operations: Regenerate the control instruction corresponding to the expected state and send it; Initiate a status query for the current actual state of the target device; S56: Continuously execute the operations of step S55 until the actual state is consistent with the expected state, or the preset retry count limit or time limit is reached; S57: When the target device is offline, suspend the instruction retry or status query process for the target device.

[0089] After the device executes the instruction and the actual state fails to reach the expected state, and the system monitors that the expected state recorded in the expected state registry has not changed, the system will further determine the current online state of the target device. If the target device is in an online state, the system will take actions according to a preset retry policy. This retry policy can limit the total number of retries or the total time length to avoid infinite attempts.

[0090] Please refer to Figure 2 、 Figure 3 A dynamic scheduling system for Bluetooth remote control switch timing tasks, applied to the steps of any of the above methods, the system includes: Acquisition module 201: Obtain control intentions from at least one task source among timed tasks, user operations, scenario triggers, and user rule engines; First management module 202: Convert control intentions into desired state requests and manage the desired state of the target device according to the desired state requests; Second management module 203: Receive the device status report of the target device and manage the current actual state of the target device according to the device status report; Instruction generation module 204: Generate control instructions corresponding to the desired state when the desired state is inconsistent with the current actual state and the target device is online; Execution module 205: Obtain the actual state of the target device after executing the control instructions. When the actual state does not reach the desired state, regenerate the control instructions corresponding to the desired state and execute them until the actual state is consistent with the desired state.

[0091] Among them, the acquisition module 201 refers to the unit responsible for collecting external or internally generated control requirements, which can be implemented by means such as message queues, event listeners, or API interfaces.

[0092] The first management module 202 refers to the unit responsible for processing control intentions and maintaining the target state of the device, which can be implemented by means such as state machines, databases, or memory registries.

[0093] The second management module 203 refers to the unit responsible for receiving device feedback and maintaining the real state of the device, which can be implemented by means such as message subscriptions, polling mechanisms, or state synchronization services.

[0094] The instruction generation module 204 refers to the unit responsible for generating specific control commands according to the state differences, which can be implemented by means such as rule engines, template engines, or protocol encoders.

[0095] The execution module 205 refers to the unit responsible for sending control commands and processing execution results, which can be implemented by means such as communication clients, task schedulers, or retry managers.

[0096] This system is implemented by decomposing the functions of the dynamic scheduling method into multiple collaborative modules. The acquisition module 201, as the entry of the system, is responsible for aggregating control intentions from different task sources, such as manual operations of users on mobile applications, triggering of preset timed tasks, sensor data meeting scenario conditions, or outputs of user-defined rule engines. These control intentions are passed to the first management module 202.

[0097] The first management module 202 receives these intents and normalizes them into desired state requests, such as specifying that the switch state of a certain device should be "on" or the brightness should be "50%". The core function of this module is to manage the desired states of target devices, which means it needs to handle multiple potentially conflicting desired state requests and determine the single desired state that the device should ultimately reach based on preset rules (such as the priority or timestamp of the request source).

[0098] Meanwhile, the second management module 203 independently receives real-time status reports from the target device and maintains the current actual state of the device. The instruction generation module continuously monitors the difference between the desired state maintained by the first management module 202 and the current actual state maintained by the second management module 203.

[0099] When it is found that there is a discrepancy between the two and the target device is in an online state, the instruction generation module 204 is triggered. It generates control instructions that can bridge this difference based on the difference between the desired state and the actual state, combined with the specific capability information of the device. The generated control instructions are then sent to the execution module 205.

[0100] The execution module 205 is responsible for sending the control instructions to the target device for execution. The execution module not only sends the instructions but also monitors the results after the instructions are executed, such as by receiving the device's status report or actively querying the device status. If the actual state of the device still does not reach the desired state after the device executes the instructions, the execution module 205 will trigger the process of regenerating and executing the control instructions. This process will continue until the actual state of the device is consistent with the desired state or stops under specific conditions (such as a change in the desired state or reaching the retry limit).

[0101] Through this modular design and clear data flow, the system can effectively handle multi-source control intents, precisely manage device states, and ensure the reliable execution of control instructions, thus providing a solid foundation for the dynamic scheduling method. The combination of this system architecture and method steps enables the clear implementation of complex scheduling logic and improves the stability and reliability of the system.

[0102] In this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0103] The above description is only for the embodiments of this application and is not intended to limit the protection scope of this application. For those skilled in the art, this application can have various changes and modifications. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this application shall be included within the protection scope of this application.

Claims

1. A dynamic scheduling method for Bluetooth remote control switch timing tasks, characterized in that, The method includes the steps of: S1: Obtain a control intention from at least one task source among a timed task, a user operation, a scenario trigger, and a user rule engine; S2: Convert the control intention into a desired state request, and manage the desired state of the target device according to the desired state request; S3: Receive a device status report of the target device, and manage the current actual state of the target device according to the device status report; S4: When the desired state is inconsistent with the current actual state and the target device is online, generate a control instruction corresponding to the desired state; S5: Obtain the actual state of the target device after executing the control instruction. When the actual state does not reach the desired state, regenerate and execute a control instruction corresponding to the desired state until the actual state is consistent with the desired state.

2. The dynamic scheduling method for the timing task of the Bluetooth remote control switch according to claim 1, wherein Step S2 includes: S21: Convert the control intention into a desired state request including a target device identifier, a desired state, a request source type, and a request priority; S22: Obtain a preset conflict adjudication rule; S23: According to the preset conflict adjudication rule, use the request source type and the request priority to judge and adjudicate at least one desired state request for the same target device, and determine the desired state of the target device; wherein, the target device has a unique target device identifier.

3. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 2, characterized in that, Step S23 includes: S231: Receive at least one desired state request for the same target device; S232: Perform a validity judgment on the at least one desired state request, filter out invalid desired state requests, and obtain a set of valid desired state requests; S233: According to the preset conflict adjudication rule, and use the request source type, the request priority, and time information of each request in the set of valid desired state requests to select an optimal desired state request from the set of valid desired state requests; S234: Determine the desired state of the optimal desired state request as the desired state of the target device.

4. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 1, characterized in that, After step S3, it further includes: S31: Judge whether the current actual state meets a preset dependency trigger condition; S32: When the current actual state meets the preset dependency trigger condition, continuously monitor the current actual state of the target device; S33: When the current actual state of the target device continuously meets the preset dependency trigger condition within a preset monitoring period, trigger the dependency processing module to process tasks with a dependency relationship.

5. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 4, characterized in that Step S33 includes: S331: When the current actual state of the target device continuously meets the preset dependency trigger condition within a preset monitoring period, according to the target device identifier and the preset dependency trigger condition, search for a preset task dependency relationship; S332: Determine at least one subsequent task that depends on the current actual state of the target device meeting the preset dependency trigger condition; S333: For each of the at least one subsequent task, obtain its corresponding subsequent target device identifier and subsequent expected state; S334: For each of the at least one subsequent task, generate a subsequent expected state request that includes the subsequent target device identifier, the subsequent expected state, the request source type, and the request priority.

6. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 1, characterized in that Step S4 includes: S41: When the expected state is inconsistent with the current actual state and the target device is online, obtain the device capability information of the target device; S42: Based on the current actual state, the expected state, and the device capability information, determine the control operation and operation parameters that the target device needs to execute; S43: Based on the determined control operation and operation parameters, generate a control instruction that conforms to the communication protocol and format requirements of the target device.

7. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 6, characterized in that, Step S42 includes: S421: Based on the difference between the current actual state and the expected state, determine the state gap that needs to be bridged; S422: Based on the state gap and the types of control instructions supported in the device capability information, determine one or more types of control instructions that can bridge the state gap; S423: Based on the one or more types of control instructions and the corresponding parameter ranges in the device capability information, determine the control operation and operation parameters that the target device needs to execute.

8. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 1, characterized in that, Step S5 includes: S51: When obtaining the actual state of the target device after executing the control instruction and the actual state does not reach the expected state, regenerate and execute a control instruction corresponding to the expected state, and continuously monitor the expected state registry of the target device during the execution process; S52: When it is detected that the expected state corresponding to the expected state registry changes, stop the current instruction retry or status query process for the expected state; S53: Obtain the updated expected state of the expected state registry, and based on the updated expected state, regenerate and send a control instruction corresponding to the updated expected state.

9. A dynamic scheduling method for Bluetooth remote control switch timing tasks according to claim 8, characterized in that, After step S51, it further includes: S54: When it is detected that the expected state corresponding to the expected state registry does not change, determine whether the target device is online; S55: When the target device is online, according to a preset retry policy, the retry policy is based on a preset retry count limit or time limit, perform at least one of the following operations: Regenerate and send a control instruction corresponding to the expected state; Initiate a status query for the current actual state of the target device; S56: Continuously execute the operations in step S55 until the actual state is consistent with the expected state, or the preset retry count limit or time limit is reached; S57: When the target device is offline, pause the instruction retry or status query process for the target device.

10. A Bluetooth remote control switch timing task dynamic scheduling system, characterized in that Applied to the steps of the method according to any one of claims 1-9 above, the system includes: An acquisition module: acquire a control intention from at least one task source among a timing task, a user operation, a scenario trigger, and a user rule engine; The first management module: converts the control intention into a desired state request, and manages the desired state of the target device according to the desired state request; The second management module: receives the device status report of the target device, and manages the current actual state of the target device according to the device status report; The instruction generation module: generates a control instruction corresponding to the desired state when the desired state is inconsistent with the current actual state and the target device is online; The execution module: obtains the actual state of the target device after executing the control instruction, and when the actual state does not reach the desired state, regenerates and executes a control instruction corresponding to the desired state until the actual state is consistent with the desired state.

Images