A device control method and apparatus, an electronic device, and a storage medium

Abstract

The application discloses a device control method and device, an electronic device and a storage medium. The method comprises the following steps: generating scene topology graph data containing device list information, criticality enumeration value, dependent edge and alternative edge; determining target scene topology graph data in response to a scene trigger request, and generating a display scene preview view; constructing a scene device execution queue in combination with an interactive adjustment instruction for the preview view and the dependent edge; and determining a treatment strategy based on the criticality enumeration value and the alternative edge and controlling the device when the target device executes abnormally. The application accurately constructs a delivery queue through a preview interaction and topology dependency, and realizes hierarchical fault-tolerant treatment in combination with criticality and alternative relationship, thereby effectively improving the visual preview capability of smart home scene control, the multi-device collaborative scheduling efficiency and the system operation fault tolerance.

Description

Technical Field

[0001] This invention relates to the field of equipment control technology, and in particular to an equipment control method, an equipment control device, an electronic device, and a readable storage medium. Background Technology

[0002] In the field of intelligent device control, scene control systems typically, upon receiving a user's scene trigger request, directly invoke a pre-defined list of device control commands or a linear sequence of instructions to sequentially drive each device to perform actions. This control approach results in a rigid instruction orchestration model, lacking interactive pre-visualization of the device control effects before the instructions are officially issued. Furthermore, when users make temporary adjustments to scene configurations, existing systems often employ simple temporal sequencing logic to generate the execution queue, neglecting the objectively existing topological dependencies between different devices. This can easily lead to instruction execution timing disorder or device state conflicts during multi-device collaborative control.

[0003] Furthermore, in scenarios where multiple devices collaborate to execute business operations, the relevant technologies primarily rely on a unified timeout retry mechanism or static error throwing rules to handle device malfunctions. Such exception handling mechanisms treat all devices in the scenario equally, lacking consideration for the varying degrees of criticality among different devices, and when a device fails, they can only adopt a single approach: a global direct interruption or blindly continuing to deploy. This often leads to unnecessarily disrupted scenarios due to occasional failures of non-critical devices, or a lack of targeted device replacement and control adjustments when critical devices fail, severely impacting the reliability and continuity of scenario control. Summary of the Invention

[0004] The present invention provides a device control method, apparatus, electronic device, and readable storage medium to overcome or at least partially solve the above-mentioned problems.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a device control method, including: Generate scene topology graph data; the scene topology graph data includes device list information for a preset scene type, keyness enumeration values ​​for expressing the criticality of the device in the preset scene type, dependency edges reflecting the dependency relationship of different devices in the preset scene type, and substitution edges reflecting the substitution relationship of different devices in the preset scene type. In response to receiving a scene trigger request initiated by a user, determine the scene identifier of the target scene corresponding to the scene trigger request; Based on the scene identifier, determine the target scene topology map data corresponding to the target scene from the scene topology map data, and extract the target device list information corresponding to the target scene from the target scene topology map data; Based on the target equipment list information, generate and display the scene pre-simulation view data of the initially determined equipment in the target scene, which corresponds to the target equipment list information; In response to receiving an interactive operation adjustment instruction for the scene preview view data, a scene device execution queue is constructed by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data; When it is determined that an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, a handling strategy for the abnormal event is determined based on the criticality enumeration value and alternative edge in the target scene topology graph data, and the target device is controlled based on the handling strategy.

[0006] Optionally, the step of generating and displaying scene preview view data of the initially determined devices corresponding to the target device list information in the target scene based on the target device list information includes: The current operating status parameters of the initially determined device are queried, and based on the current operating status parameters, status snapshot data reflecting the operating status of the initially determined device before executing the target service is generated, as well as a scenario target status vector representing the target state that the initially determined device is expected to achieve under the target service. Based on the state snapshot data and the scene target state vector, the first state change difference of each device is calculated, and the scene pre-show view data is generated and displayed.

[0007] Optionally, the step of determining a handling strategy for the abnormal event based on the criticality enumeration value and alternative edges in the target scene topology graph data when an abnormal event occurs during the execution of the target service corresponding to the scene trigger request by the target device execution queue, and controlling the target device based on the handling strategy, includes: Determine the device protocol type of the target device in the scene device execution queue; Obtain historical round-trip latency samples corresponding to the device protocol type, and calculate the dynamic timeout threshold of the target device based on the historical round-trip latency samples; Based on the scenario device execution queue, a control instruction frame for the target service is generated and sent to the target device to control the target device to execute the target service; During the execution of the target service by the target device, the response messages of the target device are monitored. When it is determined from the response messages that no response message or protocol layer heuristic confirmation event is received within the dynamic timeout threshold, the target device is identified as an abnormal device, and device abnormality alarm information is generated for the abnormal device. Based on the device anomaly alarm information, retrieve the criticality enumeration value of the abnormal device from the target scene topology map data; When the abnormal device is determined to be a critical device based on the criticality enumeration value, the target device is controlled to perform a rollback operation. When the abnormal device is determined to be a non-critical device based on the criticality enumeration value, a substitute device with a substitution relationship with the abnormal device is determined by the substitution edge of the target scene topology graph data; Control the alternative device to perform the target service.

[0008] Optionally, the step of controlling the target device to perform a rollback operation includes: Freeze other device nodes in the scene device execution queue that have not received the control command frame, and determine the abnormal device attributes of the abnormal device; Based on the abnormal device attributes and the target scene topology map data, a first decision suggestion for the abnormal device is generated and displayed. In response to receiving a first operation instruction for the first decision suggestion, and determining that the first operation instruction is a rollback operation instruction, a list of target devices that have completed the target service before the abnormal device is determined from the status snapshot data. A reverse recovery instruction sequence is generated based on the device list, and the reverse recovery instruction sequence is sent to the target device and the abnormal device in the device list to control the target device and the abnormal device in the device list to perform a rollback operation based on the reverse recovery instruction sequence.

[0009] Optionally, it also includes: If it is determined that the target device or the abnormal device in the device list has timed out during the rollback operation, the target device or the abnormal device in the device list is marked as a recovery abnormal device, and the rollback operation is continued to be performed on the next node device of the recovery abnormal device based on the order of the device list. When it is determined that the traversal of the device list is complete, a rollback report data for the abnormal device is generated and displayed.

[0010] Optionally, the step of controlling the alternative device to perform the target service includes: Based on the target scene topology map data, a second decision suggestion for the alternative device is generated and displayed; In response to receiving a second operation instruction for the second decision suggestion, and determining that the second operation instruction is a replacement operation instruction, the parameter mapping rule data of the replacement device is obtained; Based on the parameter mapping rule data, the scene target state vector is mapped and converted into an equivalent state vector that adapts to the alternative device; Based on the equivalent state vector, a compensation control instruction is generated, and based on the compensation control instruction, the alternative device is added to the scene device execution queue, and the alternative device is controlled to execute the target service based on the equivalent state vector.

[0011] Optionally, it also includes: In response to receiving a replacement success message from the replacement device, generate and display replacement success notification data for the replacement device; In response to receiving a replacement failure message returned by the alternative device, or determining that there is no alternative device that has a replacement relationship with the abnormal device, starting from the abnormal device, the dependency edges in the target scene topology graph data are traversed to extract all successor device nodes that are directly or indirectly dependent on the abnormal device. Generate a list of cascaded affected nodes using the abnormal device and the subsequent device node; Based on the criticality enumeration value of each node in the cascaded affected node list data, the abnormal device and other non-critical devices bound to the abnormal device are separated from the scene device execution queue to generate effective degradation subgraph data. The degradation scenario library data is retrieved from the preset degradation scenario library. The topological isomorphism of each candidate scenario topology graph in the degradation scenario library data and the effective degradation subgraph data is calculated to determine the target degradation scenario topology data. Determine the degraded scenario device and the degraded target state vector corresponding to the degraded scenario device from the target degraded scenario topology data; By combining the state snapshot data with the degraded target state vector, the second state change difference of the degraded scenario device is calculated, and a degraded control instruction sequence is generated; The scene device execution queue is updated based on the degradation control instruction sequence, and the degradation control instruction sequence is sent to the updated scene device execution queue to control the degraded scene device to execute the target service.

[0012] Optionally, it also includes: During the execution of the target service by the device in the downgraded scenario, the execution confirmation message returned by the device in the downgraded scenario is monitored, and an execution result representing whether the device in the downgraded scenario has successfully executed the target service is generated based on the target downgraded scenario topology data and the execution confirmation message. The abnormal event type and the handling strategy for the abnormal event type are determined by using the scene identifier of the target scene, the device identifier of the abnormal device, and any one of the rollback report data, replacement success prompt data, or execution result. Write the abnormal event type and the handling strategy into the user decision strategy table; The user decision strategy table is read at a preset period. When the frequency of using the same handling strategy for the same abnormal event type within a preset sliding window reaches a preset frequency threshold, user preference strategy vector data is generated.

[0013] Secondly, embodiments of this application provide a device control apparatus, including: A scene topology graph data generation module is used to generate scene topology graph data. The scene topology graph data includes device list information for a preset scene type, key degree enumeration values ​​for expressing the criticality of the device in the preset scene type, dependency edges reflecting the dependency relationship of different devices in the preset scene type, and substitution edges reflecting the substitution relationship of different devices in the preset scene type. The scene identifier determination module is used to determine the scene identifier of the target scene corresponding to the scene trigger request in response to receiving a scene trigger request initiated by the user; The target device list information extraction module is used to determine the target scene topology map data corresponding to the target scene from the scene topology map data based on the scene identifier, and extract the target device list information corresponding to the target scene from the target scene topology map data; The scene pre-simulation view data generation module is used to generate and display scene pre-simulation view data of the initially determined equipment in the target scene based on the target equipment list information; The scene device execution queue construction module is used to respond to the interactive operation adjustment instruction obtained for the scene pre-show view data, and construct the scene device execution queue by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data; The target device control module is used to determine a handling strategy for the abnormal event based on the criticality enumeration value and alternative edge in the target scene topology graph data when it is determined that an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, and to control the target device based on the handling strategy.

[0014] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0015] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0016] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0017] The embodiments of the present invention have the following advantages: This invention constructs a scene topology graph containing criticality enumeration values, dependency edges, and alternative edges. After receiving a scene trigger request, it first generates and displays a scene preview view, allowing users to visually preview the expected control effect before the actual issuance of control commands and to make personalized fine-tuning adjustments through interactive operations. Simultaneously, when constructing the scene device execution queue, the user's adjustment commands are combined with the dependency edges in the topology graph, avoiding the problems of command execution sequence disorder and state conflicts caused by ignoring the physical dependencies between devices. Furthermore, when an abnormal event occurs during the execution of the target service, the traditional global interruption or blind retry mechanism is abandoned. Instead, a targeted handling strategy is determined based on the criticality enumeration values ​​and alternative edges, achieving differentiated responses to critical and non-critical device failures. Alternative control paths can be quickly determined using alternative edges, significantly improving the flexibility, reliability, and operational continuity of multi-device collaborative control. Attached Figure Description

[0018] Figure 1 This is a flowchart of the steps of a device control method provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a device control apparatus provided in an embodiment of the present invention; Figure 3 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, and / or denoteing at least one of the connected objects, the character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0021] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0022] Reference Figure 1 The diagram illustrates a flowchart of a device control method provided in an embodiment of the present invention, which may specifically include the following steps: Step 101: Generate scene topology graph data; the scene topology graph data includes device list information for a preset scene type, key degree enumeration values ​​used to express the criticality of the device in the preset scene type, dependency edges reflecting the dependency relationship of different devices in the preset scene type, and substitution edges reflecting the substitution relationship of different devices in the preset scene type. Step 102: In response to receiving a scene trigger request initiated by the user, determine the scene identifier of the target scene corresponding to the scene trigger request; Step 103: Based on the scene identifier, determine the target scene topology map data corresponding to the target scene from the scene topology map data, and extract the target device list information corresponding to the target scene from the target scene topology map data; Step 104: Generate and display scene pre-simulation view data of the initially determined equipment in the target scene based on the target equipment list information; Step 105: In response to receiving an interactive operation adjustment instruction for the scene pre-view data, construct a scene device execution queue by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data; Step 106: When it is determined that an abnormal event occurs in the process of executing the target service corresponding to the scene trigger request by the target device in the scene device execution queue, a handling strategy for the abnormal event is determined according to the criticality enumeration value and alternative edge in the target scene topology graph data, and the target device is controlled based on the handling strategy.

