Internet of Things smart home automation rule conflict processing method and device

Abstract

The invention relates to the technical field of smart home, in particular to an Internet of Things smart home automation rule conflict processing method and device, and the method comprises the steps: generating a rule interaction list according to an automation rule model after a user carries out entity security configuration, smart home system region configuration and environment configuration, generating a potential rule conflict list and a rule conflict processing strategy in combination with the rule interaction list and the entity security configuration so as to obtain a final potential rule conflict list and a final rule conflict processing strategy in combination with the personal preference configuration, thereby performing dynamic detection on the system based on assertion detection. And executing a corresponding processing action according to the final potential rule conflict list and the rule conflict processing strategy. Therefore, the problems of weak regional environment perception, low detection accuracy, more false alarms, influence on system operation and lack of universal conflict processing strategies caused by the fact that the regional and environment attributes of the smart home are not configured and user preferences are neglected in the related technologies are solved.

Description

Technical Field

[0001] This application relates to the field of smart home technology, and in particular to a method and apparatus for handling conflicts in IoT smart home automation rules. Background Technology

[0002] Smart home, as a cutting-edge application in the Internet of Things (IoT) field, refers to ordinary residences equipped with various IoT devices. One of its core components is automation rules, which are logical control mechanisms that automatically execute specific operations based on preset trigger conditions and environmental conditions. These rules help users manage smart home devices more conveniently, effectively improving comfort and convenience. For example, by deploying temperature sensors and air conditioners indoors and setting an automation rule to "turn on the air conditioner when the indoor temperature is below a certain threshold," automatic temperature adjustment can be achieved. However, in actual smart home systems, multiple devices and multiple automation rules often run simultaneously. Conflicts may occur during the execution of these rules, posing significant security risks.

[0003] In related technologies, mitigation of smart home rule conflicts mainly revolves around two steps: conflict detection and conflict resolution. Conflict detection can be divided into static detection and dynamic detection. Static detection focuses on analyzing potential rule conflicts in static code, while dynamic detection monitors the system status in real time during system operation to identify conflicts. In terms of conflict resolution, typical solutions include four types: first, reconfiguring automation rules; second, assuming general predefined strategies; third, adopting strategies defined by security experts; and fourth, customizing resolution solutions based on rule conflicts. These solutions attempt to reduce the risk of rule conflicts through different paths, providing basic support for the stable operation of smart home systems.

[0004] However, in related technologies, reconfiguring automation rules may cause existing rules to malfunction and make it difficult to resolve conflicts. Assuming that general predefined policies require users to undertake a large amount of operational work, it will place a heavy burden on users. Security experts defining policies is not only costly, but may also lead to privacy leaks due to information interaction. Customizing conflict resolution solutions based on rules transfers the responsibility of conflict resolution to non-professional users, making it difficult to achieve large-scale promotion. In addition, since smart home systems are deeply integrated with the physical environment, there are mutual influences between devices at the physical channel level. However, the lack of configuration of regional and environmental attributes and the neglect of user preferences result in weak perception of regions and environments, and may also misjudge normal rule interactions as conflicts. There is a lack of general conflict resolution strategies, which urgently need to be addressed. Summary of the Invention

[0005] This application provides a method and apparatus for handling conflicts in IoT smart home automation rules, in order to solve the problems of related technologies that fail to configure the regional and environmental attributes of smart homes, ignore user preferences, resulting in weak regional environmental perception, low detection accuracy, many false alarms, impact on system operation, and lack of general conflict handling strategies.

[0006] The first aspect of this application provides a method for handling automated rule conflicts in IoT smart homes, comprising the following steps: after a user configures physical security, smart home system area, and environment, all possible rule interactions are extracted according to the automated rule model and the automated rule interaction method to generate a rule interaction list; a potential rule conflict list and a rule conflict handling strategy are generated by combining the rule interaction list and the physical security configuration, and a final potential rule conflict list and rule conflict handling strategy are obtained by combining personal preference configuration; dynamic detection of the smart home system is performed based on assertion detection to determine the rule conflicts detected in the dynamic monitoring, and corresponding processing actions are executed according to the final potential rule conflict list and rule conflict handling strategy.

[0007] Through the above technical means, the embodiments of this application can realize static and dynamic detection of rule conflicts in smart home systems based on automated rule modeling, formal language analysis, and assertion detection, achieving a high rule conflict detection rate and a low false alarm rate. Furthermore, it can reduce the system's operational burden through effective task separation. Simultaneously, through the configuration and execution of automated rule conflict handling strategies, it enables rapid decision-making to avoid blocking normal system operation. Moreover, it takes into account both regional and environmental attributes, is unaffected by the diversity of home environments, and can detect rule conflicts that affect each other through physical channels. It has the advantages of wide detection coverage and broad applicability. Furthermore, it uses natural language templates to describe rule interactions and rule conflicts, allowing the system to run automatically. Users only need to complete basic configurations according to the natural language guidance and modify conflict markers and rule conflict handling strategies themselves, achieving a low user burden and a user-friendly effect.

[0008] Optionally, in one embodiment of this application, after generating the rule interaction list, the method further includes: supplementing the interaction description and interaction type according to the semantics of the rule interaction type, so as to update the rule interaction list.

[0009] Through the above technical means, the embodiments of this application can update the rule interaction list by supplementing the interaction description and interaction type, which not only improves the readability of the rule interaction list and reduces the information understanding cost, but also provides a basis for subsequent conflict detection, reducing the misjudgment and omission of conflicts.

[0010] Optionally, in one embodiment of this application, the step of dynamically detecting the smart home system based on assertion detection to determine rule conflicts detected in dynamic monitoring includes: performing assertion detection after a rule is triggered and before its execution to determine whether the currently triggered rule conflicts with past rules.

[0011] Through the above technical means, the embodiments of this application only start assertion detection at the detection node, focusing on the targeted comparison between the current triggering rule and the past rules, which greatly reduces unnecessary resource consumption and avoids system delays caused by full-process monitoring.

[0012] Optionally, in one embodiment of this application, the step of performing the corresponding processing action according to the final potential rule conflict list and the rule conflict handling strategy includes: when a conflict arises with the past rules, generating a system instruction according to the conflict handling measures of the final potential rule conflict list and the rule conflict handling strategy; and controlling the smart home system to perform the corresponding action in response to the system instruction.

