Method for processing device control rule, device control method, device and system

Abstract

Embodiments of the present application disclose a device control rule processing method, a device control method, a device control apparatus and a system. The method preconfigures information of a signal space and information of an instruction space on an electronic device decoupled from a target hardware device, including: obtaining a target signal feature in the signal space and an instruction sequence composed of instruction in the instruction space; establishing a mapping relationship between the target signal feature and the instruction sequence; generating a rule package according to the mapping relationship; and transmitting the rule package to the target hardware device, so that the target hardware device matches a physical signal feature collected by the target hardware device with the target signal feature in the rule package to determine an instruction sequence to be executed. The scheme separates signal collection, instruction content and mapping logic through decoupled signal space, instruction space and independent rule package, facilitates rule replacement, improves system expansibility, and supports user self-definition of device control rules.

Description

Technical Field

[0001] This application relates to the fields of computer applications, the Internet of Things, and intelligent device control technology, and in particular to a method for processing device control rules, a device control method, an apparatus, and a system. Background Technology

[0002] In the field of smart device control, with the development of the Internet of Things and smart hardware, users' demand for flexible control of hardware devices is increasing. In traditional implementations, developers typically pre-write control rules for hardware devices or configure them through fixed templates, meaning that smart hardware can usually only execute fixed control logic. Alternatively, users can only select to enable a specific control rule from the pre-configured rules, resulting in poor flexibility and personalization. Summary of the Invention

[0003] In view of this, this application provides a method for processing device control rules, a device control method, an apparatus, a system, an electronic device, and a computer program product, so as to improve the configuration flexibility and personalization of hardware device control logic.

[0004] This application provides the following solution: A first aspect of this application provides a method for processing device control rules, comprising: pre-configuring information of a signal space and information of an instruction space on an electronic device decoupled from a target hardware device; acquiring features of a target signal composed of at least one signal in the signal space, and an instruction sequence composed of at least one instruction in the instruction space; establishing a mapping relationship between the features of the target signal and the instruction sequence on the electronic device; generating a rule packet based on the mapping relationship; and transmitting the rule packet to the target hardware device, wherein the rule packet is used by the target hardware device to match the features of the acquired physical signals with the features of the target signal in the rule packet to determine the instruction sequence to be executed.

[0005] A second aspect of the present invention provides a device control method applied to a target hardware device, the method comprising: Receive a rule packet sent by an electronic device decoupled from the target hardware device, the rule packet including a mapping relationship between the characteristics of the target signal and the instruction sequence; The mapping relationship between the features of the target signal and the instruction sequence is parsed and stored from the rule package; In response to the acquisition of physical signals, the features of the physical signals are extracted, and the features of the physical signals are matched with the features of the stored target signals to determine the sequence of instructions to be executed.

[0006] A third aspect of the present invention provides a device control rule processing system, comprising: a target hardware device and an electronic device decoupled from the target hardware device; the electronic device is pre-configured with information of a signal space and information of an instruction space, and the electronic device is configured to: acquire features of a target signal consisting of at least one signal in the signal space, and an instruction sequence consisting of at least one instruction in the instruction space; establish a mapping relationship between the features of the target signal and the instruction sequence on the electronic device; generate a rule packet based on the mapping relationship; transmit the rule packet to the target hardware device; the target hardware device is configured to: receive the rule packet, parse and store the mapping relationship from the rule packet; and, in response to the acquisition of a physical signal, match the features of the physical signal with the features of the target signal in the mapping relationship to determine the instruction sequence to be executed.

[0007] A fourth aspect of this application provides a device control rule processing apparatus disposed in an electronic device, the electronic device being decoupled from a target hardware device, and the electronic device having pre-configured signal space information and instruction space information. The apparatus includes: a feature acquisition unit configured to acquire features of a target signal composed of at least one signal in the signal space; an instruction acquisition unit configured to acquire an instruction sequence composed of at least one instruction in the instruction space; a mapping establishment unit configured to establish a mapping relationship between the features of the target signal and the instruction sequence on the electronic device; a rule generation unit configured to generate a rule packet based on the mapping relationship; and a rule transmission unit configured to transmit the rule packet to the target hardware device, wherein the rule packet is used by the target hardware device to match the features of the acquired physical signals with the features of the target signal in the rule packet to determine the instruction sequence to be executed.

[0008] A fifth aspect of this application provides a device control apparatus, the apparatus being disposed on a target hardware device, the apparatus comprising: The rule receiving unit is configured to receive a rule packet sent by an electronic device decoupled from the target hardware device, the rule packet including a mapping relationship between the characteristics of the target signal and the instruction sequence; The rule parsing unit is configured to parse and store the mapping relationship between the features of the target signal and the instruction sequence from the rule package; The instruction determination unit is configured to, in response to the acquisition of a physical signal, extract features of the physical signal and match the features of the physical signal with features of a stored target signal to determine the sequence of instructions to be executed.

[0009] A sixth aspect of this application provides an electronic device, including: one or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, perform the steps of the method provided in any implementation of the first aspect described above.

[0010] A seventh aspect of this application provides a target hardware device, including: one or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, perform the steps of the method described in any one of the second aspects above.

[0011] An eighth aspect of the embodiments of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method provided in any of the implementations of the first and second aspects described above.

[0012] This application pre-configures signal space and instruction space information on an electronic device decoupled from the target hardware device. It then acquires target signal characteristics and instruction sequences, establishes a mapping relationship, generates a rule package, and transmits it to the target hardware device. The target hardware device matches the acquired physical signal characteristics with the target signal characteristics in the rule package to determine the instruction sequence to be executed. Thus, signal acquisition, instruction content, and mapping logic are separated. When the device type changes or the application scenario expands, there is no need to modify the core system code; only the rule package needs to be modified or replaced to adapt to the new rules. This solves the problem of poor scalability and the inability of users to define rules due to the strong coupling of signals, instructions, and mapping in existing systems, improving system scalability and empowering users to create their own device control rules.

[0013] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a system architecture diagram applicable to the embodiments of this application.

[0016] Figure 2 A flowchart illustrating the processing method for device control rules provided in this application embodiment.

[0017] Figure 3 This is a schematic diagram of the graphical interface provided in the embodiments of this application.

[0018] Figure 4 A flowchart of a device control method provided in an embodiment of this application.

[0019] Figure 5 A schematic block diagram of a device for processing device control rules provided in an embodiment of this application.

[0020] Figure 6 A schematic block diagram of a device control apparatus provided in an embodiment of this application.

[0021] Figure 7 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] 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, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0023] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0024] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0025] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0026] In the field of intelligent device control technology, to enable hardware devices to perform specific actions based on external signals, related technologies typically employ a firmware-pre-defined rule approach. Specifically, this approach involves engineers pre-writing fixed "control logic" in the device firmware, tightly coupling feature extraction from sensor-acquired signals, instruction parsing, and the signal-to-instruction mapping relationship into a single code segment. The basic workflow is as follows: after the sensors on the hardware device acquire physical signals, the hard-coded feature matching logic identifies the signal category, and then calls the corresponding fixed instruction function to drive the actuator. This design is widely adopted because it allows the hardware device to determine its behavior before leaving the factory, directly executing the pre-defined control logic during runtime without additional configuration, ensuring deterministic response and low latency to triggered actions.

[0027] However, when users need to change or add control rules according to their own needs after the hardware device is deployed—for example, wanting to map specific punching actions on a smart punching bag to custom game keyboard combos, or associating the same clapping action in a smart home with different appliance start / stop sequences at different times—the above solution reveals structural flaws. A fundamental contradiction lies in the fact that, in order to maintain firmware stability and compactness, this solution implicitly assumes that all signal types, instruction sets, and mapping relationships can be enumerated before leaving the factory. This means that when the hardware device's application scenarios extend to personalized interactions, any adjustments to the signals, instructions, and mapping rules require redevelopment or modification of the firmware, making flexible customization and system closure mutually exclusive. Specifically, in the smart punching bag scenario, if a user only wants to bind the left punch action to a keyboard macro consisting of arrow keys and function keys, but because the mapping relationship is already fixed, they have to wait for a new firmware version or abandon the personalized definition; the hardware device cannot instantly expand its functionality according to the user's creativity.

[0028] In view of this, this application provides a new approach. To facilitate understanding of this application, the system architecture on which this application is based will first be described. Figure 1 An exemplary system architecture that can be applied to embodiments of this application is shown, such as Figure 1 As shown, the system architecture may include: an electronic device and at least one target hardware device. The electronic device and the target hardware device are physically independent of each other, and the two establish a data connection through a wired or wireless communication link. The electronic device may be a terminal with a human-computer interaction interface, such as a mobile phone, tablet computer, or personal computer. The target hardware device may be a microcontroller, embedded control module, intelligent sensor node, smart home device, game console, or other hardware entity with instruction execution capability.

[0029] On the electronic device side, a rule editing engine is provided. The rule editing engine maintains three storage and processing areas: a signal space, an instruction space, and a mapping layer. The signal space is used to record and store predefined trigger signals, each trigger signal corresponding to a signal source from the physical world or a virtual event. The instruction space is used to record and store executable instructions from the target hardware device. On the electronic device side, the mapping relationship between the characteristics of the target signals and the required instructions can be established using the method provided in this application embodiment, thereby customizing personalized rule packages and transmitting the rule packages to the target hardware device.

[0030] On the target hardware device side, a rule execution engine is set up. The rule execution engine stores the rule packets received from the electronic device in non-volatile memory and loads them into the working memory after the device is powered on; the acquisition and sensing unit collects physical signals in real time and extracts signal features; based on the extracted signal features, it queries the matching mapping relationship in the rule packet to determine the sequence of instructions to be executed.

[0031] The data flow path between the electronic device and the target hardware device is as follows: The user defines trigger signals, command sequences, and configures mapping relationships through a graphical interface provided on the electronic device. The rule editing engine packages these definitions and configurations, along with auxiliary information such as execution conditions and timing parameters, to generate a standardized rule package independent of the specific hardware platform. The rule package is transmitted to the target hardware device via Bluetooth, Wi-Fi, serial port, or other communication methods. Upon receiving the rule package, the target hardware device verifies its integrity and version. If the verification passes, it stores the rule package in the rule package storage module and begins real-time signal matching and command output according to the mapping relationships in the rule package.

[0032] Throughout the system's operation, the rule editing engine and the rule execution engine on the target hardware device are in an asynchronous and decoupled state: the generation and modification of rule packages do not require the target hardware device to restart or interrupt its current work. After receiving the updated rule package, the target hardware device can complete rule switching during operation. At the same time, electronic devices can independently complete the editing, management, import, and export of rules without the target hardware device. One electronic device can also communicate with multiple target hardware devices and issue the same or different rule packages to them respectively.

[0033] Figure 2 This is a flowchart of a method for processing device control rules provided in an embodiment of this application. This method can be performed by... Figure 1 The rule editing engine of the electronic device in the system shown is executed. This electronic device is decoupled from the target hardware device, and it has pre-configured signal space information and instruction space information. For example... Figure 2 As shown, the method may include the following steps: Step 201: Obtain the characteristics of the target signal consisting of at least one signal in the signal space, and the instruction sequence consisting of at least one instruction in the instruction space.

[0034] In this embodiment, the signal space and instruction space are pre-configured information sets on the electronic device. The signal space may contain multiple signals, each with unique identification information. The target signal can be any combination of one or more signals in the signal space, and the user can select at least one signal in the signal space as a rule triggering condition as needed.

[0035] The instruction space contains all executable instructions for the target hardware device. A user can select at least one instruction from the instruction space to form an instruction sequence. An instruction sequence can contain only a single instruction or multiple instructions arranged in a specific order.

[0036] Step 202: Establish a mapping relationship between the characteristics of the target signal and the command sequence on the electronic device.

[0037] Step 203: Generate a rule package based on the mapping relationship.