[0023] In this embodiment of the invention, scene topology graph data can be generated to establish a structured topology graph model for a specific scene, which includes a set of devices, the importance of devices, and logical relationships (dependencies and substitutions) between devices, providing a static data baseline for subsequent pre-show view rendering, execution queue construction, and fault tolerance handling.

[0024] In a specific implementation, the scene topology graph data may include device list information for a preset scene type, key degree enumeration values ​​for expressing the criticality of the device in the preset scene type, dependency edges reflecting the dependency relationship of different devices in the preset scene type, and substitution edges reflecting the substitution relationship of different devices in the preset scene type. Scene topology graph data refers to a digital data structure that uses a graph structure to represent device nodes and their interrelationships in a specific scene mode.

[0025] The device list information for a preset scenario type refers to the collection of identifiers and attribute information of all controlled devices included in a specific scenario mode that is predefined or configured.

[0026] Taking "family movie-watching scenario" as an example: Dependency logic: The smart projector turns on when the motorized screen is lowered to 100%.

[0027] Taking the "sleep and bedtime scenario" as an example: Dependency logic: When the main bedroom light is off, the night light dims, and the blackout curtains close.

[0028] Taking the "home security scenario" as an example: Dependency logic: Smart door lock completes locking - Security camera starts - Unnecessary smart sockets are turned off.

[0029] The criticality enumeration value refers to a discrete label or numerical value used to indicate the importance level of each device in the control logic of a specific scenario.

[0030] Dependency edges refer to directional association edges in scene topology graph data used to indicate the execution order, causal conditions, or linkage constraints between different devices.

[0031] Alternate edges refer to the edges in scene topology graph data that indicate that different devices have a mutually substitutable relationship in terms of function or control effect.

[0032] In this embodiment of the invention, in response to receiving a scene trigger request initiated by a user, the scene identifier of the target scene corresponding to the scene trigger request can be determined to capture the user's scene control intent in real time and accurately identify the currently invoked target scene, providing an index for subsequent accurate retrieval of the corresponding topology map data.

[0033] A scenario trigger request refers to a control command signal initiated by a user through an interactive terminal to start a specific scenario service.

[0034] The target scenario refers to the specific scenario mode in which the user is currently requesting execution.

[0035] Scene identifiers refer to strings, numbers, or code indexes used to uniquely define and distinguish different scene modes within the system.

[0036] According to the embodiments of the present invention, the target scene topology map data corresponding to the target scene can be determined from the scene topology map data based on the scene identifier, and the target device list information corresponding to the target scene can be extracted from the target scene topology map data, so as to accurately filter and load the topology map instance of the current target scene and the set of controlled devices covered by it from the global data based on the scene identifier.

[0037] Target scene topology map data refers to specific topology map data retrieved from the global scene topology map data that corresponds only to the current target scene.

[0038] The target device list information refers to the collection of information on all controlled devices involved in the control of the current target scene contained in the target scene topology map data.

[0039] In this embodiment of the invention, scenario pre-simulation view data of the initially determined devices corresponding to the target device list information in the target scenario can be generated and displayed based on the target device list information. Before the actual issuance of control commands, the list of devices to be executed and their expected control effects can be visualized and rendered, so that users can intuitively perceive the expected state after the scenario is executed.

[0040] Initially selected equipment refers to the device nodes initially chosen based on the target equipment list information, which are intended to participate in control actions in the target scenario.

[0041] Scene preview view data refers to the visual view data used to render and display the expected operating status and control effect of each initially determined device on the interactive interface.

[0042] In an embodiment of the invention, in response to receiving an interactive operation adjustment instruction for the scene preview view data, a scene device execution queue is constructed by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data. This queue receives personalized adjustment inputs made by the user based on the preview view and performs fusion constraint parsing with the inherent dependency temporal relationships in the topology map to generate a smooth control queue that takes into account both user intent and physical topology causal relationships.

[0043] Interactive operation adjustment commands refer to the commands that users can use to add, delete, select, or fine-tune parameters of initially selected devices through the interactive interface after observing the scene preview view.

[0044] The scene device execution queue refers to a list of instruction sequences generated by combining the timing constraints of dependency edges and user adjustment instructions, used to guide controlled devices to execute actions in a specific sequential or concurrent order.

[0045] In this embodiment of the invention, when an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, a handling strategy for the abnormal event is determined based on the criticality enumeration value and alternative edges in the target scene topology graph data. The target device is then controlled based on the handling strategy to achieve automated and differentiated fault-tolerant control when a device failure occurs during service delivery or execution, based on the criticality and alternative links defined in the topology graph, thereby ensuring the continuity and stability of the scene service.

[0046] The target device refers to the controlled device currently assigned or receiving control commands in the scene device execution queue.

[0047] The target business refers to the specific control process or functional logic corresponding to the target scenario.

[0048] An abnormal event refers to an unexpected situation that occurs on the target device during the execution of a business, such as timeout failure, communication interruption, or hardware failure.

[0049] The handling strategy refers to the response mechanism for faulty equipment determined based on the criticality enumeration value of the abnormal equipment and the alternative edge.

[0050] This invention constructs a scene topology graph containing criticality enumeration values, dependency edges, and alternative edges. After receiving a scene trigger request, it first generates and displays a scene preview view, allowing users to visually preview the expected control effect before the actual issuance of control commands and to make personalized fine-tuning adjustments through interactive operations. Simultaneously, when constructing the scene device execution queue, the user's adjustment commands are combined with the dependency edges in the topology graph, avoiding the problems of command execution sequence disorder and state conflicts caused by ignoring the physical dependencies between devices. Furthermore, when an abnormal event occurs during the execution of the target service, the traditional global interruption or blind retry mechanism is abandoned. Instead, a targeted handling strategy is determined based on the criticality enumeration values ​​and alternative edges, achieving differentiated responses to critical and non-critical device failures. Alternative control paths can be quickly determined using alternative edges, significantly improving the flexibility, reliability, and operational continuity of multi-device collaborative control.

[0051] This embodiment will be illustrated using a movie-watching scenario in a smart home as an example: The system pre-generates topology data for the movie-watching scene, including a list of devices such as the living room main light, smart curtains, smart blinds, projector, and speakers. The criticality enumeration value is set as follows: the projector and the living room main light are critical devices, while the smart curtains and smart blinds are non-critical devices. The dependency edge is set as follows: the speakers depend on the projector to be turned on. The substitution edge is set as follows: there is a substitution relationship between the smart curtains and the smart blinds.

[0052] The system triggers and identifies the scenario as the user clicking to start the movie-watching mode on the mobile terminal (scenario trigger request). The system identifies the scenario identifier corresponding to this request as SCENEMOVIE001 (the target scenario is the movie-watching scenario).

[0053] The process of determining the topology map and equipment list includes the system retrieving the corresponding movie-watching scene topology map data based on SCENEMOVIE001, and extracting the target equipment list information including the living room main light, smart curtains, smart blinds, projector, and speakers.

[0054] The process of generating and displaying the preview view includes the system rendering and displaying the scene preview view data on the mobile device, with the interface prompting: the main living room light will be turned off, the smart curtains will be drawn, and the projector and speakers will be turned on.

[0055] The process of constructing the scene device execution queue includes the user clicking to deselect the smart blinds on the preview view (interactive operation adjustment command). The system combines this adjustment command with the dependency edge (speaker depends on projector being turned on) to calculate and generate the scene device execution queue: [1. Turn off the living room main light / draw the smart curtains; 2. Turn on the projector; 3. Turn on the speaker].

[0056] The anomaly detection and handling process includes the following: During the execution queue, if a communication timeout occurs (an anomaly event) when the smart curtains are closed, the system retrieves topology data, determines that the smart curtains are non-critical devices, and that there is an alternative edge pointing to the smart blinds. Based on this, the system determines the handling strategy to activate the alternative device and automatically controls the smart blinds to close, thus ensuring the smooth completion of the shading service in the movie-watching scenario without interrupting the entire viewing process.

[0057] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0058] In an optional embodiment of the present invention, the step of generating and displaying scene pre-simulation view data of the initially determined equipment corresponding to the target equipment list information in the target scene includes: The current operating status parameters of the initially determined device are queried, and based on the current operating status parameters, status snapshot data reflecting the operating status of the initially determined device before executing the target service is generated, as well as a scenario target status vector representing the target state that the initially determined device is expected to achieve under the target service. Based on the state snapshot data and the scene target state vector, the first state change difference of each device is calculated, and the scene pre-show view data is generated and displayed.

[0059] In this embodiment of the invention, by actively querying the real-time operating status of the device to be controlled before issuing the scene control command, a multi-dimensional quantitative representation of the initial control baseline and the expected target state is established. Based on the difference between the two states, the dynamic change expectation of the device is accurately calculated and visualized, thereby providing users with an accurate and intuitive basis for scene execution pre-simulation, avoiding the disconnect between the pre-simulation view and the actual control effect due to static evaluation or state distortion.

[0060] Preliminary equipment refers to the controlled equipment initially selected from the target scenario equipment list that is intended to participate in the execution of the target business.

[0061] Current operating status parameters refer to the actual physical operating indicators or logical state values ​​of the controlled equipment at the current moment.

[0062] The target business refers to the specific equipment control process or functional operation to be executed in the target scenario.

[0063] Status snapshot data refers to a dataset that reflects the initial operating baseline of the device, constructed based on the initial operating status parameters of the device before the target service is triggered.

[0064] The scenario target state vector refers to a multi-dimensional numerical vector composed of the target state parameters that each initially determined device is expected to achieve after the successful execution of the target service.

[0065] Each device refers to the initially designated device covered in the target device list information that is intended to receive control commands in the target scenario.

[0066] The first state change difference refers to the quantized numerical difference between the initial scene target state vector of the device and the corresponding state parameter in the state snapshot data.

[0067] Scene preview view data refers to the visual graphics or interface data generated by combining the difference in the first state changes, which is used to intuitively show users the process of the device migrating from the current state to the target state.

[0068] For example, the control system sends status polling or reading commands to each initially determined device in the target device list through the communication interface to obtain the current operating status parameters of each initially determined device in real time, such as the current on / off status, numerical value, or working mode, and encapsulates them into a status snapshot data structure for temporary storage. At the same time, the system retrieves the preset control indicators corresponding to the target service from the scene configuration file to construct a multi-dimensional scene target state vector. Then, the central processing unit performs matrix or numerical subtraction operations on the scene target state vector and the status snapshot data in the corresponding dimensions to obtain the first state change difference of each initially determined device from the current state to the target state. Finally, the interface rendering engine converts the first state change difference into a graphical progress, numerical change prompt, or device action trend animation, and renders it on the user interaction terminal interface as scene pre-show view data for users to view and interact with.

[0069] This invention, through the introduction of a difference calculation mechanism between real-time state snapshot data and scene target state vector, achieves precise quantification of the state transition process before and after device control, effectively overcoming the shortcomings of traditional pre-simulation which relies solely on static templates and cannot reflect the actual physical state of the device. This not only avoids issuing redundant control commands to devices already in the target state, significantly improving the accuracy and realism of the pre-simulation view data, but also enables users to clearly perceive the specific adjustment range and changes of each device, enhancing the predictability and interactive experience of multi-device scene control.

[0070] In an optional embodiment of the present invention, the step of determining a handling strategy for the abnormal event based on the criticality enumeration value and alternative edges in the target scene topology graph data, and controlling the target device based on the handling strategy, when it is determined that an abnormal event occurs in the target device execution queue during the execution of the target service corresponding to the scene trigger request, includes: Determine the device protocol type of the target device in the scene device execution queue; Obtain historical round-trip latency samples corresponding to the device protocol type, and calculate the dynamic timeout threshold of the target device based on the historical round-trip latency samples; Based on the scenario device execution queue, a control instruction frame for the target service is generated and sent to the target device to control the target device to execute the target service; During the execution of the target service by the target device, the response messages of the target device are monitored. When it is determined from the response messages that no response message or protocol layer heuristic confirmation event is received within the dynamic timeout threshold, the target device is identified as an abnormal device, and device abnormality alarm information is generated for the abnormal device. Based on the device anomaly alarm information, retrieve the criticality enumeration value of the abnormal device from the target scene topology map data; When the abnormal device is determined to be a critical device based on the criticality enumeration value, the target device is controlled to perform a rollback operation. When the abnormal device is determined to be a non-critical device based on the criticality enumeration value, a substitute device with a substitution relationship with the abnormal device is determined by the substitution edge of the target scene topology graph data; Control the alternative device to perform the target service.