[0013] Through the above technical means, the embodiments of this application can generate system instructions based on conflict handling measures when assertion detection determines that the current triggering rule conflicts with past rules. This eliminates the need for manual user intervention, enabling immediate interception of conflicts, preventing actual harm, reducing user workload, and improving the convenience of smart home use. At the same time, the conflict handling measures have been integrated with user preferences and physical security configurations, ensuring both the accurate adaptation of handling actions to meet actual user needs and ensuring that security boundaries are not crossed, thus guaranteeing system stability.

[0014] A second aspect of this application provides an IoT smart home automation rule conflict handling device, comprising: a generation module, configured to extract all possible rule interactions according to an automation rule model and an automation rule interaction method after the user performs physical security configuration, smart home system area configuration, and environment configuration, to generate a rule interaction list; an acquisition module, configured to combine the rule interaction list and physical security configuration to generate a potential rule conflict list and a rule conflict handling strategy, and to obtain a final potential rule conflict list and rule conflict handling strategy by combining personal preference configuration; and a processing module, configured to perform dynamic detection on the smart home system based on assertion detection to determine the rule conflicts detected in the dynamic monitoring, and to execute corresponding processing actions according to the final potential rule conflict list and rule conflict handling strategy.

[0015] Through the above technical means, the embodiments of this application can realize static and dynamic detection of rule conflicts in smart home systems based on automated rule modeling, formal language analysis, and assertion detection, achieving a high rule conflict detection rate and a low false alarm rate. Furthermore, it can reduce the system's operational burden through effective task separation. Simultaneously, through the configuration and execution of automated rule conflict handling strategies, it enables rapid decision-making to avoid blocking normal system operation. Moreover, it takes into account both regional and environmental attributes, is unaffected by the diversity of home environments, and can detect rule conflicts that affect each other through physical channels. It has the advantages of wide detection coverage and broad applicability. Furthermore, it uses natural language templates to describe rule interactions and rule conflicts, allowing the system to run automatically. Users only need to complete basic configurations according to the natural language guidance and modify conflict markers and rule conflict handling strategies themselves, achieving a low user burden and a user-friendly effect.

[0016] Optionally, in one embodiment of this application, it further includes: an update module, used to supplement the interaction description and interaction type according to the semantics of the rule interaction type, so as to update the rule interaction list.

[0017] Through the above technical means, the embodiments of this application can update the rule interaction list by supplementing the interaction description and interaction type, which not only improves the readability of the rule interaction list and reduces the information understanding cost, but also provides a basis for subsequent conflict detection, reducing the misjudgment and omission of conflicts.

[0018] Optionally, in one embodiment of this application, the processing module includes: a judgment unit, used to perform assertion detection after rule triggering and before execution, to determine whether the currently triggered rule conflicts with past rules.

[0019] Through the above technical means, the embodiments of this application only start assertion detection at the detection node, focusing on the targeted comparison between the current triggering rule and the past rules, which greatly reduces unnecessary resource consumption and avoids system delays caused by full-process monitoring.

[0020] Optionally, in one embodiment of this application, the processing module includes: a generation unit, configured to generate system instructions based on the final potential rule conflict list and the conflict handling measures of the rule conflict handling strategy when a conflict arises with the past rules; and a processing unit, configured to control the smart home system to perform corresponding actions in response to the system instructions.

[0021] Through the above technical means, the embodiments of this application can generate system instructions based on conflict handling measures when assertion detection determines that the current triggering rule conflicts with past rules. This eliminates the need for manual user intervention, enabling immediate interception of conflicts, preventing actual harm, reducing user workload, and improving the convenience of smart home use. At the same time, the conflict handling measures have been integrated with user preferences and physical security configurations, ensuring both the accurate adaptation of handling actions to meet actual user needs and ensuring that security boundaries are not crossed, thus guaranteeing system stability.

[0022] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the IoT smart home automation rule conflict handling method as described in the above embodiments.

[0023] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for handling conflicting rules in IoT smart home automation.

[0024] A fifth aspect of this application provides a computer program product, including a computer program that, when executed, implements the above-described method for handling conflicting rules in IoT smart home automation.

[0025] This application's embodiments can achieve static and dynamic detection of rule conflicts in smart home systems based on automated rule modeling, formal language analysis, and assertion detection. This achieves a high rule conflict detection rate and a low false alarm rate, while effectively reducing system workload through task separation. Furthermore, the automated configuration and execution of rule conflict handling strategies enable rapid decision-making to avoid blocking normal system operation. In addition, it considers both regional and environmental attributes, remaining unaffected by the diversity of home environments, and can detect rule conflicts that interact through physical channels. It boasts advantages in broad detection scope and applicability. Moreover, it uses natural language templates to describe rule interactions and conflicts, allowing the system to run automatically. Users only need to complete basic configurations based on natural language guidance and modify conflict markers and rule conflict handling strategies themselves, resulting in a low user burden and a user-friendly experience. Therefore, it solves the problems of related technologies that fail to configure regional and environmental attributes of smart homes, ignore user preferences, leading to weak regional environmental perception, low detection accuracy, high false alarm rates, impact on system operation, and a lack of universal conflict handling strategies.

[0026] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0027] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for handling rule conflicts in IoT smart home automation according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating six typical conflict scenarios of IoT smart home automation rules provided according to embodiments of this application; Figure 3 This is a schematic diagram of a smart home interface provided according to an embodiment of this application; Figure 4 This is a schematic diagram of the environment parameter definition page of the environment settings interface provided in an embodiment of this application; Figure 5 This is a schematic diagram of the rule environment selection page of the environment settings interface provided in the embodiments of this application; Figure 6 This is a schematic diagram of a static detection page for rule conflict detection provided according to an embodiment of this application; Figure 7 A schematic diagram of an entity security configuration page configured according to the rule conflict handling strategy provided in the embodiments of this application; Figure 8 This is a schematic diagram of a page configured to securely configure a camera as an important security entity according to the rule conflict handling strategy provided in the embodiments of this application. Figure 9 This is a schematic diagram of a processing strategy configuration page configured according to the rule conflict handling strategy provided in the embodiments of this application; Figure 10 This is a schematic diagram illustrating the dynamic detection and processing information provided according to the embodiments of this application; Figure 11 This is a block diagram of an IoT smart home automation rule conflict handling device provided according to an embodiment of this application; Figure 12 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application.