[0038] Electronic devices generate standardized rule packages that are independent of specific hardware platforms, based on user-configured mapping relationships and related execution parameters (such as instruction execution order, execution conditions, delay parameters, etc.). The rule package format can be JSON, Protocol Buffer, or a custom binary format. The process of generating a rule package involves packaging mapping relationships and execution conditions into standardized data packets, and then encapsulating them with metadata such as version information and verification information to form a complete rule package file.

[0039] Step 204: Transmit the rule packet to the target hardware device. The rule packet is used by the target hardware device to match the features of the acquired physical signals with the features of the target signals in the rule packet to determine the sequence of instructions to be executed.

[0040] Electronic devices can send rule packets to target hardware devices via communication methods such as Bluetooth, wireless, and serial ports. After receiving the rule packets, the target hardware device stores them in local non-volatile memory (such as Flash or NVS) and loads them into memory during runtime.

[0041] During operation, the target hardware device acquires physical signals (such as acceleration, sound, and images) in real time through its sensing unit, extracts signal features, and matches the extracted features with the features of the target signal stored in the rule package. Once a match is successful, the corresponding instruction sequence is determined based on the mapping relationship.

[0042] As can be seen from the above process, the method provided in this application completely decouples the signal space, instruction space, and mapping relationship, and generates a rule package independent of the target hardware device. This allows users to define the control rules of the target hardware device independently without unlocking the hardware firmware. When it is necessary to change the control rules, the user only needs to modify the mapping relationship on the electronic device and generate a new rule package to send to the target hardware device. This achieves asynchronous decoupling between modifying the control rules and the operation of the hardware device, greatly improving the system's flexibility, scalability, and personalization.

[0043] The steps in the above process will be described in detail below with reference to the embodiments. First, step 201, namely "acquiring the characteristics of the target signal composed of at least one signal in the signal space, and the instruction sequence composed of at least one instruction in the instruction space", will be described in detail with reference to the embodiments.

[0044] In this embodiment, the electronic device maintains a signal space and an instruction space. The signal space is like a warehouse of signals that may be triggered. The signal space may contain signals entered by the user through demonstrating physical actions, or it may have pre-set standard signals available for the user to select. The target signal is a signal in the signal space, or it may be composed of a combination of multiple signals in the signal space, and its generation can be in various ways.

[0045] The instruction space contains all executable instructions of the target hardware device. Users can select at least one instruction from the instruction space to form an instruction sequence. An instruction sequence can contain only a single instruction or multiple instructions arranged in a specific order. It is important to note that the signal space and instruction space are independent of each other and decoupled from the subsequently established mapping relationships. This design allows signal definition, instruction definition, and rule orchestration to be performed independently; modifications to any part will not affect other parts, thus ensuring system scalability and user-configurable flexibility in the architecture.

[0046] One possible way to acquire the characteristics of a target signal is through user demonstration. Specifically, the sensing unit of an electronic device can collect the physical actions demonstrated by the user, acquire the signal corresponding to the physical actions and belonging to the signal space as the target signal; acquire the identification information of the target signal; extract the features of the target signal, and store the correspondence between the features and the identification information of the target signal.

[0047] For example, an electronic device, such as a mobile phone, tablet, or personal computer, is equipped with at least one sensing unit, such as a microphone, camera, or accelerometer. When a user demonstrates a physical action, such as clapping, hitting a virtual button, or striking a specific area of ​​a punching bag, the sensing unit collects the raw signal corresponding to that physical action. If the raw signal belongs to a signal type defined in the signal space, then that raw signal is used as the target signal.

[0048] Simultaneously or subsequently, the electronic device acquires the identification information of the target signal. This identification information may include a unique identifier automatically generated by the system (e.g., signal identifier S1) and a user-defined signal name (e.g., left fist). This identification information is used to uniquely mark the target signal in the signal space, thereby distinguishing different target signals when establishing mapping relationships and generating rule packages. In practice, the user can assign a readable name to the entered target signal in the graphical interface of the electronic device, and the system binds and stores this name with the unique identifier.

[0049] Subsequently, the electronic device extracts features of the target signal from the target signal. Feature extraction can employ algorithms such as time-domain analysis, frequency-domain analysis, or joint time-frequency-domain analysis to generate feature vectors that characterize the uniqueness of the signal. For example, for a striking action signal acquired by an accelerometer, statistical quantities such as peak amplitude, pulse width, and vibration period in its time-domain waveform, as well as the frequency-domain energy distribution obtained after fast Fourier transform, can be extracted as components of the feature vector; for clapping sound signals acquired by a microphone, acoustic features such as Mel-frequency cepstral coefficients can be extracted; for video signals acquired by a visual sensor (such as a camera) (e.g., a user demonstrating a specific gesture, body posture, or action sequence), computer vision and pattern recognition technologies can be used (e.g., using traditional visual extraction methods to extract spatiotemporal key point features, motion trajectory features, etc.; or, for example, using deep learning models for action recognition, skeleton key point recognition, etc.) to extract the feature vector corresponding to the video. The extracted feature vectors constitute the features of the target signal. The electronic device associates and stores the correspondence between the extracted features of the target signal and the identification information (e.g., signal identifier S1 and name left fist), for example, recording them in the form of key-value pairs in the storage area of ​​the signal space.

[0050] By utilizing the aforementioned method of acquiring target signal features through user-demonstrated physical actions using a sensing unit, users only need to perform natural physical actions to define and input trigger signals, without requiring knowledge of signal processing or programming, thus lowering the barrier to user-defined rules. Simultaneously, the system generates feature vectors using a unified feature extraction algorithm, ensuring consistent feature representations for similar signals input by different users or at different times, thereby improving the accuracy of subsequent signal matching.

[0051] It is understood that the aforementioned sensing units are not limited to accelerometers and microphones, but may also include cameras (for recognizing gestures or postures), gyroscopes, pressure sensors, etc., as long as they can convert the user's physical actions into electrical or digital signals and extract features. Furthermore, the specific algorithm used for feature extraction can be flexibly selected according to the signal type and application requirements. For example, machine learning models such as support vector machines and convolutional neural networks can be used for feature learning and extraction, as long as they can generate stable and discriminative feature vectors. These equivalent implementations all fall within the scope of this application.

[0052] When acquiring an instruction sequence consisting of at least one instruction in the instruction space, one possible approach is to acquire at least one instruction input by a user through the input interface of an electronic device, and map the input at least one instruction into an instruction sequence executable by the target hardware device based on a preset instruction mapping table.

[0053] In this implementation, users do not need to directly interact with the underlying instruction protocols or control codes of the target hardware device. Instead, they can define instructions using familiar and convenient operating methods through the electronic device's standard input interfaces. For example, the electronic device could be a user's personal computer or smartphone, and its input interfaces could include, but are not limited to, a keyboard, mouse, touchscreen, microphone, or camera. Users can demonstrate a standard set of keyboard macros on the electronic device using a keyboard and mouse, such as sequentially pressing a series of keys in a fighting game to unleash a skill. The electronic device captures and records this series of input events performed by the user on the input interface, using this sequence of input events as a user-defined instruction.

[0054] Next, to convert this user-level input into a sequence of instructions that the target hardware device can parse and execute, the system invokes a pre-defined instruction mapping table. This instruction mapping table, stored in the electronic device, contains the correspondence between user-side input events and standard instruction codes on the target hardware device side. For example, the instruction mapping table can maintain one or more mapping entries, mapping keyboard key events (such as pressing a specific combination of keys) to specific HID keyboard report codes, Bluetooth command frames, serial port control commands, or GPIO level signal sequences. Based on this mapping table, the system converts the user-input keyboard macros into a sequence of standard control instructions that the target hardware device can directly invoke.

[0055] As an alternative, users can also define commands via voice input. For example, a user can say "turn on the light" into the microphone of an electronic device. The electronic device receives the voice signal, first converts the voice into text, then matches the text command "turn on the light" with preset device control commands in the command mapping table, and finally parses it to obtain a Bluetooth command sequence that the target hardware device can execute to control the smart light. Similarly, users can also define commands through various input interfaces such as mouse drag-and-drop operations and touchscreen gestures. All these user-side operations can be uniformly converted into standard command sequences for the target hardware device through the command mapping table.

[0056] In this way, the specific operations of user-defined instructions are completely decoupled from the underlying instructions ultimately executed by the target hardware device in terms of format and protocol. The instruction mapping table acts as a conversion bridge between the two. This not only allows ordinary users without programming skills or hardware knowledge to easily define complex device control instructions in a WYSIWYG, zero-code manner, but also ensures that user-defined personalized instructions can be accurately recognized and executed by target hardware devices of different models and communication protocols. This significantly lowers the technical threshold for users to define their own device control rules and improves the user experience.

[0057] In this embodiment, the process of acquiring the characteristics of the target signal and the instruction sequence in the above steps can also be implemented using natural language interaction to further reduce the operational threshold for user-defined rules. In one implementation of this embodiment, the input interface of the electronic device may include a microphone and a speech recognition module. The user inputs natural language instructions through the electronic device, for example, the user says to the phone, "If a clapping action is detected, execute the instruction to turn on the living room light." After acquiring the natural language instruction in speech form, the electronic device converts it into corresponding text content and performs intent parsing. The intent parsing process can be implemented based on a preset intent template, trigger words, or a trained intent classification model, decomposing the text content into signal intent content and instruction intent content. For example, the signal intent content parsed from the above statement is "clapping action," and the instruction intent content is "turn on the living room light."

[0058] After obtaining the signal intent content, the electronic device maps it to the corresponding signal in the signal space. For example, each signal in the signal space can be pre-associated with one or more natural language keywords (such as "clapping" or "high five"). The electronic device finds the signal identifier (such as signal ID "S_CLAP") corresponding to the "clapping action" by performing semantic matching or keyword retrieval on the signal intent content, and obtains the feature vector already stored for that signal. If the signal space does not yet contain the signal, the electronic device can prompt the user to supplement the demonstration of the physical action through the sensing unit to store it in the signal space, and then extract the features according to the aforementioned embodiment before completing the mapping.

[0059] Similarly, electronic devices map the intent of instructions to corresponding instruction sequences in the instruction space. For example, the instruction space stores the instruction identifier "I_LIGHT_ON," whose associated natural language keywords include "turn on the living room light" and "turn on the light," and corresponds to a series of control codes or keyboard macro instruction sequences executable by the target hardware device. The electronic device retrieves the instruction identifier "I_LIGHT_ON" from the instruction space based on "turn on the living room light," and then obtains the corresponding instruction sequence. This instruction sequence can be an infrared control code, a Wi-Fi control message, or a GPIO output signal sequence, depending on the interface type of the target hardware device.

[0060] This embodiment allows users to simply describe the desired signal triggering and action execution relationships in everyday language, without needing to concern themselves with the underlying signal feature extraction algorithms or specific instruction formats. The system automatically converts natural language into standardized rule packages, further lowering the technical barrier for users to define their own device control rules. Simultaneously, the intent parsing process can reuse existing signal features and instruction sequences in the signal and instruction spaces, ensuring the standardization and executability of the rule packages.

[0061] The following describes step 202, namely "establishing a mapping relationship between the characteristics of the target signal and the instruction sequence on the electronic device", in detail with reference to the embodiments.

[0062] After acquiring the characteristics of the target signal and the command sequence, the electronic device further establishes a mapping relationship between the two. To facilitate users in defining the mapping relationship between the target signal and the command sequence in an intuitive and visual way, a typical implementation is to provide a graphical interface (GUI). This GUI displays at least one signal node and at least one command sequence node, where the target signal corresponds to the first node and the command sequence corresponds to the second node. Users can establish the mapping relationship by performing selection and pairing operations (such as dragging and dropping lines, checking group numbers, etc.) on the first and second nodes within this GUI. This method allows users to intuitively complete the logical binding of signals and commands without writing any code or understanding the underlying data structures.

