A linkage rule matching method based on an internet of things scene and an electronic device

Abstract

The application discloses a kind of linkage rule matching method and electronic equipment based on Internet of Things scene, the method includes: receiving and analyzing Internet of Things trigger event, and one or more event source identifications are extracted from the Internet of Things trigger event, the Internet of Things trigger event is the event of triggering linkage rule matching;According to one or more event source identifications, determine the corresponding to-be-matched linkage rule of the Internet of Things trigger event from rule cache;According to the trigger type configured in the to-be-matched linkage rule, call trigger matcher to perform type matching verification;If the type matching verification passes, perform condition grouping matching verification to the to-be-matched linkage rule, and the condition grouping matching verification includes two layers of "or-and" logic.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method and electronic device for matching linkage rules based on IoT scenarios. Background Technology

[0002] With the rapid development and large-scale deployment of the IoT smart hardware industry, the needs for device linkage in scenarios such as smart homes, smart offices, and industrial IoT are becoming increasingly complex and diverse. As a core functional module of the IoT platform, the ease of use, flexibility, and reliability of the linkage rule engine directly determine the user experience and market competitiveness of the platform. However, existing linkage rule implementation solutions generally suffer from technical problems such as high configuration thresholds, difficulty in eliminating semantic ambiguities, and insufficient scalability. These issues prevent them from adapting to the rapidly iterating business needs and increasingly prevalent intelligent interaction modes in IoT scenarios, becoming a key bottleneck restricting the large-scale application and intelligent upgrade of IoT platforms.

[0003] Especially against the backdrop of the rapid rise of large language model intelligent agents, the semantic ambiguity problem of existing technologies has been further amplified, becoming a core obstacle restricting the deep integration of intelligent agents and IoT platforms. Future IoT smart hardware platforms will gradually support the automatic generation and distribution of linkage rules to IoT devices by large language model intelligent agents based on user natural language commands. However, Boolean logic described in natural language has inherent semantic ambiguity; the same natural language expression may correspond to multiple completely different logical combinations, easily leading to the execution results of rules generated by the intelligent agent not matching user expectations and causing erroneous device control operations. Summary of the Invention

[0004] In view of the above-mentioned prior art, the present invention provides a linkage rule matching method and electronic device based on Internet of Things scenarios, which mainly solves the technical problems existing in the background art.

[0005] To achieve the above objectives, the technical solution of this invention is implemented as follows: The first aspect of this invention discloses a method for matching linkage rules based on an Internet of Things (IoT) scenario, the method comprising: Receive and parse IoT trigger events, and extract one or more event source identifiers from the IoT trigger events, wherein the IoT trigger events are events that trigger linkage rule matching; Based on one or more event source identifiers, determine the linkage rule to be matched corresponding to the IoT trigger event from the rule cache; Based on the trigger type configured in the linkage rule to be matched, the trigger matcher is invoked to perform type matching verification; If the type matching verification passes, a condition grouping matching verification is performed on the linkage rule to be matched. The condition grouping matching verification includes two layers of "OR-AND" logic. If the conditional grouping matching verification passes, the linkage action corresponding to the linkage rule to be matched is executed.

[0006] Optionally, the IoT triggering events include device attribute reporting events, device event reporting events, device status change events, timed triggering events, and external triggering events received through a preset API interface.

[0007] Optionally, the event source identifier includes at least one of the following: product identifier, device identifier, gateway identifier, subsystem identifier, spatial area identifier, and user identifier.

[0008] Optionally, determining the matching linkage rule corresponding to the IoT triggering event from the rule cache based on one or more event source identifiers includes: A mapping relationship between an index key and a candidate rule list set is pre-established, and the mapping relationship is stored in the rule cache. The index key is a single event source identifier or a preset combination of multiple event source identifiers. The event source identifiers extracted from the IoT-triggered events are combined to generate a target index key; The target index key is used to perform a matching search in the rule cache to determine a candidate rule list, which contains at least one linkage rule to be matched.

[0009] Optionally, the step of calling the trigger matcher to perform type matching verification according to the trigger type configured in the linkage rule to be matched includes: For each linkage rule to be matched, obtain the pre-configured trigger array, and traverse each trigger in the trigger array in a preset order to extract its type identifier; From the pre-built matcher mapping table, query the trigger matcher corresponding to the type identifier of the trigger; The matching method of the trigger matcher is invoked, and the IoT trigger event is used as an input parameter to perform basic trigger condition judgment; If the basic trigger condition of the current trigger does not match, continue to traverse the next trigger in the trigger array. If all triggers in the trigger array have been traversed and do not match, the type matching check of the linkage rule to be matched is determined to be unsuccessful. If the basic trigger condition of any trigger matches, the type matching check of the linkage rule to be matched is determined to be successful.

[0010] Optionally, conditional grouping matching verification is performed on the linked rules to be matched, including: Based on the linked rules to be matched, a condition grouping array is established. The condition grouping array contains zero or at least one condition group, and each condition group contains zero or at least one condition. All condition groups in each condition grouping array are logical OR relations, and all conditions in each condition group are logical AND relations. When the condition grouping array contains at least one condition group, traverse each condition group in the condition grouping array; When the traversed condition group contains at least one condition, the IoT trigger event is matched and calculated with each condition in the traversed condition group one by one to obtain the satisfaction status of each condition. If all conditions in any condition group are met, the condition group matching check is considered successful, and the traversal of the remaining condition groups and their corresponding trigger arrays is stopped. When the condition grouping array is traversed and no condition group has all conditions satisfied, the condition grouping matching check is determined to have failed.