[0028] Figure label: 110 - IoT smart home automation rule conflict handling device; 100 - Generation module, 200 - Acquisition module, 300 - Processing module; 1201 - Memory, 1202 - Processor, 1203 - Communication interface. Detailed Implementation

[0029] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0030] The following describes an embodiment of the IoT smart home automation rule conflict handling method and apparatus with reference to the accompanying drawings. Addressing the problems mentioned in the background art, such as the lack of configuration of smart home area and environmental attributes, neglect of user preferences, resulting in low detection accuracy, high false alarm rates, impact on system operation, weak area and environmental perception, and a lack of universal conflict handling strategies, this application provides an IoT smart home automation rule conflict handling method. This method achieves static and dynamic detection of rule conflicts in the smart home system based on automated rule modeling, formal language analysis, and assertion detection, resulting in a high rule conflict detection rate and a low false alarm rate. It also reduces the system's operational burden through effective task separation. Furthermore, the configuration and execution of automated rule conflict handling strategies enable rapid decision-making to avoid blocking normal system operation. In addition, it considers both area and environmental attributes, is unaffected by the diversity of home environments, and can detect rule conflicts that interact through physical channels, offering advantages of wide detection coverage and broad applicability. Moreover, it uses natural language templates to describe rule interactions and conflicts, allowing the system to run automatically. Users only need to complete basic configurations based on natural language guidance and modify conflict markers and rule conflict handling strategies themselves, achieving a user-friendly and low-burden experience. This solves the problems of related technologies not configuring smart home area and environmental attributes, ignoring user preferences, resulting in weak area environmental perception, low detection accuracy, many false alarms, affected system operation, and lack of general conflict handling strategies.

[0031] Specifically, Figure 1 This is a flowchart of a method for handling rule conflicts in IoT smart home automation according to an embodiment of this application.

[0032] like Figure 1 As shown, the method for handling conflicts in IoT smart home automation rules includes the following steps: In step S101, after the user configures the physical security, smart home system area and environment, all possible rule interactions are extracted according to the automated rule model and the automated rule interaction method to generate a rule interaction list.

[0033] In the embodiments of this application, physical security configuration refers to the configuration made for physical devices (such as cameras, door locks, air conditioners, sensors, etc.) in a smart home system to prevent security risks (unauthorized operation, data leakage, abnormal device control, etc.). This configuration ensures the safe and compliant operation of the devices themselves, preventing malicious control or security vulnerabilities. Examples include setting smart door locks to be unlocked only by family members' fingerprints / passwords, encrypting data transmission and issuing alarms for stranger access to smart cameras, automatically cutting off power to smart sockets when overloaded, and restricting smart curtain motors to be controlled only via the local area network.

[0034] In addition, smart home system zone configuration refers to binding physical devices to specific zones according to the physical space division of the home (such as living room, bedroom, kitchen, study, etc.), clearly defining which space each device belongs to. This configuration enables zone-based device control and avoids chaotic device associations (such as accidentally triggering the living room air conditioner when the bedroom air conditioner is accidentally operated). For example, smart lights, smart TVs, and temperature and humidity sensors in the living room can be grouped into the living room zone, while air conditioners, bedside lamps, and human body sensors in the master bedroom can be grouped into the master bedroom zone.

[0035] Furthermore, smart home system environment configuration refers to the configuration of monitoring dimensions, threshold ranges, and applicable scenarios for the physical environmental factors (such as temperature, humidity, light intensity, air quality, noise level, etc.) required for the operation of the smart home system. This ensures that automation rules adapt to actual environmental changes and avoids rules that are out of touch with reality (e.g., triggering air conditioning to cool down in low-temperature environments). For example, setting thresholds for light intensity—strong light (>800 lux), weak light (200-800 lux), and dim light (<200 lux)—is used to trigger light brightness adjustments; and configuring air quality parameters... This is a pollution warning value used to trigger the air purifier to turn on automatically.

[0036] It is understood that, in the embodiments of this application, when handling smart home automation rule conflicts, smart home automation rule conflict detection is performed first, and then smart home automation rule conflict handling is performed. The smart home automation rule conflict detection includes static detection and dynamic monitoring, and conflict handling follows immediately after dynamic monitoring.

[0037] In actual implementation, the embodiments of this application can guide users to configure physical security, smart home system area and environment, and then establish an automated rule model, thereby performing static detection based on the automated rule model.

[0038] Specifically, the embodiments of this application can be based on an automated rule model, and according to the automated rule interaction method, extract all possible rule interactions through formal language analysis to generate a rule interaction list, providing data support for conflict detection and handling.

[0039] For example, this application provides an automated rule model establishment method, which represents a single automated rule model as follows: This is abbreviated as TCAE model. A trigger representing a rule can include, but is not limited to, trigger type, device list, and decision parameters. This represents a list of conditions for a rule, and there can be multiple such lists. belong each This represents a specific condition check, which may include, but is not limited to, condition type, device list, and judgment parameters. This represents a list of actions to be executed under a rule; there are multiple such lists. belong each It may include, but is not limited to, the type of action to be performed, a list of devices to be used, and execution data. express The corresponding environment attributes, and the environment attributes are defined as follows: ,in, These describe the regional characteristics of the environment, such as the kitchen and living room. Indicates environmental factors, such as temperature, humidity, and light intensity. It indicates an influence trend, such as increasing or decreasing.

[0040] Furthermore, in one embodiment of this application, after generating the rule interaction list, the method further includes: supplementing the interaction description and interaction type according to the semantics of the rule interaction type, so as to update the rule interaction list.

[0041] In the embodiments of this application, the interaction description refers to a concrete description of the interaction process of two or more automated rules in a smart home, including the rule identifiers involved in the interaction, the associated areas, devices, parameters, and the specific manifestations of the interaction (such as the bedroom air conditioner cooling rule and the heating rule, which perform opposite adjustments for the same temperature parameter), in order to clearly present the interaction scenario.

[0042] In addition, interaction type refers to the standardized classification of interactions based on the semantic features of rule-based interactions (such as action logic and parameter association) (such as parameter conflict type, action mutual exclusion type, etc.), which is used to clarify the core nature of the interaction and provide a basis for judgment in subsequent conflict detection and handling.

[0043] In actual implementation, to compensate for the lack of semantic information in the rule interaction list, this application embodiment can identify the semantic association features of rule interaction based on the semantics of rule interaction type, that is, through the triggering conditions, execution actions, and associated attributes of smart home automation rules, and supplement the interaction description and interaction type to update the rule interaction list.