[0063] Figure 3 A schematic diagram of the graphical interface is shown. See also Figure 3 The graphical interface displays three signal nodes and five instruction sequence nodes. Signal nodes correspond to trigger signals in the signal space, and each node can be associated with and display the signal's name and identifier. Instruction sequence nodes correspond to instruction sequences in the instruction space, and each node can be associated with and display the instruction sequence's name, identifier, or a summary of the instruction's content. After the user has defined the target signal and instruction sequence through demonstration or input, the first node corresponding to that target signal can be seen on the graphical interface. For example, a target signal named "3 consecutive left punches," another named "clapping," and yet another named "start voice." The instruction sequence entered by the user corresponds to a second node, for example, the instruction sequence corresponding to "Fighting Skill A," and yet another named "Turn on the living room light." Users can establish mapping relationships through selection and pairing operations.

[0064] The selection and pairing operations can take several forms. One possible approach is to display signal nodes in the signal space and instruction nodes in the instruction space on a graphical interface. Users can then select a first node and a second node by checking boxes and setting a group number, thus achieving the selection and pairing of the first and second nodes. For example... Figure 3 As shown, assuming the user selects the signal node named "3-hit left punch" (as the first node) and the command sequence node named "Fighting Skill A" (as the second node), and clicks the "Pair" button, a mapping relationship between the two can be established. Besides this method, other methods can also be used. For example, the user can drag the first node to the second node, or the second node to the first node, using a mouse, touch, or gesture; or they can select the first node and then click the second node, and so on.

[0065] Through the visualization and operation methods described above, users do not need programming skills or knowledge of underlying data structures to intuitively complete the logical binding of signals and instructions, greatly reducing the complexity of rule configuration and improving the efficiency and accuracy of rule definition. Furthermore, the graphical interface can provide auxiliary components such as group number identifiers and enable / disable switches to support users in managing and adjusting established mapping relationships.

[0066] Based on the above-mentioned establishment of the mapping relationship between target signals and instruction sequences through a graphical interface, in order to meet the user's need for precise control over the execution order of multiple instructions under the same mapping relationship, in one optional implementation, the execution order of each instruction within the instruction sequence node can also be adjusted, and the mapping relationship can be updated in a linked manner if the mapping relationship has been established.

[0067] Specifically, in response to the user's operation of adjusting the execution order of each instruction in the second node (i.e., the node corresponding to the instruction sequence) in the graphical interface, the instruction sequence corresponding to the second node is updated based on the adjusted execution order; if a mapping relationship between the target signal and the instruction sequence has been established, the mapping relationship is updated based on the updated instruction sequence.

[0068] Taking the intelligent punching target scenario as an example, after the user selects the first node representing a three-hit left punch signal and the second node representing the command sequence "Fighting Skill A" in the graphical interface, the second node can expand to display the commands contained in the command sequence, for example, the default order is down, forward, punch. If the user wants to change the execution order, they can drag and drop the punch button to move it before the down button, or click the sort button to adjust the button order to forward, down, punch. After the system captures this adjustment operation, it will update the internal order identifier of the command sequence and store the adjusted command sequence as a new ordered set. At the same time, since the command sequence node has already established a mapping relationship with the left punch signal node, the system automatically refreshes the associated mapping relationship based on the updated command sequence, so that the command sequence pointed to by the mapping relationship is consistent with the adjusted order. When the subsequent rule package is generated, it will include the updated mapping relationship and the corresponding command order information.

[0069] In this way, users can intuitively modify the execution order of multiple instruction combinations without deleting the original mapping relationship and reconfiguring, thereby simplifying the definition process of complex rules and ensuring that when users arrange multiple consecutive instructions to form an instruction sequence for the same signal, the target hardware device can execute multiple consecutive instructions in the instruction sequence accurately and orderly according to the user's intention.

[0070] Optionally, adjusting the execution order is not limited to dragging; it can also be achieved by clicking the up or down buttons, entering a sequence number, etc. When storing the instruction sequence, the system can assign a unique sequence identifier to each instruction in the sequence, such as an integer value incrementing from 1. After adjusting the order, the sequence identifier is reassigned. If a new mapping relationship is subsequently established, the new mapping relationship will directly point to the latest instruction sequence, ensuring the real-time nature and consistency of rule editing.

[0071] Building upon the above embodiments, this application further provides an optimized implementation scheme for establishing mapping relationships. During the process of a user defining control rules through an electronic device, if only basic functions such as signal selection and command selection are provided, the user still needs to understand the correspondence logic between signal identifiers and command identifiers, and manually establish the association between them via text or command lines. This still presents a high operational threshold and is prone to errors for ordinary users without programming skills. To further simplify the process of establishing mapping relationships and make the operation more intuitive and efficient, this application further introduces a first setting component into the graphical interface.

[0072] Specifically, in addition to displaying the signal nodes and instruction sequence nodes in the aforementioned embodiments, the graphical interface also provides one or more first setting components. These first setting components can be represented on the graphical interface as input boxes, drop-down selection boxes, time selectors, sliders, switches, map point selection controls, etc., and are used to receive execution condition information configured by the user for a specific mapping relationship. After the user performs selection and pairing operations on the first and second nodes to establish the mapping relationship between the characteristics of the target signal and the instruction sequence, they can further add one or more execution conditions to the mapping relationship through the first setting components. This ensures that the device does not unconditionally execute the instruction sequence during actual operation, but rather performs white-box decision-making based on environmental conditions, device conditions, or user-preset rules.

[0073] The condition setting area on the graphical interface may include at least one of the following components: time condition setting component, location condition setting component, environmental condition setting component, device status condition setting component, execution timing condition setting component, biometric condition component, security threshold setting component, and conflict detection condition setting component. In addition to these components, it may also include user-defined condition setting components. The user inputs or selects the corresponding parameters in these components, and the system will obtain the execution condition information set by the user.

[0074] The time condition setting component allows users to define the time range within which the mapping relationship takes effect, such as 22:00 to 06:00 the next day, 09:00 to 17:00 on weekdays, or specify a specific date interval. In one implementation, this component can provide a time selector, allowing users to set time parameters through a visual clock or date calendar interface. The system then converts the user-defined time conditions into a set of time judgment expressions that can be parsed by the hardware device, such as "current_time>22:00 AND current_time<06:00".

[0075] The location conditions setting component allows users to define the geographical range within which the mapping relationship applies. When the electronic device has location capabilities, this component can call the device's map interface, allowing the user to define a geographical area on the map or enter a specific location name. The system then converts the geographical location conditions into a set of coordinate ranges or geographic identifiers, such as "current_location = home". In one implementation, location conditions can be associated with pre-stored points of interest (POIs) on the electronic device; the user simply selects a preset location such as "home" or "work" to complete the configuration.

[0076] The environmental conditions setting component allows users to configure execution conditions related to environmental sensing data. This component provides options for environmental parameter types, comparison operators, threshold inputs, duration inputs, and logical combinations of multiple environmental conditions within a graphical interface. Configurable environmental parameter types can include ambient temperature, ambient humidity, light intensity, air quality index, ambient noise, atmospheric pressure, vibration amplitude, and weather conditions. Users can configure conditions such as "ambient light intensity less than 50 lux," "ambient temperature below 10 degrees Celsius," "rainy weather," and "ambient noise greater than 70 dB for more than 3 seconds."

[0077] The device status condition setting component allows users to set status conditions that a target hardware device or its associated devices must meet. For example, in a smart home scenario, users can set status conditions such as "current room brightness is below a threshold," "air conditioner is off," and "door lock is engaged." In a smart boxing target scenario, users can set status conditions such as "boxing target is in game mode" and "battery level is above 20%." The implementation of this component can rely on the status parameters reported by the target hardware device. When configuring the rule package, the electronic device selects the corresponding parameters and thresholds from a pre-obtained list of device status parameters.

[0078] The execution timing condition setting component allows users to set the execution order and time interval between instructions in an instruction sequence. Combined with the drag-and-drop method used in the previous embodiment to adjust the instruction execution order, this component can further provide precise settings for delay parameters. For example, users can input a time parameter such as "wait 500 milliseconds after instruction A is executed before executing instruction B". This timing condition configuration can be nested within the editing interface corresponding to the instruction sequence node, or it can be used as an external additional condition for the mapping relationship.

[0079] The biometric condition setting component allows users to set execution conditions related to a user's physical condition or identity characteristics. This component provides options for biometric type selection, comparison mode selection, threshold range input, continuous satisfaction duration configuration, and logical combination configuration between multiple biometric conditions within a graphical interface. Biometric types can include heart rate, body temperature, respiratory rate, blood oxygen saturation, skin conductance, facial features, voiceprint features, fingerprint features, gait features, and posture features. Comparison modes can include threshold comparison, range comparison, template matching, and feature similarity comparison. Users can configure corresponding biometric conditions for specific application scenarios. For example, in wearable device scenarios, conditions such as "heart rate greater than 100 beats / minute," "body temperature higher than 37.3 degrees Celsius," and "continuous high heart rate state for 2 minutes" can be set; in smart interactive device scenarios, conditions such as "voiceprint matching to a registered user" and "facial recognition to a family member" can be set.

[0080] The safety threshold setting component allows users to set threshold conditions related to physical safety. For example, in a robot control scenario, a user can set "do not execute the forward command when the distance to an obstacle is less than 2 meters." This component is typically presented as a numerical input box with a unit selection, allowing users to enter a specific threshold value and select the corresponding physical quantity unit.

[0081] The conflict detection condition setting component allows users to set detection conditions related to multi-task conflicts. For example, in an embodied smart device, a user can set "prohibit the execution of the door opening command when the gripper is holding an object." This component can be implemented by querying the task state machine of the target hardware device. For instance, the electronic device interacts with the target hardware device to query its task state machine information, and the configuration interface can provide a list of the current device's task states, allowing the user to select the conflicting task states.

[0082] The user-defined condition setting component allows users to set execution conditions represented by user-defined logical expressions, in addition to system preset options. This component provides a variable selector, operator selector, function selector, expression editing area, and expression validation entry point within a graphical interface. Variables can include time variables, location variables, device status variables, signal parameter variables, resource usage variables, environmental variables, and biometric variables. Operators can include comparison operators, arithmetic operators, logical operators, and function calls. Users can directly input conditional expressions or generate them by adding variables, operators, and functions.

[0083] After the user completes the execution conditions settings through the first settings component, the system obtains the execution condition information set by the user for the mapping relationship and stores this information in association with the mapping relationship. This association can be achieved by adding a condition field to the data structure of the mapping relationship. This condition field contains structured expressions for various execution conditions set by the user. For example, in a JSON-formatted data structure, time conditions, location conditions, device status conditions, etc., can be organized into independent sub-objects and uniformly attached to the mapping relationship object. Simultaneously, the system supports users setting logical combinations between different conditions. For example, using AND logic to require all conditions to be met simultaneously, using OR logic to require at least one condition to be met, or combining them using more complex nested logical expressions.

[0084] In this way, when defining device control rules, users can not only specify "what triggers what," but also precisely define "under what circumstances it triggers," enabling the target hardware device to make adaptive decisions based on the environment. This method of explicitly and structurally integrating execution conditions into the rule package ensures the transparency, determinism, and traceability of execution. It solves the problem that simple signal-to-instruction mapping in related technologies cannot meet the needs of conditional decision-making in complex scenarios, allowing device behavior to automatically adapt to different environmental states and ensuring the safety of the execution process.

[0085] It should be noted that the above execution conditions can be used individually or in any combination. In a specific application scenario, taking a smart boxing target as an example, the user can configure the graphical interface to establish a mapping relationship between the target signal "3 consecutive left punches" and the instruction sequence "fighting skill A," while simultaneously setting the device status condition component to "only take effect when the boxing target's battery level is greater than 20%." The generated rule package will contain both this mapping relationship and the aforementioned execution conditions. When the boxing target is running, it will only trigger the execution of the "fighting skill A" instruction sequence after recognizing the "3 consecutive left punches" signal if the battery level condition is met; otherwise, even if the "3 consecutive left punches" signal is matched, the instruction sequence will not be executed.