[0011] Optionally, if the number of condition groups in the condition grouping array is zero, the condition grouping matching verification is determined to have failed, and the process continues to traverse the next trigger in the array of triggers for the linkage rules to be matched.

[0012] Optionally, the IoT trigger event is matched and calculated one by one with each condition in the traversed condition group to obtain the satisfaction status of each condition, specifically including: For each condition, extract the operator enumeration value configured for it; Verify the validity of the operator enumeration value. If it is valid, construct the expression variable corresponding to the condition. Otherwise, mark the condition as not satisfied. If the parameter values ​​required for the expression variable cannot be obtained from the IoT trigger event, the expression calculation is performed; If the parameter values ​​required for the expression variable are obtained from the IoT trigger event, and the parameter values ​​are all numbers and involve number comparison operations, the parameter values ​​are converted into numeric types before the expression calculation is performed, and the satisfaction status of each condition is obtained based on the calculation result.

[0013] Optionally, if the conditional grouping matching verification passes, the execution of the linkage action corresponding to the linkage rule to be matched includes: Determine whether the currently matched linkage rule has a preset linkage action configured; If a preset linkage action is configured, obtain the action executor corresponding to the preset linkage action; If the action executor is obtained, the action executor is invoked to execute the preset linkage action, and the execution log is recorded before traversing the next linkage rule to be matched.

[0014] A second aspect of the present invention discloses an electronic device, including a processor and a memory, the memory storing a plurality of instructions; the processor loads instructions from the memory to execute steps in the linkage rule matching method based on the Internet of Things scenario as described in any of the preceding claims.

[0015] The beneficial effects of this invention are as follows: By setting type matching and condition grouping matching checks, the inherent semantic ambiguity caused by unclear logical priorities in expressions such as "A and B or C" in natural language is eliminated at the data structure level. This ensures that the execution logic and execution result of each linkage rule are unique and predictable, solving the technical problems of uncertain rule execution results and easy logical deviations in existing technologies. Compared with the existing methods of distinguishing logical relationships, this invention does not require any additional semantic interpretation or grammatical conventions. The rule engine performs matching checks according to the fixed rule that "condition groups are logically ORed and all conditions within the same condition group are logically ANDed." This eliminates rule execution errors caused by different understandings of the same logical expression by different personnel or semantic parsing deviations in large language models. At the same time, it greatly reduces the difficulty of rule debugging, troubleshooting, and verification. Operation and maintenance personnel can directly locate logical problems through the structure of condition groups without having to sort out complex nested logical relationships. Furthermore, when adding new condition types, action types, or trigger types, this invention only requires implementing the corresponding matcher or executor interface and completing registration; there is no need to modify the parsing, matching, and execution logic of the condition groups, ensuring the platform's backward compatibility and continuous scalability. At the same time, this structure can adapt to the complex linkage needs of most IoT scenarios, such as smart homes, smart offices, industrial IoT, and smart security, demonstrating good versatility and applicability. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only preferred embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of the application architecture of the linkage rule matching method based on the Internet of Things scenario in an embodiment of the present invention; Figure 2 This is a schematic diagram of the overall process of the linkage rule matching method based on the Internet of Things scenario in an embodiment of the present invention; Figure 3This is a schematic diagram of the process of calling the trigger matcher to perform type matching verification in an embodiment of the present invention; Figure 4 This is a schematic diagram of the overall process of conditional grouping matching verification in an embodiment of the present invention; Figure 5 This is a schematic diagram of the matching calculation process for a single condition in an embodiment of the present invention; Figure 6 This is a flowchart illustrating the execution of the linkage action corresponding to the linkage rule to be matched in an embodiment of the present invention. Detailed Implementation

[0018] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. In the following description, the expression "some embodiments" refers to a subset of all possible embodiments; however, it should be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with each other without conflict.

[0019] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0020] It should be understood that the present invention can be embodied in various forms and should not be construed as being limited to the embodiments set forth herein. Rather, providing these embodiments will make the disclosure thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Furthermore, the terminology used herein is intended only to describe particular embodiments and is not intended to limit the invention. When used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “compose” and / or “comprising,” when used in this specification, identify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups. When used herein, the term “and / or” includes any and all combinations of the associated listed items.

[0021] It should also be noted that when an element is referred to as being "fixed to" another element, it can be directly attached to the other element or there may be an intervening element. When an element is referred to as being "connected to" another element, it can be directly connected to the other element or there may be an intervening element. The terms "vertical," "horizontal," "inner," "outer," "left," "right," and similar expressions used herein are for illustrative purposes only and do not represent the only possible implementation.

[0022] To fully understand this invention, a detailed structure will be presented in the following description to illustrate the technical solution proposed by this invention. Optional embodiments of the invention are described in detail below; however, in addition to these detailed descriptions, the invention may have other embodiments.

[0023] The linkage rule matching method based on the Internet of Things (IoT) scenario provided in this application embodiment is applied to a rule engine. The rule engine, as the core of the IoT linkage system, is responsible for the unified management of all linkage rules within the platform and for implementing trigger event reception, rule matching verification, and linkage action execution. See also... Figure 1 The diagram shows the architecture of a rule engine, which includes a message input layer, a rule matching layer, and an action execution layer.