[0044] The embodiments of this application can update the rule interaction list by supplementing the interaction description and interaction type, which not only improves the readability of the rule interaction list and reduces the information understanding cost, but also provides a basis for subsequent conflict detection, reducing the misjudgment and missed judgment of conflicts.

[0045] Based on the descriptions of other embodiments, this application provides a rule interaction and conflict classification method. According to the TCAE model, rule interactions in the system, i.e., the ways in which automated rules influence each other, are divided into six types: "rule execution interaction" (meaning the execution of two rules interacts with each other), "rule triggering interaction" (one rule triggers another rule), "rule condition interaction" (the execution result of one rule allows or disables the condition of another rule), "rule execution indirect interaction" (different devices executing two rules share the same environmental attributes, such as controlling the opening of a window and turning on the air conditioner), "rule triggering indirect interaction" (the execution of one rule and the trigger of another rule share environmental attributes), and "rule condition indirect interaction" (the execution of one rule and the condition of another rule share environmental attributes). Thus, six types of rule conflicts are obtained: "rule execution conflict", "rule triggering conflict", "rule condition conflict", "rule execution indirect conflict", "rule triggering indirect conflict", and "rule condition indirect conflict". Rule conflicts are included in rule interactions, but a pair of rule interactions is not necessarily a rule conflict.

[0046] Furthermore, embodiments of this application provide a formal analysis method for an automated rule model, used to obtain a list of rule interactions through static detection. Specifically, it is assumed that rules exist. and rules , express The corresponding environmental attributes, ( The result of the former element causes the function of the latter element to be disabled (or ineffective), such as This indicates that the execution of rule 1 caused the trigger of rule 2 to be activated.

[0047] Furthermore, the formal expression for "rule enforcement conflict" can be, but is not limited to, as follows: , The formal expression for "rule triggering conflict" can be, but is not limited to, as follows: , The formal expression for "rule condition conflict" can be, but is not limited to, as follows: , The formal expression for "indirect conflict in rule enforcement" can be, but is not limited to, as follows: , The formal expression for "rule triggering indirect conflict" can be, but is not limited to, as follows: , The formal expression for "indirect conflict of rule conditions" can be, but is not limited to, as follows: .

[0048] like Figure 2 As shown, six typical conflict scenarios of IoT smart home automation rules are illustrated, and the occurrence of conflicts is intuitively presented through specific rule examples.

[0049] (a) Rule execution conflict, corresponding to "rule execution conflict".

[0050] Rule R3 can be understood as turning on the air conditioner and setting it to 20°C when the temperature is >27°C and the air conditioner is off; Rule R4 can be understood as turning on the air conditioner and setting it to 23°C when the temperature is >27°C and the air conditioner is off. The conflict logic is that the two rules have the same triggering conditions, but the execution actions (target air conditioner temperature) are contradictory, resulting in a conflict during execution.

[0051] (b) State influences conflict - triggering, corresponding to "rule triggers conflict".

[0052] Rule R6 can be understood as turning on the front door light when the front door is open and the front door light is off; rule R7 can be understood as turning off the camera when the front door light is on and the camera is on. The conflict logic is that the action of R6 (turning on the front door light) will trigger the triggering condition of R7 (the front door light is on), causing R7 to turn off the camera. This is a conflict where the action of one rule triggers the action of another rule.

[0053] (c) State influence conflict - condition, corresponding to "rule condition conflict".

[0054] Rule R9 can be understood as turning on the front door light when the front door is open and the time is between 0:00 and 7:00 AM; rule R6 can be understood as turning on the front door light when the front door light is open and the front door light is off. The conflict logic is that the triggering condition of R9 (nighttime) is an implicit restriction of the triggering condition of R6 (front door light off), causing the two rules to conflict at the condition level (for example, the front door light may have been turned on at night due to R9, making the front door light off condition of R6 not met).

[0055] (d) Environmental impact state conflict - triggering, corresponding to "rule triggering indirect conflict".

[0056] Rule R1 can be understood as turning on the humidifier when the humidity is less than 35% and the humidifier is off; rule R8 can be understood as turning on the dehumidifier when the humidity is greater than 70% and the dehumidifier is off. The conflict logic is that the actions of R1 (humidification) and R8 (dehumidification) directly change the ambient humidity, thus affecting the triggering conditions of the other (e.g., R1 increases the humidity, which may trigger R8; R8 decreases the humidity, which may trigger R1). This is a conflict caused by the environmental state being changed by the rule actions.

[0057] (e) Environmental impact state conflict - condition, corresponding to "rule condition indirect conflict".

[0058] Rule R3 can be understood as turning on the air conditioner and setting it to 20°C when the temperature is >27°C and the air conditioner is off; Rule Rd can be understood as turning on the air conditioner and setting it to 20°C when the temperature is above 27°C and the window is closed. The conflict logic is that the triggering condition of the two rules (temperature >27°C) is indirectly affected by the closed window (environmental factor) (closed windows make it easier for the indoor temperature to rise), resulting in a conflict at the condition level.

[0059] (f) Conflicts in the execution of environmental impacts, corresponding to “indirect conflicts in the execution of rules”.

[0060] Rule R1 can be understood as turning on the humidifier when the humidity is <35% and the humidifier is off; Rule R2 can be understood as turning on the dehumidifier when the humidity is >70% and the dehumidifier is off. The conflict logic is that the actions of R1 (humidification) and R2 (dehumidification) directly change the ambient humidity, causing the other's action to contradict the environmental requirements (e.g., after R1 humidifies, the humidity increases, and although R2's dehumidification action meets the condition of humidity >70%, it is completely opposite to the goal of R1). This is a conflict arising from the change in environment.

[0061] In step S102, a potential rule conflict list and a rule conflict handling strategy are generated by combining the rule interaction list and the entity security configuration, and then combined with personal preference configuration to obtain the final potential rule conflict list and rule conflict handling strategy.

[0062] In the embodiments of this application, the potential rule conflict list refers to a list that records potentially conflicting rule pairs, and includes key information such as conflict description and conflict type, providing a clear object for subsequent conflict handling.

[0063] In addition, the rule conflict handling strategy refers to the strategy for resolving conflicts among potentially conflicting rule pairs in the potential rule conflict list, which is used to ensure system security.