[0086] In another application scenario, taking smart home control as an example, users can establish a mapping relationship between the trigger signal "clapping" and the command sequence "turn off all lights," and set it to "only effective when at home" through the location condition setting component, and "effective from 22:00 to 06:00" through the time condition setting component. In this way, the hardware device will only execute the light-off command sequence when it recognizes the clapping signal at night and when the user is at home (this can be determined by obtaining the user's mobile phone location). During the day or when the user is away from home, even if the clapping signal is recognized, the light-off action will not be executed, realizing context-aware differentiated control.

[0087] The mapping relationship can support multiple types, including but not limited to one-to-one (one signal corresponds to one instruction sequence), one-to-many (one signal corresponds to multiple instruction sequences), many-to-one (multiple signals correspond to the same instruction sequence), and many-to-many.

[0088] By establishing a mapping relationship between the characteristics of the target signal and the instruction sequence, this application extracts the corresponding rules of triggering conditions and execution actions from the hardware firmware and transforms them into user-editable logical data, laying the foundation for the subsequent generation of portable rule packages.

[0089] The aforementioned execution condition information and execution sequences typically correspond one-to-one. Since the same target signal may correspond to multiple execution sequences, this means that the same target signal may correspond to multiple execution condition information. The execution condition information is used to route to the corresponding execution sequence. In other words, the execution condition information is used by the target hardware device to determine the sequence of instructions to be executed based on the execution condition information contained in the rule package.

[0090] In one embodiment, the graphical interface further includes a second setting component, which may be a parameter panel, pop-up window, slider, input box, drop-down box, check box or a combination thereof, for allowing the user to set resource quota information for the instruction sequence.

[0091] In one possible implementation, when a user selects an instruction sequence node or mapping record, the electronic device displays a second settings component in a graphical interface. The second settings component can display at least one configuration item among CPU quota, memory quota, and I / O quota. For example, CPU quota can represent the processing time slice, number of execution cycles, or processor usage limit allowed for the instruction sequence within a single trigger cycle; memory quota can represent the maximum amount of heap memory, cache size, or number of temporary objects allowed to be requested during the execution of the instruction sequence; and I / O quota can represent the maximum access frequency, number of accesses, or duration of input / output resources such as serial ports, Bluetooth, Wi-Fi, GPIO, and peripheral buses allowed for the instruction sequence.

[0092] In response to a user setting control parameters via a second setting component, the electronic device acquires the resource quota information set by the user for the instruction sequence. This resource quota information can be stored in association with the instruction identifier of the instruction sequence, the mapping identifier of the mapping record, and the corresponding signal identifier. For example, the mapping record may include signal identifier S1, instruction identifier I1, enable status, sequence identifier, and resource quota information; whereby the resource quota information may include fields such as CPU time slice limit, memory usage limit, and I / O access limit. Therefore, the resource quota information is not an isolated global configuration, but rather bound to a specific mapping relationship and its corresponding instruction sequence, allowing different instruction sequences under different mapping relationships to have different resource scheduling constraints.

[0093] Furthermore, during the rule packet generation process, the electronic device can encapsulate the characteristics of the target signal, the instruction sequence, the mapping record, and the resource quota information into a rule packet. The resource quota information enables the target hardware device to determine the resource scheduling boundary corresponding to each executable instruction sequence after parsing the rule packet.

[0094] After the target hardware device receives the rule packet, the rule execution engine can parse and store the rule packet. Based on the mapping relationship in the rule packet, the engine determines the sequence of instructions to be executed and schedules the corresponding computing resources for the instruction sequence based on the resource quota information.

[0095] If the actual resource usage of an instruction sequence is close to or reaches the corresponding quota, the resource quota scheduling module can postpone execution, execute in segments, suspend execution, or terminate the execution of the instruction sequence and record the execution status.

[0096] In another embodiment, the graphical interface also includes a third setting component, which may be a parameter panel, pop-up window, input box, drop-down box, check box, slider or a combination thereof, for users to set circuit breaker parameter information for the instruction sequence and select or enter alternative instruction sequences from the instruction space.

[0097] In one feasible implementation, when the user selects a mapping connection or instruction sequence node, the electronic device displays a third settings component in a graphical interface. This third settings component may include configuration items such as a maximum number of consecutive failures, a timeout threshold, overload degradation conditions, and a backup instruction sequence selection option. The maximum number of consecutive failures limits the number of times the same instruction sequence is allowed to fail during continuous triggering or execution; the timeout threshold limits the allowed time between the start of instruction sequence execution and receiving completion feedback; the overload degradation condition triggers degradation processing when the device's processor load, memory usage, I / O congestion, or peripheral response anomalies reach preset conditions; and the backup instruction sequence selection option allows selecting at least one existing instruction sequence from the instruction space, or inputting new device control codes, keyboard macros, voice commands, peripheral control commands, etc., as backup instruction sequences.

[0098] In response to a user setting circuit breaker parameters via a third-party settings component, the electronic device acquires the circuit breaker parameters and backup command sequences set by the user for the command sequence. For example, a user can set a maximum of 3 consecutive failures and a timeout threshold of 2 seconds for a device control command sequence, and configure the device to stop executing the current command sequence or switch to a backup command sequence when the number of consecutive failures reaches the maximum or the duration of a single execution exceeds the timeout threshold. The above values ​​are merely examples; specific values ​​can be adjusted based on the processing power of the target hardware device, the communication link response time, the peripheral device's action cycle, and the user's configuration.

[0099] Electronic devices can associate and store circuit breaker parameters, backup instruction sequences, and mapping relationships. The same instruction sequence can have different circuit breaker strategies under different mapping relationships, and different instruction sequences can also be configured with different backup instruction sequences.

[0100] When generating rule packets, electronic devices can generate rule packets based on mapping relationships and circuit breaker parameter information. After receiving the rule packets, the target hardware device can parse and store them using the rule execution engine. The rule execution engine in the target hardware device collects physical signals in real time and extracts features. It then matches the features of the collected physical signals with the features of the target signals in the rule packets to determine the instruction sequence to be executed. During the execution of this instruction sequence, execution parameters are acquired, and it is determined whether the execution parameters meet the corresponding circuit breaker parameter information. If the circuit breaker is triggered, the execution of the current instruction sequence is stopped or downgraded to the execution of the corresponding backup instruction sequence.

[0101] In a specific application scenario, users can configure a circuit breaker strategy for a device control command sequence on an electronic device. For example, a user maps a clapping signal to a curtain-closing command sequence and sets circuit breaker parameters through a third-party setting component: when the curtain-closing command fails consecutively a preset number of times or exceeds a preset execution time, the execution of the curtain-closing command is stopped, and a pre-configured backup command sequence is executed. After the rule package is sent to the target hardware device, the target hardware device, upon detecting the clapping signal and determining that the curtain-closing command sequence is the command to be executed, can continuously record the feedback status and execution time of the command sequence during execution. Once the execution parameters meet the circuit breaker parameters, the target hardware device can stop the abnormal command sequence and execute the backup command sequence, thereby reducing the situation where the device occupies execution resources for a long time due to repeated attempts at abnormal commands.

[0102] In this way, circuit breaker parameters and backup instruction sequences are configured and written into the rule package during the rule editing phase, and directly parsed and executed by the target hardware device during the execution phase. This method allows the circuit breaker strategy to be migrated, stored, and reused as part of the rule package along with the mapping relationship, rather than relying on runtime temporary configuration. When a user-defined instruction sequence repeatedly fails, times out, or causes overload, the target hardware device can promptly stop abnormal execution or degrade to a backup execution path based on the encapsulated circuit breaker parameters, thereby reducing the risk of the system getting stuck in an infinite loop, waiting indefinitely, or occupying resources for a long time, and improving the stability and recoverability of user-defined rules in embedded control scenarios.

[0103] In some embodiments, to reduce redundant signal objects generated when users repeatedly input the same physical action, the electronic device can extract waveform key points, temporal distribution information, and extreme value distribution information from the target signal when extracting its features. Based on this information, a feature fingerprint is generated and used as the feature of the target signal. When establishing a mapping relationship between the features of the target signal and the instruction sequence on the electronic device, it can first determine whether an existing target signal feature with a similarity greater than or equal to a preset similarity threshold already exists in the existing mapping relationship on the electronic device. If such a feature already exists, the mapping relationship between the generated feature fingerprint and the instruction sequence is updated using this mapping relationship; otherwise, a new mapping relationship between the generated feature fingerprint and the instruction sequence is created on the electronic device.

[0104] In one feasible approach, key waveform points can include one or more of the following: start point, end point, slope abrupt change point, zero-crossing point, local peak point, local valley point, and energy abrupt change point in the target signal waveform. Taking the acceleration signal of hitting a punching target as an example, key waveform points can include the main peak point generated at the moment of impact, the rising edge inflection points before and after the main peak, and the decay edge inflection points. Taking the clapping sound wave signal as an example, key waveform points can include the starting point of the rapid increase in sound pressure amplitude, the peak point of sound wave energy, and the point where the energy decays to a preset proportion. By extracting these key points, the characteristics of the target signal can not only depend on the sampled values ​​of the complete waveform but also reflect the main structural changes of the physical action.

[0105] Temporal distribution information can be used to describe the variation patterns of a target signal over time. For example, it can include the time intervals between key waveform points, signal duration, peak arrival time, energy concentration periods, the order of appearance of multiple sub-peaks, and the distribution of energy over time within the sampling window. When the same user repeatedly performs the same action, although the amplitude of each action may differ, the order of key point appearances and the temporal relationship between the main peak and the attenuation segment usually exhibit relatively stable patterns. Therefore, incorporating temporal distribution information into the feature fingerprint helps distinguish different types of actions and reduces sensitivity to single amplitude fluctuations.

[0106] Extreme value distribution information can be used to describe the maximum, minimum, local maxima, and local minima in a target signal, as well as their relative positions and amplitude relationships. For example, extreme value distribution information can include the amplitude of the main peak, the amplitude of the secondary peak, the peak-to-valley difference, the number of extreme values, the extreme value density, the amplitude ratio between adjacent extreme values, and the relative position of the extreme values ​​within a time window. Taking a left punch and a right punch as examples, both may manifest as acceleration impact signals, but due to differences in the striking position, direction, or sensor installation angle, the extreme value amplitude distribution and the location of the extreme values ​​may differ. Extreme value distribution information can enhance the distinguishability between different actions.

[0107] As one feasible approach, during the feature fingerprint generation process, waveform key points, temporal distribution information, and extreme value distribution information can be structurally combined to obtain the feature vector of the target signal. Then, the feature vector can be reduced in dimension, quantized, or hashed to generate the feature fingerprint.

[0108] When establishing the mapping relationship between the features of a target signal and the command sequence, the similarity between the newly generated feature fingerprint and the features of existing target signals can be calculated one by one. If it is determined that there is a feature of an existing target signal in the existing mapping relationship whose similarity to the newly generated feature fingerprint is greater than or equal to a preset similarity threshold, then it can be determined that the target signal being entered this time and the existing target signals belong to the same source signal or the same type of action signal. In this case, the electronic device does not need to create a new trigger signal object separately for this entry, but can use the mapping relationship between the newly generated feature fingerprint and the command sequence to update the mapping relationship between the features of the existing target signal and the command sequence. The update may include: replacing the feature fields of the existing target signal with the newly generated feature fingerprint, or saving the newly generated feature fingerprint as a new fingerprint version of the existing target signal; at the same time, updating the command sequence identifier corresponding to the target signal to the command sequence identifier selected or entered by the user this time.

[0109] For example, in a smart punching target scenario, when a user strikes the left fist area for the first time, the system generates a feature fingerprint FP1 and establishes a mapping relationship between the signal identifier S1 and the keyboard macros down, forward, and punch corresponding to the command identifier I1. If the user subsequently records a left fist action, generating a feature fingerprint FP1a due to slight differences in striking force or angle, the electronic device can compare FP1a with FP1 for similarity. If the similarity is greater than or equal to a preset similarity threshold, the electronic device can recognize that the action corresponding to FP1a still belongs to the left fist action and update the mapping relationship between S1 and the currently set command sequence by the user, instead of adding a new signal identifier. In this way, when the target hardware device subsequently collects a physical signal matching the left fist action, it can still find the updated command sequence through the same signal object.

[0110] In some embodiments, in order to retain historical traceability after the user modifies the acquisition parameters, waveform recording results or identification features of the target signal, the electronic device can maintain a feature snapshot version chain for the target signal in the signal space.

[0111] The feature snapshot of the target signal can be understood as a fixed record of the features of a certain version of the target signal. The version number can be represented by an incrementing number, a timestamp, a hash version identifier, or a combination thereof, such as S1_V1, S1_V2, etc. The enabled status can be used to indicate the version currently being used by the rule editing engine or the rule execution engine.

[0112] In one implementation, after a user re-records or modifies the target signal via an electronic device, the electronic device extracts waveform key points, temporal distribution information, and extreme value distribution information from the new target signal, and generates a new feature fingerprint accordingly. If the electronic device determines that the similarity between the new feature fingerprint and the features of the existing target signal is greater than or equal to a preset similarity threshold, it can be considered that the new feature fingerprint and the existing target signal belong to different versions of the same source signal. In this case, the electronic device no longer creates a new independent signal object, but instead generates a feature snapshot of a new version of the target signal under the existing target signal object, for example, generating version S1_V2 after the existing version S1_V1.

[0113] When generating a feature snapshot of a new version of the target signal, the electronic device can write the new feature fingerprint into the new version snapshot record while retaining the previous version snapshot record unchanged. The mapping layer can synchronously record the mapping relationship between the feature snapshot of the new version of the target signal and the instruction sequence, and mark the mapping relationship as enabled. For example, the target signal S1 originally corresponded to version S1_V1, and S1_V1 had a mapping relationship with the instruction sequence I1. When the user re-records the same striking action and generates the feature fingerprint FP2, the electronic device can generate a snapshot S1_V2, establish a mapping relationship between S1_V2 and the instruction sequence I1, and set the enabled state field of this mapping relationship to enabled. Correspondingly, the mapping relationship between S1_V1 and the instruction sequence I1 can be retained and can be set to disabled or historical state.

[0114] The above processing method ensures that the target signal maintains object continuity by using the same signal identifier when iteratively modified, instead of generating multiple isolated signal objects due to each re-recording. Since the mapping layer records the relationship between versioned feature snapshots and instruction sequences, downstream rules can clearly correspond to a specific version of the signal features, avoiding situations where the features on which historical rules were based cannot be determined after the signal features are overwritten.

[0115] In some embodiments, version rollback can be triggered by a user in a graphical interface. For example, an electronic device can display multiple historical version snapshots of a target signal in the target signal's details interface, including version number, creation time, feature summary, enabled status, and associated instruction sequence. The user can select a feature snapshot of the previous version of the target signal and trigger the rollback control. In response to the version rollback operation, the electronic device marks the mapping relationship between the feature snapshot and instruction sequence of the previous version of the target signal as enabled.

[0116] In some embodiments, electronic devices may also record metadata such as creation time, usage count, or operation source in version snapshots. Creation time can be used to display versions chronologically on the interface; usage count can help users determine the frequency of use of a particular version in actual operation; operation source can distinguish whether the version was generated by re-recording, parameter modification, or version rollback. The aforementioned metadata does not change the basic logic of signal matching and instruction execution, but it facilitates the management and traceability of rule assets.

[0117] In this way, each feature update of the target signal is fixed as a traceable feature snapshot, and the mapping relationship is also recorded as a versioned record along with the feature snapshot. This allows users to repeatedly debug and iterate on the signal features, and also enables quick restoration to the previous version when modifications do not meet expectations. This avoids erroneous modifications that cause associated instruction sequences to fail to trigger or trigger errors, thereby improving the stability of user-defined rules in long-term use and cross-device migration.

[0118] The following describes step 203, namely "generating a rule package based on mapping relationship", in detail with reference to the embodiments.

[0119] Electronic devices generate standardized rule packages that are independent of specific hardware platforms, based on user-configured mapping relationships and related execution parameters (such as instruction execution order, execution conditions, and delay parameters). The rule package format can be JSON, Protocol Buffer, or a custom binary format. The process of generating a rule package involves packaging mapping relationships and execution conditions into standardized data packets, and then encapsulating them with metadata such as version information and verification information to form a complete rule package file. In this way, the rule package becomes a digital asset that can be independently stored, transmitted, and reused.

[0120] In other words, when an electronic device generates a rule package based on a mapping relationship, it not only packages the mapping relationship itself but also includes associated stored information such as execution condition information. That is, the rule package is generated based on the mapping relationship and the execution condition information. Each mapping record in the rule package is associated with a set of conditional expressions that can be parsed by the hardware device. After receiving and parsing the rule package, the target hardware device, upon matching the corresponding mapping relationship based on the collected physical signals and determining the instruction sequence to be executed, does not immediately execute the instruction sequence. Instead, it first performs condition verification based on the execution condition information contained in the rule package. The condition judgment module on the hardware device acquires real-time data such as current environmental parameters and device status parameters one by one, performs Boolean evaluation with the pre-set conditional expressions in the rule package, and executes the instruction sequence only if all conditions are met (or the user-defined logical combination is met); if any condition is not met, the mapping can be skipped or rejection processing can be performed.

[0121] The following describes step 204, namely, "transmitting the rule packet to the target hardware device, whereby the target hardware device matches the features of the acquired physical signals with the features of the target signals in the rule packet to determine the sequence of instructions to be executed."

[0122] Electronic devices can send rule packets to target hardware devices via communication methods such as Bluetooth, wireless, and serial ports. After receiving the rule packets, the target hardware device performs integrity and version verification. If the verification is successful, the rule packets are stored in local non-volatile memory (such as Flash or NVS) and loaded into memory during runtime.

[0123] To enhance the security of rule packets transmitted between electronic devices and target hardware devices, in one embodiment, the target hardware device is equipped with a first port, a sandbox, and a second port. The first port is used to receive knock messages, and the second port is used to establish a temporary communication connection after successful authentication.

[0124] In one feasible approach, the first port can be a restricted UDP port or any other restricted listening port used solely for receiving knock messages. The first port does not carry the function of transmitting rule packet bodies; it is only used to receive knock messages with a preset format. If the data received by the first port does not conform to the knock message format, the target hardware device can directly discard the data without returning a response to the sender. Through this silent discarding method, even if an external device sends probe data to the first port, it is difficult to confirm whether the target hardware device has an available data transmission service based on the network response.

[0125] When preparing to send a rule packet, an electronic device can first generate a knock message containing identity information. This identity information may include at least one of the following: electronic device identifier, user identifier, target hardware device identifier, timestamp, random number, rule packet digest, and digital signature. The rule packet digest can be calculated based on the rule packet to be transmitted, for example, using the SHA256 digest algorithm. The digital signature can be obtained by signing the identity information and the rule packet digest using the electronic device's private key, and the target hardware device can verify the signature using a pre-stored public key. The specific fields and encryption algorithms of the aforementioned identity information can be adjusted according to the deployment environment, as long as the target hardware device can confirm the sender's identity and the integrity of the rule packet to be transmitted before transmitting it.

[0126] After an electronic device sends a knock message to the first port of a target hardware device, the target hardware device can perform format verification, authentication, and digest consistency verification on the knock message. Format verification confirms whether the knock message conforms to a preset field structure; authentication confirms whether the sender has the authority to send rule packets to the target hardware device; digest consistency verification confirms that the rule packet digest declared in the knock message corresponds to the rule packets to be transmitted later. In one implementation, the target hardware device can first verify the digital signature. If the signature verification fails, the knock message is discarded; if the signature verification passes, the device identity, user permissions, timestamp validity, and rule packet digest are checked.

[0127] In one embodiment, the target hardware device can locally record audit logs related to unauthorized knocking messages. The audit logs may include information such as request time, source address, verification failure reason, and digest mismatch identifier. These audit logs may be stored only in the target hardware device's local storage area and not returned to external devices through the first port, to prevent unauthorized probes from inferring port status or verification rules from the returned information.

[0128] After the knock message passes authentication, the electronic device can load the rule package into a sandbox for pre-validation. Sandbox pre-validation can include syntax and structure checks. Specifically, the sandbox can parse the rule package using JSON, ProtocolBuffer, or custom binary formats to check the completeness of fields, data type conformity to preset formats, version information parsing capability of the target hardware device, and checksum matching with the rule package body. Sandbox pre-validation can also include runtime environment compatibility checks. The electronic device can simulate the execution of the rule package to be deployed within the sandbox. The sandbox can perform cross-layer association retrieval and conflict detection, such as checking whether the rule package to be deployed has deleted signal features still referenced by mapping relationships, whether mutual exclusion modes on the same device are simultaneously marked as enabled, and whether there are spare instruction sequences referencing non-existent items. If conflicts or incompatibilities are found, the sandbox can prevent the rule package from entering the production environment and generate conflict details for later review.

[0129] In response to the establishment of a temporary communication connection between the electronic device and the target hardware device and the successful pre-verification, the electronic device transmits rule packets to the target hardware device using this temporary communication connection. This temporary communication connection is not a long-term open data connection for the target hardware device; rather, it is a communication connection dynamically established between the target hardware device and the electronic device via a second port after the target hardware device completes authentication based on a knock message. The second port can be randomly generated by a dynamic temporary port allocator in the target hardware device, for example, by selecting a currently unused port from a range of high-order ports. The port range mentioned above is merely an example; the specific port selection strategy can be determined based on the target hardware device's operating system, network protocol stack, and security policies.

[0130] In one implementation, after successful authentication and sandbox pre-verification, the target hardware device generates a session key and returns the port information of the second port and the session key to the electronic device in an encrypted manner. Based on this port information and session key, the electronic device establishes a temporary communication connection with the target hardware device. This temporary communication connection can use an AES symmetric encrypted session channel or other encrypted channels that ensure the confidentiality and integrity of the transmitted content. Since the second port is only open during this transmission, and the port information is only provided to the authenticated electronic device, the attack surface caused by the target hardware device's long-term exposure of its data transmission port can be reduced.

[0131] During rule packet transmission, the electronic device can transmit the rule packet as a whole file or in fragments. After the rule packet transmission via the temporary communication connection is complete, the target hardware device can write the rule packet to the rule packet storage area. After the rule packet transmission is complete, the target hardware device disconnects the temporary communication connection. Specifically, the target hardware device can close the socket corresponding to the second port, destroy the session key, clear the temporary receive buffer, and restore the second port from a connectable state to a closed state. The electronic device can also release the session context corresponding to the temporary communication connection after detecting confirmation of rule packet transmission completion. In this way, the second port will not exist as a long-term open port, allowing the target hardware device to maintain a communication state of establishing connections on demand and closing them after use.

[0132] By adopting the above method, the transmission of rule packets is transformed from long-term open port transmission to a controlled process of knocking authentication, isolation verification, temporary connection establishment and post-transmission closure. This can reduce the risks of port scanning, malicious access, loading of incorrect rule packets and injection of unauthorized rules, and improve the security and reliability of user-defined rules when distributed across devices.

[0133] For the target hardware device, the method flow of the device control method it executes can be as follows: Figure 4 As shown, the steps include: Step 401: Receive a rule packet sent by an electronic device decoupled from the target hardware device. The rule packet includes the mapping relationship between the characteristics of the target signal and the instruction sequence.

[0134] As one possible implementation, the target hardware device can first receive a knock message containing identity information sent by an electronic device through a first port, while the first port rejects other types of messages besides the knock message; perform identity verification based on the knock message, and after successful authentication, establish a temporary communication connection with the electronic device through a second port; receive rule packets transmitted by the electronic device through the temporary communication connection, and disconnect the temporary communication connection after the rule packet transmission is complete. This process can be specifically referred to in the relevant descriptions in the previous embodiments, and will not be repeated here.

[0135] Step 402: Parse and store the mapping relationship between the features of the target signal and the instruction sequence from the rule package.

[0136] In addition, the target hardware device can also parse one or more execution condition information set for the target signal from the rule package, and the execution condition information corresponds one-to-one with the instruction sequence; wherein, the execution condition information includes at least one of time condition, location condition, environmental condition, device status condition, execution timing condition, biometric condition, security threshold and conflict detection condition.

[0137] Step 403: In response to the acquisition of physical signals, extract the features of the physical signals, and match the features of the physical signals with the features of the stored target signals to determine the sequence of instructions to be executed.

[0138] During operation, the target hardware device acquires physical signals (such as acceleration, sound, and images) in real time through its sensing unit, extracts signal features, and matches the extracted features with the features of the target signal stored in the rule package. Once a match is successful, the corresponding instruction sequence is determined based on the mapping relationship. Further adjudication can be performed based on execution conditions (if they exist) to determine the instruction sequence to be executed, driving the hardware to execute the instruction sequence.

[0139] For example, after the ESP32 module built into the punching target recognizes the acceleration characteristics matching three consecutive left punches, it looks up the keyboard macro for "Fighting Skill A" according to the rule packet lookup table, and then sends the key sequence to the game console via Bluetooth HID protocol to make the game character release Fighting Skill A.

[0140] In one implementation designed to improve signal matching efficiency, the rule execution engine of the target hardware device, after loading the rule package, constructs a hash index table based on the mapping relationships within the rule package. This hash index table uses the hash value of the target signal's characteristics as the key and the corresponding instruction sequence pointer or its offset in memory as the value.

[0141] The specific construction process is as follows: The rule execution engine traverses each mapping record in the rule package, calculates a hash value for the characteristics of the target signal in each record (for example, using the DJB2 or MurmurHash algorithm), and associates the hash value with the storage address or index number of the instruction sequence in the mapping record and inserts it into the hash table.

[0142] During runtime, after the sensing unit of the target hardware device acquires physical signals and extracts their features, the lookup module first calculates the same hash value for that feature, and then searches the hash index table. If a matching key is found, the corresponding value, i.e., the memory address of the instruction sequence, is directly obtained to determine the instruction sequence to be executed. If no matching key is found, it is determined that there is no matching rule, the signal is ignored, and listening continues.

[0143] By using a hash table lookup method, the time overhead of linearly traversing the entire rule package mapping table can be avoided, significantly improving the real-time performance of signal matching in complex scenarios with a large number of rule entries (such as hundreds or even thousands of rules), and ensuring that the target hardware device (such as a high-speed robot or game peripheral) can respond to physical input with low latency.

[0144] To ensure the integrity, verifiability, and cross-device compatibility of the rule package, this application also optimizes the encapsulation of the rule package.

[0145] In one implementation, generating a rule package based on mapping relationships and execution condition information includes: packaging the mapping relationships and execution condition information into a standardized data packet; and encapsulating the data packet and its metadata to obtain the rule package, wherein the metadata includes at least one of version information and verification information. For example, an electronic device serializes mapping tables, conditional expressions, and instruction codes into JSON, calculates a SHA-256 checksum, writes a version number in the file header, and finally encapsulates it into a rule package file. When the target hardware device receives the rule package, it verifies the file integrity based on the checksum to ensure that the rule data has not been tampered with or damaged during transmission, thereby making the rule package a reliable digital asset.

[0146] In this embodiment of the application, sending the rule packet to the target hardware instead of sending the execution instruction sequence to the target hardware device has advantages including, but not limited to, the following: Advantage 1: The rule package is a standardized data file that is independent of the hardware. Users only need to modify the rule package on their electronic devices (such as mobile phones) and then transmit it to the target hardware device like sending a file. After receiving it, the hardware device can complete the rule switching (hot update) during operation without restarting or modifying the firmware. This truly achieves asynchronous decoupling between "rule editing and modification" and "stable hardware operation".

[0147] Advantage 2: The rule package can contain multiple sets of mapping relationships, execution conditions (time, location, device status, etc.), and instruction sequence identifiers. When the hardware device is running, it no longer simply responds to signals, but executes a complete pipeline of "trigger → mapping → condition decision → execution".

[0148] Advantage 3: The rule package is a hardware-independent, standalone file (such as JSON). Users can export, share, or back up their configured rule packages. When replacing or adding new devices, simply import the rule package for one-click deployment, enabling rule reuse and accumulation, making it a user's digital asset.

[0149] Advantage 4: All mappings and conditions in the rule package are explicit and structured. When the hardware device executes, it performs deterministic table lookups and Boolean operations based on preset, traceable rules, rather than relying on black-box reasoning from external AI. This makes every action of the device traceable, and the operation process predictable and auditable, which is crucial for safety-sensitive scenarios (such as the adjudication logic of autonomous driving).

[0150] Advantage 5: Users can create rules using only a graphical interface on their mobile phone or computer, through zero-code operations such as dragging, checking, and configuring conditions. The system automatically compiles these intuitive operations into a standardized rule package. This allows ordinary users to easily create and modify complex device control rules, completely solving the technical problem of the extremely high barrier to entry for users to configure rules independently in traditional solutions.

[0151] Based on the above embodiments, this embodiment further illustrates how to configure multiple different instruction sequences and their corresponding execution conditions for the characteristics of the same target signal, so that the target hardware device can adaptively select the instruction sequence to be executed according to the environment, and exhibit context-aware differentiated behavior.

[0152] Specifically, a mapping relationship between the characteristics of the target signal and multiple instruction sequences can be established on the electronic device, and different execution condition information configured by the user for each of the multiple mapping relationships can be obtained. The execution condition information is used by the target hardware device to determine the instruction sequence to be executed based on the execution condition information contained in the rules.

[0153] Take the application scenario of an intelligent robot dog as an example. Users want to trigger different behaviors of the robot dog under different conditions through clapping, forming automated rules with context awareness. In this scenario, the electronic device can be the user's smartphone, and the target hardware device is the intelligent robot dog. On the smartphone, the rule editing engine pre-maintains a signal space and a command space.

[0154] First, the user records a clapping motion using their smartphone's microphone. The system extracts the sound wave and acceleration features of the clapping motion, generates a unique feature vector, assigns it a signal identifier CLAP, and names it "clapping." The user then records two command sequences via the phone's input interface: command sequence one is a quiet, prone movement sequence, stored as the command identifier QUIET; command sequence two is an excited, circling movement sequence, stored as the command identifier EXCITED. Both command sequences are stored in the command space.

[0155] Next, the user configures the mapping relationship using the graphical interface provided by the smartphone. The graphical interface displays signal nodes and command sequence nodes. The signal nodes include a first node corresponding to the clapping signal, and the command sequence nodes include multiple second nodes corresponding to "quiet down" and "excited spinning," respectively. The user connects the first node to two second nodes by checking boxes, thus establishing a first mapping relationship between the characteristics of the target signal CLAP and the command sequence QUIET, and a second mapping relationship between the characteristics of the target signal CLAP and the command sequence EXCITED, on the smartphone.

[0156] Furthermore, the graphical interface also includes a first settings component. Through this component, the user sets first execution condition information C1 for the first mapping relationship, such as a time condition of time greater than 22:00 and a location condition of location equal to home, with the logical combination method being AND. Simultaneously, the user sets second execution condition information C2 for the second mapping relationship, such as a time condition of time less than or equal to 22:00 and a location condition of location equal to outdoors, also with the logical combination method being AND. These execution condition information are associated and stored with their respective mapping relationships. Thus, a rule configuration is formed on the mobile phone where the same target signal points to different instruction sequences, and each mapping relationship is bound with non-conflicting execution conditions.

[0157] The rule editing engine generates a rule package based on the aforementioned first mapping relationship and its associated first execution condition information C1, and the second mapping relationship and its associated second execution condition information C2. Specifically, the rule engine packages the feature vector of the clapping signal, the instruction codes for lying down quietly and spinning excitedly, the two sets of mapping relationships, and their corresponding condition expressions into a standardized data package, such as JSON or ProtocolBuffer format, and adds metadata including a version number and checksum before encapsulation to obtain the final rule package. The rule package is transmitted to the rule execution engine on the intelligent robot dog via wireless communication methods such as Bluetooth or Wi-Fi.

[0158] After receiving the rule package, the intelligent robot dog performs integrity and version verification. If the verification passes, the rule package is stored in local non-volatile memory and loaded into working memory to build a lookup table structure. During operation, the robot dog continuously collects environmental sound signals and extracts features through its microphone. When the collected physical signal features successfully match the features of the clapping signal stored in the rule package, the rule execution engine identifies the matched signal as CLAP. Unlike the previous embodiment with only a single mapping relationship, the rule execution engine now finds the first and second mapping relationships associated with CLAP and reads the corresponding first execution condition information C1 and second execution condition information C2, respectively. The execution engine then collects the current real-time environmental data and evaluates each condition item in C1 and C2. For example, assuming the current time is 11:00 PM and the robot dog determines its current location as home via GPS or Wi-Fi positioning, then after evaluation, C1 is satisfied while C2 is not. Accordingly, the execution engine, based on the conditional release decision logic, selects to execute the instruction sequence QUIET corresponding to the first mapping relationship, controlling the robot dog to perform a quiet lying-down action instead of an excited circling action. Conversely, at another time, such as 10:00 AM and the robot dog is in an outdoor park, C2 satisfies the condition while C1 does not. The execution engine will then select to execute the instruction sequence EXCITED corresponding to the second mapping relationship, controlling the robot dog to perform an excited circling action.

[0159] In this process, the same clapping signal automatically triggers drastically different behavioral responses under different time and location conditions, realizing intelligent-like behavioral emergence. The existence of execution condition information enables the target hardware device to perform white-box adjudication (or routing) on ​​multiple candidate instruction sequences based on the execution condition information contained in the rule package, ensuring that only one instruction sequence is allowed under a given environmental state, while the rest are rejected, thereby avoiding conflicts between multiple instruction sequences.

[0160] It is understood that the above embodiments are only illustrated using two instruction sequences and two execution conditions as examples. Those skilled in the art can establish mapping relationships pointing to more instruction sequences for a target signal according to actual needs, and configure more dimensions or multi-level execution conditions for each mapping relationship, such as adding weather conditions, device status conditions, safety threshold conditions, historical execution record conditions, etc., and supporting more complex AND / OR combination logic. The execution condition information in the rule package can be expressed as a structured condition expression, which is evaluated by the execution engine one by one in a predefined order. In addition, the target signal is not limited to clapping, but can also be various physical signals such as user-demonstrated voice commands, gestures, and hitting actions. The instruction sequence is not limited to the action sequence of the robot dog, but can also be the control instruction sequence of smart home devices, the key macro sequence in games, the start / stop sequence of industrial equipment, etc., all of which can use the mechanism provided in this embodiment to realize context-aware differentiated control.

[0161] By establishing multiple mapping relationships for a single trigger signal pointing to different instruction sequences and binding mutually exclusive execution conditions, users can endow the device with environmental adaptability without writing code. At the same time, the rule execution process is based entirely on user-preset explicit rules for deterministic white-box adjudication, without relying on black-box reasoning from artificial intelligence. Therefore, the behavior is predictable and traceable, achieving a highly personalized intelligent control effect while ensuring security.

[0162] In another optional embodiment, the aforementioned execution condition information is managed and adjudicated by a condition constraint layer independent of any artificial intelligence (AI) system. Specifically, this condition constraint layer is deployed on the target hardware device, physically or logically isolated from the AI ​​planning module. When the target hardware device receives an action proposal generated by an external AI system, it first converts the action proposal into a standardized trigger signal and queries the mapping relationship to obtain the associated execution condition information. Subsequently, the condition constraint layer evaluates each execution condition information item by item and derives a decision result based on a preset AND / OR logic combination. Only when all execution condition information is satisfied is the corresponding instruction sequence allowed and the hardware executed; otherwise, the action proposal is rejected, and a structured information packet containing the rejection reason and scenario data is sent back to the AI ​​system for the AI ​​system to regenerate the proposal. The condition constraint layer is not affected by the training or inference results of the AI ​​system and performs white-box deterministic adjudication only based on user-defined explicit rules and traceable lookup logic, thereby providing a hard safety boundary in the intelligent system.

[0163] In an optional embodiment, after the target hardware device successfully matches the characteristics of the acquired physical signals with the characteristics of the target signal in the rule package to determine the instruction sequence to be executed, it does not immediately execute the instruction sequence. Instead, it first parses the execution conditions stored in the rule package that are associated with the mapping relationship and performs white-box deterministic evaluation of the current device state, environment state, etc.

[0164] Specifically, the execution condition can contain one or more conditional clauses, such as "device battery > 20%", "current time BETWEEN 22:00 AND 06:00", "robot gripper status = idle", "distance to obstacle ahead > 2 meters", etc. Each conditional clause is predefined in the rule package as a structured expression (such as JSON format).

[0165] The rule execution engine of the target hardware device includes a condition evaluation function, which is responsible for: 1) reading the real-time status quantities corresponding to the condition clauses from local sensors, device registers, or system clocks; 2) performing Boolean operations (e.g., greater than, less than, equal to, within a range, etc.) on each condition clause; and 3) obtaining the final decision result according to the preset logical combination method (e.g., AND requires all conditions to be met, OR requires at least one condition to be met).