[0071] In this embodiment of the invention, the timeout threshold is dynamically calculated by combining the communication protocol type of the controlled device and historical round-trip delay samples to achieve high-precision and adaptive device fault determination. At the same time, based on the criticality enumeration value of the device and the alternative edge in the topology graph data, a differentiated fault tolerance and self-healing mechanism is established after the fault (critical device fault triggers rollback, non-critical device fault triggers alternative switching), thereby improving the sensitivity of anomaly detection and the continuity and stability of scene control.

[0072] The scene device execution queue refers to a list of instruction sequences generated by combining device dependencies and user adjustment instructions, used to guide the controlled device to perform actions in a specific time sequence.

[0073] The target device refers to the controlled device currently assigned or receiving control commands in the scene device execution queue.

[0074] Device protocol type refers to the specific communication protocol classification or standard specification followed by the controlled device at the network transport layer or application layer.

[0075] Historical round-trip delay samples refer to the set of data collected and recorded during past communication processes for this device protocol type, showing the time interval between the sending of an instruction and the receipt of a response.

[0076] Dynamic timeout threshold refers to an adaptive time threshold that is calculated in real time based on historical round-trip delay samples using a specific statistical or weighted algorithm to determine whether communication has timed out.

[0077] The target business refers to the specific equipment control process or functional operation to be executed in the target scenario.

[0078] A control command frame is a data packet that is encapsulated according to the device protocol format and contains specific control parameters and action instructions.

[0079] A response message refers to an acknowledgment message or status feedback data packet returned by the target device to the control system after receiving and executing a control command frame.

[0080] Protocol-layer heuristic acknowledgment events refer to heuristic signal events inferred from changes in the underlying protocol state or indirect feedback from neighboring nodes when no explicit response message is received, indicating that the device has received the instruction.

[0081] An abnormal device refers to a controlled device that does not return a response message within the dynamic timeout threshold and does not trigger a protocol-layer heuristic acknowledgment event.

[0082] Equipment malfunction alarm information refers to alarm data used to indicate that a specific device has experienced a control timeout or response failure.

[0083] Target scene topology data refers to the topology data corresponding to the current target scene, which includes device nodes and logical relationships between devices.

[0084] The criticality enumeration value refers to a discrete label or numerical value used to indicate the importance level of each device in the control logic of a specific scenario.

[0085] Critical equipment refers to controlled equipment whose criticality enumeration value reaches a preset high importance level and has a decisive impact on the execution of scenario business.

[0086] A rollback operation refers to the process of undoing executed control actions and restoring the control device to its initial state before executing the target service.

[0087] Non-critical equipment refers to controlled equipment whose criticality enumeration value is at a low importance level, and whose failure will not directly cause the overall failure of the scenario.

[0088] Alternate edges in target scene topology graph data refer to the associated edges in the target scene topology graph data used to indicate that different devices have a mutually substitutable relationship in terms of function or control effect.

[0089] Alternate equipment refers to backup equipment identified through alternative edge retrieval of the target scenario topology graph data, which can replace the faulty equipment and continue to perform the target business.

[0090] In its implementation, the system first identifies the device protocol type (e.g., MQTT, Zigbee, or Modbus) of the target device in the scene device execution queue. It then retrieves historical round-trip latency samples (e.g., mean and variance) of the protocol to calculate an adaptive dynamic timeout threshold and encapsulates control command frames to send to the target device. Subsequently, the system starts a high-precision timer to monitor the device's response messages or protocol-layer heuristic acknowledgment events. If no valid response is received by the time the dynamic timeout threshold is reached, the device is marked as an abnormal device and an alarm is triggered. The system then consults the target scene topology map data to obtain its criticality enumeration value. If the abnormal device is determined to be a critical device, the system immediately sends a reverse recovery command to the relevant devices in the execution queue to perform a rollback operation to avoid state distortion. If the abnormal device is a non-critical device, the system quickly optimizes and locks a substitute device with alternative functions along the alternative edges in the topology map, transfers the target business to the substitute device for continued execution, and ensures the smooth completion of the scene control process.

[0091] For example, the system retrieves a locally maintained library of historical interaction samples of sliding windows based on the type of physical communication protocol used by the target device (such as WiFi, Zigbee, BLEMesh, Matter, etc.).

[0092] Sliding window sample set: The sample set S = t1, t2, ..., t represents the round-trip time (RTT) of the K most recent successful control interactions with devices of this protocol type. K It is updated using a first-in, first-out (FIFO) mechanism.

[0093] WiFi protocol: high communication frequency, relatively stable network, sample window size set to K = 50.

[0094] Zigbee / BLE Mesh protocol: multi-hop networking and greatly affected by channel interference, sample window size is set to K = 20.

[0095] Backup strategy: If the number of newly configured network devices or the current number of successful interactions is less than K, the preset empirical timeout threshold of the protocol (such as 2000ms for Zigbee and 1000ms for WiFi) will be directly used as the initial timeout threshold.

[0096] Based on the obtained sample set S, the dynamic timeout threshold T out The calculation formula is as follows: T out =avg(t) + α·dev(t) + β·t proc avg(t) is the arithmetic mean of the samples, reflecting the underlying network latency under the current protocol; dev(t) is the sample standard deviation, used to quantify the severity of current network jitter and fluctuation; α is the jitter tolerance factor, used to cover long-tail latency. For minimalist WiFi environments, α defaults to 2.0; for complex Zigbee / Mesh environments, α defaults to 2.5. If the system detects a recent increase in timeout rate, α can be dynamically increased by 0.5; β is the device processing margin factor, fixed at 1.0; t proc This refers to the typical hardware instruction processing time for the target device's category, read from the factory configuration or device capability schema (e.g., relay switch t). proc = 30ms, motor-type equipment t proc =100ms).

[0097] This invention effectively eliminates the problems of misjudgment or delayed fault response caused by traditional fixed timeout times by dynamically calculating timeout thresholds based on device protocol type and historical round-trip delay, significantly improving the accuracy and timeliness of device anomaly detection. Simultaneously, it introduces protocol-layer heuristic confirmation events, enhancing the robustness of fault detection in complex network environments. Furthermore, by combining criticality enumeration values ​​and alternative edges in the topology graph, it achieves differentiated and fine-grained fault tolerance after a fault. This allows for timely rollback to protect system consistency in the event of a critical device failure, and seamless switching to alternative devices in the event of a non-critical device failure, greatly improving the self-healing capability and continuous operational stability of the multi-device collaborative control system.

[0098] In an optional embodiment of the present invention, the step of controlling the target device to perform a rollback operation includes: Freeze other device nodes in the scene device execution queue that have not received the control command frame, and determine the abnormal device attributes of the abnormal device; Based on the abnormal device attributes and the target scene topology map data, a first decision suggestion for the abnormal device is generated and displayed. In response to receiving a first operation instruction for the first decision suggestion, and determining that the first operation instruction is a rollback operation instruction, a list of target devices that have completed the target service before the abnormal device is determined from the status snapshot data. A reverse recovery instruction sequence is generated based on the device list, and the reverse recovery instruction sequence is sent to the target device and the abnormal device in the device list to control the target device and the abnormal device in the device list to perform a rollback operation based on the reverse recovery instruction sequence.

[0099] In this embodiment of the invention, when a critical device malfunctions, subsequent device nodes that have not yet sent instructions are frozen in a timely manner to prevent the cascading spread of the fault. Human-computer interaction decision suggestions are generated by combining the attributes of the malfunctioning device and the scene topology diagram. When the user confirms the rollback, the pre-stored state snapshot data is accurately retrieved, and reverse recovery instructions are precisely issued to the devices that have completed the actions and the malfunctioning devices. This ensures the consistency of state, control security, and user controllability in multi-device collaborative scenarios under fault conditions.

[0100] The scene device execution queue refers to a list of instruction sequences generated by combining device dependencies and user adjustment instructions, used to guide the controlled device to perform actions in a specific time sequence.

[0101] A control command frame is a data packet that is encapsulated according to the device protocol format and contains specific control parameters and action instructions.

[0102] An abnormal device refers to a controlled device that does not return a response message within the dynamic timeout threshold and does not trigger a protocol-layer heuristic acknowledgment event.

[0103] Abnormal device attributes refer to characteristic information that reflects the hardware category, fault type, network connectivity, or current fault status of the abnormal device itself.

[0104] Target scene topology data refers to the topology data corresponding to the current target scene, which includes device nodes and logical relationships between devices.

[0105] The first decision suggestion refers to the visualized suggestion information generated based on the abnormal device attributes and the target scene topology map data, which includes the user's choice of handling options such as rollback, retry, or manual intervention.

[0106] The first operation command refers to the trigger selection command made by the user on the interactive interface in response to the first decision suggestion.

[0107] A rollback operation instruction refers to a specific first operation instruction that indicates the user's choice to revoke the system control state and restore it to the initial state before business execution.

[0108] Status snapshot data refers to a dataset that reflects the initial operating baseline of a device, constructed based on the device's current operating status parameters before the target service is triggered.

[0109] The target business refers to the specific equipment control process or functional operation to be executed in the target scenario.

[0110] The target device refers to the controlled device in the scene device execution queue that has been assigned or has executed control commands.

[0111] The device list refers to the set of controlled devices selected from status snapshot data and execution history that have successfully completed the target business control actions before the occurrence of abnormal devices.

[0112] A reverse recovery instruction sequence refers to a set of reverse instructions generated based on the device list and status snapshot data, used to control the relevant devices to reverse the execution of actions and restore the initial state.

[0113] Rollback operation refers to the process by which a controlled device, after receiving a reverse recovery instruction sequence, cancels the executed control actions and restores itself to the initial state before executing the target service.

[0114] For example, when an anomaly is detected in a specific device, the control system immediately applies a freeze state to the device nodes in the scene device execution queue that have not yet issued subsequent instructions to suspend the issuance of subsequent instructions. At the same time, it collects the hardware fault type and communication link attributes of the abnormal device, calculates the scope of the fault impact by combining the target scene topology map data, and pushes a first decision suggestion containing a rollback prompt to the user interaction terminal. The decision generation engine cross-inputs "abnormal device attributes" and "target scene topology data" into the decision matrix, and assembles a suggestion list as follows: 1. Initial screening based on "abnormal device attributes" (determining the option framework): Critical devices: High security / core function risk, the system tightens the decision chain, and a default 2-option framework is generated (rollback / forced continue). Non-critical devices: Large fault tolerance margin, the system expands the decision chain, and a default 4-option framework is generated (replace / degrade / skip / rollback).

[0115] 2. Conditional Enrichment Based on "Scene Topology Map Data" (Filling in Specific Suggestions): If there are alternative edges in the topology: Retrieve the online status of alternative devices. If available alternative devices exist, activate and prioritize "Enable Alternative Device Compensation" in the suggestions, and automatically calculate parameter mapping relationships. If there are dependent edges in the topology: Calculate the impact radius of the node failure on downstream successor nodes: If all downstream dependent nodes are non-critical devices, recommend "Skip and Continue" in the suggestions, and mark the impact range; if downstream dependent nodes include critical devices, disable "Skip and Continue," and indicate the risk of dependency interruption. Associate with the Degradation Scene Library: Perform fuzzy matching using scene intent tags. If there are degradation sub-scenes with high similarity (Jaccard similarity ≥ 0.5) and fully usable devices, recommend "Switch to Degradation Scene" in the suggestions.

[0116] Specific types and examples of first decision recommendations: Recommendation 1: Enable Alternative Substitution Applicable conditions: The abnormal device is a non-critical device, and there are alternative edges in the topology graph pointing to other available devices.

[0117] The accompanying text reads: "The main light is not responding. We recommend using the [Living Room Ambient Light Strip] as an alternative lighting source (it has been automatically matched with the optimal color temperature and brightness)." Underlying mechanism: The engine reads the ParameterMapper mounted on the alternative edge, maps the original target parameters (such as 80% brightness of the main light) proportionally and trims them to the capability range of the alternative device (such as 60% brightness of the ambient light), and constructs a new compensation node to insert into the scene queue.