[0064] In actual implementation, this application embodiment can use the rule interaction list obtained by static detection as a basis, compare the interaction rule pairs in it with the entity security configuration pre-configured by the user, automatically determine whether the interaction rule pair belongs to a potential conflict rule pair, and when the interaction rule pair is determined to belong to a potential conflict rule pair, simultaneously mark its interaction description and interaction type as a potential conflict description and potential conflict type, and automatically configure the corresponding rule conflict handling strategy for the conflict pair, forming a preliminary potential rule conflict list and rule conflict handling strategy.

[0065] Furthermore, embodiments of this application can display a preliminary list of potential rule conflicts, along with their corresponding descriptions and types, to users in natural language. Users can then modify the list of potential rule conflicts based on their personal usage habits and preferences: potential rule conflict pairs can be deleted from the list so that the system considers them as normal interaction rule pairs; alternatively, interaction rule pairs that violate personal usage habits and preferences can be marked as potential rule conflict pairs and added to the list of potential rule conflicts from among the normal interaction rule pairs.

[0066] In addition, the embodiments of this application allow users to modify the rule conflict handling strategy based on natural language descriptions, thereby obtaining the final list of potential rule conflicts and the rule conflict handling strategy. While ensuring the security configuration of entities, the potential rule conflict list and rule conflict handling strategy can be made both in line with security specifications and meet the actual needs of users through user-led adjustments based on personal preferences.

[0067] In step S103, the smart home system is dynamically detected based on assertion detection to determine the rule conflicts detected in the dynamic monitoring, and the corresponding processing actions are executed according to the final list of potential rule conflicts and the rule conflict handling strategy.

[0068] In the embodiments of this application, assertion detection refers to a real-time checking mechanism that verifies whether there is a conflict between the current rule and historical rules after the rule is triggered and before the action is executed. This is used to predict conflicts in advance and avoid actual problems caused after the action is executed.

[0069] The following details how to perform dynamic detection on a smart home system based on assertion detection to identify rule conflicts detected during dynamic monitoring, and to execute corresponding processing actions based on the final list of potential rule conflicts and the rule conflict handling strategy.

[0070] Specifically, in one embodiment of this application, assertion detection is used to dynamically detect smart home systems in order to determine rule conflicts detected in dynamic monitoring. This includes performing assertion detection after a rule is triggered and before it is executed to determine whether the currently triggered rule conflicts with past rules.

[0071] In actual implementation, the embodiments of this application can monitor the smart home system in real time through dynamic detection, and limit the detection node to the period after the rule is triggered and before the execution action (i.e. the period before and after the rule condition check, at which time the trigger condition of the rule has been met, but the actual execution action has not yet occurred). By performing dynamic monitoring through assertion detection, it can be determined whether the current triggered rule conflicts with the past rules, so as to determine whether there is a rule conflict before the rule is actually executed and the conflict actually occurs.

[0072] This application provides an assertion detection method for dynamically detecting and determining whether a rule conflict actually occurs in a smart home system. Specifically, it assumes that a rule conflict exists. and rules , express The corresponding environmental attributes specify The symbol indicates that the occurrence of an event is observed and held, including the triggering of a trigger. Passing conditional detection Failed conditional detection With the execution of actions , Indicates an event and The time interval between occurrences is less than , The default value is 0.1 seconds.

[0073] Meanwhile, the assertion expression for "rule enforcement conflict" can be, but is not limited to, as follows: , The assertion expression for "rule triggers conflict" can be, but is not limited to, as follows: , Under the category of "Rules and Conditions Conflicts": If one rule prohibits the condition of another rule, then the assertion expression can be, but is not limited to, as follows: , If one rule is a condition met by another rule, then the assertion expression can be, but is not limited to, the following: , The assertion expression for "indirect conflict in rule enforcement" can be, but is not limited to, as follows: , The assertion expression for "rule triggers indirect conflict" can be, but is not limited to, as follows: , Under the category of "Indirect Conflict of Rules and Conditions": If one rule prohibits the condition of another rule, then the assertion expression can be, but is not limited to, as follows: , If one rule is a condition met by another rule, then the assertion expression can be, but is not limited to, the following: .

[0074] This application embodiment only initiates assertion detection at the detection node, focusing on a targeted comparison between the current triggering rule and past rules, which greatly reduces unnecessary resource consumption and avoids system delays caused by full-process monitoring.

[0075] Specifically, in one embodiment of this application, the corresponding processing action is executed according to the final potential rule conflict list and the rule conflict handling strategy, including: when a conflict arises with past rules, generating a system instruction according to the conflict handling measures of the final potential rule conflict list and the rule conflict handling strategy; and controlling the smart home system to execute the corresponding action in response to the system instruction.

[0076] In actual implementation, when the assertion detection determines that the current triggering rule conflicts with the past rules, this application embodiment does not wait for manual operation by the user, but directly enters the conflict handling. Specifically, it can call the previously determined final list of potential rule conflicts and the rule conflict handling strategy, and automatically generate system control instructions based on the conflict handling measures set therein (such as suspending low-priority rules, adjusting the rule execution order, etc.), and control the smart home system to perform the corresponding actions.

[0077] In addition, since the logical location of conflict handling is completely consistent with dynamic detection, that is, after the rule is triggered and before the action is executed, the embodiments of this application can handle the conflict before the rule conflict actually occurs, thus avoiding the impact of rule conflict on the system or user experience from the source.

[0078] Furthermore, in this embodiment of the application, after the conflict resolution is completed, the processing result can be fed back to the user according to the rule conflict resolution description, so that the user is clearly aware of the conflict type, processing method and final status, thus balancing the efficiency of automated processing with the user's right to know about the system operation.

[0079] Based on the descriptions of other related embodiments, this application provides a method for generating default rule conflict handling measures through entity security configuration, which is used to automatically generate default rule conflict handling measures through the user's entity security configuration. It is understood that the user can configure entity security for all entities in all rule execution actions, such as setting the security status of a "door" to "closed" and the security status of a "camera" to "on".