[0166] If the ruling is "allow," the target hardware device executes the predetermined sequence of instructions sequentially. If the ruling is "reject," the target hardware device abandons the execution of this instruction sequence and may further execute preset fallback logic, such as ignoring the trigger, logging, or re-evaluating on the next trigger. In this way, the behavior of the target hardware device is no longer a simple "signal-action" hard connection, but incorporates user-customizable and auditable environmental awareness and conditional decision-making capabilities, which is particularly suitable for scenarios with high requirements for safety or situational adaptability (e.g., preventing robots from performing high-intensity actions when the battery is too low, or preventing sound alarms from being triggered when no one is home at night).

[0167] In another preferred embodiment, the target hardware device supports dynamic replacement and loading of rule packages without restarting or interrupting the currently executing process. This functionality is implemented based on a double buffer and atomic pointer switching mechanism.

[0168] Specifically, the target hardware device's non-volatile memory has two pre-defined rule packet storage areas: an active zone and a standby zone. When the target hardware device is running, its rule execution engine always loads rule data from the "currently active zone." When a new rule packet is received via Bluetooth, Wi-Fi, or serial port, the following process is followed: Reception and Verification: The hardware device first writes the received rule packet data to the backup storage area. After writing, it performs integrity verification (such as CRC or SHA-256 checksum) on the data in the backup storage area to ensure that the data has not been corrupted during transmission. If the verification fails, the data in the backup storage area is discarded, the active storage area remains unchanged, and an error code is sent back to the sender.

