Smart home layered intent analysis and safe execution method and system, and storage medium

Abstract

The application provides a smart home layered intention analysis and safe execution method and system and a storage medium, and relates to the technical field of smart home control. The method analyzes natural language into structured intention by constructing control context and home capability graph; adopts a layered mechanism to constrain retrieval candidate entities and calculate relevance score; performs risk scoring on control plan based on five dimensions of device risk level, control range, remote access state, time period and instruction conflict state, and adopts a hierarchical confirmation strategy; generates an execution graph and performs state checking, automatically reverts when a strong consistency scene fails; stores the correction result as personalized preference and sets a confidence decay rule. The application can significantly reduce the range of candidate devices, support contextual dialogue, control high-risk devices in stages, reduce the risk of miscontrol, ensure the consistency of complex scene execution, continuously improve the accuracy of alias recognition, and thus improve the efficiency, safety and user experience of smart home control.

Description

Technical Field

[0001] This invention relates to the field of smart home control technology, and in particular to a method, system, and storage medium for layered intent parsing and secure execution in smart homes. Background Technology

[0002] As homes become increasingly digital, they typically house a large number of networked devices, including lighting, curtains, air conditioners, ventilation systems, door locks, cameras, sensors, and scene control panels. While existing smart home platforms can provide device access, status monitoring, and scene linkage capabilities, users still generally rely on fixed buttons, fixed voice templates, or preset automation rules in mobile applications for actual control.

[0003] Existing smart home control solutions based on mobile applications or fixed voice slots typically involve a smart home platform that pre-defines a list of devices, room information, and control pages. Users manually select the target room, device, and action within the application, or input fixed-format commands such as "turn on the living room lights" or "turn off the air conditioner" through a preset voice slot. Upon receiving the command, the platform directly calls the corresponding service interface based on the device identifier to complete the control. However, this type of solution requires users to strictly adhere to the preset format and cannot handle natural language commands with context, ellipsis, pronouns, and ambiguous aliases, such as "turn off all the lights here," "I'm home, turn on the living room comfort mode," or "restore those devices." This results in users repeatedly needing to specify rooms and devices, leading to low interaction efficiency.

[0004] In another chat-based smart home control solution based on direct tool calls from a large model, after the user sends natural language commands through a message channel, the large model directly selects tools and concatenates parameters based on the dialogue text, and initiates requests for entity control, scene activation, or automation triggering to the smart home platform. While this type of solution lowers the operational threshold, when there are many home device entities and complex room aliases, if the large model directly faces all entity names, it is easy to confuse similar aliases such as "main light," "chandelier," "living room light strip," and "floor lamp next to the sofa," resulting in the wrong device being controlled.

[0005] Therefore, a technical solution suitable for smart home control is needed that can leverage the flexibility of natural language interaction and achieve sustainable dialogue and secure execution of smart home control. Summary of the Invention

[0006] This invention provides a method, system, and storage medium for layered intent parsing and secure execution in smart homes, which addresses the problems of weak context inheritance, high misselection rate due to an excessively large range of candidate devices, and lack of hierarchical control over security risks in existing technologies.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, embodiments of the present invention provide a method for layered intent parsing and secure execution in smart homes, comprising: Get the natural language control messages sent by the user through the message channel, and extract the sender identifier and session identifier; The roles and permissions of family members are determined based on the sender identifier, and the recent dialogue memory is read based on the session identifier. The recent dialogue memory includes at least the room area, device entity set and user correction result of the previous round of control hit, and a control context is constructed. Synchronize the mapping of device entities, room areas, and aliases from the smart home platform to generate a home capability map; Layered intent parsing of the natural language control message includes: First layer: Input the natural language control message and the control context into the structured extraction engine, and output a structured intent tuple, which includes action type, target region, target device type, target alias and target value; The second layer: Based on the structured intent tuple and the control context, the device entities in the family capability graph are constrained to retrieve candidate entities, the relevance score is calculated, and the candidate entity set is obtained by filtering according to the score threshold; The third layer: semantic determination is performed within the candidate entity set to identify the target entity and control action; A control plan is generated based on the target entity and control actions; The control plan is expanded into one or more action nodes, and an execution graph is generated based on the dependencies between the action nodes. The action nodes are then scheduled to be executed in the topological order of the execution graph.

[0008] Preferably, the relevance score Calculate using the following formula:

[0009] Where, Aalias represents the device alias matching degree, Aarea represents the room area matching degree, Adomain represents the device domain type matching degree, Asession represents the consistency with the most recent session control object, and Astate represents the adaptability of the device's current state to the target action; α1, α2, α3, α4, and α5 are the weight coefficients of the above scoring factors, and α1+α2+α3+α4+α5=1, and α1, α2, α3, α4, and α5 are all greater than 0; The relevance scores are filtered according to the filtering threshold θ1, and the top K candidate entities with the highest scores are retained as the candidate entity set. In the third-level semantic determination, when the score difference between the two candidate entities with the highest scores in the candidate entity set is less than the score difference threshold θ2, a clarification question is generated; otherwise, the candidate entity with the highest score is selected as the target entity. Here, θ1 and θ2 are threshold parameters that are greater than 0 and less than 1, and K is a positive integer.

[0010] Preferably, after generating the control plan, the following steps are also included: The control plan is risk-scored, and the risk score is calculated based on at least the equipment risk level, control scope, remote access status, time period and command conflict status. The execution strategy is determined based on the risk score results: low risk is executed directly, medium risk is executed after confirmation, and high risk is rejected. The rules for detecting and prioritizing instruction conflict states include: When two control plans under the same household identifier act on the same target object and perform opposite actions within a preset time window, they are marked as conflicting plans; the preset time window T conflict =5s; The control priorities, from highest to lowest, are: security policies or alarm linkage, homeowner's local manual commands, homeowner's remote manual commands, manual commands from ordinary family members, automation rules, and temporary visitor commands. High-priority plans cover low-priority plans. When there is a conflict between plans of the same priority, ordinary low-risk devices shall follow the latest instructions, while high-risk devices shall initiate a second confirmation. When a user's manual command conflicts with an automation rule, the relevant automation is paused for a preset duration, and then reassessed based on the current status after the duration expires; the automation pause duration is T. hold =15min.

[0011] Preferably, the risk score RR(Plan) is calculated using the following formula:

[0012] Wherein, Bdevice is the risk level of the target device, which is the maximum value of the risk value of the device corresponding to each action node in the control plan; Bscope is the number of devices involved in the control and the scope of influence; Bremote is the remote channel access identifier; Btime is the time period risk identifier; Bconflict is the degree of conflict with existing automation rules or instructions; β1, β2, β3, β4, and β5 are the weight coefficients of the above risk factors, and β1+β2+β3+β4+β5=1, and β1, β2, β3, β4, and β5 are all greater than 0; The risk score results are graded according to the first risk threshold R1 and the second risk threshold R2, where 0 < R1 < R2 < 1; when RR(Plan) < R1, it is a low - risk plan and is directly executed; when R1 ≤ RR(Plan) < R2, it is a medium - risk plan and requires user confirmation before execution; when RR(Plan) ≥ R2, it is a high - risk plan and is either rejected or requires a higher - level confirmation.

[0013] Preferably, after expanding the control plan into action nodes, it further includes: classifying the action nodes into a strongly consistent action group Gs and a weakly consistent action group Gw. The strongly consistent action group Gs is an action group where all action nodes within the plan must be executed successfully for the whole to be considered successful, and the weakly consistent action group Gw is an action group where partial action node failures are allowed and the overall execution is still determined to be completed; when any action node in the strongly consistent action group Gs finally fails, the rollback actions are sequentially executed on the successfully executed rollback - enabled nodes according to the state snapshot saved before execution, so that the home state is restored to or close to the state before execution; when an action node in the weakly consistent action group Gw fails, the failed node is added to the compensation queue and the user is notified.