[0080] Specifically, the embodiments of this application assume and Yes, this is a pair of conflicting rules. and They represent and The security level value indicates the degree to which the rule's execution result favors the entity's security configuration. The default value is 0, meaning it first... and The execution safety level is evaluated. If the execution action is the same as that in the entity's safety configuration, the safety level value is incremented by 1; otherwise, it is decremented by 1. If the entity's safety configuration selects the default, the safety level value remains unchanged, with a default value of 1. This yields the execution safety level of the two rules. Furthermore, based on the safety levels of the two rules, a conflict pair is determined and a handling strategy is assigned, prioritizing the execution of rules with higher safety levels and avoiding the execution of rules with lower safety levels (less than 1). The automatic configuration mapping method based on safety level values ​​is as follows: Regarding "rule enforcement conflict" and "indirect rule enforcement conflict," if If it is determined to be non-conflictual, the handling measure is "default operation (no intervention)". The conflict resolution measure is "only execute". ",if The conflict resolution measure is "only execute". ",if The conflict resolution measure is to "enforce both rules, but with the latter taking precedence." "The End", if The conflict resolution measure is to "enforce both rules, but with the latter taking precedence." "The End", if In this case, the conflict resolution measure is "neither rule shall be enforced"; Regarding "rule triggering conflict" and "rule triggering indirect conflict", if If it is determined to be non-conflictual, the handling measure is "default operation (no intervention)". The conflict resolution measure is "only execute". ",if The conflict resolution measure is "default execution". ",if The conflict resolution measure is "cancel execution". ”; Regarding "rule condition conflict" and "indirect rule condition conflict", if If it is determined to be non-conflictual, the handling measure is "default operation (no intervention)". The conflict resolution measure is "enforcement". ",if The conflict resolution measure is "mandatory non-compliance". ".

[0081] This application embodiment can generate system instructions based on conflict handling measures when assertion detection determines that the current triggering rule conflicts with past rules. This eliminates the need for manual user intervention, enabling immediate interception of conflicts, preventing actual harm, reducing user workload, and improving the ease of use of smart homes. At the same time, the conflict handling measures are integrated with user preferences and physical security configurations, ensuring both accurate adaptation of the handling actions to meet actual user needs and ensuring that security boundaries are not crossed, thus guaranteeing system stability.

[0082] Based on the above description of the embodiments, this application provides an IoT smart home automation rule conflict handling platform, such as... Figure 3 The image shows a smart home interface for centralized management of smart devices and automation rules in the home. In the left-hand operation tab area, the top section is the platform's function navigation bar, which may include, but is not limited to, core function entries such as overview, energy, map, logs, and history, used to view global information such as device status, energy consumption, device location, and operation records. Below are developer tools, configuration, and notifications, used by advanced users to debug rules, modify system configurations, and manage message notifications. At the bottom is the user identifier "cst-zyd," displaying the currently logged-in account for permission management. In the right-hand virtual device area, the status and control options of various smart devices or automation rules are displayed in a list and control format, including, but not limited to, MyRule-Camera, MyRule-FrontDoor, MyRule-FrontLight, MyRule-Clock-DayTime, MyRule-Clock-NightTime, MyRule-conditioner-value, MyRule-HumiditySensor, and MyRule-TemperatureSensor.

[0083] like Figure 4The image shows the environment parameter definition page of the environment settings interface. The page selection can include, but is not limited to, the environment parameter definition page and the rule environment selection page, used to switch between different configuration scenarios. The environment attribute display presents defined environment parameters in a list format, such as kitchen temperature (up / down), living room brightness (up / down), and bedroom humidity (up / down), corresponding to different environmental dimensions (temperature, brightness, humidity) and parameter directions (increase / decrease) for different areas. Each parameter supports deletion for managing existing configurations. In the environment definition input, by adding an environment parameter entry, users can define new environment parameters (such as study humidity, balcony brightness, etc.), expanding the system's perception of the home environment and meeting personalized configuration needs.

[0084] like Figure 5 The image shows the rule environment selection page of the environment settings interface. The rule information displays the specific logic of the automation rules. For example, the rule `automation.r1_humidityhelper1` is "When the ambient humidity is below 35%, turn on the humidifier if it is off," clearly defining the triggering condition and action for each rule, providing a logical basis for subsequent environmental attribute binding. In the rule environment attribute selection, rules are broken down into three dimensions: Trigger, Condition, and Action. Each dimension allows selection of corresponding environmental attributes, distinguishing attribute types. It should be noted that Trigger and Condition environmental attributes belong to sensor environmental attributes (such as detection parameters of humidity and temperature sensors), and can be left unselected if no sensor is present; Action environmental attributes belong to device environmental attributes (such as adjustment parameters of humidifiers and air conditioners).

[0085] like Figure 6The image shows a static detection page for rule conflict detection. The number of conflict types and pairs is categorized by conflict logic, including but not limited to rule execution conflicts (8), state impact conflicts - triggers (4), state impact conflicts - conditions (14), environmental impact state conflicts - triggers (6), environmental impact state conflicts - conditions (3), and environmental impact execution conflicts (2). Each category can be expanded or collapsed for users to view details as needed. Taking environmental impact execution conflicts as an example, the rule conflict type description states, "Two rules interact with two different devices, and these two devices affect shared environmental attributes," helping users understand the nature of this type of conflict (e.g., rule conflicts when humidifiers and dehumidifiers share humidity environmental attributes). The rule conflict pair display lists the specific conflicting rule combinations, such as R1-HumidityHelper1 and R2-HumidityHelper2, R2-HumidityHelper2 and R8-HumidityHelper, clearly identifying the specific rule objects involved in the conflict. The static detection time and number of detection rules are displayed, showing the static detection time (0.0035s) and the number of detection rules (13), demonstrating the advantages of low resource consumption and high speed of static detection, while also indicating the coverage of the detection rules.

[0086] like Figure 7 The image shows the entity security configuration page for configuring rule conflict handling strategies. The page selection may include, but is not limited to, the entity security configuration page and the handling strategy configuration page. The introduction and examples explain that security configuration is required for all entities involved in rule execution actions, such as scenarios like doors always closed, cameras always on, and air conditioners and fans at default settings, clearly defining the scope of application. In the entity security configuration options, taking `input_boolean.frontlight` (front door light) as an example, the dropdown menu provides options such as default, always off, always on, and set value. Users can specify the secure operating state for each entity when a conflict occurs based on the device's security priority (e.g., setting security devices like cameras to always on, and ordinary devices to default). This allows for resolving rule conflicts while prioritizing the security logic of home devices (e.g., critical security devices continue to operate, and ordinary devices adapt flexibly).