[0118] Recommendation 2: Skip and Continue Applicable conditions: The abnormal device does not affect the core dependency path (the subsequent nodes have no strong dependency relationship), or the subsequent dependency nodes are all non-critical devices.

[0119] The message reads: "Fragrance diffuser communication timed out. This device does not affect the main process. It is recommended to skip the fragrance diffuser and continue to complete the initialization of the remaining viewing devices." Underlying mechanism: The controller marks the device node as SKIPPED in the session state table, unfreezes subsequent blocked independent branch device nodes, and keeps the scene process moving forward.

[0120] Recommendation 3: Switch to a fallback scene. Applicable conditions: When critical equipment malfunctions but the user wishes to retain some of the scene atmosphere, or when non-critical equipment malfunctions and there are pre-built degradation alternatives with highly overlapping functions.

[0121] The accompanying text reads: "Smart projector failed to start. We recommend switching to the downgraded option [Soft Light Music Mode] (which will keep the screen lowered and play background music)." Underlying mechanism: The controller seamlessly switches the current execution session to the degraded scenario ID, uses the same state snapshot, skips the initialization steps of the failed device, and only executes the remaining available devices in the degraded scenario topology.

[0122] Recommendation 4: Force Continue with Override Applicable conditions: Critical equipment is malfunctioning, but the user explicitly wants to ignore dependency checks and force the process to proceed.

[0123] The text message reads: "The motorized screen is not in place. Forcibly turning on the projector may result in abnormal image projection. Are you sure you want to [force continue]?" Underlying mechanism: The controller writes the dependency_override flag in the dynamic policy patch to remove the blocking constraint of the node on the successor node and continue to issue subsequent instructions.

[0124] When the user clicks to confirm the rollback on the terminal (triggering the rollback operation command), the system parses the previously saved state snapshot data and automatically sorts out the list of target devices that have successfully executed commands before the abnormal device appeared. Then, the system reverse-engineers the recovery parameters based on the initial state of each device in the device list and the abnormal device, generates a reverse recovery command sequence, and synchronously sends it to all target devices and abnormal devices in the device list, thereby driving each device to revert to the initial state according to the reverse logic, completing the controlled rollback of the entire scenario.

[0125] This invention, by freezing device nodes that have not sent instructions in the event of a device malfunction, completely prevents the cascading spread of faults and erroneous actions in the scenario topology network, greatly improving the system's fault prevention and escalation capabilities. Simultaneously, by proactively generating first decision suggestions based on the attributes of the malfunctioning device and topology data, human-computer interaction decision-making is introduced into the anomaly handling process, granting users the right to know and decide on high-risk rollback operations. Furthermore, based on the state snapshot data before business execution, the completed device list is accurately identified and a reverse recovery instruction sequence is issued, ensuring absolute consistency between the rollback path and historical states. This effectively avoids multi-device state distortion and security risks caused by blind or partial recovery, significantly improving the fault tolerance, security, and state consistency recovery capabilities of complex collaborative scenarios.

[0126] In an optional embodiment of the present invention, it further includes: If it is determined that the target device or the abnormal device in the device list has timed out during the rollback operation, the target device or the abnormal device in the device list is marked as a recovery abnormal device, and the rollback operation is continued to be performed on the next node device of the recovery abnormal device based on the order of the device list. When it is determined that the traversal of the device list is complete, a rollback report data for the abnormal device is generated and displayed.

[0127] In this embodiment of the invention, a fault-tolerant traversal and status aggregation mechanism based on the device list arrangement order is established during the rollback operation. By accurately marking and isolating recovery timeout nodes that occur during the rollback process, blocking nodes are skipped and subsequent devices are driven to perform rollback recovery. After the traversal is completed, a panoramic rollback report data is generated and displayed, thereby avoiding rollback process deadlock or system deadlock and ensuring the completeness, fault tolerance and traceability of the scenario recovery process.

[0128] The device list refers to the set of controlled devices selected from status snapshot data and execution history that have successfully completed the target business control actions before the occurrence of abnormal devices.

[0129] The target device refers to the target controlled device in the device list that participates in the rollback recovery.

[0130] Abnormal equipment refers to controlled equipment that experiences an initial failure in the aforementioned control process and requires rollback recovery.

[0131] Rollback operation refers to the process by which a controlled device, after receiving a reverse recovery command, cancels the actions already performed and restores itself to its initial operating state.

[0132] Recovery timeout refers to the situation where the device fails to return a successful rollback confirmation message within the preset recovery response time when performing a rollback operation.

[0133] Recovery of abnormal devices refers to the target device or abnormal device that experiences a recovery timeout during the rollback operation.

[0134] The order of arrangement refers to the sequence in which the devices in the device list are executed according to the timing or dependency relationship of the target service.

[0135] A node device refers to a logic diagram node unit in the device list that corresponds to each specific controlled device.

[0136] Traversal refers to the complete process of issuing reverse recovery commands to each device in the order of the device list and monitoring their rollback status.

[0137] Rollback report data refers to the summary report data generated after the device list has been traversed, which is used to statistically analyze and display the rollback execution results, success rate, and details of recovery anomalies for each device.

[0138] For example, the control system sequentially sends reverse recovery commands to each target device and abnormal device according to the order of dependency sequence in the device list, and starts a high-precision recovery timer to listen for the response from each device. When it is detected that a device has not returned a recovery success confirmation message within a preset time (i.e., it is determined to be a recovery timeout), the system does not stop the entire rollback process, but marks the device as an abnormal recovery device and writes it to the log. Then, it automatically extracts the next node device in the device list and continues to send reverse recovery commands until the sequential traversal of all nodes in the device list is completed. Finally, the system summarizes the execution details of successfully rolled-back devices and abnormal recovery devices, generates graphical or structured rollback report data, and displays it on the user interface so that maintenance personnel or users can accurately grasp the final result of the scenario recovery.

[0139] This invention, by introducing node-level timeout marking and an automatic skip continuation mechanism into the rollback process, completely solves the problem of the entire scenario rollback being interrupted and the system permanently deadlocked due to a single device's rollback failure or recovery failure. This greatly enhances the rollback process's anti-interference capability and execution completeness. Simultaneously, traversing based on a strict device list arrangement order ensures that the remaining recoverable nodes can still safely undone according to the correct logical sequence, maximizing the recovery of the scenario state. Furthermore, by generating visualized rollback report data after the traversal is completed, users and maintenance personnel can intuitively and accurately locate the faulty nodes that failed to recover, providing comprehensive and traceable data support for subsequent precise manual intervention and fault diagnosis.

[0140] In an optional embodiment of the present invention, the step of controlling the alternative device to perform the target service includes: Based on the target scene topology map data, a second decision suggestion for the alternative device is generated and displayed; In response to receiving a second operation instruction for the second decision suggestion, and determining that the second operation instruction is a replacement operation instruction, the parameter mapping rule data of the replacement device is obtained; Based on the parameter mapping rule data, the scene target state vector is mapped and converted into an equivalent state vector that adapts to the alternative device; Based on the equivalent state vector, a compensation control instruction is generated, and based on the compensation control instruction, the alternative device is added to the scene device execution queue, and the alternative device is controlled to execute the target service based on the equivalent state vector.

[0141] In this embodiment of the invention, when a non-critical equipment failure is detected and a replacement equipment is selected, a second decision suggestion is displayed interactively and combined with the user's replacement instruction. The original scene target state vector is heterogeneously converted into an equivalent state vector that adapts to the replacement equipment using parameter mapping rules. Compensation control instructions are generated and dynamically incorporated into the scene equipment execution queue. Thus, seamless replacement between heterogeneous equipment and precise compensation control of target services are achieved while ensuring controllable human-computer interaction.

[0142] Target scene topology data refers to the topology data corresponding to the current target scene, including device nodes and their substitution relationships.

[0143] Alternative devices refer to controlled devices that are associated with abnormal devices through alternative edges in the target scene topology graph data and have the ability to replace functions.

[0144] The second decision suggestion refers to the suggestion information generated based on the target scene topology map data and pushed to the user, suggesting whether to enable alternative devices for function replacement.

[0145] The second operation command refers to the control input command made by the user on the interactive interface in response to the second decision suggestion.

[0146] A replacement operation instruction is a specific second operation instruction that explicitly instructs the system to use an alternative device to replace the malfunctioning device in performing its business.

[0147] Parameter mapping rule data refers to the mapping function or quantization conversion rule used to convert the control parameters or status indicators of the original abnormal equipment into attributes that are suitable for the replacement equipment.

[0148] The scenario target state vector refers to a multi-dimensional numerical vector composed of the target state parameters that the original abnormal device is expected to achieve under the target service.

[0149] An equivalent state vector refers to a state parameter vector generated by transforming the scene target state vector using parameter mapping rule data, which enables alternative devices to achieve the same or equivalent business effects.

[0150] Compensation control commands refer to specific control command data packets generated based on equivalent state vectors, used to drive alternative equipment to perform replacement actions.

[0151] The scene device execution queue refers to a list of instruction sequences used to guide controlled devices to execute actions in a specific timing or logical order.

[0152] The target business refers to the specific equipment control process or functional operation to be executed in the target scenario.

[0153] For example, after identifying a replacement device, the control system first combines the target scene topology map data to push a second decision suggestion on the user interface, which includes the name of the replacement device and an assessment of the impact of the replacement. The triggering timing and generation logic of the second decision recommendation are as follows: Dependency Edges of Alternative Devices in the Topology: Whether turning on an alternative device will hinder or trigger the actions of other devices (e.g., whether turning on an alternative light strip requires the smart socket in front to be powered on first).

[0154] The parameter mapping function between the alternative device and the original device: whether there are limitations such as parameter overflow or color temperature / power mismatch after capability mapping.

[0155] Composite Substitution Edges: Does it have options for "single-device partial substitution" and "multi-device combined collaborative substitution"?

[0156] Specific types and examples of second decision recommendations Example 1: Suggestions for adjusting linked nodes (transitive topology dependencies) Topology: The main light (abnormal target) is replaced by a "floor lamp (alternative device)". The topology graph contains a dependency edge: floor lamp -> smart wall socket (the floor lamp depends on the socket for power).

[0157] The second decision recommendation is: "The floor lamp is currently offline / power off. It is recommended to use the automatic power-on smart socket and enable the floor lamp as a replacement." Underlying logic: Based on the dependent edges in the topology graph, the system automatically adds the opening instructions of the upstream dependent nodes (sockets) to the second decision suggestion to avoid replacement failure.

[0158] Example 2: Suggestions for Parameter Limitation and Atmosphere Compromise (Capacity Mapping Constraints) Topology: The projector's main lighting (target) requires a brightness of 800lm; the topology diagram replaces the edge main light -> ambient light strip mounting parameter mapping function, but the maximum output of the light strip is only 300lm.

[0159] Second decision recommendation: "The maximum brightness of the ambient light strip can only reach 40% of the original main light. It is recommended to choose: [Option A: Turn on the maximum brightness compensation of the light strip] or [Option B: Simultaneously turn on the wall lights for combined compensation]." Underlying logic: Based on the mapping calculation, it is found that the capability of a single alternative device is insufficient. Combined with the parallel alternative edges in the topology graph, a second suggestion is generated to provide single-device limit compensation or multi-device combination compensation.

[0160] Example 3: Secondary replacement / downgrade fallback recommendation (replacement device itself is faulty) Topology: The system is preparing to use "living room light strip" to replace "living room main light", but the real-time topology status shows that "living room light strip" is also in an abnormal / timeout state; there is a secondary replacement edge in the topology graph: living room light strip -> balcony viewing light.

[0161] Second decision recommendation: "The primary alternative device [living room light strip] is also unresponsive. Based on the scene topology, it is recommended to enable the secondary alternative device [balcony viewing light], or switch to degraded mode." Underlying logic: Based on the alternative edge hierarchy (first-level alternative - second-level alternative) in the topology graph, a second-level alternative decision is generated when the preferred alternative device fails.

[0162] Example 4: Suggestions for resolving scenario conflicts (removing reverse dependencies) Topology: The "main light" in the movie-watching scene is malfunctioning, and it is proposed to use "electric curtains half-open (letting in a little outdoor light)" as a replacement. However, there is a strong constraint in the topology diagram: Movie-watching mode -> curtains must be fully closed.