[0024] In this embodiment, the message input layer of the rule engine first receives and parses various IoT trigger events that can trigger the linkage rule matching process, and extracts one or more event source identifiers from the parsed structured event data to identify the event generating entity. The rule matching layer of the rule engine searches in the pre-built rule cache based on one or more extracted event source identifiers to determine the linkage rule to be matched corresponding to the current IoT trigger event. The rule cache is a high-speed storage medium used to store all linkage rules in the platform and build a fast retrieval index. Targeted retrieval through event source identifiers can effectively avoid traversing all rules. For each retrieved linkage rule to be matched, the rule engine calls the corresponding trigger matcher to perform type matching verification based on the trigger type pre-configured for that rule. The trigger matcher is an independent functional unit that encapsulates the basic verification logic for a specific trigger type. Type matching verification verifies whether the current trigger event meets the basic trigger qualifications set by the rule. Only linkage rules that pass type matching verification will proceed to the subsequent matching verification stage. If a linkage rule passes type matching verification, the rule engine will perform condition grouping matching verification on that rule. If a linkage rule passes condition grouping matching verification, the rule engine's action execution layer will execute the linkage action corresponding to that linkage rule, completing the linkage control flow corresponding to this trigger event. The linkage action is a pre-configured operation that needs to be executed after all matching conditions are met, used to achieve automatic linkage between IoT devices and automatic triggering of system functions.

[0025] In this embodiment, a linkage rule matching method based on an Internet of Things (IoT) scenario is provided, such as... Figure 2 As shown, the specific process of this linkage rule matching method based on the Internet of Things scenario can be as follows: S1. Receive and parse IoT trigger events, and extract one or more event source identifiers from the IoT trigger events.

[0026] The IoT trigger event is an event that triggers the matching of linkage rules. It carries the basic information required to trigger linkage. According to at least one embodiment of this disclosure, the IoT trigger event can be a device attribute reporting event. The device attribute reporting event is an event generated when an IoT terminal device actively uploads its own operating parameters and status information to the rule engine platform according to a preset period or when its own operating attributes change. The event includes the device's unique identifier and the corresponding attribute parameter data. After receiving and parsing such an event, the rule engine can extract the corresponding device identifier and attribute parameters as the basic data for rule matching.

[0027] Alternatively, according to at least one embodiment of this disclosure, the IoT triggering event may be a device event reporting event. The device event reporting event is a non-periodic business event that an IoT device actively reports to the rule engine when a specific business action occurs or a preset triggering condition is met. Such events typically correspond to a single behavior trigger of the device, such as device alarm reporting, button operation triggering, sensor threshold exceeding limit reporting, etc. The event carries an event type identifier and corresponding business-related data.

[0028] Alternatively, according to at least one embodiment of this disclosure, the IoT triggering event can be a device state change event, which is an event generated when the overall operating state of the IoT device undergoes a substantial transition, such as switching between online and offline states, changing the device's operating mode, or transitioning between a fault state and a normal state. This type of event focuses on the change in the overall state of the device rather than a change in a single attribute value. Alternatively, according to at least one embodiment of this disclosure, the IoT triggering event may be a timed triggering event, which is a triggering event automatically generated by the rule engine when a specified time node or time period is reached, based on a preset time configuration strategy. This type of event does not require the IoT device to actively report, but is generated by the internal scheduling of the rule engine.

[0029] Alternatively, according to at least one embodiment of this disclosure, the IoT triggering event may be an external triggering event received through a preset API interface. Such an event is formed by a triggering instruction transmitted to the rule engine by a third-party business system, external management platform or other IoT platform in accordance with an agreed data format via the preset API interface.

[0030] According to at least one embodiment of this disclosure, the event source identifier includes at least one of a product identifier, a device identifier, a gateway identifier, a subsystem identifier, a spatial area identifier, and a user identifier.

[0031] For example, according to at least one embodiment of this disclosure, when the IoT trigger event is a device attribute reporting event, the identification information corresponding to the preset fields is extracted from the event structure, which includes at least a device identifier and a product identifier. The device identifier is a unique identity identifier of the IoT terminal device, used to uniquely locate the source device of the trigger event. The product identifier is a unified identifier of the product series to which the device belongs, used to associate all devices under the same product, such as product ID, device ID, etc.

[0032] Alternatively, according to at least one embodiment of this disclosure, when the IoT trigger event is a device state change event, in addition to extracting the device identifier and product identifier, a gateway identifier can also be extracted. When the device is a sub-device attached to a gateway, the gateway identifier is used to identify the gateway device to which the sub-device is connected. The rule engine can filter out the linkage rules associated with the gateway through the gateway identifier. At the same time, if the device belongs to a device deployed in a specific spatial area, a spatial area identifier can also be extracted from the event. The spatial area identifier is used to identify the physical space or logical area where the device is located.

[0033] Alternatively, according to at least one embodiment of this disclosure, when the IoT trigger event is a device event reporting event, the device identifier, product identifier, and subsystem identifier are extracted from it. The subsystem identifier is used to identify the IoT subsystem to which the device belongs, such as a security subsystem, energy consumption subsystem, environmental monitoring subsystem, etc. Through the subsystem identifier, the rule engine can filter out the linkage rules within the corresponding subsystem to achieve precise linkage at the subsystem level and avoid false triggering of rules between different subsystems. At the same time, if the event is a device event triggered by a specific user operation, the user identifier can also be extracted. The user identifier is used to identify the user who triggered the event. The rule engine can combine the user identifier to verify the user's permissions and filter out the linkage rules that the user has the authority to trigger.