[0087] like Figure 8The page shown illustrates the configuration of the rule conflict handling strategy, which treats the camera as a critical security entity. Most devices (such as front door lights, dehumidifiers, humidifiers, air conditioner switches, air conditioner temperatures, and home modes) have their configuration options set to default, indicating that these devices follow the system's or user's usual security logic without any special mandatory state settings, maintaining a flexible operating strategy. `input_boolean.camera` (the camera) is set to always on, indicating that the user considers it a critical security entity (e.g., for home security monitoring) and requires it to remain continuously on, prioritizing its operation even in the event of rule conflicts to avoid security blind spots caused by the camera being turned off due to conflicts.

[0088] like Figure 9 The image shows the rule conflict handling strategy configuration page. The interface description, "The following are static detection results of rule conflicts. Conflicts may not actually occur; a handling strategy is specified for potential conflicts," clarifies that this page is for pre-configuring resolution logic for statically detected potential conflicts. The rule conflict type is rule execution conflict. The rule conflict pair is R1-HumidityHelper1 and R8-HumidityHelper, clearly indicating the two conflicting rules. In the rule description and conflict description, R1-HumidityHelper1 states "If the ambient humidity is below 35%, turn on the humidifier if it is off," while R8-HumidityHelper states "If the ambient humidity is above 65%, turn off the humidifier if it is on." Therefore, a conflict arises, described as a contradiction in the two rules' operations on input_boolean.humidifier (humidifier) ​​(R1 executes turn_on, R8 executes turn_off), leading to a conflicting execution action. In the processing strategy selection, the drop-down menu provides a variety of personalized options, allowing users to choose different operations according to their personal preferences, including but not limited to: default operation; execute only one rule (such as "execute only R1-HumidityHelper1" or "execute only R8-HumidityHelper"); execute both rules, ending with the action of one of the rules (such as "ending with R1-HumidityHelper1"); execute neither rule.

[0089] like Figure 10As shown, the dynamic detection and processing information is displayed. The "Dynamic Detection and Processing - In Progress" interface on the left is used to monitor and handle rule conflicts in real time: In the conflict type, it is a state-affected conflict - triggered; in the conflict rule pair, automation.r6_doorlight and automation.r7_lightcamera; in the conflict description, R6-DoorLight executes the action of turning on the front door light (turn_on), triggering the trigger condition of R7-LightCamera (requiring the front door light to be on), causing R7-LightCamera to execute the action, thus forming a conflict; in the detection efficiency, the dynamic detection time is only 0.0109s, demonstrating the characteristics of low resource consumption and high response speed; in the processing scheme, the default operation is selected, that is, the conflict is automatically processed according to the preset strategy without manual intervention by the user. The "My Home" device status interface on the right displays the device status in real time and is linked to the conflict scenario on the left: MyRule-FrontDoor and MyRule-FrontLight are both on, corresponding to the action of turning on the front door light triggered by R6-DoorLight on the left; MyRule-Camera is off, indicating that R7-LightCamera did not perform the action of turning on due to the conflict (or was not triggered according to the processing strategy), which intuitively reflects the real-time control of device status by dynamic detection and processing.

[0090] The working principle of the IoT smart home automation rule conflict handling method proposed in this application is illustrated below with a specific embodiment.

[0091] Users can configure physical security for devices and configure smart home system zones and environments. The system can automatically model based on the automation rule configuration file to obtain an automation rule model, which is represented as follows: Then, all rule models are traversed and analyzed and tested using formal language analysis tools to obtain a rule interaction list. The rule interaction list contains interaction rule pairs, the interaction types they satisfy, and specific interaction descriptions.

[0092] Furthermore, the system can generate a potential rule conflict list and conflict handling strategy based on the rule interaction list and entity security configuration. Simultaneously, users can configure the final potential rule conflict list and conflict handling strategy according to their personal preferences, and then perform dynamic detection to monitor rule triggering in real time. Specifically, dynamic monitoring through assertion detection can determine whether the currently triggered rule conflicts with past rules. This allows for the determination of whether a rule conflict exists before the rule is actually executed and a conflict actually occurs. If the assertion detection passes, it indicates that a rule conflict has occurred, and the next step is performed; otherwise, it indicates that no rule conflict has occurred, and the system status continues to be monitored.

[0093] Subsequently, the system can execute corresponding conflict resolution measures for detected conflicts. After execution, if there are no changes to the system rules (including user additions, modifications, and deletions of automation rules in the smart home system), the system status will continue to be monitored. Otherwise, the user will be prompted to configure the new rule environment. If the user does not configure, the system status will continue to be monitored. If the user configures, all steps will be re-executed.

[0094] The IoT smart home automated rule conflict handling method proposed in this application can achieve static and dynamic detection of rule conflicts in smart home systems based on automated rule modeling, formal language analysis, and assertion detection. This achieves a high rule conflict detection rate and a low false alarm rate, while effectively reducing system workload through task separation. Furthermore, the automated configuration and execution of rule conflict handling strategies enable rapid decision-making to avoid blocking normal system operation. In addition, it considers both regional and environmental attributes, is unaffected by the diversity of home environments, and can detect rule conflicts that interact through physical channels. It has the advantages of broad detection scope and wide applicability. Moreover, it uses natural language templates to describe rule interactions and conflicts, allowing the system to run automatically. Users only need to complete basic configurations based on natural language guidance and modify conflict markers and rule conflict handling strategies themselves, resulting in a low user burden and a user-friendly experience. Therefore, it solves the problems of related technologies that fail to configure regional and environmental attributes of smart homes, ignore user preferences, leading to weak regional environmental perception, low detection accuracy, high false alarm rates, impact on system operation, and a lack of universal conflict handling strategies.

[0095] Next, with reference to the accompanying drawings, an IoT smart home automation rule conflict handling device according to an embodiment of this application is described.

[0096] Figure 11 This is a block diagram of an IoT smart home automation rule conflict handling device provided according to an embodiment of this application.

[0097] like Figure 11 As shown, the IoT smart home automation rule conflict handling device 110 includes: a generation module 100, an acquisition module 200, and a processing module 300.

[0098] The generation module 100 is used to extract all possible rule interactions according to the automated rule interaction method based on the automated rule model after the user performs physical security configuration, smart home system area configuration and environment configuration, so as to generate a rule interaction list.

[0099] The acquisition module 200 is used to generate a potential rule conflict list and a rule conflict handling strategy by combining the rule interaction list and the entity security configuration, and to obtain the final potential rule conflict list and rule conflict handling strategy by combining personal preference configuration.