[0163] Second decision recommendation: "Using half-open curtains as a substitute for supplemental lighting will compromise the shading requirements for movie viewing. Recommendation: [Confirm the removal of shading restrictions and partially open the curtains] or [Abandon the curtains as an alternative and use a mobile phone / remote control for dim lighting]." Underlying logic: If a conflict is detected between the control parameters of the alternative device and the global constraints of the target scene topology, a confirmation suggestion for removing the constraint or changing the solution is generated.

[0164] When the user clicks to confirm the replacement (i.e., triggers the replacement operation command), the system automatically retrieves the parameter mapping rule data corresponding to the replacement device. Through unit conversion, scale mapping, or protocol conversion algorithms, the system maps the scene target state vector of the original abnormal device into an equivalent state vector that adapts to the hardware characteristics of the replacement device. Subsequently, the system assembles and generates compensation control commands based on the equivalent state vector, dynamically inserts the replacement device into the current scene device execution queue, and sends the compensation control commands to the replacement device to drive the replacement device to output equivalent functional control effects, seamlessly taking over the target business of the original abnormal device.

[0165] This invention, through deep integration of decision confirmation and heterogeneous parameter conversion, ensures the safety of human-computer interaction and the user's right to know during the replacement device takeover process through a second decision suggestion, avoiding unexpected risks caused by blind replacement. On the other hand, by accurately converting the original state vector into an equivalent state vector suitable for the replacement device through parameter mapping rule data, it solves the industry problem that devices of different brands, models, or protocols cannot be directly replaced due to incompatible control parameters. This enables dynamic reconstruction and seamless compensation control of the scene device execution queue, greatly ensuring the continuous operation stability and high availability of services in multi-device collaborative scenarios when local devices fail.

[0166] In an optional embodiment of the present invention, it further includes: In response to receiving a replacement success message from the replacement device, generate and display replacement success notification data for the replacement device; In response to receiving a replacement failure message returned by the alternative device, or determining that there is no alternative device that has a replacement relationship with the abnormal device, starting from the abnormal device, the dependency edges in the target scene topology graph data are traversed to extract all successor device nodes that are directly or indirectly dependent on the abnormal device. Generate a list of cascaded affected nodes using the abnormal device and the subsequent device node; Based on the criticality enumeration value of each node in the cascaded affected node list data, the abnormal device and other non-critical devices bound to the abnormal device are separated from the scene device execution queue to generate effective degradation subgraph data. Data from the pre-set degradation scenario library is retrieved. The topological isomorphism of each candidate scenario topology graph and the effective degradation subgraph data in the degradation scenario library data is calculated to determine the target degradation scenario topology data. Determine the degraded scenario device and the degraded target state vector corresponding to the degraded scenario device from the target degraded scenario topology data; By combining the state snapshot data with the degraded target state vector, the second state change difference of the degraded scenario device is calculated, and a degraded control instruction sequence is generated; The scene device execution queue is updated based on the degradation control instruction sequence, and the degradation control instruction sequence is sent to the updated scene device execution queue to control the degraded scene device to execute the target service.

[0167] In this embodiment of the invention, feedback is promptly provided to the user when a replacement device is successfully used. However, when replacement fails or no replacement device is available, the cascading affected nodes of the fault are traced using the dependency relationship of the topology graph. An effective degradation subgraph is constructed by stripping the faulty and affected non-critical nodes. Then, the topology isomorphism is matched with the degradation scenario library to accurately locate the target degradation scenario. The degradation control instruction update execution queue is calculated based on the state snapshot. Thus, when a severe local fault cannot be directly replaced, a gradual and smooth degradation of the overall system control mode is achieved, ensuring the continuous availability of core scenario functions and system security.

[0168] Alternative devices refer to controlled devices that are associated with abnormal devices through alternative edges in the target scene topology graph data and have the ability to replace functions.

[0169] A successful replacement message is a confirmation response message returned by the replacement device to the control system after successfully receiving and completing the compensation control command, indicating that the replacement was successful.

[0170] Replacement success notification data refers to visual notification information used on the interactive interface to show users that the replacement device has successfully taken over and completed the replacement operation.

[0171] A replacement failure message is a response message returned to the control system by the replacement device when an abnormality or failure occurs during the execution of the compensation control command, indicating that the replacement was unsuccessful.

[0172] Abnormal equipment refers to controlled equipment that malfunctions, times out, or fails to be replaced during the aforementioned control process.

[0173] Target scene topology data refers to the topology data corresponding to the current target scene, which includes device nodes and the dependencies and substitution relationships between devices.

[0174] Dependency edges refer to directional association edges in the target scene topology graph data used to indicate the order of control, execution conditions, or causal relationships between different devices.

[0175] Successor device nodes refer to all downstream controlled device nodes that directly or indirectly depend on the operation of the faulty device along the direction of the dependency edge.

[0176] The cascaded affected node list data refers to a data list consisting of the abnormal device and all its subsequent device nodes, reflecting the scope of the cascaded spread of the fault.

[0177] The criticality enumeration value refers to a discrete label or numerical value used to indicate the importance level of each device in the control logic of a specific scenario.

[0178] The scene device execution queue refers to a list of instruction sequences used to guide controlled devices to execute actions in a specific timing or logical order.

[0179] Non-critical equipment refers to controlled equipment whose criticality enumeration value is at a low importance level, and whose removal will not affect the operation of the core functions of the scenario.

[0180] Effective degradation subgraph data refers to the subtopology data structure that remains after removing abnormal devices and affected non-critical devices from the target scene topology data, and that can maintain the basic or partial operation of the scene.

[0181] The degradation scenario library data refers to a data set that is pre-stored in the system and contains a variety of preset backup degradation scenario topology diagrams.

[0182] The candidate scenario topology map refers to the structure of each independent, preset backup scenario topology map contained in the degradation scenario library data.

[0183] Topological isomorphism calculation refers to the algorithmic process of quantitatively matching and calculating the similarity of two topological graphs in terms of node composition, dependency edge relationships, and graph structure.

[0184] The target degradation scenario topology data refers to the degradation scenario topology data selected from the degradation scenario library that best matches or is isomorphic to the effective degradation subgraph data in terms of topology structure.

[0185] Degraded scenario devices refer to controlled devices contained in the target degraded scenario topology data that are intended to participate in executing control actions in the degraded scenario mode.

[0186] The degradation target state vector refers to a multi-dimensional numerical vector composed of the target state parameters that the device is expected to achieve in the degradation scenario.

[0187] Status snapshot data refers to a dataset that reflects the initial operating baseline of a device, constructed based on the device's current operating status parameters before the target service is triggered.

[0188] The second state change difference refers to the quantized numerical difference between the target state vector and the corresponding state parameters in the state snapshot data of the device in the downgraded scenario.

[0189] The degradation control instruction sequence refers to a set of instructions generated based on the difference in the second state change, used to drive devices in a degradation scenario to perform degradation business actions.

[0190] The target business refers to the specific equipment control process or functional operation to be executed in the target scenario.

[0191] For example, embodiments of the present invention can retrieve degradation scenario library data from a preset degradation scenario library in the following manner, perform topological isomorphism calculation on the topological graphs of each candidate scenario in the degradation scenario library data and the effective degradation subgraph data, and determine the target degradation scenario topological data.

[0192] Given valid degraded subgraph data G sub =(V sub E sub W sub ) and the topology graph Gk=(V) of the k-th candidate scene in the degradation scene library k E k W k ), whose topological isomorphism Sim(G) sub G k The calculation is performed using the following weighted collaborative mapping function:

[0193] in, V sub For the set of device nodes in the effectively degraded subgraph data; E sub This is the set of associated edges (including dependent edges and substitute edges) in the effectively degraded subgraph data. W sub This is a set of criticality enumeration values ​​and device attribute weights for each node in the subgraph data to effectively degrade the subgraph data; V k E k W k These represent the set of device nodes, the set of associated edges, and the set of node attribute weights in the topology graph of the k-th candidate scene, respectively. Φ is V sub →V k This is a mapping function (i.e., overlap and alignment relationship) for effectively degrading subgraph nodes to candidate scene topology graph nodes. |V sub ∩ Φ V k| represents the number of device nodes that, under the mapping relationship Φ, are completely matched or of the same type as the candidate scene topology graph in the effective degraded subgraph; |E sub ∩ Φ E k | represents the number of aligned associated edges between two graphs that have the same topological direction and dependency type under the mapping relation Φ; Sim attr (v, Φ(v)) represents the node v ∈ V sub Its mapping node Φ(v)∈V k The formula for calculating the attribute similarity between them is:

[0194] Where Attr(*) is the enumerated value of the criticality level of the node or the normalized value of the functional parameter; w1, w2, and w3 are preset weight coefficients, representing the weights of node matching, topology matching, and attribute matching, respectively, and satisfying w1+w2+w3=1 (for example, w1=0.4, w2=0.4, w3=0.2 can be set).

[0195] After calculating the isomorphism between the topology graph of each candidate scene in the candidate scene library and the effective degradation subgraph data, the formula for determining the target degradation scene topology data G* is as follows:

[0196] Among them, G deg This represents the preset set of degradation scenarios, where τ is the preset topological isomorphism matching threshold (e.g., τ=0.75). If the maximum isomorphism is less than τ, it is determined that there is no matching degradation scenario, triggering the safety backup shutdown logic.

[0197] For example, when the control system receives a replacement success message from the alternative device, it immediately displays a replacement success message on the user terminal interface. If a replacement failure message is received or no alternative device is found, the system performs a depth-first traversal along the dependency edges of the target scenario topology graph data, starting from the abnormal device, to identify all subsequent device nodes that depend on the abnormal device and generate a list of cascaded affected nodes. Then, based on the criticality enumeration value, the system removes the abnormal device and its bound non-critical devices from the execution queue, extracting the effective degradation subgraph data that can operate safely. Subsequently, the system retrieves the candidate scenario topology graph from the degradation scenario library, calculates its topological isomorphism with the effective degradation subgraph data, and locks the target degradation scenario topology data with the highest isomorphism, along with its degradation scenario devices and degradation target state vector. Finally, the system subtracts the degradation target state vector from the initial state snapshot data to obtain the second state change difference, generates a degradation control instruction sequence based on this, updates the scenario device execution queue, and finally issues instructions to drive the degradation scenario devices to perform degradation services, completing the intelligent progressive degradation and baseline control of the scenario.

[0198] This invention, by introducing a cascading impact analysis and topology isomorphism matching mechanism based on dependency edges when the alternative mechanism fails or there is no alternative equipment, breaks the limitation of traditional control systems that can only collapse completely or blindly shut down when encountering irreversible faults. By accurately extracting cascading affected nodes and separating non-critical equipment, it achieves strict isolation of the fault impact range and safe pruning of the control subgraph. At the same time, it uses a topology isomorphism algorithm to intelligently match the best degradation scenario from a preset degradation library and dynamically reconstructs the degradation control instruction sequence based on the initial state snapshot, ensuring a seamless and smooth transition of scenario services from a full-function state to a backup function state. This greatly improves the fault tolerance and business continuity of complex multi-device collaborative systems under extreme fault conditions.

[0199] In an optional embodiment of the present invention, it further includes: During the execution of the target service by the device in the downgraded scenario, the execution confirmation message returned by the device in the downgraded scenario is monitored, and an execution result representing whether the device in the downgraded scenario has successfully executed the target service is generated based on the target downgraded scenario topology data and the execution confirmation message. The abnormal event type and the handling strategy for the abnormal event type are determined by using the scene identifier of the target scene, the device identifier of the abnormal device, and any one of the rollback report data, replacement success prompt data, or execution result. Write the abnormal event type and the handling strategy into the user decision strategy table; The user decision strategy table is read at a preset period. When the frequency of using the same handling strategy for the same abnormal event type within a preset sliding window reaches a preset frequency threshold, user preference strategy vector data is generated.

[0200] In this embodiment of the invention, a closed-loop monitoring mechanism for results is established during the execution phase of the downgraded business. The scene identifier, device identifier, and final handling result (rollback, replacement, or downgrade) are multidimensionally integrated and summarized into anomaly event types, and the handling strategy is persistently recorded. Furthermore, through the statistical analysis of sliding window data with a preset period and the determination of frequency thresholds, the user's habitual decision preferences are automatically mined and extracted, thereby generating user preference strategy vector data, realizing the adaptive evolution and intelligent autonomous decision-making of the device control system for anomaly handling strategies.

[0201] Degradation scenario devices refer to controlled devices identified in the target degradation scenario topology data that participate in executing backup or degradation business logic.