[0034] Alternatively, according to at least one embodiment of this disclosure, when the IoT triggering event is a timed triggering event, its event source identifier mainly includes a user identifier and a subsystem identifier. The user identifier is a unique identifier of the user who configures the timed rule and is used to associate all timed linkage rules configured by the user. The subsystem identifier is the IoT subsystem identifier to which the timed rule belongs.

[0035] Alternatively, according to at least one embodiment of this disclosure, when the IoT triggering event is an external triggering event received through a preset API interface, its identifier is a product identifier, a device identifier, and a user identifier, wherein the product identifier and the device identifier are used to locate the IoT device associated with the external triggering event, and the user identifier is used to identify the identity of the third-party user or the user corresponding to the system that initiated the external triggering command.

[0036] S2. Based on one or more event source identifiers, determine the matching linkage rule corresponding to the IoT trigger event from the rule cache.

[0037] The rule cache pre-establishes a multi-level association index based on various event source identifiers. Product identifier, device identifier, gateway identifier, subsystem identifier, spatial region identifier, and user identifier are used as index keys, respectively or in combination. All linkage rules within the platform are classified and stored. Through this index retrieval method, the rule set associated with the current triggered event can be directly located, avoiding the traversal of all rules and effectively reducing the computational cost of the rule matching process.

[0038] In some embodiments, this step may include: A mapping relationship between an index key and a candidate rule list set is pre-established, and the mapping relationship is stored in the rule cache. The index key is a single event source identifier or a preset combination of multiple event source identifiers. The event source identifiers extracted from the IoT-triggered events are combined to generate a target index key; The target index key is used to perform a matching search in the rule cache to determine a candidate rule list, which contains at least one linkage rule to be matched.

[0039] According to at least one embodiment of this disclosure, the candidate rule list set consists of multiple candidate set lists, each containing at least one linkage rule. For each index key, the rule engine pre-records its corresponding candidate set list or linkage rule, thereby establishing a mapping relationship between all index keys and candidate rule list sets. When an IoT trigger event occurs, the rule engine can quickly locate the corresponding linkage rule based on the index key without traversing all linkage rules. For example, when the event source identifier parsed from the IoT trigger event is a device identifier and a product identifier, the rule engine combines these two identifiers to generate a target index key, performs a retrieval in the rule cache based on the target index key, extracts all linkage rules belonging to the corresponding product and bound to the device, and thus forms the candidate rule list for this matching process.

[0040] Alternatively, according to at least one embodiment of this disclosure, if the extracted event source identifier includes a gateway identifier and a spatial region identifier, the rule engine queries the rule cache using these two types of identifiers as target index keys to obtain linkage rules that are connected to the corresponding gateway and deployed in the specified spatial region, thereby forming a candidate rule list. This retrieval method can achieve rule filtering by physical region and access gateway dimension, and is suitable for IoT linkage scenarios with distributed deployment of multiple devices. Alternatively, according to at least one embodiment of this disclosure, for timed trigger events or external trigger events passed through a preset API interface, the rule engine extracts the user identifier and subsystem identifier from the event as the target index key, filters all linkage rules configured by the user under the corresponding subsystem in the rule cache, and forms a unique candidate rule list.

[0041] S3. Based on the trigger type configured in the linkage rule to be matched, call the trigger matcher to perform type matching verification.

[0042] Each matching linkage rule is pre-configured with a trigger array. This array stores at least one trigger that can trigger the corresponding linkage rule. Each trigger is also pre-configured with a type identifier, which characterizes the basic trigger condition type. For each linkage rule, the configured trigger type is determined based on the type identifiers of all triggers in its configured trigger array. For each type of basic trigger condition, a corresponding trigger matcher is used to determine whether the IoT trigger event meets the condition. The rule engine pre-establishes a matcher mapping table that records the mapping relationship between type identifiers and trigger matchers, enabling it to quickly determine the corresponding trigger matcher based on the type identifier. Each trigger matcher performs type matching checks based on different judgment logics to determine whether the IoT trigger event meets the trigger's basic trigger condition, thus ensuring that the linkage rule determined based on the event source identifier can be triggered by the IoT trigger event and thus apply the corresponding linkage rule.

[0043] See Figure 3 In some embodiments, this step may include: For each linkage rule to be matched, obtain the pre-configured trigger array, and traverse each trigger in the trigger array in a preset order to extract its type identifier; From the pre-built matcher mapping table, query the trigger matcher corresponding to the type identifier of the trigger; The matching method of the trigger matcher is invoked, and the IoT trigger event is used as an input parameter to perform basic trigger condition judgment; If the basic trigger condition of the current trigger does not match, continue to traverse the next trigger in the trigger array. If all triggers in the trigger array have been traversed and do not match, the type matching check of the linkage rule to be matched is determined to be unsuccessful. If the basic trigger condition of any trigger matches, the type matching check of the linkage rule to be matched is determined to be successful.