[0014] Preferably, after each action node is executed, it further includes: State verification step: query the real - time state of the target entity and determine whether it reaches the expected state; if it does not reach the expected state, retry within the retry count; if it still fails after retrying, perform rollback compensation or irreversible action remediation according to the rollback - enabled flag of the action node; The rollback compensation or irreversible action remediation includes: for devices that support rollback, perform reverse operations according to the preset rollback action template; for irreversible actions that do not support rollback, perform compensation according to the preset remediation action template. The compensation includes: pushing notifications to a specified terminal, starting countdown monitoring, recording audit logs, upgrading alarms to a third - party platform, or generating a manual handling task.

[0015] Preferably, it further includes a memory update step: Write the set of target entities, user alias preferences, and user correction results of the current execution into the session memory according to the confidence decay and validity period rules for subsequent dialogue inheritance; Among them, the confidence of the set of target entities decays according to the following formula: Confidence_t = C0·e^(-Δt / τ); Among them, C0 is the initial confidence, Δt is the time interval since the most recent control, and τ is the time decay parameter; When Confidence_t is less than the preset confidence threshold Cmin, or Δt is greater than the longest inheritance duration Tmax, the target entity set will no longer participate in the recent session consistency calculation; the validity period of user alias preference is Talias, and the confidence is decreased according to the daily decay coefficient γ; where C0, τ, Cmin, Tmax, and Talias are all preset positive parameters, and γ is a preset decay coefficient greater than 0 and less than 1.

[0016] Preferably, the structured extraction engine triggers a degradation process when the output confidence level is lower than a preset threshold: Level 1 Degradation: Revert to a combination of rule engine and named entity recognition scheme for secondary parsing; Second-level degradation: The field with the highest confidence in the parsed result is compared with the previous round of session context to complete the analysis; Level 3 Degradation: Generate a clarification question to request additional information from the user.

[0017] Secondly, embodiments of the present invention provide a smart home layered intent parsing and secure execution system, comprising: The channel access module is used to acquire natural language control messages sent by users through the message channel and extract the sender identifier and session identifier; The context building module is used to determine the roles and permissions of family members based on the sender identifier, read the recent conversation memory based on the session identifier, and build the control context. The Home Capability Graph module is used to synchronize device entities, room areas, and alias mappings from the smart home platform to generate a home capability graph; The intent parsing module is used to perform hierarchical intent parsing on the natural language control message and output structured intent tuples; The candidate entity scoring module is used to perform constraint retrieval of device entities in the family capability graph based on structured intent tuples and control context, calculate relevance scores, and filter to obtain a set of candidate entities. The semantic determination module is used to perform semantic determination within the candidate entity set by combining the natural language control message and the control context, and to determine the target entity and control action. The execution orchestration module is used to generate a control plan based on the target entity and control actions, expand the control plan into action nodes, generate an execution graph based on dependencies, and schedule execution in topological order.

[0018] Preferably, the system further includes: The risk assessment module is used to score the risk of the control plan and determine the implementation strategy based on the risk score. The status verification and compensation module is used to verify the status after each action node is executed, and to perform retry, rollback compensation or remedial actions when failure occurs. The memory update module is used to write the execution results and user correction results into the session memory and store them according to the decay rules.

[0019] Thirdly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the smart home layered intent parsing and secure execution method described in the first aspect above.

[0020] The technical solution provided by this invention, through mechanisms such as layered intent parsing, context inheritance, risk assessment, execution verification, and session memory, can significantly narrow the range of candidate devices and reduce the device misselection rate compared to existing technologies; support more natural contextual dialogue and reduce repetitive user operations; implement graded control for high-risk devices to reduce the risk of miscontrol; ensure the execution consistency of multi-device linkage in complex scenarios and support failure rollback; and continuously improve the accuracy of alias recognition by learning user correction results, thereby improving the efficiency, security, and user experience of smart home control.

[0021] Compared with the prior art, the present invention has the following beneficial effects: (1) By constructing a control context that includes the room area of ​​the previous round, the set of control devices of the previous round, and the user's correction results, combined with the family capability map, and using a hierarchical intent parsing funnel, the control plan is finally generated and scheduled for execution according to the topological order of the execution graph, thus solving the problem of referential ambiguity in multi-turn dialogue: Since the control context stores the room area and set of devices hit by the previous round of control, when the user issues abbreviated or referential instructions such as "this way", "those ones just now", "turn it down a little", the system can prioritize reasoning within the nearest control range, rather than re-parsing from all devices each time, thereby greatly improving the coherence of multi-turn dialogue and the accuracy of instruction understanding.

[0022] (2) The second layer of the hierarchical intent parsing performs constraint retrieval and filtering on all device entities through relevance scoring, compressing the candidate entity set to a small scale, thereby reducing the selection space of large models or semantic judgment modules from dozens or even hundreds of devices to a manageable scale, thereby reducing the probability of misselecting similar devices.

[0023] (3) Expand the control plan into action nodes and generate a directed acyclic graph. Schedule the execution according to the topology order. It can correctly handle the dependencies between actions (such as turning on the TV first and then adjusting the volume), avoid control failure or abnormal device status due to incorrect execution order, and ensure the execution consistency of complex scenarios.

[0024] (4) The five-dimensional weighted calculation formula for relevance scoring in this invention allows the basis for each device selection to be quantified and traceable (e.g., a device scores zero due to region mismatch), facilitating system debugging and user understanding, overcoming the shortcomings of the "black box" model that is difficult to interpret, and achieving interpretable device selection. The weight setting is based on user behavior statistical analysis, making alias matching, the most intuitive user expression, occupy the largest weight. At the same time, although the session consistency weight is relatively low, it can still play an important role in a short time through the design of the subsequent decay function, thus achieving a balance between accuracy and flexibility.

[0025] (5) A mechanism for risk scoring of control plans and determination of execution strategies (direct execution for low-risk, execution after confirmation for medium-risk, and refusal to execute for high-risk) based on the score value. The risk scoring is based on at least five dimensions: equipment risk level, control scope, remote access status, time period, and instruction conflict status. This enables graded interception of high-risk operations: By combining remote access status and time period with high-risk equipment such as door locks, cameras, and gas valves, the system can automatically push the RR(Plan) to above 0.70 in dangerous scenarios such as remote door opening at night, thereby refusing execution or forcing secondary confirmation, effectively preventing safety accidents. For low-risk equipment such as ordinary lighting and curtains, even under remote access, the RR(Plan) is usually still below 0.35. The system executes directly without user confirmation, ensuring the convenience of daily use and avoiding excessive interference with low-risk operations. It can also dynamically adapt to conflict scenarios: When instruction conflict occurs, the system upgrades the plan to medium-high risk and requires confirmation before execution, avoiding state disorder caused by multiple users controlling simultaneously or conflicts between automated and manual instructions.

[0026] (6) Action nodes are divided into strongly consistent action groups and weakly consistent action groups, and different failure handling strategies are specified to avoid the home state from entering an uncontrollable intermediate state: For security scenarios that require overall success, such as "away mode" and "sleep mode", a strongly consistent group strategy is adopted. If any sub-action fails, all executed actions are rolled back to ensure that the home device state either fully enters the target mode or fully returns to the state before execution, eliminating the security risks caused by partial success such as "the lights are off but the air conditioner is not". For atmosphere scenarios such as "movie mode" and "reading mode", a weakly consistent group strategy is adopted. Even if a certain device (such as a certain ambient light) fails to execute, it will not affect the normal execution of other devices. The user only receives a failure notification, and the overall experience is not significantly affected.

[0027] (7) Status verification steps after each action node is executed: query the real-time status and determine whether the expected status has been achieved. If not, retry within the number of retries. If the retry still fails, perform rollback compensation or irreversible action remedy according to the rollback flag. The system can confirm whether the device has truly reached the target status. For short-term failures caused by network delays, device busyness, etc., compensation is provided through the retry mechanism, which significantly improves the control success rate.

[0028] (8) Distinguish between reversible and non-reversible actions: The subsequent processing method is determined according to the reversible flag. For reversible actions (such as turning lights on and off), the reverse operation can be performed to restore the state. For non-reversible actions (such as unlocking and alarm), the remedial process is initiated to avoid secondary risks caused by incorrect restoration.