[0169] Preparing the new index: The hardware device maintains a pointer (Active_Ptr) in memory to the starting address of the rule packet in the active storage area. Simultaneously, after the data in the backup storage area passes verification, the device parses the rule packet in the backup storage area, generating its corresponding hash index table and a memory copy of the condition evaluation logic.

[0170] Atomic pointer switching: After successful verification, the hardware device considers the memory data of the new rule packet and its corresponding hash index table to be in a ready state. Subsequently, through a non-interruptible atomic operation (e.g., using the CPU's CAS instruction or a memory write instruction with interrupt protection disabled), the value of Active_Ptr is switched from pointing to an address in the active memory area to pointing to an address in the standby memory area. This switching operation takes an extremely short time, typically within microseconds.

[0171] Executing New Rules and Reclaiming Old Areas: After the switchover is complete, subsequent physical signal matching, condition evaluation, and instruction execution will all be based on the new rule packages. The rule packages of the original active storage area will then become the old rules. Once the hardware device confirms that the new rule packages are running stably, it can mark the storage area containing the old rule packages as the "backup storage area" for the next round of hot updates.

[0172] Through the atomic pointer switching mechanism described above, the entire rule package replacement process does not require restarting the hardware's operating system or main loop, nor does it require interrupting the currently running task (for example, the rule update can be completed synchronously while the robot is walking), realizing that user-defined rules can be "modified and used immediately", which greatly improves the user experience and system flexibility.

[0173] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0174] Figure 5 This is a schematic block diagram of a device for processing device control rules provided in an embodiment of this application. The device is disposed in... Figure 1Electronic devices in the architecture shown. For example... Figure 5 As shown, the device 500 may include: a feature acquisition unit 501, an instruction acquisition unit 502, a mapping establishment unit 503, a rule generation unit 504, and a rule transmission unit 505. The main functions of each component are as follows: The feature acquisition unit 501 is configured to acquire features of a target signal consisting of at least one signal in the signal space.