[0202] The target business refers to the specific equipment control process or functional operation that is being prepared or is being executed in the target scenario.

[0203] An execution confirmation message refers to a status response data packet returned by a device in a degraded scenario to the control system after receiving and responding to a degraded control command, indicating whether the command execution was completed or failed.

[0204] Target degradation scenario topology data refers to the target degradation scenario topology data that matches the effective degradation subgraph, selected from the degradation scenario library.

[0205] The execution result refers to the judgment data generated by analyzing the topology data of the target degradation scenario and the execution confirmation message, which is used to clearly identify whether the device in the degradation scenario has successfully completed the target service.

[0206] The target scenario refers to the specific scenario or pattern that the user initially triggers or requests to execute.

[0207] Scene identifiers refer to strings, numbers, or code indexes used to uniquely define and distinguish different scene modes within the system.

[0208] Abnormal equipment refers to controlled equipment that malfunctions, times out, or responds unexpectedly during the aforementioned control process.

[0209] Device identifier refers to a code or address string used to uniquely distinguish and identify a specific controlled hardware device.

[0210] Rollback report data refers to the data generated after performing an undo rollback operation on abnormal devices and related nodes, which includes a summary of rollback status and results.

[0211] Successful replacement notification data refers to visual or logical notification information indicating that the replacement device has successfully taken over and completed the replacement control operation.

[0212] Abnormal event types refer to classification labels that reflect the failure modes of specific devices in a specific scenario, which are comprehensively summarized by combining scenario identifiers, device identifiers, and final processing results (rollback, replacement, or degradation execution results).

[0213] The handling strategy refers to the specific control and response mechanisms adopted for specific abnormal event types, including rollback, alternative takeover, or scenario degradation.

[0214] The user decision strategy table refers to a relational database table or key-value pair data structure used to persistently store historical abnormal event types and corresponding handling strategies (as well as user selection or confirmation records).

[0215] The preset cycle refers to the time interval at which the system periodically triggers the analysis of user decision strategy table data.

[0216] A sliding window refers to a time interval set in the time dimension to extract historical decision records for statistical purposes within a specific recent time period.

[0217] The preset frequency threshold refers to the critical value used to determine the number of times a certain treatment strategy is repeatedly used within a sliding window.

[0218] User preference strategy vector data refers to a multi-dimensional quantitative vector generated based on sliding window frequency statistics, used to characterize users' fixed tendencies and adaptive decision parameters in handling specific abnormal events.

[0219] For example, when a device in a downgraded scenario executes a target service, the control system activates a message listener to capture the execution confirmation messages returned by each device and generates an execution result by matching the expected response in the topology data of the target downgraded scenario. Subsequently, the system extracts the scenario identifier of the current target scenario, the device identifier of the faulty device, and combines it with one of the following: rollback report data, replacement success prompt data, or the aforementioned execution result, to synthesize a unique abnormal event type. The system writes the event type and the handling strategy adopted this time (such as automatic replacement, rollback, or specific downgrade mode) into the user decision strategy table. The system background service automatically reads the table according to a preset period (e.g., every 24 hours) and performs cluster statistics on the historical records using a preset sliding window (e.g., the last 30 days). When it is calculated that the number of times the same handling strategy is adopted for a specific abnormal event type within the sliding window reaches a preset frequency threshold (e.g., 5 times), the system automatically extracts the feature of the strategy and constructs user preference strategy vector data to update the system's preset default arbitration rule, so that when the same abnormal event occurs again, the preference vector can be directly applied for automatic handling.

[0220] This invention achieves comprehensive state closed-loop and observability of the degradation control process by monitoring execution confirmation messages and topology matching; it constructs a high-value anomaly handling knowledge base by deeply binding scenarios, devices, and handling results and writing them into the user decision strategy table; more importantly, it realizes the leap from passive response / manual interaction arbitration to proactive adaptive evolution of the system by utilizing a preset periodic sliding window and frequency threshold analysis mechanism. It can automatically capture and solidify users' personalized usage habits and decision preferences, significantly reducing the disturbance to users when similar faults occur in the future, and greatly improving the intelligence level and interactive experience of the multi-device scenario control system.

[0221] To enable those skilled in the art to better understand the embodiments of the present invention, an example is used below to illustrate the embodiments of the present invention.

[0222] The system architecture description can be found in the Mermaid graphics language code: graph TB subgraph Smart Central Control Screen Host A [User Interaction Layer] --> |Scene Triggering| B [Scene Orchestration Engine] B --> C [Scene Topology Parser] C -->|Equipment List + Topology Relationship| D[Scene Execution Controller] E [Local Persistent Storage] --> C E -->D D -->|Read / Write| F [Status Snapshot Manager] D -->|Issue Command / Recover / Compensate| G[Multi-protocol Device Adaptation Layer] G -->|Execution Confirmation| H[Execution Phase Tracker] H -->|Phase Change Notification| D D -->|Rollback Trigger| I[Reverse Recovery Scheduler] I -->G D -->|Degradation Trigger| J[Degradation Scenario Retrieval Tool] J -->D D -->|Progress / Exception / Arbitration Request| K[Screen-side State Rendering and Arbitration Engine] K -->|User Decision Vector| D K --> L [Central Control Screen Display Output] end subgraph (sub-device network) M [Lighting Equipment] --> G N [Environmental Control Equipment] --> G O[Security Sensing Devices] -->G P [Audio-visual entertainment equipment] --> G end The intelligent central control screen host uses an embedded heterogeneous computing platform running a streamlined Linux operating system. From a logical functional perspective, the system is divided into four layers: user interaction layer, scene orchestration layer, execution control layer, and device adaptation layer. The layers communicate with each other through internal message queues and event channels.

[0223] The user interaction layer simultaneously hosts the touch display interface, voice interaction pipeline, and automation rule engine. Regardless of which channel the user initiates the scene invocation request from, the request will be packaged into a structured message containing the scene identifier, trigger source, and timestamp, and sent to the scene orchestration layer. The technical process protected by this invention does not limit the specific transmission protocol or message format used; any local message bus, publish-subscribe channel, or shared memory mechanism that enables communication between functional modules within the central control screen host can be considered an equivalent implementation of this embodiment.

[0224] The scene orchestration layer includes a scene topology parser responsible for reading scene configurations from local persistent storage. Unlike traditional scenes that only store a flat list of device control parameters, this invention requires scene configurations to include two additional types of semantic information: the first is device dependency relationships, described using a directed acyclic graph (DAG), where nodes represent devices and directed edges indicate that the control of a subsequent device can only take effect after the previous device has successfully executed (e.g., the projector can only adapt to the light and turn on after the screen is lowered); the second is device substitution relationships, described using undirected edges or weak connections, indicating which devices can functionally overlap and how their parameters are mapped. These two types of semantic information can be automatically recommended by the system based on device categories when the user creates a scene through the central control screen and written into the configuration after user confirmation, or they can be manually edited by the user through drag-and-drop.

[0225] The execution control layer is the core layer of this project, and it is uniformly scheduled by the scene execution controller. Internally, the controller maintains an execution session table indexed by scene batch number. Each session records the complete lifecycle data of this scene trigger, including state snapshot references, the current execution stage of each device, elapsed time, and exception records. The controller operates using a single-threaded event loop to avoid multiple threads competing for instructions from the same device during concurrency. However, instructions for different devices can be issued in parallel at the device adaptation layer.

[0226] The device adaptation layer is responsible for shielding the differences in the underlying communication protocols and providing a unified abstract interface to the upper layers: issuing commands and then waiting for confirmation. Internally, the adaptation layer is divided into several adapter instances according to protocol type. Each instance independently manages the connection status, message sending and receiving, and timeout timer of its own protocol stack.

[0227] The on-screen state rendering and arbitration engine is a key new module in this implementation compared to existing technologies. This engine subscribes to the real-time state stream published by the execution phase tracker and maintains an execution image synchronized with the execution control layer locally. Upon receiving an arbitration request, the engine dynamically assembles the data model of the decision panel based on the current scene context, renders it into touch interface elements, and then encodes the user's touch selection into a decision vector and sends it back. The engine is also responsible for generating a scene preview view: before formal execution, it calculates the state change difference for each device based on the state snapshot and the target state vector, and previews it on the screen using an animation sequence.

[0228] For a detailed implementation process, please refer to the Mermaid graphics language code: sequenceDiagram participant UI as central control screen Participant SE as Scene Execution Controller participant SS as State Snapshot Manager participant EX as execution phase tracker participant DA as device adapter layer participant DEV as target equipment group UI->>SE: User-triggered scenario S SE->>SS: Generate a state snapshot SS-->>SE: Returns snapshot ID and state vector SE->>UI: Push preview view UI->>UI: Rendering Preview Animations UI->>SE: Confirm execution / Dynamic policy patch Devices within the loop are dispatched one by one. SE->>DA: Issue control commands DA->>DEV: Send after protocol conversion DEV-->>DA: Return to execution confirmation DA->>EX: Progress of the reporting phase EX-->>UI: Real-time push status stream UI->>UI: Update progress animation end alt All equipment has been confirmed EX-->>SE: Execution complete SE->>UI: Displays "Scene executed successfully" else, a device timed out and was not confirmed. EX-->>SE: Exception Alarm SE->>UI: Push arbitration request The abnormal device is a critical device. UI->>UI: Pop-up decision panel A: Rollback immediately / B: Force continue UI->>SE: Return user decision vector Alt select rollback SE->>SE: Trigger rollback Reverse loop order recovery SE->>DA: Issue recovery command DA->>DEV: Send to the activated device DEV-->>DA: Recovery Confirmation DA->>EX: Report recovery phase EX-->>UI: Push recovery progress UI->>UI: Render scrollback image end SE->>UI: Displays "Execution failed, environment has been restored". else Select Force Continue SE->>SE: Mark skipped SE->>UI: Displays "Scene partially complete" end else, the faulty equipment is a normal / atmosphere equipment. UI->>UI: Pop-up decision panel A: Enable Alternative / B: Switch to Degradation / C: Rollback / D: Skip UI->>SE: Return user decision vector Alt select Enable Alternative SE->>SE: Query topology graph, parameter mapping SE->>DA: Issue compensation commands to the alternative device DA->>DEV: Send to alternative device DEV-->>DA: Compensation Confirmation EX-->>UI: Push compensation completed UI->>UI: Highlight alternative device icons SE->>UI: Displays "Scene executed, a certain device compensated by a substitute device". else Select switch to downgrade SE->>SE: Search the downgrade library and match the sub-scenario with the closest intent. SE->>DA: Switch execution context DA->>DEV: Execute the downgrade scenario command. DEV-->>DA: Execution confirmation EX-->>UI: Push downgrade complete UI->>UI: Smooth transition to the degraded scene view SE->>UI: Displays "Switched to a similar scene" else select rollback SE->>SE: Trigger rollback SE->>UI: Displays "Environment restored" else Select skip SE->>SE: Mark skipped SE->>UI: Displays "Scene partially complete" end end end Step 1: Scene topology modeling, incremental snapshot generation, and pre-visualization view rendering 1. Scene topology modeling and static recommendation The system uses an adjacency list to store the scenario topology graph in its data structure. Each device node in the topology graph contains: a globally unique device identifier, a device category code, a criticality enumeration value (CRITICAL critical device, NORMAL ordinary device, AMBIENT ambient device), a state vector schema definition, a list of pointers to dependent successor nodes, and a list of pointers to alternative peer nodes.

[0229] Dependency edges include conditional expressions (such as curtain opening degree le 5%) to constrain the completion state of the front-end device; alternative edges include parameter mapping function identifiers (Mapper ID).

[0230] When creating a scene, the system automatically generates a draft topology graph based on the built-in category combination heuristic rule library (for example, when matching projector and motorized_screen, a one-way dependency edge is automatically established for screen lowering -> projector turning on; when matching main_light and ambient_light, a two-way substitution edge is automatically established).

[0231] The recommended results are displayed on the scene editing interface of the central control screen. User-defined operations such as dragging, modifying, or deleting relationships are written into the user-defined rule table, which has higher priority than the default rules in the knowledge base. The confirmed topology diagram, along with the control parameters, is serialized into JSON format and stored in the local database.

[0232] 2. Standardized encapsulation of cross-category capability schema The system registers corresponding schemas for different device categories and abstracts them uniformly into global capability dimensions (CapabilityKey) at the underlying level, such as ILLUM_POWER (lighting switch), HVAC_MODE (temperature control mode), SHADE_POSITION (shading position), etc.