[0029] (9) Devices that support rollback perform reverse operations based on the rollback action template; irreversible actions that do not support rollback perform compensation based on the remedial action template, so that even if rollback is not possible, the system can reduce the impact of the fault through notification, auditing, and manual intervention, rather than being helpless. In particular, for high-risk irreversible actions such as door lock unlocking, a tiered remedial approach is adopted, which not only provides users with a window of time for manual correction, but also promptly notifies property management or the police in the event of large-scale anomalies. The remedial template supports user customization and system presets, and can be flexibly configured according to device type and security level, making it easy to adapt to devices from different manufacturers and with different security requirements.

[0030] (10) By introducing a memory update step, the target entity set and the user's correction result of this execution are written into the session memory and stored according to the decay rule for subsequent dialogue inheritance. When the user manually corrects the device pointing (e.g., "I said the main light is the restaurant's main light"), the system stores the correction result as an alias preference memory. The next time the same user issues the same command, it will directly hit the correct device without further clarification, which significantly improves the long-term user experience.

[0031] (11) Dynamically maintain the previous round control set. After each successful execution, update the target entity set hit this time to LastEntitySet, so that instructions such as "turn off all the ones you just controlled" can accurately point to the object controlled most recently, rather than a vague guess. Through the memory mechanism, users do not need to completely repeat room, device type and other information in each session. The system automatically inherits from the context, reducing the user's operational burden.

[0032] (12) The structured extraction engine performs a three-level degradation process when the output confidence is lower than the preset threshold (rule engine + named entity recognition rollback, comparison and completion with the previous context, generation of clarification questions); when the confidence of large model parsing is insufficient, the step-by-step degradation mechanism ensures that the system will not fail directly or output randomly, but will try its best to complete the parsing through rule engine, context completion and other methods; for extremely ambiguous instructions such as "turn that on", the system can initiate clarification through the third-level degradation ("Which device do you want to turn on?"), instead of randomly selecting a device to execute, thus avoiding misoperation; the slower degradation process is only triggered when the confidence is low, and the fast large model parsing is used under normal circumstances, which not only ensures the response speed, but also provides a fallback guarantee.

[0033] It is understood that the beneficial effects of the second and third aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating the smart home layered intent parsing and secure execution method provided in an embodiment of the present invention.

[0035] Figure 2 This is a block diagram of a smart home layered intent parsing and secure execution system provided in an embodiment of the present invention.

[0036] Figure 3 This is a schematic diagram of the layered intent parsing mechanism provided in an embodiment of the present invention. Detailed Implementation

[0037] The technical solutions provided by the embodiments of the present invention will be described below with reference to the accompanying drawings.

[0038] General Description In this embodiment of the invention, the intelligent proxy gateway is a gateway platform that supports message channel access, session management, and tool invocation, and can connect to a smart home platform. Preferably, the intelligent proxy gateway is OpenClaw, and the smart home platform is Home Assistant. It should be noted that this embodiment of the invention is not limited to this preferred embodiment; the intelligent proxy gateway can also be other gateway platforms that support message channel access, session management, and tool invocation, and the smart home platform can also be a Matter gateway platform or a vendor's proprietary platform.

[0039] In this embodiment of the invention, structured intent extraction is preferably achieved by combining prompt words from a large language model system with structured field template constraints. Alternatively, it can be achieved by using a function call mechanism or a rule engine plus named entity recognition. As long as a unified structured intent tuple can be output, the purpose of this embodiment of the invention can be achieved.

[0040] In this embodiment of the invention, the confidence decay formula for LastEntitySet is preferably Confidencet = e - Δt / 30 (where C0 is 1), and when Δt > 60 minutes, it is not included in the Assessment consistency calculation; the alias preference validity period is preferably 30 days, and the confidence decreases by a coefficient of 0.97 per day. It should be noted that these parameters can be adjusted according to the conversation rhythm. For example, the confidence decay formula can also be e - Δt / 60 or e - Δt / 15.

[0041] In this embodiment of the invention, the system is applicable to scenarios where smart home control is performed through messaging channels such as Telegram, WhatsApp, and iMessage, and also applicable to scenarios where smart home control is performed through local channels such as indoor unit local voice and Lilin building intercom.

[0042] Example 1 (Method): like Figure 1 As shown, this embodiment provides a method for layered intent parsing and secure execution in smart homes, including the following steps: Step S101: Obtain natural language control messages and extract identification information.

[0043] Users send natural language control messages through messaging channels (such as Telegram, WhatsApp, and WeChat) accessed via a smart proxy gateway (e.g., OpenClaw). Upon receiving the message, the system extracts the ChannelID, SenderID, SessionID, and MessageText. The SessionID is created by the smart proxy gateway when the user first sends a message and is used to maintain the continuous dialogue context for the same user.

[0044] Step S102: Construct the control context.

[0045] The system queries the family member binding table based on the sender ID (SenderID) to obtain the corresponding family ID (HouseholdID), member roles (e.g., homeowner, family member, visitor), and permission level. Simultaneously, it retrieves the most recent conversation memory from the session storage based on the SessionID, including the LastArea (room area hit in the previous control round), the LastEntitySet (device entity set), the LastIntent (control intent), and the user's most recent correction result (LastCorrection). All of this information together constitutes the control context Ctx = {HouseholdID, SenderRole, PermissionLevel, LastArea, LastEntitySet, LastIntent, LastCorrection, Timestamp}.

[0046] This context allows the system to prioritize reasoning within the most recently controlled scope when subsequent ellipsis or referential expressions such as "this side," "that one just now," or "lower it a bit" appear, instead of starting from all devices each time.

[0047] Step S103: Generate a family capability map.