[0175] The instruction acquisition unit 502 is configured to acquire an instruction sequence consisting of at least one instruction in the instruction space.

[0176] The mapping establishment unit 503 is configured to establish a mapping relationship between the features of the target signal and the instruction sequence on the electronic device.

[0177] The rule generation unit 504 is configured to generate a rule package based on the mapping relationship.

[0178] The rule transmission unit 505 is configured to transmit the rule packet to the target hardware device. The rule packet is used by the target hardware device to match the features of the acquired physical signals with the features of the target signals in the rule packet to determine the sequence of instructions to be executed.

[0179] As one possible implementation method, the feature acquisition unit 501 can be specifically configured to: collect the physical actions demonstrated by the user through the sensing unit of the electronic device, acquire the signal corresponding to the physical actions and belonging to the signal space as the target signal; acquire the identification information of the target signal; extract the features of the target signal, and store the correspondence between the features of the target signal and the identification information.

[0180] As one possible implementation, the instruction space includes all executable instructions of the target hardware device; the instruction acquisition unit 502 can be specifically configured to: acquire at least one instruction input by the user through the input interface of the electronic device, and map the at least one input instruction into a sequence of instructions executable by the target device based on a preset instruction mapping table.

[0181] As another possible implementation, the device may further include an intent parsing module (not shown in the figure), configured to acquire natural language commands input by the user through the electronic device; and to perform intent parsing on the natural language commands to obtain signal intent content and instruction intent content. Accordingly, the feature acquisition unit 501 may be specifically configured to: parse the signal intent content to obtain parameter features conforming to the signal in the signal space as features of the target signal. The instruction acquisition unit 502 may be specifically configured to: based on the instruction space, parse the instruction intent content to obtain a sequence of instructions executable by the target hardware device.

[0182] As one possible implementation, the mapping establishment unit 503 can be specifically configured to: provide a graphical interface displaying at least one signal node and at least one instruction sequence node, wherein the at least one signal node includes a first node corresponding to the target signal and the at least one sequence node includes a second node corresponding to the instruction sequence; and, in response to a user performing a selection and pairing operation on the first node and the second node in the graphical interface, establish a mapping relationship between the features of the target signal and the instruction sequence.

[0183] Furthermore, the mapping establishment unit 503 can also be configured to: update the instruction sequence based on the adjusted execution order in response to a user's operation of adjusting the execution order of each instruction in the second node in the graphical interface; and update the mapping relationship based on the updated instruction sequence if the mapping relationship has already been established.

[0184] Furthermore, the graphical interface also includes a first setting component; the mapping establishment unit 503 can also be configured to: in response to a user setting execution conditions through the first setting component, obtain the execution condition information set by the user for the mapping relationship; and associate and store the execution condition information with the mapping relationship; wherein the execution condition information includes at least one of time conditions, environmental conditions, location conditions, device status conditions, execution timing conditions, biometric conditions, security thresholds, and conflict detection conditions. Correspondingly, the rule generation unit 504 can be specifically configured to: generate a rule package based on the mapping relationship and the execution condition information; the execution condition information is used by the target hardware device, and the sequence of instructions to be executed is determined based on the execution condition information contained in the rule package.

[0185] As another possible implementation, the mapping establishment unit 503 can be specifically configured to: establish mapping relationships between the features of the target signal and multiple instruction sequences on the electronic device, and obtain different execution condition information configured by the user for each of the multiple mapping relationships. This execution condition information is used by the target hardware device to execute the instruction sequence to be executed based on the execution condition information contained in the rules after determining the instruction sequence to be executed. Correspondingly, the rule generation unit 504 can be specifically configured to: generate a rule package based on the multiple mapping relationships and their configured execution condition information.

[0186] Specifically, when generating a rule package based on the mapping relationship and the execution condition information, the rule generation unit 504 can be configured to: package the mapping relationship and the execution condition information into a data packet in a standardized format; and encapsulate the data packet and its metadata to obtain the rule package, wherein the metadata includes at least one of version information and verification information.

[0187] Figure 6 This is a schematic block diagram of a device for processing device control rules provided in an embodiment of this application. The device is disposed in... Figure 1 The target hardware device in the architecture shown. For example... Figure 6 As shown, the device 600 may include: a rule receiving unit 601, a rule parsing unit 602, and an instruction determining unit 603. The main functions of each component are as follows: The rule receiving unit 601 is configured to receive a rule packet sent by an electronic device decoupled from the target hardware device, the rule packet including a mapping relationship between the characteristics of the target signal and the instruction sequence.

[0188] The rule parsing unit 602 is configured to parse and store the mapping relationship between the features of the target signal and the instruction sequence from the rule package.

[0189] The instruction determination unit 603 is configured to, in response to the acquisition of a physical signal, extract features of the physical signal and match the features of the physical signal with the features of a stored target signal to determine the sequence of instructions to be executed.

[0190] As one possible implementation, the rule receiving unit 601 can be specifically configured to receive a knock message containing identity information sent by the electronic device through a first port, wherein the first port rejects messages of other types besides the knock message; perform identity verification based on the knock message, and after successful identity verification, establish a temporary communication connection with the electronic device through a second port; receive rule packets transmitted by the electronic device through the temporary communication connection, and disconnect the temporary communication connection after the rule packets have been transmitted.

[0191] Furthermore, the rule parsing unit 602 can also be configured to: parse execution condition information set for the mapping relationship from the rule package; wherein the execution condition information includes at least one of time conditions, location conditions, environmental conditions, device status conditions, execution timing conditions, biometric conditions, security thresholds, and conflict detection conditions. When the instruction determination unit 603 matches the features of the physical signal with the features of the stored target signal to determine the instruction sequence to be executed, it can be specifically configured to: match the features of the physical signal with the features of the stored target signal to determine the features of the matched target signal and its corresponding execution conditions; and determine the instruction sequence to be executed based on the execution conditions.

[0192] As one possible implementation, the rule receiving unit 601 can be configured to: receive action proposals generated by the AI ​​system, and convert the action proposals into trigger signals of a preset type as the acquired physical signals. When determining the sequence of instructions to be executed based on execution conditions, the instruction determination unit 603 can be specifically configured to: in response to the satisfaction of a target execution condition among one or more execution condition information set for the target signal, determine the instruction sequence corresponding to the target execution condition as the instruction sequence to be executed; in response to the failure to satisfy any one or more execution condition information set for the target signal, reject the action proposal and send back a structured information packet containing the rejection reason and scene data to the AI ​​system for the AI ​​system to regenerate the action proposal.

[0193] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0194] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0195] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0196] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0197] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0198] in, Figure 7 An exemplary architecture of an electronic device is shown, which may include a processor 710, a video display adapter 711, a disk drive 712, an input / output interface 713, a network interface 714, and a memory 720. The processor 710, video display adapter 711, disk drive 712, input / output interface 713, network interface 714, and memory 720 can communicate with each other via a communication bus 730.

[0199] The processor 710 can be implemented using a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs and implement the technical solution provided in this application.

[0200] The memory 720 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 720 can store the operating system 721 for controlling the operation of the electronic device 700, and the basic input / output system (BIOS) 722 for controlling the low-level operations of the electronic device 700. Additionally, it can store a web browser 723, a data storage management system 724, and a device control rule processing device 500 / device control device 600, etc. The aforementioned device control rule processing device 500 / device control device 600 can be the application program that specifically implements the aforementioned steps in this embodiment. In summary, when implementing the technical solution provided in this application through software or firmware, the relevant program code is stored in the memory 720 and executed by the processor 710.