[0233] When storing snapshots, the states of different product categories are uniformly packaged and encapsulated into a Map.<CapabilityKey, TypedValue> The mapping structure enables a normalized representation of the capabilities of devices across different product categories.

[0234] 3. Dual-trigger lightweight incremental baseline snapshot generation When the scene execution controller receives a valid scene trigger request, it requests the state snapshot manager to generate a snapshot. The snapshot manager adopts a dual-trigger incremental baseline mechanism: the background automatically scans the global device status every 5 minutes to refresh the global state baseline table; at the same time, as long as the device adaptation layer receives any state change message or state modification instruction from an external entry point (such as a mobile APP), it immediately incrementally updates the corresponding record in the baseline table.

[0235] When generating a snapshot, the system directly copies the current state vector of the relevant devices in the baseline table and only initiates incremental queries for devices that have changed after the baseline is generated, reducing the snapshot generation time to tens of milliseconds.

[0236] Snapshot data is bound to the scenario batch number (Batch ID) and generation timestamp and then written to local persistent storage. For scenarios that complete normally, the snapshot is marked as ready for elimination immediately after execution; for scenarios that enter rollback or degradation, the snapshot is forcibly retained until a complete cycle after the process ends, for use in historical fault tracing and log analysis.

[0237] 4. Preview rendering and conflict detection strategy patch The controller pushes snapshot data and target state vectors to the on-screen state rendering and arbitration engine. The engine calculates the state change difference Δ = T - S for each device dimensionally (e.g., switch state change Δ = 1, brightness adjustment from 50% to 80% Δ = 30) and drives the pre-show view animation rendering.

[0238] The preview view displays the device sequence in a timeline manner, traversing the topology graph's dependent edges: if the dependency condition is not yet met (such as when the screen is fully open), the dependent edge is rendered as a yellow dashed line; if the dependency condition is met, it is rendered as a green solid line.

[0239] Users can adjust the execution order of the device by dragging and dropping or by clicking a card to skip it this time. If a user adjusts the order and disrupts the topological partial order (e.g., dragging a dependent node before a preceding node), a warning message with a red box will pop up on the interface. If the user forces confirmation, the system will insert a dependency_override flag into the generated dynamic policy patch. After the controller reads this flag, it will temporarily lift the blocking check on the dependency edge during actual execution, and the user will bear the operational risk.

[0240] If the user clicks "Confirm Execution" on the pre-launch interface, the system will enter the formal distribution process; if the user does not take any action after the preset waiting period, the controller will automatically distribute the data according to the original default strategy.

[0241] Step Two: Stage Status Tracking, Protocol Heuristic Confirmation, and Dynamic Timeout Issuance 1. Instruction Frame Construction and Stage Tracking After the pre-rehearsal is confirmed, the scene execution controller begins to traverse the topology nodes. For devices with no prior dependencies or whose prior dependencies are already satisfied, the controller constructs a control instruction frame (containing the scene batch ID, device identifier, target state vector, and instruction sequence number) and issues it through the device adaptation layer.

[0242] After the device adaptation layer successfully converts the instruction into a physical protocol message and sends it, it reports the stage progress to the execution stage tracker, updates the status from pending execution to issued in a hash table indexed by the device identifier, and records the time of the change.

[0243] 2. Protocol-level heuristic confirmation The device adaptation layer initiates a response listener. If any of the following conditions are met, the process is considered confirmed, and the phase is advanced to confirmed: Explicit response: Receiving an ACK message from the device within the timeout window or observing an explicit state change event.

[0244] Protocol heuristics: Each protocol adapter implements the `confirmHeuristic()` interface. For example: the Zigbee protocol listens to the ZCL layer's Default Response, and a return of SUCCESS indicates confirmation; the Matter protocol listens to the InteractionStatus in InvokeResponse, and a return of Success without additional errors indicates confirmation; the BLEMesh protocol indirectly confirms confirmation by listening to changes in the status fields of the Status Message or Gatt Notify.

[0245] Protocol Adaptive Dynamic Timeout Algorithm If in the dynamic timeout window T out If no valid response is received by the due date, the device adaptation layer reports the device malfunction to the controller.

[0246] Timeout threshold T out Semi-adaptive computation is performed based on a sliding window of historical interaction samples from the protocols (K=50 most recent interactions for WiFi, K=20 most recent interactions for Zigbee, with strict FIFO elimination).

[0247] In the formula: avg(t) is the sample arithmetic mean delay; dev(t) is the sample standard deviation (quantization delay jitter); β = 1.0 is the equipment processing margin coefficient; t proc The typical processing time for device commands is α; α is the jitter tolerance coefficient (α=2.0 for WiFi environment, α∈[2.5, 3.0] for Zigbee / Mesh environment). If a protocol experiences a sudden increase in timeout rate recently, α is dynamically increased by 0.5, and then adjusted back after the network stabilizes; if the sample size is less than K times, the protocol's preset value is used as a fallback.

[0248] 3. Real-time status stream push and bus / session isolation Each time a phase change occurs, the execution phase tracker pushes a real-time status stream (including Batch ID, device identifier, change phase, timestamp, and exception reason code) to the on-screen engine via the event channel. The on-screen progress view is synchronized in real time: confirmed devices are highlighted in a stable state, unconfirmed devices that have been issued are displayed with pulse animations, and devices awaiting execution are displayed in a grayed-out state.

[0249] Multi-scenario concurrency isolation: The controller maintains an execution session table with Batch ID as the unique index, ensuring complete data isolation; device-level mutex locks are applied to controlled devices, with granularity accurate to a single device, ensuring concurrent parallel delivery of non-conflicting devices.

[0250] Bus Fault Isolation: The central control screen and the gateway controller communicate via Unix Domain Socket by default. If the bus is disconnected, the controller temporarily stores the arbitration request and status notification in a local circular buffer and attempts to restore communication via shared memory or local file locks; if restoration fails, it executes silently according to the default strategy. If the gateway controller malfunctions, the central control screen freezes the interface trigger entry through heartbeat loss detection and prompts that the system is recovering.

[0251] Step 3: Critical equipment anomaly detection, central control screen arbitration, and reverse recovery rollback 1. Abnormal Freeze and Arbitration Panel Assembly Upon receiving a device anomaly report, the controller queries the criticality_enum attribute of the node in the topology graph. If the device is a critical device, the controller immediately freezes all ordinary devices in the scene queue that have not yet received instructions, suspends execution, and sends an arbitration request to the screen engine.

[0252] The engine dynamically assembles the UI decision panel based on a JSON template and the attributes of the faulty device. A pop-up in the center displays the name of the faulty device and the reason for the failure, providing two mutually exclusive options: immediately roll back and restore the environment or force continue (preserving some scene states). A decision waiting countdown (e.g., 15 seconds) is displayed at the bottom of the panel.

[0253] 2. Security and Tamper-Proofing, and Decision Prioritization The decision vector transmission has three layers of security protection: 1) The payload is appended with a 2-byte CRC16 checksum; 2) Millisecond-level timestamp verification (rejection occurs if the deviation exceeds 15 seconds); 3) Strong binding to the currently active scene batch number (Batch ID).

[0254] If the countdown ends without user action, the following priority will be applied: User-defined configuration > Adaptive learning preference vector > System hard-coded default strategy (default rollback for critical devices) 3. Reverse recovery rollback and electrical / mechanical stabilization interval (T) stable ) If the user selects or the default triggers an immediate rollback, the reverse recovery scheduler extracts the list of devices that have progressed to the confirmed or completed stage corresponding to the Batch ID from the snapshot, submits recovery requests in strict reverse order of the original execution order, and sends the original state vector from the snapshot.

[0255] To prevent electrical or mechanical damage caused by frequent equipment operation, a stable interval T_stable is forcibly inserted between adjacent steps during reverse recovery. For motor-driven devices (curtains, curtains): T_stable = 3s; For ordinary relays (sockets): T_stable = 1s; Lighting equipment: T_stable = 0.5s.

[0256] Before executing each recovery step, the scheduler checks the difference between the recovery confirmation time and the previous recovery confirmation time. If the time T_stable has not been reached, the scheduler automatically delays and waits.

[0257] 4. Restore fault tolerance and completion notification During the rollback process, the on-screen engine uses an animation that is the opposite of the forward animation (a reverse progress loop during recovery, with the abnormal device warning color highlighted).

[0258] If a device times out and fails to respond again during the recovery process, the scheduler records it in the list of failed recovery devices, does not block the process, skips it directly, and continues to execute the recovery of the next node, ensuring the termination of the rollback process.

[0259] After all recoverable nodes have been processed, the controller generates a rollback report containing success and failure details and pushes it to the central control screen for non-blocking display, while simultaneously retaining the scene re-trigger entry and manual intervention guidance.

[0260] If the user chooses to force continue, the controller will mark the abnormal device as skipped, unfreeze the subsequent normal devices and continue to issue the device. After completion, the unresponsive devices will be listed in a collapsed card.

[0261] Step 4: Arbitration compensation and gradual degradation of the central control screen for non-critical equipment malfunctions 1. Four-option arbitration panel and decision-making decentralization If the faulty device is a non-critical device (NORMAL or AMBIENT), the on-screen decision panel dynamically expands to four options: enable alternative device compensation, switch to a degraded scenario, roll back and restore the environment, and skip to continue execution. The process for selecting rollback or skip is the same as step three.

[0262] 2. Algorithm for Alternative Equipment Compensation and Parameter Mapping After a user selects to enable alternative device compensation, the controller queries the alternative edge of that node in the topology graph. If the alternative device is online and available, the controller calls the attached parameter mapper to convert the original target state vector into an equivalent vector that adapts to the capability range of the alternative device.

[0263] The mapping algorithm follows the principle of first clamping, then linear scaling (LinearMap): Cutting calculation: V clamped = min(max(V target V alt_min ), V alt_max ) 1. Explanation of parameter symbols V clamped (The pruned target control value) represents the actual control parameter value finally issued to the alternative equipment after correction by the physical capability boundary constraint (Clamp) of the alternative equipment.

[0264] V target (Original target control value) represents the target value of the control parameter originally planned to be issued for the original device that has an abnormality in the original logic of the scene (such as the brightness or color temperature value that the original main light was planned to adjust to).

[0265] V alt_min (Lower limit of alternative equipment capability) indicates the minimum effective physical parameter boundary value that the alternative equipment can support in the corresponding control dimension (such as brightness percentage, color temperature Kelvin value, fan speed level, etc.).

[0266] V alt_max (Upper limit of alternative equipment capability) represents the maximum effective physical parameter boundary value that the alternative equipment can support in the corresponding control dimension.