[0048] The system periodically or before receiving control commands synchronizes the following objects from a smart home platform (such as Home Assistant, Matter gateway, or manufacturer's private platform): device entity, room area, device domain type (lights, air conditioners, curtains, etc.), controllable attributes and value range, current device status, risk level (such as door lock 0.9, air conditioner 0.3, lighting 0.2), user-defined alias, and system alias.

[0049] After synchronization, a family capability graph G is constructed, whose nodes include device entity nodes, area nodes, scene nodes, and automation nodes; edges include relationships such as "located in area", "belongs to domain type", "possesses attributes", "can be called by scene", and "corresponds to alias". Each device entity node contains at least: EntityID, AreaID, DomainType, AliasSet, AttributeSet, CurrentState, RiskLevel, ReversibleFlag (whether rollback is supported), InverseActionTemplate (rollback action template), and CompensationTemplate (remedial action template).

[0050] Step S104: Layered intent parsing.

[0051] like Figure 3 As shown, layered intent parsing includes three sub-layers: First layer: Structured intent extraction In this embodiment of the invention, the inputs to the first layer of structured intent extraction are MessageText, Ctx, allowed output field definitions, region dictionary, and device type dictionary, and the output is a structured intent tuple I={ActionType, AreaName, DeviceType, AliasName, AttributeName, TargetValue, ScopeType, TimeConstraint}. The preferred implementation method combines prompts from a large language model system with structured field template constraints for output, performing unit conversion and range pruning on TargetValue. For example, if a user says "dim the lights in the living room," the system performs text normalization on the MessageText, mapping "dim a little" to a standard action word; it then inputs the normalized text, Ctx, allowed output field definitions, region dictionary, and device type dictionary into the structured extraction engine, limiting the output fields to those defined in I; it performs field missing checks, data type validation, and numerical validity processing on the output results; if validation fails or the confidence level is lower than the preset threshold θ0=0.70, it reverts to the rule engine with named entity recognition for re-parsing; and it performs unit conversion and range pruning on the TargetValue, for example, mapping "dim a little" to a 15% reduction in brightness.

[0052] Second layer: Constraint retrieval and MR(e) scoring Relevance score Calculate using the following formula:

[0053] Where, Aalias represents the device alias matching degree, Aarea represents the room area matching degree, Adomain represents the device domain type matching degree, Asession represents the consistency with the most recent session control object, and Astate represents the adaptability of the device's current state to the target action; α1, α2, α3, α4, and α5 are the weight coefficients of the above scoring factors, and α1+α2+α3+α4+α5=1, and α1, α2, α3, α4, and α5 are all greater than 0; The relevance scores are filtered according to the filtering threshold θ1, and the top K candidate entities with the highest scores are retained as the candidate entity set. In the third-level semantic determination, when the score difference between the two candidate entities with the highest scores in the candidate entity set is less than the score difference threshold θ2, a clarification question is generated; otherwise, the candidate entity with the highest score is selected as the target entity. Here, θ1 and θ2 are threshold parameters that are greater than 0 and less than 1, and K is a positive integer.

[0054] In this embodiment of the invention, the inputs to the second-layer constraint retrieval and MR(e) scoring are I, Ctx, and the family capability graph G, and the output is a candidate entity set C (the first K=5). The preferred weights for each dimension of the candidate entity relevance score MR(e) are 0.35 / 0.25 / 0.20 / 0.15 / 0.05, the preferred filtering threshold θ1 is 0.55, the preferred number of candidates K is 5, and the preferred score difference threshold θ2 is 0.10. It should be noted that these parameters can be adjusted according to the actual application scenario; for example, the weights for each dimension can also be 0.40 / 0.20 / 0.20 / 0.15 / 0.05 or 0.30 / 0.30 / 0.20 / 0.15 / 0.05.

[0055] The specific calculation process in this embodiment is as follows: For each device entity e in G, calculate MR(e) = 0.35Aalias + 0.25Aarea + 0.20Adomain + 0.15Asession + 0.05Astate. Where, Aalias=1-d / Lmax (d is the edit distance), Aarea=1.0 (regions are completely identical) or 0.7 (region aliases are identical) or 0.5 (inherited from LastArea) or 0 (region conflict), Adomain=1.0 (device domain types are completely identical) or 0.6 (belong to the same parent category) or 0.5 (device type is not explicitly given) or 0 (type mismatch), Asession=Ssession·e-Δt / 30 (Ssession=1.0 when e belongs to LastEntitySet, Ssession=0.7 when it is only the same as LastIntent in terms of region and type, and 0.2 in other cases; when Δt>120 minutes, Asession is directly set to 0), Astate=1.0 (device meets the preconditions and will produce a valid state change after execution) or 0.6 (device is in the target state but the action allows idempotent execution) or 0.4 (state unknown) or 0 (attribute is not supported or action cannot be executed). The top K candidates with MR(e)≥θ1=0.55 are retained.

[0056] For example, when a user says "turn on the main living room light," if the main living room light's Aalias=1.0, Aarea=1.0, Adomain=1.0, Asession=0.2, and Astate=1.0, then its MR(e)=0.88. The dining room light, with the same other conditions but Aarea=0, has an MR(e)=0.63. The difference between the two is 0.25 > θ2, so the system directly selects the main living room light. However, if the user only says "turn on the main light" and the top two candidate scores are 0.74 and 0.69 respectively, the system generates a clarification question instead of executing the command directly because the difference is 0.05 < θ2.

[0057] Third layer: Semantic determination within candidates In this embodiment of the invention, the input to the semantic determination of the third-layer candidate entity is the candidate entity set C, MessageText, and Ctx, and the output is the final target entity or a clarification question. The algorithm is as follows: if the score difference between the top two candidate entities is less than the threshold θ2=0.10, the system does not execute directly, but generates a clarification question, such as "Are you referring to the main light in the dining room or the main light in the living room?"; otherwise, the candidate entity with the highest score is selected as the final target.

[0058] Step S105: Generate a control plan.

[0059] Based on the identified target entity and control actions, a control plan is generated. If the command corresponds to a single entity, the plan contains one action node; if it corresponds to a scenario or automation, it is expanded into multiple action nodes.

[0060] Step S106: Generate an execution graph and schedule execution according to the topology order.

[0061] Each action node in the Plan is represented as Node = {EntityID, ServiceType, ServiceParam, Precondition, ExpectedState, Timeout, RetryLimit, RollbackAction, CompensationAction}. If there are dependencies between nodes (e.g., turning on the TV before adjusting the volume), a Directed Acyclic Graph (DAG) is constructed as the execution graph. The system executes nodes in topological order; nodes that are independent and have no dependencies can be executed in parallel to reduce the overall execution time.

[0062] Step S107 (optional): Status verification and rollback compensation.

[0063] After each action node is executed, the following is also included: Status verification steps: Query the real-time status of the target entity to determine whether the expected status has been reached; if the expected status has not been reached, retry within the number of retries; if it still fails after retrying, perform rollback compensation or irreversible action remedy according to the rollback flag of the action node. The rollback compensation or irreversible action remedy includes: for devices that support rollback, performing a reverse operation according to a preset rollback action template; for irreversible actions that do not support rollback, performing compensation according to a preset remedy action template. The compensation includes: pushing a notification to a designated terminal, starting countdown monitoring, recording audit logs, escalating alarms to a third-party platform, or generating a manual handling task.

[0064] Step S108 (optional): Memory update.

[0065] The target entity set, user alias preference, and user correction results of this execution are written into the session memory according to the confidence decay and validity period rules, for use in subsequent dialogues. The confidence level of the target entity set is decayed according to the following formula: Confidence_t=C0·e^(-Δt / τ); Where C0 is the initial confidence level, Δt is the time interval since the most recent control, and τ is the time decay parameter; When Confidence_t is less than the preset confidence threshold Cmin, or Δt is greater than the longest inheritance duration Tmax, the target entity set will no longer participate in the recent session consistency calculation; the validity period of user alias preference is Talias, and the confidence is decreased according to the daily decay coefficient γ; where C0, τ, Cmin, Tmax, and Talias are all preset positive parameters, and γ is a preset decay coefficient greater than 0 and less than 1.

[0066] In this embodiment, when the confidence level output by the structured extraction engine is lower than the preset threshold θ0 = 0.70, the system triggers a three-level degradation mechanism: Level 1 Degradation: Fallback to a combination of rule engine and named entity recognition. The rule engine performs matching based on predefined device type dictionaries, region dictionaries, and action dictionaries; the named entity recognition model (such as BiLSTM-CRF) extracts key entities from the message.

[0067] Second-level downgrade: If the complete structure still cannot be extracted, the field with the highest confidence in the extraction result (e.g., AreaName="Living Room") is compared with the previous round of session context (LastArea) to complete the missing field.

[0068] Level 3 Degradation: If all the above fail, the system generates a clarification question to request additional information from the user, such as "Do you want to control the devices in the living room, or devices in other rooms?" This embodiment also includes a strong consistency / weak consistency grouping and rollback compensation mechanism.

[0069] Grouping Rules: The system dynamically determines the grouping of action nodes based on scenario type and user expression. Strongly consistent action group Gs is suitable for "safe mode" (leaving home, sleeping), user explicit requests such as "together" or "all," or plans containing high-risk devices such as door locks / gas valves. Weakly consistent action group Gw is suitable for "ambience mode" (watching movies, reading), user expressions such as "as much as possible," or independent, undependent devices.

[0070] Rollback strategy: For failed nodes in Gs, the system executes RollbackAction (reverse operation) sequentially on the successfully executed rollbackable nodes based on the state snapshot saved before execution. For example, during the execution of the away mode, if turning off the lights is successful but turning off the air conditioner fails, the system will turn the lights back on and restore the home state to its state before execution.

[0071] Irreversible action remedy: For devices or actions with ReversibleFlag=0 (such as door lock unlocking or alarm triggering), the system executes CompensationAction. Preset remedy templates include: Door lock unlocking: Immediately send an alarm to the homeowner and start a 60-second countdown. If the door is not detected to be closed within the time limit, notify the property management. Gas valve open: A push notification will be sent and the exhaust fan will be turned on automatically. If no confirmation is received within 30 minutes, an upgrade notification will be sent. Alarm triggered: Stop subsequent actions, send cancellation instructions, and record audit logs.

[0072] This embodiment also includes a session memory decay and learning mechanism.

[0073] Memory structure: Each memory record is MemoryItem = {MemoryType, Key, Value, Confidence, UpdateTime, ExpireAt}. MemoryType includes LastEntitySet (the set of objects controlled in the previous round), AliasPref (alias preference), LastCorrection (recent correction), etc.

[0074] Attenuation rule: The confidence level of LastEntitySet decays by Confidencet = e - Δt / 30 (where C0 is 1, and Δt is in minutes). When Confidencet < 0.30 or Δt > 60 minutes, it no longer participates in the Assessment consistency calculation.

[0075] The confidence level of user alias preference decays by 0.97 per day, with a validity period of 30 days. For example, the confidence level of the mapping "main light → restaurant main light" drops from 1.0 to approximately 0.40 if it is not used again within 30 days.

[0076] When a device in the family capability map is deleted, renamed, or moved, the associated memory immediately becomes invalid.

[0077] For example: When the user first says "main light", the system initiates clarification because the scores of the main lights in the living room and the dining room are close. The user selects "the main light in the dining room". The system creates an alias preference record with Confidence = 1.0. The next time the user says "main light", the A_alias of the main light in the dining room is increased to 1.0 and is directly selected without further clarification. If it has not been used again within 30 days, the confidence level drops, and the system may initiate clarification again to avoid the solidification of stale memories.

[0078] This embodiment further includes: risk scoring and conflict detection.

[0079] The risk score RR(Plan) is calculated using the following formula:

[0080] Where Bdevice is the risk level of the target device, which is the maximum value of the risk values of the devices corresponding to each action node in the control plan; Bscope is the number of devices involved in the control and the scope of influence, Bremote is the remote channel access identifier, Btime is the time period risk identifier, and Bconflict is the degree of conflict with existing automation rules or instructions; β1, β2, β3, β4, and β5 are the weight coefficients of the above risk factors respectively, and β1 + β2 + β3 + β4 + β5 = 1, and β1, β2, β3, β4, and β5 are all greater than 0; The risk score result is classified according to the first risk threshold R1 and the second risk threshold R2, where 0 < R1 < R2 < 1; when RR(Plan) < R1, it is a low-risk plan and is directly executed; when R1 ≤ RR(Plan) < R2, it is a medium-risk plan and requires user confirmation before execution; when RR(Plan) ≥ R2, it is a high-risk plan and is rejected or requires a higher-level confirmation.

[0081] In the embodiment of the present invention, the weight of each dimension of the control plan risk score RR(Plan) is preferably 0.40 / 0.15 / 0.15 / 0.10 / 0.20, and the risk classification thresholds are preferably 0.35 and 0.70. It should be noted that these parameters can be adjusted according to the home security policy. For example, the weights of each dimension can also be 0.50 / 0.10 / 0.15 / 0.10 / 0.15 or 0.35 / 0.20 / 0.15 / 0.10 / 0.20.

[0082] In the embodiment of the present invention, the specific calculation process of calculating the control plan risk score using the risk assessment algorithm is as follows: RR(Plan)=0.40Bdevice+0.15Bscope+0.15Bremote+0.10Btime+0.20Bconflict Among them, Bdevice takes the maximum risk value corresponding to all action nodes in the plan (ordinary lighting, curtains 0.2, air conditioning, fresh air 0.3, camera privacy masking or arming switch 0.7, door lock unlocking or unit door opening 0.9, gas valve opening or emergency alarm linkage 1.0), Bscope takes the value according to the number of devices and the scope of impact (single device 0.2, 2-5 devices in the same area 0.5, cross-area scene or automation 0.8, whole house control or involving access control, security, community linkage 1.0), and Bremote takes the value according to the channel type (local panel, indoor unit or LAN 0). 0.1, authorized mobile terminals within the home geofence 0.4, external network chat channel or cross-public network access 1.0), Btime value is determined by time period (06:00-22:00 0.2, 22:00-next day 06:00 0.6, arming away from home or child alone mode 0.8, unattended and high-alert mode 1.0), Bconflict value is determined by conflict status (no conflict 0, conflict with existing automated actions of the same device 0.6, opposite manual command within Tconflict=5s 0.8, conflict with high-priority security policies or homeowner commands 1.0). A tiered strategy is adopted based on RR (Plan): RR<0.35 executes directly, 0.35≤RR<0.70 confirms execution, RR≥0.70 rejects execution.