[0044] According to at least one embodiment of this disclosure, each trigger in the trigger array is a logical OR relation. When traversing the trigger array, if the basic trigger condition of any trigger is successfully matched, the short-circuit traversal of the remaining triggers in the rule is immediately terminated, and the linkage rule to be matched is determined to have passed the type matching verification and enter the subsequent condition grouping matching verification stage. If all triggers in the trigger array have been traversed and none have passed the basic trigger condition judgment, then the type matching verification of the linked rule to be matched is determined to be unsuccessful, and the rule engine continues to traverse the next linked rule to be matched in the candidate rule list. This short-circuit traversal mechanism can effectively avoid redundant verification operations on irrelevant triggers. When a single rule is configured with multiple trigger scenarios, it can significantly reduce the computational overhead of type matching verification, adapt to the operating scenarios of high-frequency reported events from IoT terminal devices, and improve the overall response speed of the rule engine.

[0045] In this implementation method, each trigger can correspond to different trigger sources and different basic trigger conditions, and the triggers do not affect or depend on each other. For example, the same "turn on the air conditioner" linkage rule can be configured with three independent triggers at the same time: device attribute trigger, timed trigger, and manual trigger. If any trigger matches successfully, the subsequent condition grouping verification process can be triggered. There is no need to create multiple rules for each trigger scenario, which greatly simplifies the complexity of rule configuration and management.

[0046] In particular, when a trigger passes the basic trigger condition but fails the subsequent condition grouping and matching verification, the rule engine will return to the trigger array traversal process of that rule and continue to verify the next trigger, instead of directly eliminating the entire rule. This approach further improves the flexibility of rule configuration, allowing different trigger scenarios of the same rule to have their own independent business constraints, meeting the diverse needs of complex IoT linkage scenarios.

[0047] According to at least one embodiment of this disclosure, when adding a new trigger type, it is only necessary to implement the corresponding RuleTriggerMatcher interface and register it to the matcher mapping table. There is no need to modify the traversal logic of the trigger array and the short-circuit judgment mechanism, which ensures the stability and backward compatibility of the core scheduling logic and facilitates the continuous iteration and functional expansion of the rule engine.

[0048] For example, according to at least one embodiment of this disclosure, for IoT trigger events of the device attribute reporting type, when the rule engine traverses the trigger array of the linkage rules to be matched, it first reads the type identifier configured for each trigger. If a trigger is identified as a device attribute trigger type, a pre-registered device attribute trigger matcher is retrieved from the matcher mapping table. The matcher encapsulates the basic trigger condition verification logic for device attribute events. By passing the IoT trigger event as an input parameter to the matching method of the matcher, it can quickly determine whether the event meets the basic trigger qualification defined by the trigger, such as whether the event contains the specified attribute parameter of the specified device, thereby completing the basic trigger condition judgment.

[0049] In another embodiment, for device state change trigger events, the rule engine extracts the type identifier of each trigger in the trigger array. When a state change trigger type is matched, the corresponding state change trigger matcher is obtained from the matcher mapping table. This matcher implements specific basic trigger condition verification logic according to the interface specification. When its matching method is called, the IoT trigger event is input into it, which can verify whether the event represents a substantial change in the device state, such as switching between online and offline, or the conversion between normal and fault states. This completes the basic trigger condition judgment for this type of trigger event, ensuring that the type matching verification is passed only when the event meets the trigger characteristics of a state change.

[0050] For device event reporting trigger events, the rule engine traverses the trigger array in a preset order, extracts the type identifier of each trigger, and if a trigger is detected as a device event trigger type, it queries the corresponding device event trigger matcher from the matcher mapping table, calls its matching method and passes in the IoT trigger event, and performs legality and matching checks on the event type identifier, business data fields, etc., to determine whether the event belongs to the preset business event category of the trigger, thereby completing the judgment of the basic trigger conditions and effectively filtering irrelevant event reports.

[0051] For timed events, when the rule engine traverses the trigger array, after identifying a trigger of the timed type, it retrieves the corresponding timed trigger matcher from the matcher mapping table. This matcher implements the basic trigger condition verification logic of the time dimension according to the interface specification. By calling its matching method and taking the timed trigger event as the input parameter, it can determine whether the current time meets the preset time strategy of the trigger, such as whether the specified time has been reached or whether the preset period condition is met. This completes the basic trigger condition judgment of timed events and realizes the pre-screening of rules based on time strategy.

[0052] For external trigger events received through the preset API interface, the rule engine extracts the type identifier of each trigger in the trigger array. If an external API trigger type is matched, the corresponding external trigger matcher is retrieved from the matcher mapping table. After calling its matching method and passing in the external trigger event, the legality of the event source, the validity of the interface identifier, and the completeness of the agreed parameters can be verified. It is then determined whether the event meets the basic trigger conditions of the external trigger type, thereby completing the type matching and verification of the external event. This broadens the trigger source range of the rule engine while ensuring the standardization of the basic trigger conditions.

[0053] S4. If the type matching verification passes, perform conditional grouping matching verification on the linkage rule to be matched. See [link / reference]. Figure 4 Its specific implementation process further includes: Based on the linked rules to be matched, a condition grouping array is established. The condition grouping array contains zero or at least one condition group, and each condition group contains zero or at least one condition. All condition groups in each condition grouping array are logical OR relations, and all conditions in each condition group are logical AND relations. When the condition grouping array contains at least one condition group, traverse each condition group in the condition grouping array; When the traversed condition group contains at least one condition, the IoT trigger event is matched and calculated with each condition in the traversed condition group one by one to obtain the satisfaction status of each condition. If all conditions in any condition group are met, the condition group matching check is considered successful, and the traversal of the remaining condition groups and their corresponding trigger arrays is stopped. When the condition grouping array is traversed and no condition group has all conditions satisfied, the condition grouping matching check is determined to have failed.