[0267] 2. Explanation of Nested Logical Operators max(V target V alt_min (Lower limit defense correction) When the original target value V target Below the lower limit of the capability V of the alternative equipment alt_min At that time, the calculation will force the control value to be increased to V. alt_min This prevents invalid or illegal commands from being sent to alternative devices below their physical response limits.

[0268] min(..., V alt_max (Upper limit truncation constraint) When the control target value after the lower limit judgment is higher than the upper limit of the alternative equipment's capacity V. alt_max At that time, the calculation will force the control value to be truncated downwards to V. alt_max This ensures that the final control commands issued do not exceed the physical capacity limits of the replacement equipment.

[0269] 3. Engineering Application Examples Taking the example of a floor lamp being used as a replacement device when the main light malfunctions in a "living room movie-watching scenario": Original scene requirement: Target brightness V of the original main light target = 80%; Alternative device capability: The floor lamp supports a brightness range of V. alt_min =10%, V alt_max = 50%.

[0270] Substitute into the formula to calculate: V clamped=min(max(80%, 10%), 50%) = min(80%, 50%) = 50% Calculation result: The system automatically corrected the control target issued to the floor lamp to 50% (i.e., the floor lamp's maximum output), thus maximizing the fulfillment of the user's original lighting needs without compromising the legality of the system commands.

[0271] Proportional mapping calculation:

[0272] (For example: if the main light brightness target is 80%, which is abnormal, and the upper limit of the alternative ambient light is only 60%, then first trim it to 60%, and then map the color temperature proportionally).

[0273] The mapped compensation command is inserted as a new node into the current scene session and issued. The replacement device icon is highlighted on the screen, and its replacement relationship with the abnormal device is marked with a dashed line.

[0274] 3. Progressive Degradation and Fuzzy Matching Algorithms When a user's choice to switch to a downgrade scenario or when the replacement fails, the controller initiates a progressive downgrade process, performing a two-step fuzzy matching in the local downgrade scenario library: Step 1 (Jaccard similarity calculation for intent tags):

[0275] In the formula, I represents the set of scene function intent tags such as lighting, temperature control, security, and audio-visual.

[0276] Step 2 (hard filtering of device availability): Verify the online status of devices in candidate sub-scenes, and prioritize filtering sub-scenes where all devices are available; if none are available, relax the filter to include at most one non-critical abnormal device that can be replaced.

[0277] After identifying the most compatible downgrade target, the controller seamlessly switches the current session context to the downgrade scenario, continuing execution using the same state snapshot. The on-screen interface smoothly transitions to the downgrade scenario view, with the abnormal original scenario device placed in a collapsed card at the bottom of the view.

[0278] 4. Dynamic evolution of the degradation scenario library The degradation scenario library evolves dynamically as it is used: a scenario that is successfully executed is marked as highly reliable; if a replacement or degradation occurs and is successfully executed, the system stores it as a new candidate entry in the degradation library and establishes a parent-child relationship with the original scenario.

[0279] When a user manually deletes or replaces a device, the system automatically scans the downgrade library and invalidates all downgrade entries related to the removed device, ensuring the timeliness of the downgrade library.

[0280] Step 5: Decision Strategy Persistence and Adaptive Learning Evolution 1. Persistent recording of decision-making strategies Each arbitration decision by a user is persistently written to the local user decision strategy table. The record structure includes: scenario identifier, abnormal device category, user-selected handling strategy, and decision time.

[0281] 2. Sliding Window and Frequency Mining Algorithm The system uses a 30-day sliding window (decision records older than 30 days have a weight of 0 and are not included in the statistics) and performs statistical analysis according to a preset period.

[0282] For the same scenario under the same abnormal mode (such as a projector malfunction in movie viewing mode), if the user selects the same handling strategy ≥ 3 times in the sliding window, the system will automatically generate a user preference strategy vector.

[0283] 3. Strategy Enhancement and Adaptive Evolution The system will promote the generated preference policy vector to the default automatic handling policy for this scenario under the corresponding abnormal mode. When similar abnormalities occur subsequently, the controller will automatically execute this policy directly, without interrupting the user with the pop-up arbitration panel.

[0284] Users can disable the adaptive learning function or clear the statistical records at any time in the system settings, restoring the fully manual arbitration mode where the decision panel always pops up.

[0285] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0286] Reference Figure 2 The diagram illustrates a structural block diagram of a device control apparatus provided in an embodiment of the present invention, which may specifically include the following modules: Scene topology graph data generation module 201 is used to generate scene topology graph data; the scene topology graph data includes device list information for a preset scene type, key degree enumeration values ​​for expressing the criticality of the device in the preset scene type, dependency edges reflecting the dependency relationship of different devices in the preset scene type, and substitution edges reflecting the substitution relationship of different devices in the preset scene type. The scene identifier determination module 202 is used to determine the scene identifier of the target scene corresponding to the scene trigger request in response to receiving a scene trigger request initiated by the user; The target device list information extraction module 203 is used to determine the target scene topology map data corresponding to the target scene from the scene topology map data according to the scene identifier, and extract the target device list information corresponding to the target scene from the target scene topology map data; The scene pre-simulation view data generation module 204 is used to generate and display scene pre-simulation view data of the initially determined equipment in the target scene according to the target equipment list information; The scene device execution queue construction module 205 is used to respond to the acquisition of the interactive operation adjustment instruction for the scene pre-show view data, and to construct the scene device execution queue by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data; The target device control module 206 is used to determine a handling strategy for the abnormal event based on the criticality enumeration value and alternative edge in the target scene topology graph data when it is determined that an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, and to control the target device based on the handling strategy.

[0287] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0288] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 3 As shown, it includes a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304. Memory 303 is used to store computer programs; When the processor 301 executes the program stored in the memory 303, it implements any of the device control methods described in the above embodiments: The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0289] The communication interface is used for communication between the aforementioned terminal and other devices.

[0290] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0291] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0292] like Figure 4 As shown, in another embodiment of the present invention, a computer-readable storage medium 401 is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the device control method described in the above embodiments.

[0293] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described device control method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0294] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0295] It should be noted that, in this document, the terms include, encompass, or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "including a…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0296] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0297] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A device control method, characterized in that, include: Generate scene topology map data; The scene topology map data includes device list information for a preset scene type, a criticality enumeration value used to express the criticality of the device in the preset scene type, a dependency edge reflecting the dependency relationship of different devices in the preset scene type, and a substitution edge reflecting the substitution relationship of different devices in the preset scene type. In response to receiving a scene trigger request initiated by a user, determine the scene identifier of the target scene corresponding to the scene trigger request; Based on the scene identifier, determine the target scene topology map data corresponding to the target scene from the scene topology map data, and extract the target device list information corresponding to the target scene from the target scene topology map data; Based on the target equipment list information, generate and display the scene pre-simulation view data of the initially determined equipment in the target scene, which corresponds to the target equipment list information; In response to receiving an interactive operation adjustment instruction for the scene preview view data, a scene device execution queue is constructed by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data; When it is determined that an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, a handling strategy for the abnormal event is determined based on the criticality enumeration value and alternative edge in the target scene topology graph data, and the target device is controlled based on the handling strategy.

2. The method according to claim 1, characterized in that, The step of generating and displaying the scene pre-simulation view data of the initially determined equipment corresponding to the target equipment list information in the target scene includes: The current operating status parameters of the initially determined device are queried, and based on the current operating status parameters, status snapshot data reflecting the operating status of the initially determined device before executing the target service is generated, as well as a scenario target status vector representing the target state that the initially determined device is expected to achieve under the target service. Based on the state snapshot data and the scene target state vector, the first state change difference of each device is calculated, and the scene pre-show view data is generated and displayed.

3. The method according to claim 2, characterized in that, When it is determined that an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, the step of determining a handling strategy for the abnormal event based on the criticality enumeration value and alternative edges in the target scene topology graph data, and controlling the target device based on the handling strategy, includes: Determine the device protocol type of the target device in the scene device execution queue; Obtain historical round-trip latency samples corresponding to the device protocol type, and calculate the dynamic timeout threshold of the target device based on the historical round-trip latency samples; Based on the scenario device execution queue, a control instruction frame for the target service is generated and sent to the target device to control the target device to execute the target service; During the execution of the target service by the target device, the response messages of the target device are monitored. When it is determined from the response messages that no response message or protocol layer heuristic confirmation event is received within the dynamic timeout threshold, the target device is identified as an abnormal device, and device abnormality alarm information is generated for the abnormal device. Based on the device anomaly alarm information, retrieve the criticality enumeration value of the abnormal device from the target scene topology map data; When the abnormal device is determined to be a critical device based on the criticality enumeration value, the target device is controlled to perform a rollback operation. When the abnormal device is determined to be a non-critical device based on the criticality enumeration value, a substitute device with a substitution relationship with the abnormal device is determined by the substitution edge of the target scene topology graph data; Control the alternative device to perform the target service.

4. The method according to claim 3, characterized in that, The steps of controlling the target device to perform a rollback operation include: Freeze other device nodes in the scene device execution queue that have not received the control command frame, and determine the abnormal device attributes of the abnormal device; Based on the abnormal device attributes and the target scene topology map data, generate and display a first decision suggestion for the abnormal device; In response to receiving a first operation instruction for the first decision suggestion, and determining that the first operation instruction is a rollback operation instruction, a list of target devices that have completed the target service before the abnormal device is determined from the status snapshot data. A reverse recovery instruction sequence is generated based on the device list, and the reverse recovery instruction sequence is sent to the target device and the abnormal device in the device list to control the target device and the abnormal device in the device list to perform a rollback operation based on the reverse recovery instruction sequence.

5. The method according to claim 4, characterized in that, Also includes: If it is determined that the target device or the abnormal device in the device list has timed out during the rollback operation, the target device or the abnormal device in the device list is marked as a recovery abnormal device, and the rollback operation is continued to be performed on the next node device of the recovery abnormal device based on the order of the device list. When it is determined that the traversal of the device list is complete, a rollback report data for the abnormal device is generated and displayed.

6. The method according to claim 3, characterized in that, The step of controlling the alternative device to perform the target service includes: Based on the target scene topology map data, a second decision suggestion for the alternative device is generated and displayed; In response to receiving a second operation instruction for the second decision suggestion, and determining that the second operation instruction is a replacement operation instruction, the parameter mapping rule data of the replacement device is obtained; Based on the parameter mapping rule data, the scene target state vector is mapped and converted into an equivalent state vector that adapts to the alternative device; Based on the equivalent state vector, a compensation control instruction is generated, and based on the compensation control instruction, the alternative device is added to the scene device execution queue, and the alternative device is controlled to execute the target service based on the equivalent state vector.

7. The method according to claim 6, characterized in that, Also includes: In response to receiving a replacement success message from the replacement device, generate and display replacement success notification data for the replacement device; In response to receiving a replacement failure message returned by the alternative device, or determining that there is no alternative device that has a replacement relationship with the abnormal device, starting from the abnormal device, the dependency edges in the target scene topology graph data are traversed to extract all successor device nodes that are directly or indirectly dependent on the abnormal device. Generate a list of cascaded affected nodes using the abnormal device and the subsequent device node; Based on the criticality enumeration value of each node in the cascaded affected node list data, the abnormal device and other non-critical devices bound to the abnormal device are separated from the scene device execution queue to generate effective degradation subgraph data. Data from the pre-set degradation scenario library is retrieved. The topological isomorphism of each candidate scenario topology graph and the effective degradation subgraph data in the degradation scenario library data is calculated to determine the target degradation scenario topology data. Determine the degraded scenario device and the degraded target state vector corresponding to the degraded scenario device from the target degraded scenario topology data; By combining the state snapshot data with the degraded target state vector, the second state change difference of the degraded scenario device is calculated, and a degraded control instruction sequence is generated; The scene device execution queue is updated based on the degradation control instruction sequence, and the degradation control instruction sequence is sent to the updated scene device execution queue to control the degraded scene device to execute the target service.

8. The method according to claim 5 or 7, characterized in that, Also includes: During the execution of the target service by the device in the downgraded scenario, the execution confirmation message returned by the device in the downgraded scenario is monitored, and an execution result representing whether the device in the downgraded scenario has successfully executed the target service is generated based on the target downgraded scenario topology data and the execution confirmation message. The abnormal event type and the handling strategy for the abnormal event type are determined by using the scene identifier of the target scene, the device identifier of the abnormal device, and any one of the rollback report data, replacement success prompt data, or execution result. Write the abnormal event type and the handling strategy into the user decision strategy table; The user decision strategy table is read at a preset period. When the frequency of using the same handling strategy for the same abnormal event type within a preset sliding window reaches a preset frequency threshold, user preference strategy vector data is generated.

9. A device control system, characterized in that, include: Scene topology map data generation module, used to generate scene topology map data; The scene topology map data includes device list information for a preset scene type, a criticality enumeration value used to express the criticality of the device in the preset scene type, a dependency edge reflecting the dependency relationship of different devices in the preset scene type, and a substitution edge reflecting the substitution relationship of different devices in the preset scene type. The scene identifier determination module is used to determine the scene identifier of the target scene corresponding to the scene trigger request in response to receiving a scene trigger request initiated by the user; The target device list information extraction module is used to determine the target scene topology map data corresponding to the target scene from the scene topology map data based on the scene identifier, and extract the target device list information corresponding to the target scene from the target scene topology map data; The scene pre-simulation view data generation module is used to generate and display scene pre-simulation view data of the initially determined equipment in the target scene based on the target equipment list information; The scene device execution queue construction module is used to respond to the interactive operation adjustment instruction obtained for the scene pre-show view data, and construct the scene device execution queue by combining the interactive operation adjustment instruction with the dependency edges in the target scene topology map data; The target device control module is used to determine a handling strategy for the abnormal event based on the criticality enumeration value and alternative edge in the target scene topology graph data when it is determined that an abnormal event occurs in the target device of the scene device execution queue during the execution of the target service corresponding to the scene trigger request, and to control the target device based on the handling strategy.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any one of claims 1-8.

11. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in any one of claims 1-8.

Images