[0083] To handle scenarios where multiple family members simultaneously issue conflicting commands, and where user commands conflict with automation rules, the system performs conflict detection and priority decision-making before calculating Bconflict, with the following preferred rules: If two control plans under the same HouseholdID act on the same target object and have opposite actions within Tconflict=5s, they are marked as conflicting plans. The control priorities from high to low are: security policies or alarm linkage, homeowner local manual commands, homeowner remote manual commands, ordinary family member manual commands, automation rules, and temporary visitor commands. Higher priority plans override lower priority plans. When there is a conflict between plans of the same priority, ordinary low-risk devices take the latest command as the standard, while high-risk devices initiate a second confirmation. When a user's manual command conflicts with an automation rule, the system suspends the relevant automation for Thold=15min, and then reassesses whether to resume based on the current status after the suspension.

[0084] For example, ordinary lighting switches are generally considered low-risk; controls such as door lock opening, camera deactivation, and gas valve opening are generally considered medium- to high-risk and cannot be executed without confirmation. Furthermore, when a "open the door" command is sent via the external network message channel at night, if Bdevice=0.9, Bscope=0.2, Bremote=1.0, Btime=0.6, and Bconflict=0.8, then RR(Plan)=0.76. The system identifies this as a high-risk plan and requires the homeowner to confirm again or refuse execution directly.

[0085] Example 2 (System): like Figure 2 As shown, this embodiment of the invention provides a smart home hierarchical intent parsing and secure execution system, including a channel access module, a context construction module, a home capability graph module, an intent parsing module, a candidate entity scoring module, a semantic determination module, a risk assessment module, an execution orchestration module, a state verification and compensation module, and a memory update module.

[0086] The connections and data flow between the modules are as follows: Users send control messages through a message channel. The channel access module extracts the message channel identifier, sender identifier, session identifier, and message content. The context construction module queries family member information based on the sender identifier and reads the historical control objects and correction records associated with the session to form a control context. The family capability graph module synchronizes device entities, regions, scenes, and their relationships from the smart home platform to construct a family capability graph. The intent parsing module parses natural language messages into structured intents. The candidate entity scoring module retrieves candidate entities from the family capability graph based on the structured intent and control context and calculates relevance scores. The semantic determination module performs semantic analysis within the candidate entity set, combining the natural language control messages and control context. The system is divided into three modules: 1) Definition and 2) Target entity and control action determination; 3) Execution orchestration module generates a control plan based on the target entity and control action, and expands the control plan into an execution graph of action nodes containing dependencies; 4) Risk assessment module calculates the comprehensive risk score of the control plan and adopts a graded strategy of direct execution, confirmed execution, or rejection based on the risk level; 5) Status verification and compensation module executes actions in the order of dependencies and verifies the actual status of each node, automatically reverting executed actions when execution fails in strongly consistent scenarios, and executing preset remedial actions for actions that cannot be reverted; 6) Memory update module stores the user's correction results as personalized alias preferences, saves the control object from the previous round and sets a time decay mechanism, and sets the memory validity period and confidence decay rules.