[0201] Input / output interface 713 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0202] Network interface 714 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.).

[0203] Bus 730 includes a pathway for transmitting information between various components of the device, such as processor 710, video display adapter 711, disk drive 712, input / output interface 713, network interface 714, and memory 720.

[0204] It should be noted that although the above-described device only shows the processor 710, video display adapter 711, disk drive 712, input / output interface 713, network interface 714, memory 720, bus 730, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the solution of this application, and does not necessarily include all the components shown in the figures.

[0205] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. 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 computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0206] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for processing equipment control rules, characterized in that, The method includes: An electronic device decoupled from the target hardware device has pre-configured signal space information and instruction space information; The characteristics of a target signal consisting of at least one signal in the signal space and an instruction sequence consisting of at least one instruction in the instruction space are obtained. A mapping relationship between the characteristics of the target signal and the instruction sequence is established on the electronic device; A rule package is generated based on the mapping relationship; The rule packet is transmitted to the target hardware device. The rule packet is used by the target hardware device to match the features of the acquired physical signals with the features of the target signals in the rule packet to determine the sequence of instructions to be executed.

2. The method according to claim 1, characterized in that, Acquiring features of a target signal composed of at least one signal in the signal space includes: The electronic device collects the physical actions demonstrated by the user through its sensing unit, and obtains the signal corresponding to the physical action and belonging to the signal space as the target signal. Obtain the identification information of the target signal; Extract the features of the target signal and store the correspondence between the features of the target signal and the identification information.

3. The method according to claim 1, characterized in that, The features of the target signal include: a feature fingerprint generated using the waveform key points, time-series distribution information and extreme value distribution information after extracting waveform key points, time-series distribution information and extreme value distribution information from the target signal; The step of establishing a mapping relationship between the features of the target signal and the instruction sequence on the electronic device includes: determining whether there is already a feature of the target signal in the existing mapping relationship on the electronic device that has a similarity greater than or equal to a preset similarity threshold with the generated feature fingerprint; if there is already a feature, then updating the mapping relationship between the features of the target signal and the instruction sequence using the generated feature fingerprint; otherwise, creating a new mapping relationship between the generated feature fingerprint and the instruction sequence on the electronic device.

4. The method according to claim 3, characterized in that, The step of updating the mapping relationship between the features of the existing target signal and the instruction sequence using the generated feature fingerprint and the instruction sequence includes: Generate a feature snapshot of the target signal for the generated feature fingerprint, record the mapping relationship between the feature snapshot of the target signal and the instruction sequence, and mark it as enabled; In response to a version rollback operation, the mapping relationship between the feature snapshot of the target signal of the previous version and the instruction sequence is marked as enabled.

5. The method according to claim 1, characterized in that, The instruction space includes all executable instructions of the target hardware device; obtaining an instruction sequence consisting of at least one instruction in the instruction space includes: The system acquires at least one instruction input by the user through the input interface of the electronic device, and maps the at least one input instruction into a sequence of instructions executable by the target hardware device based on a preset instruction mapping table.

6. The method according to claim 1, characterized in that, The instruction space includes all executable instructions of the target hardware device; the characteristics of a target signal consisting of at least one signal in the signal space are obtained, and the instruction sequence consisting of at least one instruction in the instruction space includes: Acquire natural language commands input by the user through the electronic device; The natural language instructions are parsed to obtain the signal intent content and the instruction intent content; The parameter features that conform to the signal in the signal space are parsed from the signal intent content and used as the features of the target signal; Based on the instruction space, the executable instruction sequence of the target hardware device is obtained by parsing the instruction intent content.

7. The method according to claim 1, characterized in that, Establishing a mapping relationship between the features of the target signal and the instruction sequence on the electronic device includes: A graphical interface is provided, on which at least one signal node and at least one instruction sequence node are displayed, wherein the at least one signal node includes a first node corresponding to the target signal, and the at least one instruction sequence node includes a second node corresponding to the instruction sequence; In response to the user performing a selection and pairing operation on the first node and the second node in the graphical interface, a mapping relationship between the characteristics of the target signal and the instruction sequence is established.

8. The method according to claim 7, characterized in that, The graphical interface further includes a first setting component; establishing a mapping relationship between the characteristics of the target signal and the instruction sequence on the electronic device further includes: in response to the user setting execution conditions through the first setting component, acquiring the execution condition information set by the user for the mapping relationship; associating and storing the execution condition information with the mapping relationship; wherein the execution condition information includes at least one of time conditions, environmental conditions, location conditions, device status conditions, execution timing conditions, biometric conditions, security thresholds, and conflict detection conditions; Generating a rule package based on the mapping relationship includes: generating a rule package based on the mapping relationship and the execution condition information; The execution condition information is used by the target hardware device to execute the determined sequence of instructions to be executed based on the execution condition information contained in the rule package.

9. The method according to claim 7, characterized in that, The graphical interface further includes a second setting component; establishing a mapping relationship between the characteristics of the target signal and the instruction sequence on the electronic device further includes: in response to the user's operation of setting control parameters through the second setting component, obtaining the resource quota information set by the user for the instruction sequence; and associating and storing the resource quota information with the mapping relationship; Generating a rule package based on the mapping relationship includes: generating a rule package based on the mapping relationship and the resource quota information; The resource allocation information is used by the target hardware device to schedule corresponding computing resources for the instruction sequence after determining the instruction sequence to be executed.

10. The method according to claim 7, characterized in that, The graphical interface further includes a third setting component; establishing a mapping relationship between the characteristics of the target signal and the instruction sequence on the electronic device further includes: in response to the user's operation of setting circuit breaker parameter information through the third setting component, acquiring the circuit breaker parameter information and the backup instruction sequence set by the user for the instruction sequence; and associating and storing the circuit breaker parameter information, the backup instruction sequence, and the mapping relationship. Generating a rule package based on the mapping relationship includes: generating a rule package based on the mapping relationship and the circuit breaker parameter information; The circuit breaker parameter information is used when the target hardware device executes the instruction sequence to be executed. If the execution parameters corresponding to the execution sequence meet the circuit breaker parameter information, the execution will be stopped or downgraded to the execution of the corresponding backup instruction sequence.

11. The method according to claim 1, characterized in that, Establishing a mapping relationship between the features of the target signal and the instruction sequence on the electronic device includes: establishing mapping relationships between the features of the target signal and multiple instruction sequences on the electronic device, and obtaining different execution condition information configured by the user for the multiple mapping relationships; The step of generating a rule package based on the mapping relationship includes: generating a rule package based on the multiple mapping relationships and their configured execution condition information; The execution condition information is used by the target hardware device to execute the instruction sequence to be executed based on the execution condition information contained in the rule package after determining the instruction sequence to be executed.

12. The method according to claim 8 or 11, characterized in that, A rule package is generated based on the mapping relationship and the execution condition information, including: The mapping relationship and the execution condition information are packaged into a data packet in a standardized format; The rule package is obtained by encapsulating the data packet and its metadata, wherein the metadata includes at least one of version information and verification information.

13. The method according to claim 1, characterized in that, The step of transmitting the rule packet to the target hardware device includes: A knock message containing identity information is sent to the first port of the target hardware device, and the first port rejects other types of messages besides the knock message. The rule package is loaded into the sandbox for pre-validation; In response to the establishment of a temporary communication connection between the electronic device and the target hardware device and the passing of the pre-verification, the rule packet is transmitted to the target hardware device using the temporary communication connection; The temporary communication connection is established between the target hardware device and the electronic device through the second port after the target hardware device has successfully authenticated the user based on the knock message, and is disconnected after the rule packet transmission is completed.

14. A device control method, characterized in that, Applied to a target hardware device, the method includes: Receive a rule packet sent by an electronic device decoupled from the target hardware device, the rule packet including a mapping relationship between the characteristics of the target signal and the instruction sequence; The mapping relationship between the features of the target signal and the instruction sequence is parsed and stored from the rule package; In response to the acquisition of physical signals, the features of the physical signals are extracted, and the features of the physical signals are matched with the features of the stored target signals to determine the sequence of instructions to be executed.

15. The method according to claim 14, characterized in that, The receipt of rule packets sent by the electronic device decoupled from the target hardware device includes: The first port receives a knock message containing identity information sent by the electronic device, and the first port rejects other types of messages besides the knock message. The authentication is performed based on the knock message. After successful authentication, a temporary communication connection is established with the electronic device through the second port. The temporary communication connection is used to receive rule packets transmitted by the electronic device, and the temporary communication connection is disconnected after the rule packets are transmitted.

16. The method according to claim 14, characterized in that, The method further includes: parsing execution condition information set for the mapping relationship from the rule package; wherein the execution condition information includes at least one of time conditions, location conditions, environmental conditions, device status conditions, execution timing conditions, biometric conditions, security thresholds, and conflict detection conditions; The step of matching the features of the physical signal with the features of the stored target signal to determine the sequence of instructions to be executed includes: The characteristics of the physical signal are matched with the characteristics of the stored target signal to determine the characteristics of the matched target signal and its corresponding execution conditions. The sequence of instructions to be executed is determined based on the execution conditions.

17. The method according to claim 16, characterized in that, The acquired physical signal includes: receiving an action proposal generated by the AI ​​system and converting the action proposal into a trigger signal of a preset type as the acquired physical signal; The step of determining the sequence of instructions to be executed based on the execution conditions includes: If a target execution condition is met in one or more execution condition information set for the target signal, then the instruction sequence corresponding to the target execution condition is determined to be the instruction sequence to be executed. If one or more execution conditions set for the target signal are not met, the action proposal is rejected, and a structured information packet containing the rejection reason and scene data is sent back to the AI ​​system for the AI ​​system to regenerate the action proposal.

18. A system for processing equipment control rules, characterized in that, The processing system includes: a target hardware device and an electronic device decoupled from the target hardware device; The electronic device is pre-configured with information in a signal space and information in an instruction space. The electronic device is configured to acquire features of a target signal consisting of at least one signal in the signal space, and an instruction sequence consisting of at least one instruction in the instruction space; establish a mapping relationship between the features of the target signal and the instruction sequence on the electronic device; generate a rule packet based on the mapping relationship; and transmit the rule packet to the target hardware device. The target hardware device is configured to: receive rule packets transmitted by the electronic device; parse and store the mapping relationship between the features of the target signal and the instruction sequence from the rule packets; and, in response to the acquisition of a physical signal, match the features of the physical signal with the features of the target signal in the mapping relationship to determine the instruction sequence to be executed.

19. A device for processing equipment control rules, characterized in that, The device is disposed in an electronic device, which is decoupled from the target hardware device, and the electronic device is pre-configured with signal space information and instruction space information. The device includes: The feature acquisition unit is configured to acquire features of a target signal consisting of at least one signal in the signal space; The instruction fetching unit is configured to fetch an instruction sequence consisting of at least one instruction in the instruction space; A mapping establishment unit is configured to establish a mapping relationship between the features of the target signal and the instruction sequence on the electronic device; The rule generation unit is configured to generate a rule package based on the mapping relationship; The rule transmission unit is configured to transmit the rule packet to the target hardware device, wherein the rule packet is used by the target hardware device to match the features of the acquired physical signals with the features of the target signals in the rule packet to determine the sequence of instructions to be executed.

20. A device control apparatus, characterized in that, The device is installed in the target hardware device, and the device includes: The rule receiving unit is configured to receive a rule packet sent by an electronic device decoupled from the target hardware device, the rule packet including a mapping relationship between the characteristics of the target signal and the instruction sequence; The rule parsing unit is configured to parse and store the mapping relationship between the features of the target signal and the instruction sequence from the rule package; The instruction determination unit is configured to, in response to the acquisition of a physical signal, extract features of the physical signal and match the features of the physical signal with features of a stored target signal to determine the sequence of instructions to be executed.

21. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 13.

22. A target hardware device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 14 to 17.

23. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program performs the steps of the method according to any one of claims 1 to 17.

Images