[0054] This embodiment defines a two-layer logical architecture. The condition grouping array contains zero or at least one condition group, and each condition group contains zero or at least one condition. The logical relationship is configured as follows: all condition groups are related by a logical "OR" relationship, while all conditions within a single condition group are related by a logical "AND" relationship. Through this nested logical structure of "AND within groups and OR between groups," a single rule can cover multiple completely independent triggering scenarios, and the business constraints of each scenario can be precisely combined and defined, thereby significantly improving the flexibility and expressiveness of rule configuration. In at least one embodiment of this disclosure, a null value protection mechanism is further introduced to prevent false triggering due to configuration deficiencies, thereby ensuring the security and reliability of rule execution. This mechanism specifically includes the following decision path: If the extracted condition grouping array is empty, meaning it does not contain any condition groups, it indicates that the current trigger is not configured with valid business constraints. In this case, the condition grouping matching verification is directly determined to have failed, and this step is terminated. The execution flow is then rolled back to continue traversing the next trigger in the array of triggers for the linked rules to be matched. Furthermore, if the currently traversed single condition group is empty, it is determined that the condition group has failed to match, and the next condition group is traversed. If the configuration parameter of a single condition is empty, it is determined that the condition has failed to match, and the next condition in the condition group is traversed. The above-mentioned null value protection mechanism can effectively prevent the false triggering of unconstrained rules and ensure the security and reliability of rule execution.

[0055] According to at least one embodiment of this disclosure, during the traversal of a single condition group, if any condition fails to match, the verification of the remaining conditions in that group is immediately terminated, the condition group is determined to have failed to match, and the traversal of the next condition group continues; during the traversal of the condition group array, if any condition group matches successfully, the verification of all remaining condition groups is immediately terminated, and the verification of all remaining triggers of the linkage rule to be matched is also terminated.

[0056] Furthermore, if the condition grouping matching verification of a single trigger fails, it only means that the triggering scenario corresponding to that trigger does not meet the business requirements. It will not directly eliminate the entire linkage rule to be matched. Instead, the execution process will be rolled back to the trigger array traversal stage of that rule to continue to verify the basic triggering conditions and corresponding condition groups of the next trigger. This allows the same linkage rule to support multiple completely independent triggering scenarios, each with its own exclusive basic triggering conditions and business constraints, which greatly improves the flexibility and expressiveness of rule configuration.

[0057] See Figure 5 According to at least one embodiment of this disclosure, the linkage rule matching method further includes a step of sequentially checking all conditions within the condition group in step S4, the specific steps of which are as follows: For the current condition to be checked, extract its configured operator enumeration value, and verify the validity of the operator enumeration value. If it is invalid, the condition is determined to fail to match; if the operator is valid, construct the expression variable corresponding to the condition. Check whether the parameter value of the expression variable is not empty. If the parameter value is empty, directly execute the expression calculation and determine whether the condition is successfully matched based on the calculation result. If the parameter value is not empty, further determine whether it is a numeric comparison operation and whether the parameter value is all numbers. If it is not a numeric comparison operation or the parameter value is not all numbers, directly execute the expression and determine whether the condition is successfully matched based on the calculation result. If the parameter value is not empty, and it is a numeric comparison operation with all parameter values ​​being numbers, the parameter value is converted to a numeric type before the expression is calculated.

[0058] Specifically, if the operator enumeration value is valid, an expression variable corresponding to the condition is constructed based on the context data of the current IoT trigger event. The expression variable includes the actual reported value of the event and the preset threshold of the condition. Then, it is checked whether the parameter value of the expression variable is not empty. If the parameter value is empty, the expression is directly calculated, and the corresponding Boolean value is returned based on the calculation result to determine whether the condition is successfully matched. If the parameter value is not empty, it is further determined whether the current operation is a numeric comparison operation and whether all parameter values ​​of the expression variable are convertible numeric formats. If it is not a numeric comparison operation or the parameter values ​​are not all numeric, the expression is directly calculated, and the corresponding Boolean value is returned based on the calculation result. If the parameter value is not empty and it is a numeric comparison operation and the parameter values ​​are all numeric, all parameter values ​​are uniformly converted to standard numeric types before the expression is calculated. Finally, the corresponding Boolean value is returned based on the calculation result to complete the matching determination of the condition.

[0059] In some optional embodiments of this disclosure, when extracting the configured operator enumeration value and verifying the validity of the operator enumeration value, if the operator enumeration value is determined to be invalid, a structured warning log containing a unique condition identifier, error type, triggering event device identifier and timestamp is recorded, and the condition matching is directly determined to fail, and a boolean value false is returned.