[0087] Channel access module: The channel access module receives user control messages from different message channels and extracts the sender identifier, channel identifier, session identifier, and message content. In this embodiment of the invention, message channels include, but are not limited to, Telegram, WhatsApp, iMessage, local voice communication from indoor units, and Liling building intercom. When a user sends a control message through any message channel, the channel access module first extracts the following information: ChannelID (message channel identifier), SenderID (sender identifier), SessionID (session identifier maintained by the intelligent proxy gateway), MessageText (user's natural language message text), and Timestamp (message timestamp). This information is then passed to the context construction module for subsequent context association and control logic processing.

[0088] Context building module: The context building module is used to associate the sender with family member roles, family identifiers, most recently controlled objects, most recently controlled room semantics, and most recently controlled results to form a control context. In this embodiment of the invention, the context building module queries the family member binding table based on the SenderID to obtain the corresponding HouseholdID (family identifier), member role, permission level, and default activity area; at the same time, it reads the most recently spoken conversation memory associated with the SessionID, including the room (LastArea), device set (LastEntitySet), scene name, attribute value, and the user's most recently corrected result (LastCorrection). Subsequently, a control context Ctx is generated, which includes at least: Ctx={HouseholdID,SenderRole,PermissionLevel,LastArea,LastEntitySet,LastIntent,LastCorrection,Timestamp}. In this way, when abbreviated expressions such as "here," "that one just now," "turn them all off," or "turn them down a bit" appear later, the system can first use the session context to narrow down the interpretation scope, instead of re-inferring from all devices every time.

[0089] Family Competency Mapping Module: The Home Capability Graph module is used to synchronize device entities, regions, scenes, automations, attribute ranges, risk levels, and alias mappings from the smart home platform to form a home capability graph. In this embodiment of the invention, the home capability graph module periodically, or before receiving a control command, synchronizes the following objects from the smart home platform: device entities, room regions, device domain types, controllable attributes and value ranges, scene objects, automation objects, current device status, risk levels, user-defined aliases, and system aliases. After synchronization is complete, a home capability graph G is constructed.

[0090] The system includes at least device entity nodes, area nodes, scene nodes, and automation nodes; edges include at least the following relationships: "located in an area," "belongs to a domain type," "possesses attributes," "can be invoked by a scene," and "corresponds to an alias." Each device entity node contains at least the following fields: Entity={EntityID, AreaID, DomainType, AliasSet, AttributeSet, CurrentState, RiskLevel, ReversibleFlag, InverseActionTemplate, CompensationTemplate}. ReversibleFlag indicates whether the action supports rollback, InverseActionTemplate represents the reverse control template when compensation is needed for the device action, and CompensationTemplate represents the remedial action template for non-rollback actions or failed rollbacks. For example, for lighting equipment, the reverse action corresponding to "on" can be set to "off"; for brightness control, the original brightness value can be stored in the rollback template; for door lock unlocking actions, "relock and push an alarm to the homeowner" can be stored in the remedial template.

[0091] Intent parsing module: The intent parsing module extracts natural language into action type, target area, target device type, target alias, target attribute and value, time constraint, and scope through system prompts, function call mechanisms, or rule engines, and performs field validation and missing slot completion. In this embodiment of the invention, the intent parsing module converts natural language into a structured intent tuple I: I={ActionType, AreaName, DeviceType, AliasName, AttributeName, TargetValue, ScopeType, TimeConstraint}. For example, if a user says "dim the lights in the living room that are too bright," the system can extract: ActionType=adjust, AreaName=living room, DeviceType=light, AttributeName=brightness, TargetValue≈reduce by a preset step size.

[0092] Preferably, structured extraction is implemented along the following path: Text normalization is performed on MessageText, mapping expressions such as "dimming a little", "too bright", "26 degrees", and "five minutes later" to standard action words, attribute words, numerical words, and time words; the normalized text, Ctx, allowed output field definitions, region dictionary, and device type dictionary are input into the structured extraction engine. The structured extraction engine preferably uses a large language model system prompt combined with structured field template constraints or a function call mechanism, limiting the output fields to those defined in I; field missing checks, data type validation, and numerical validity processing are performed on the output results; when validation fails or the confidence level is lower than the preset threshold θ0 = 0.70, the process reverts to the rule engine with named entity recognition for re-parsing; unit conversion and range pruning are performed on TargetValue, for example, mapping "dimming a little" to a 15% reduction in brightness and "26 degrees" to an air conditioner setting temperature of 26°C.

[0093] Candidate Entity Scoring Module: The candidate entity scoring module is used to perform constraint retrieval and relevance scoring on device entities in the family capability graph based on intent parsing results and control context. In this embodiment of the invention, the candidate entity scoring module retrieves a set of candidate entities C from the family capability graph based on I and Ctx, and calculates a relevance score MR(e) for each candidate entity e: MR(e)=0.35Aalias+0.25Aarea+0.20Adomain+0.15Asession+0.05Astate The scores for each dimension are normalized to the [0,1] interval and are preferably quantified as follows: Aalias represents the matching degree of the device alias. It is 1.0 when AliasName is exactly the same as the device main name or alias; when it is a fuzzy match, it is calculated as Aalias=1-d / Lmax, where d is the edit distance and Lmax is the maximum length of the two strings; it is 0.5 when the user does not explicitly give an alias; if there is a mapping from the alias to the target entity in the historical bias correction preference table, the larger of the current value and 0.6+0.4Ppref is taken, where Ppref is the preference confidence.

[0094] Aarea represents the room area matching degree. It is 1.0 when the areas are completely consistent; 0.7 when the area aliases are the same or there is a parent-child area relationship; 0.5 when the user does not explicitly give an area but it can be inherited by LastArea; and 0 when there is an area conflict.

[0095] Adomain represents the device type matching degree. It is 1.0 when the device domain types are completely consistent; 0.6 when they belong to the same parent category; 0.5 when the user does not explicitly specify the device type; and 0 when the types do not match.

[0096] Asession represents the consistency with the most recent session control object. Let the time interval between the current entity and the most recent related control be Δt minutes, then Asession = Asessione - Δt / 30; where, when e belongs to LastEntitySet, Asession = 1.0, when it is the same as LastIntent only in terms of region and type, Asession = 0.7, and in other cases, it is 0.2; when Δt > 120 minutes, Asession is directly set to 0.

[0097] Astate represents the compatibility between the device's current state and the target action. It is set to 1.0 when the device meets the preconditions and the action will result in a valid state change; 0.6 when the device is already in the target state but the action allows idempotent execution; 0.4 when the state is unknown; and 0 when the attribute is not supported or the action cannot be executed. Among a set of directly implementable default parameters, the relevance filtering threshold is θ1=0.55, the number of candidates to retain is K=5, and the threshold for the difference in scores between the top two candidates is θ2=0.10.

[0098] Risk assessment module: The risk assessment module is used to classify the risk of the proposed control plan and output the results of direct execution, confirmed execution, or rejection. In this embodiment of the invention, the risk assessment module calculates a risk score RR(Plan) for the control plan: RR(Plan)=0.40Bdevice+0.15Bscope+0.15Bremote+0.10Btime+0.20Bconflict The scores for each dimension are preferably quantified as follows: Bdevice represents the risk level of the target device, taking the maximum value of the risk value corresponding to all action nodes in the plan. Ordinary lighting and curtains are scored as 0.2, air conditioning and fresh air are scored as 0.3, camera privacy masking or arming switching is scored as 0.7, door lock unlocking or unit door opening is scored as 0.9, and gas valve opening or emergency alarm linkage is scored as 1.0.

[0099] Bscope represents the number of devices involved and the scope of impact of this control. Single device control is 0.2; linkage of 2 to 5 devices in the same area is 0.5; cross-area scenarios or automated triggering is 0.8; whole-house control or plans involving access control, security, and community linkage are 1.0.

[0100] Bremote indicates whether it is remote channel control: 0.1 for local panel, indoor unit or LAN channel; 0.4 for authorized mobile terminals within the home geofence; and 1.0 for external chat channel or cross-public network access.

[0101] Btime indicates whether it is currently nighttime, away from home, or a sensitive time period: 06:00 to 22:00 takes 0.2; 22:00 to 06:00 the next day takes 0.6; away from home or in the mode where children are alone takes 0.8; and unattended and in high alert mode takes 1.0.

[0102] Bconflict indicates whether the target action conflicts with existing automation rules, arming status, or the current state of the device. It is 0 when there is no conflict; 0.6 when it conflicts with existing automation actions of the same device; 0.8 when a contrary manual instruction appears within Tconflict=5s; and 1.0 when it conflicts with high-priority security policies or owner instructions.

[0103] The system categorizes plans into three types based on RR(Plan): when RR(Plan) < 0.35, it is a low-risk plan and is executed directly; when 0.35 ≤ RR(Plan) < 0.70, it is a medium-risk plan, requiring the user to confirm through the current message channel before execution; when RR(Plan) ≥ 0.70, it is a high-risk plan, requiring higher-level confirmation or direct rejection with a reason for rejection.

[0104] To handle scenarios where multiple family members issue conflicting commands simultaneously, and where user commands conflict with automation rules, the system performs conflict detection and priority decision-making before calculating Bconflict. The preferred rules are as follows: If two control plans under the same HouseholdID act on the same target object and perform opposite actions within Tconflict=5s, they are marked as conflicting plans. The control priorities from high to low are: security policies or alarm linkage, homeowner's local manual commands, homeowner's remote manual commands, ordinary family member manual commands, automation rules, and temporary visitor commands. Higher priority plans override lower priority plans. When there is a conflict between plans of the same priority, ordinary low-risk devices take the latest command as the standard, while high-risk devices initiate a second confirmation. When a user's manual command conflicts with an automation rule, the system suspends the relevant automation for Thold=15min, and then re-evaluates whether to resume based on the current status after the expiration.

[0105] Semantic determination module: The semantic determination module is used to perform semantic determination within the candidate entity set output by the candidate entity scoring module, combining natural language control messages and control context, to determine the target entity and control action. In this embodiment of the invention, if the relevance score difference between the top two candidate entities is less than the score difference threshold θ2, it is not executed directly, but a clarification question is generated to request confirmation from the user; otherwise, the candidate entity with the highest score is selected as the final target entity, and it is bound to the action type and target value in the structured intent tuple to form the final control action, which is then passed to the execution orchestration module.

[0106] Execution orchestration module: The execution orchestration module expands the control plan into one or more ordered action nodes and generates an execution graph based on dependencies. In this embodiment, the execution orchestration module represents each action node as: Node={EntityID,ServiceType, ServiceParam, Precondition, ExpectedState, Timeout, RetryLimit, RollbackAction, CompensationAction}. If there are dependencies between multiple action nodes, the execution graph is established as a directed acyclic graph. The system executes action nodes in topological order; for action nodes that are independent and have no dependencies, they can be executed in parallel to shorten the total execution time.

[0107] Status verification and compensation module: The status verification and compensation module is used to perform status verification, failure retry, rollback compensation, irreversible action remedy, and exception notification on the execution results. In this embodiment of the invention, the status verification and compensation module performs the following operations after each action node is executed: query the real-time status of the target entity; determine whether the real-time status meets ExpectedState; if it does, record the node as successful; if it does not, retry within the RetryLimit range; if the retry still fails, take compensation measures according to the plan category to which the node belongs. Preferably, this embodiment of the invention divides the action nodes in the control plan into: strongly consistent action group Gs (suitable for scenarios that require overall success, such as "away mode" and "sleep mode") and weakly consistent action group Gw (suitable for actions where failure of some devices does not affect global security), wherein the strongly consistent action group Gs is an action group that requires all action nodes in the plan to be executed successfully in order to be considered as overall success, and the weakly consistent action group Gw is an action group that allows failure of some action nodes but still determines that the overall execution is completed. When any action node in Gs fails, the system executes RollbackAction sequentially on the successfully executed rollback actions based on the state snapshot saved before execution, so that the family state is restored to or close to the state before execution; when an action node in Gw fails, the system can add the failed item to the compensation queue, retry it later, and notify the user of the abnormal result.

[0108] Furthermore, for non-reversible actions with ReversibleFlag=0, or scenarios where RollbackAction fails even for reversible actions, the system executes CompensationAction. Preferably: for notification, broadcast, and message push actions, a correction notification is sent with a manual verification prompt; for security entry actions such as door locks, access control, and garage doors, reverse locking or time-limited recovery is immediately attempted, and the homeowner, indoor unit, or property management terminal is notified simultaneously; for irreversible actions such as alarm triggering and external call linkage, subsequent low-priority actions are stopped, audit logs are recorded, and manual handling tasks are generated; for actions that third-party platforms do not support reverse control, a status snapshot, failure reason, and remedial suggestions are retained for manual remediation.

[0109] Memory update module: The memory update module is used to write the user's correction results, alias preferences, and the set of controlled objects from the previous round back to the session memory according to the confidence decay and validity period rules, for inheritance in subsequent dialogues. In this embodiment of the invention, when the system initiates clarification to the user due to ambiguity, or when the user actively corrects the device's orientation, the memory update module writes the results into the alias preference table and the session memory. For example, if the user says "main light," the system clarifies after the first time that the user refers to "restaurant main light"; the system writes the mapping "main light → restaurant main light" into the preference table corresponding to the HouseholdID and the SenderID; if the same user says "main light" again in a similar time period or similar room semantics, the system prioritizes increasing the alias score of "restaurant main light." At the same time, the system saves the set of target entities successfully executed in the previous round as LastEntitySet. When the user issues commands such as "turn off all of those" or "restore to the previous state" in the next round, the system prioritizes reasoning and restoring LastEntitySet, rather than re-retrieving all entities.

[0110] To avoid miscontrol due to long-term memory solidification, the memory update module stores each memory record in the following structure: MemoryItem={MemoryType, Key, Value, Confidence, UpdateTime, ExpireAt}, and preferably adopts the following decay and expiration rules: The initial confidence of LastEntitySet is 1.0, decaying according to Confidencet=e-Δt / 30, where Δt is in minutes; when Confidencet<0.30 or Δt>60 minutes, it will no longer participate in Assession calculation; the validity period of user alias preferences is preferably 30 days, and the confidence is reset to 1.0 after each explicit correction, and decreased by a coefficient of 0.97 per day; when the same alias has opposite corrections, the latest correction overwrites the old mapping; the validity period of the most recent correction result LastCorrection is preferably 7 days, and it is only effective within the corresponding region and the corresponding sender; when the family capability map is affected by device deletion, device renaming, room relocation, or changes in family member permissions, the relevant memory is immediately invalidated and relearned.

[0111] The working principle is illustrated below with examples from specific application scenarios: Taking a user sending the message "I'm home, turn on the living room comfort mode and dim that light that was too bright" to OpenClaw in the preferred embodiment via Telegram as an example, the system works as follows: The channel access module identifies the sender as family member A and reads their current session ID; the context construction module learns from the last two rounds of dialogue that "that light" corresponds to "the floor lamp next to the living room sofa"; the intent parsing module obtains a structured result through system prompt word constraints and standardizes "dim a little" as a 15% reduction in brightness; the family capability graph module queries the actions of four types of devices corresponding to the living room comfort mode: main light, light strip, air conditioner, and curtains; for "that light that was too bright...", the system... The "too bright light" option, combined with LastEntitySet, elevates the candidate score of the "floor lamp next to the living room sofa" to the highest level. The risk assessment module determines that the control plan only involves general lighting, curtains, and air conditioning, and there are no conflicting plans, classifying it as a low-risk plan. The execution orchestration module first activates the "living room comfort mode," and then performs a brightness reduction action on the "floor lamp next to the living room sofa." The status verification module verifies whether the light brightness, air conditioning mode, and curtain position have reached the target state. If the curtain device times out and fails to respond, the successfully executed strong consistency action is rolled back according to the preset strategy, or the curtain action is added to the compensation queue and the user is returned with the result "living room comfort mode partially successful, curtain will be retried later."

[0112] Example 3 (Storage Medium) This invention also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of the aforementioned smart home layered intent parsing and secure execution method. The computer-readable storage medium is a non-volatile storage medium, including flash memory, solid-state drive, hard disk drive, read-only memory, or programmable read-only memory.

[0113] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art can make various improvements and modifications without departing from the spirit and principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for layered intent parsing and secure execution in smart home systems, characterized in that, include: Get the natural language control messages sent by the user through the message channel, and extract the sender identifier and session identifier; The roles and permissions of family members are determined based on the sender identifier, and the recent dialogue memory is read based on the session identifier. The recent dialogue memory includes at least the room area, device entity set and user correction result of the previous round of control hit, and a control context is constructed. Synchronize the mapping of device entities, room areas, and aliases from the smart home platform to generate a home capability map; Layered intent parsing of the natural language control message includes: First layer: Input the natural language control message and the control context into the structured extraction engine, and output a structured intent tuple, which includes action type, target region, target device type, target alias and target value; The second layer: Based on the structured intent tuple and the control context, the device entities in the family capability graph are constrained to retrieve candidate entities, the relevance score is calculated, and the candidate entity set is obtained by filtering according to the score threshold; The third layer: semantic determination is performed within the candidate entity set to identify the target entity and control action; A control plan is generated based on the target entity and control actions; The control plan is expanded into one or more action nodes, and an execution graph is generated based on the dependencies between the action nodes. The action nodes are then scheduled to be executed in the topological order of the execution graph.

2. The method according to claim 1, characterized in that, The relevance score Calculate using the following formula: Among them, Aalias represents the device alias matching degree, Aarea represents the room area matching degree, Adomain represents the device domain type matching degree, Asession represents the consistency with the most recent session control object, and Astate represents the compatibility between the device's current state and the target action's executableness. α1, α2, α3, α4, and α5 are the weight coefficients of the above scoring factors, and α1+α2+α3+α4+α5=1, and α1, α2, α3, α4, and α5 are all greater than 0. The relevance scores are filtered according to the filtering threshold θ1, and the top K candidate entities with the highest scores are retained as the candidate entity set. In the third-level semantic determination, when the score difference between the two candidate entities with the highest scores in the candidate entity set is less than the score difference threshold θ2, a clarification question is generated; otherwise, the candidate entity with the highest score is selected as the target entity. Where θ1 and θ2 are threshold parameters that are greater than 0 and less than 1, and K is a positive integer.

3. The method according to claim 1, characterized in that, After generating the control plan, the following is also included: The control plan is risk-scored, and the risk score is calculated based on at least the equipment risk level, control scope, remote access status, time period and command conflict status. The execution strategy is determined based on the risk score results: low risk is executed directly, medium risk is executed after confirmation, and high risk is rejected. The rules for detecting and prioritizing instruction conflict states include: When two control plans under the same family identifier act on the same target object and have opposite actions within a preset time window, they are marked as conflicting plans; the preset time window Tconflict = 5s. The control priorities from high to low are as follows: security policies or alarm linkages, local manual instructions from the household head, remote manual instructions from the household head, manual instructions from ordinary family members, automation rules, and temporary visitor instructions; High-priority plans override low-priority plans. When there is a conflict at the same priority, ordinary low-risk devices follow the latest instructions, and high-risk devices initiate a secondary confirmation; When there is a conflict between a user's manual instruction and an automation rule, the relevant automation is paused for a preset duration, and after the expiration, it is re-evaluated based on the current status; the automation pause duration Thold = 15 min.

4. The method according to claim 3, characterized in that, The risk score RR(Plan) is calculated using the following formula: where Bdevice is the risk level of the target device, taking the maximum value of the risk values of the devices corresponding to each action node in the control plan; Bscope is the number of devices involved in the control and the scope of influence, Bremote is the remote channel access identifier, Btime is the time period risk identifier, and Bconflict is the degree of conflict with existing automation rules or instructions; β1, β2, β3, β4, β5 are the weight coefficients of the above risk factors respectively, and β1 + β2 + β3 + β4 + β5 = 1, and β1, β2, β3, β4, β5 are all greater than 0; The risk score results are classified according to the first risk threshold R1 and the second risk threshold R2, where 0 < R1 < R2 < 1; when RR(Plan) < R1, it is a low-risk plan and is directly executed; when R1 ≤ RR(Plan) < R2, it is a medium-risk plan and requires user confirmation before execution; when RR(Plan) ≥ R2, it is a high-risk plan and is rejected or requires a higher-level confirmation.

5. The method according to claim 1, characterized in that, After expanding the control plan into action nodes, it further includes: classifying the action nodes into a strongly consistent action group Gs and a weakly consistent action group Gw. The strongly consistent action group Gs is an action group that requires all action nodes in the plan to be executed successfully to be regarded as a whole success, and the weakly consistent action group Gw is an action group that allows some action nodes to fail and still determines that the overall execution is completed; when any action node in the strongly consistent action group Gs finally fails, the rollback actions are sequentially executed on the successfully executed rollback nodes according to the saved state snapshot before execution, so that the home state is restored to the state before execution or close to the state before execution; when an action node in the weakly consistent action group Gw fails, the failed node is added to the compensation queue and the user is notified; After each action node is executed, it further includes: Status verification step: query the real-time status of the target entity and determine whether it reaches the expected status; if it does not reach the expected status, retry within the number of retry times; if it still fails after retrying, perform rollback compensation or irreversible action remedies according to the rollback flag of the action node; The rollback compensation or irreversible action remedies include: for devices that support rollback, perform reverse operations according to the preset rollback action template; for irreversible actions that do not support rollback, perform compensation according to the preset remedy action template, and the compensation includes: pushing notifications to specified terminals, starting countdown monitoring, recording audit logs, upgrading alarms to third-party platforms, or generating manual handling tasks.

6. The method according to claim 1, characterized in that, It also includes the memory update step: The target entity set, user alias preference, and user correction results of this execution are written into the session memory according to the confidence decay and validity period rules, for use in subsequent dialogues. The confidence level of the target entity set is decayed according to the following formula: Confidence_t=C0·e^(-Δt / τ); Where C0 is the initial confidence level, Δt is the time interval since the most recent control, and τ is the time decay parameter; When Confidence_t is less than the preset confidence threshold Cmin, or Δt is greater than the longest inheritance duration Tmax, the target entity set will no longer participate in the recent session consistency calculation. The validity period of user alias preferences is Talias, and the confidence level is decreased according to the daily decay coefficient γ; Where C0, τ, Cmin, Tmax, and Talias are all preset positive parameters, and γ is a preset attenuation coefficient greater than 0 and less than 1.

7. The method according to claim 1, characterized in that, The structured extraction engine triggers a degradation process when the output confidence level is lower than a preset threshold: Level 1 Degradation: Revert to a combination of rule engine and named entity recognition scheme for secondary parsing; Second-level degradation: The field with the highest confidence in the parsed result is compared with the previous round of session context to complete the analysis; Level 3 Degradation: Generate a clarification question to request additional information from the user.

8. A smart home layered intent parsing and secure execution system, characterized in that, include: The channel access module is used to acquire natural language control messages sent by users through the message channel and extract the sender identifier and session identifier; The context building module is used to determine the roles and permissions of family members based on the sender identifier, read the recent conversation memory based on the session identifier, and build the control context. The Home Capability Graph module is used to synchronize device entities, room areas, and alias mappings from the smart home platform to generate a home capability graph; The intent parsing module is used to perform hierarchical intent parsing on the natural language control message and output structured intent tuples; The candidate entity scoring module is used to perform constraint retrieval of device entities in the family capability graph based on structured intent tuples and control context, calculate relevance scores, and filter to obtain a set of candidate entities. The semantic determination module is used to perform semantic determination within the candidate entity set by combining the natural language control message and the control context, and to determine the target entity and control action. The execution orchestration module is used to generate a control plan based on the target entity and control actions, expand the control plan into action nodes, generate an execution graph based on dependencies, and schedule execution in topological order.

9. The system according to claim 8, characterized in that, Also includes: The risk assessment module is used to score the risk of the control plan and determine the implementation strategy based on the risk score. The status verification and compensation module is used to verify the status after each action node is executed, and to perform retry, rollback compensation or remedial actions when failure occurs. The memory update module is used to write the execution results and user correction results into the session memory and store them according to the decay rules.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images