[0100] The processing module 300 is used to perform dynamic detection on the smart home system based on assertion detection, in order to determine the rule conflicts detected in the dynamic monitoring, and to execute the corresponding processing actions according to the final list of potential rule conflicts and the rule conflict handling strategy.

[0101] Optionally, in one embodiment of this application, it further includes: an update module, used to supplement the interaction description and interaction type according to the semantics of the rule interaction type, so as to update the rule interaction list.

[0102] Optionally, in one embodiment of this application, the processing module 300 includes: a judgment unit, used to perform assertion detection after the rule is triggered and before its execution, so as to determine whether the currently triggered rule conflicts with past rules.

[0103] Optionally, in one embodiment of this application, the processing module 300 includes a generation unit and a processing unit.

[0104] The generation unit is used to generate system instructions based on the final list of potential rule conflicts and the conflict handling measures of the rule conflict handling strategy when conflicts arise with past rules.

[0105] The processing unit is used to respond to system commands and control the smart home system to perform corresponding actions.

[0106] It should be noted that the foregoing explanation of the embodiment of the IoT smart home automation rule conflict handling method also applies to the IoT smart home automation rule conflict handling device of this embodiment, and will not be repeated here.

[0107] The IoT smart home automated rule conflict handling device proposed in this application can achieve static and dynamic detection of rule conflicts in smart home systems based on automated rule modeling, formal language analysis, and assertion detection. This achieves a high rule conflict detection rate and a low false alarm rate, while effectively reducing system workload through task separation. Furthermore, the automated configuration and execution of rule conflict handling strategies enable rapid decision-making to avoid blocking normal system operation. It also considers both regional and environmental attributes, remaining unaffected by the diversity of home environments, and can detect rule conflicts that interact through physical channels. This gives it the advantages of broad detection scope and wide applicability. Moreover, it uses natural language templates to describe rule interactions and conflicts, allowing the system to run automatically. Users only need to complete basic configurations based on natural language guidance and modify conflict markers and rule conflict handling strategies themselves, resulting in a low user burden and a user-friendly experience. Therefore, it solves the problems of related technologies that fail to configure regional and environmental attributes of smart homes, ignore user preferences, leading to weak regional environmental perception, low detection accuracy, high false alarm rates, impact on system operation, and a lack of universal conflict handling strategies.

[0108] Figure 12 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. The electronic device may include: The memory 1201, the processor 1202, and the computer program stored on the memory 1201 and executable on the processor 1202.

[0109] When the processor 1202 executes the program, it implements the IoT smart home automation rule conflict handling method provided in the above embodiments.

[0110] Furthermore, electronic devices also include: Communication interface 1203 is used for communication between memory 1201 and processor 1202.

[0111] The memory 1201 is used to store computer programs that can run on the processor 1202.

[0112] The memory 1201 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage.

[0113] If the memory 1201, processor 1202, and communication interface 1203 are implemented independently, then the communication interface 1203, memory 1201, and processor 1202 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0114] Optionally, in a specific implementation, if the memory 1201, processor 1202, and communication interface 1203 are integrated on a single chip, then the memory 1201, processor 1202, and communication interface 1203 can communicate with each other through an internal interface.

[0115] The processor 1202 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0116] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for handling conflicting rules in IoT smart home automation.

[0117] This application also provides a computer program product, including a computer program that, when executed, implements the above-described method for handling conflicting rules in IoT smart home automation.

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

[0119] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0120] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0121] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0122] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0123] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0125] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for handling conflicts in IoT smart home automation rules, characterized in that, Includes the following steps: After the user configures the physical security, smart home system area and environment, all possible rule interactions are extracted according to the automated rule model and the automated rule interaction method to generate a rule interaction list. The potential rule conflict list and rule conflict handling strategy are generated by combining the rule interaction list and entity security configuration, and the final potential rule conflict list and rule conflict handling strategy are obtained by combining personal preference configuration. Assertion detection is used to dynamically detect smart home systems in order to identify rule conflicts detected during dynamic monitoring, and to execute corresponding processing actions based on the final list of potential rule conflicts and the rule conflict handling strategy.

2. The method according to claim 1, characterized in that, After generating the rule interaction list, the following is also included: The interaction description and interaction type are supplemented according to the semantics of the rule interaction type to update the rule interaction list.

3. The method according to claim 1, characterized in that, The assertion-based detection-based dynamic detection of the smart home system to determine rule conflicts detected during dynamic monitoring includes: Assertion checks are performed after a rule is triggered and before it is executed to determine whether the currently triggered rule conflicts with past rules.

4. The method according to claim 3, characterized in that, The step of performing corresponding processing actions based on the final list of potential rule conflicts and the rule conflict handling strategy includes: If a conflict arises with the previous rules, a system instruction is generated based on the final list of potential rule conflicts and the conflict resolution measures of the rule conflict resolution strategy. In response to the system commands, control the smart home system to perform corresponding actions.

5. A device for handling conflicting rules in IoT smart home automation, characterized in that, include: The generation module is used to extract all possible rule interactions according to the automated rule interaction method based on the automated rule model after the user has configured physical security, smart home system area and environment, in order to generate a rule interaction list. The acquisition module is used to generate a potential rule conflict list and a rule conflict handling strategy by combining the rule interaction list and the entity security configuration, and to obtain the final potential rule conflict list and rule conflict handling strategy by combining personal preference configuration. The processing module is used to perform dynamic detection on the smart home system based on assertion detection to determine the rule conflicts detected in the dynamic monitoring, and to execute corresponding processing actions according to the final list of potential rule conflicts and the rule conflict handling strategy.

6. The apparatus according to claim 5, characterized in that, Also includes: The update module is used to supplement the interaction description and interaction type according to the semantics of the rule interaction type, so as to update the rule interaction list.

7. The apparatus according to claim 5, characterized in that, The processing module includes: The judgment unit is used to perform assertion checks after a rule is triggered and before it is executed, in order to determine whether the currently triggered rule conflicts with past rules.

8. An electronic device, characterized in that, include: The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the IoT smart home automation rule conflict handling method as described in any one of claims 1-4.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the IoT smart home automation rule conflict handling method as described in any one of claims 1-4.

10. A computer program product, comprising a computer program, characterized in that, The computer program is executed to implement the IoT smart home automation rule conflict handling method as described in any one of claims 1-4.

Images