[0060] According to at least one embodiment of this disclosure, the number type conversion step is specifically designed to address the common problem of inconsistent data formats reported by devices in IoT scenarios. Since IoT devices from different manufacturers and models often transmit numerical data in string format, performing a unified type conversion before the number comparison operation can completely avoid matching errors caused by logical differences between string comparison and numerical comparison. For example, it avoids judging the string "25" as mismatched with the number 25, or incorrectly judging the string "100" as less than the number "20", ensuring the accuracy and consistency of the condition judgment results. For non-number comparison operations or cases where the parameter values ​​are not all numbers, the design of directly performing expression calculation takes into account the processing needs of non-numerical type conditions (such as string inclusion, enumeration value matching, etc.), without unnecessary type conversion, further improving the execution efficiency of condition checks.

[0061] S5. If the conditional grouping matching verification passes, execute the linkage action corresponding to the linkage rule to be matched. See below. Figure 6 Its specific implementation process further includes: Determine whether the current linkage rule to be matched has a preset linkage action configured. If a preset linkage action is configured, obtain the action executor corresponding to the preset linkage action, call the action executor to execute the preset linkage action, record the action execution success log when the preset linkage action is successfully executed, and traverse the next linkage rule to be matched.

[0062] Specifically, if the current linked rule to be matched does not have a preset linked action configured, the action execution stage of that rule is skipped, and the process continues to traverse the next linked rule to be matched; if the current linked rule to be matched has a preset linked action configured, the action executor corresponding to the preset linked action is obtained; if no matching action executor is obtained, the execution of the current preset linked action is skipped, and the process continues to traverse the next linked rule to be matched; if a matching action executor is obtained, the action executor is invoked to execute the preset linked action; if the preset linked action is executed successfully, an action execution success log is recorded, and the process continues to traverse the next linked rule to be matched; if the preset linked action fails to execute, an action execution error log is recorded, and the process continues to traverse the next linked rule to be matched.

[0063] According to at least one embodiment of this disclosure, the matcher in this application adopts a layered pluggable matcher architecture, which completely decouples the rule matching process into two independent layers: trigger matching and condition matching. Each layer defines an extension specification through a unified interface abstraction. The trigger matching layer defines the unified behavior of all trigger matchers through the RuleTriggerMatcher interface, and the condition matching layer defines the unified behavior of all condition matchers through the RuleConditionMatcher interface. When adding a trigger type, condition type, or action type, it is only necessary to implement the corresponding interface and complete the registration, without modifying the core rule matching scheduling logic.

[0064] For example, in practical applications of smart home IoT platforms, as the number of connected device types increases, the platform needs to add a trigger type of "triggering linkage when device battery level is below a preset threshold" to support low-battery device reminders and automatic charging scenarios. Using the pluggable and extensible architecture of this solution, developers do not need to modify existing trigger traversal logic, type matching validation logic, or conditional grouping matching logic; they only need to add a new class that implements the RuleTriggerMatcher interface.

[0065] In this implementation class, developers need to define the trigger type identifier and basic trigger condition validation logic according to the interface specification. For example, they need to validate whether the trigger event is a device attribute reporting event and whether the device power attribute carried by the event is lower than a preset threshold. Through Spring autowiring, the matcher mapping table will be automatically built when the platform starts through Spring's autowiring mechanism. The type identifier of the matcher will be associated with its instance object. The core scheduling code can automatically identify and call the newly added trigger matcher without any modification. The entire extension process can be completed in just a few hours. Compared with the existing technology that requires modification of the core code and full regression testing, the extension efficiency is greatly improved.

[0066] To verify the effectiveness of this embodiment, this disclosure uses a smart home temperature control scenario as an example. If the user needs to configure a linkage rule that "the air conditioner will be turned on when any of the following conditions are met", the first condition is that the temperature is greater than 30 degrees Celsius and the humidity is greater than 60% and the current time is between 8:00 and 22:00. The second condition is that the human body sensor detects that there is someone in the room.

[0067] In practical applications, if the above business requirement is described in natural language as "turn on the air conditioner when the temperature is greater than 30 degrees Celsius, the humidity is greater than 60%, and the current time is between 8:00 and 22:00, or someone is in the room," it will create serious semantic ambiguity. The large language model agent may interpret it as two completely different logical combinations: the first is "(temperature > 30 and humidity > 60 and current time is between 8:00 and 22:00) or someone is in the room," and the second is "temperature > 30 and humidity > 60 and (current time is between 8:00 and 22:00 or someone is in the room)." The execution results of these two logics are significantly different. For example, when the room temperature is 25 degrees Celsius, the humidity is 50%, and someone is detected, the first logic will trigger the air conditioner to turn on, while the second logic will not. Without a clear conditional grouping structure to define the logical combinations, the platform cannot distinguish between these two logics, which will inevitably lead to rule execution errors, affecting the user experience and even causing security risks.

[0068] Using the condition grouping structure of this solution, the rule can be implemented as an array of condition groups containing two condition groups. The first condition group contains three conditions: "Temperature > 30", "Humidity > 60", and "Current Time ∈ [8:00, 22:00]". All conditions in this group are enforced as a logical AND relationship. The second condition group contains three conditions: "Temperature > 30", "Humidity > 60", and "Human Sensor Status = 1". The conditions in this group are also enforced as a logical AND relationship. The two condition groups are enforced as a logical OR relationship. When performing matching verification, the rule engine executes according to the logic of "OR between groups, AND within groups". As long as all conditions in any condition group match successfully, the rule is considered to have passed the match, and the linkage action of turning on the air conditioner is executed. Its execution logic is consistent with the user's business requirements and there is no ambiguity.

[0069] A second aspect of the present invention discloses an electronic device, including a processor and a memory, the memory storing a plurality of instructions; the processor loads instructions from the memory to execute steps in the linkage rule matching method based on the Internet of Things scenario as described in any of the preceding claims.

[0070] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for matching linkage rules based on Internet of Things (IoT) scenarios, characterized in that, The method includes: Receive and parse IoT trigger events, and extract one or more event source identifiers from the IoT trigger events, wherein the IoT trigger events are events that trigger linkage rule matching; Based on one or more event source identifiers, determine the linkage rule to be matched corresponding to the IoT trigger event from the rule cache; Based on the trigger type configured in the linkage rule to be matched, the trigger matcher is invoked to perform type matching verification; If the type matching verification passes, a condition grouping matching verification is performed on the linkage rule to be matched. The condition grouping matching verification includes two layers of "OR-AND" logic. If the conditional grouping matching verification passes, the linkage action corresponding to the linkage rule to be matched is executed.

2. The linkage rule matching method based on an Internet of Things scenario according to claim 1, characterized in that, The IoT triggering events include device attribute reporting events, device event reporting events, device status change events, timed triggering events, and external triggering events received through preset API interfaces.

3. The linkage rule matching method based on an Internet of Things scenario according to claim 1, characterized in that, The event source identifier includes at least one of the following: product identifier, device identifier, gateway identifier, subsystem identifier, spatial area identifier, and user identifier.

4. The linkage rule matching method based on an Internet of Things scenario according to claim 1, characterized in that, The step of determining the matching linkage rule corresponding to the IoT trigger event from the rule cache based on one or more event source identifiers includes: A mapping relationship between an index key and a candidate rule list set is pre-established, and the mapping relationship is stored in the rule cache. The index key is a single event source identifier or a preset combination of multiple event source identifiers. The event source identifiers extracted from the IoT-triggered events are combined to generate a target index key; The target index key is used to perform a matching search in the rule cache to determine a candidate rule list, which contains at least one linkage rule to be matched.

5. The linkage rule matching method based on an Internet of Things scenario according to claim 1, characterized in that, The step of calling the trigger matcher to perform type matching verification according to the trigger type configured based on the linkage rule to be matched includes: For each linkage rule to be matched, obtain the pre-configured trigger array, and traverse each trigger in the trigger array in a preset order to extract its type identifier; From the pre-built matcher mapping table, query the trigger matcher corresponding to the type identifier of the trigger; The matching method of the trigger matcher is invoked, and the IoT trigger event is used as the input parameter to perform basic trigger condition judgment; If the basic trigger condition of the current trigger does not match, continue to traverse the next trigger in the trigger array. If all triggers in the trigger array have been traversed and do not match, the type matching check of the linkage rule to be matched is determined to be unsuccessful. If the basic trigger condition of any trigger matches, the type matching check of the linkage rule to be matched is determined to be successful.

6. The linkage rule matching method based on an Internet of Things scenario according to claim 5, characterized in that, Perform conditional grouping matching verification on the linked rules to be matched, including: Based on the linked rules to be matched, a condition grouping array is established. The condition grouping array contains zero or at least one condition group, and each condition group contains zero or at least one condition. All condition groups in each condition grouping array are logical OR relations, and all conditions in each condition group are logical AND relations. When the condition grouping array contains at least one condition group, traverse each condition group in the condition grouping array; When the traversed condition group contains at least one condition, the IoT trigger event is matched and calculated with each condition in the traversed condition group one by one to obtain the satisfaction status of each condition. If all conditions in any condition group are met, the condition group matching check is considered successful, and the traversal of the remaining condition groups and their corresponding trigger arrays is stopped. When the condition grouping array is traversed and no condition group has all conditions satisfied, the condition grouping matching check is determined to have failed.

7. The linkage rule matching method based on an Internet of Things scenario according to claim 6, characterized in that, If the number of condition groups in the condition grouping array is zero, the condition grouping matching verification is determined to have failed, and the process continues to traverse the next trigger in the array of triggers for the linkage rules to be matched.

8. The linkage rule matching method based on an Internet of Things scenario according to claim 6, characterized in that, The IoT trigger event is matched and calculated one by one with each condition in the traversed condition group to obtain the satisfaction status of each condition, specifically including: For each condition, extract the operator enumeration value configured for it; Verify the validity of the operator enumeration value. If it is valid, construct the expression variable corresponding to the condition. Otherwise, mark the condition as not satisfied. If the parameter values ​​required for the expression variable cannot be obtained from the IoT trigger event, the expression calculation is performed; If the parameter values ​​required for the expression variable are obtained from the IoT trigger event, and the parameter values ​​are all numbers and involve number comparison operations, the parameter values ​​are converted into numeric types before the expression calculation is performed, and the satisfaction status of each condition is obtained based on the calculation result.

9. The linkage rule matching method based on an Internet of Things scenario according to claim 6, characterized in that, If the conditional grouping matching verification passes, the linkage action corresponding to the linkage rule to be matched is executed, including: Determine whether the currently matched linkage rule has a preset linkage action configured; If a preset linkage action is configured, obtain the action executor corresponding to the preset linkage action; If the action executor is obtained, the action executor is invoked to execute the preset linkage action, and the execution log is recorded before iterating through the next linkage rule to be matched.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to execute the steps in the linkage rule matching method based on the Internet of Things scenario as described in any one of claims 1-9.

Images