Event-driven rule data interaction method, device, equipment and storage medium

Abstract

The application discloses an event-driven rule data interaction method and device, equipment and a storage medium. The method comprises the following steps: in response to a new rule operation sent by a user terminal, acquiring rule content corresponding to the new rule operation; constructing rule data based on the rule content, and sending the rule data to a terminal-side device, so that the terminal-side device runs the rule data. The application acquires rule content of an Internet of Things scene through a cloud device, then constructs rule data based on the rule content, and interacts the rule data with a terminal-side device included in the Internet of Things scene, so that the terminal-side device only needs to interact with the cloud device to acquire scene information of the Internet of Things scene, and data interaction between each device node in the Internet of Things scene is not needed, thereby avoiding problems of data loss and data congestion caused by too much interaction data.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and particularly to an event-driven rule data interaction method, apparatus, device, and storage medium. Background Art

[0002] With the rapid development of Internet of Things (IoT) technology, the number of devices connected to the IoT has increased sharply. Especially in the scenario of multi-device linkage, data interaction is required between the linked devices to obtain the linkage execution rules. Then, when the number of devices in the device linkage scenario is large, data interaction between the linked devices requires establishing network connections between multiple devices before data interaction. This will result in the loss of interaction data between some devices, or data blocking due to some devices simultaneously interacting with the same device, or even device downtime.

[0003] Therefore, the existing technology still needs to be improved. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide an event-driven rule data interaction method, apparatus, device, and storage medium in view of the deficiencies of the existing technology.

[0005] To solve the above technical problem, a first aspect of this application provides an event-driven rule data interaction method. Specifically, the event-driven rule data interaction method includes:

[0006] Respond to a new rule operation sent by a client, and obtain the rule content corresponding to the new rule operation;

[0007] Construct rule data based on the rule content, and send the rule data to the end-side device so that the end-side device runs the rule data.

[0008] The event-driven rule data interaction method, wherein constructing rule data based on the rule content specifically includes:

[0009] Read the trigger category of the new rule operation;

[0010] If the trigger category is device trigger, convert the rule content into rule data according to a preset rule template, and use the end-side device as placeholder information.

[0011] The event-driven rule data interaction method, wherein constructing rule data based on the rule content specifically includes:

[0012] Read the trigger category of the new rule operation;

[0013] If the trigger category is a super device trigger, the rule content is converted into rule data according to the preset rule template, and the device node information matched by the end device is used as placeholder information to construct rule data containing device node information.

[0014] The event-driven rule data interaction method further includes, when using device node information matched by the end-side device as placeholder information:

[0015] When the device node associated with the end-side device fails, the device node is replaced by a device of the same type as the device node.

[0016] The event-driven rule data interaction method further includes, after constructing rule data based on the rule content and sending the rule data to the end-side device so that the end-side device runs the rule data:

[0017] The receiving end-side device reports the operation process in batches so that the cloud can track the operation process of the end-side device.

[0018] The event-driven rule data interaction method further includes:

[0019] In response to the user's command to disable a rule, a command to delete the rule is sent to the end device.

[0020] Based on the deletion rule instruction, the control terminal device stops running the rule data and deletes the rule information corresponding to the rule data.

[0021] The event-driven rule data interaction method further includes:

[0022] Log information generated by saving the running rule data when communication anomalies occur through the end-side device;

[0023] When communication returns to normal, the receiving end device sends log information and synchronizes the operation process formed during the communication anomaly period based on the log information.

[0024] A second aspect of this application provides an event-driven rule data interaction device, wherein the event-driven rule data interaction device specifically includes:

[0025] The acquisition module is used to respond to the new rule operation sent by the user terminal and acquire the rule content corresponding to the new rule operation;

[0026] A construction module is used to construct rule data based on the rule content and send the rule data to the end-side device so that the end-side device can run the rule data.

[0027] A third aspect of this application provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps in the event-driven rule data interaction method as described above.

[0028] A fourth aspect of this application provides a server, which includes: a processor and a memory;

[0029] The memory stores a computer-readable program that can be executed by the processor;

[0030] When the processor executes the computer-readable program, it implements the steps in any of the event-driven rule-based data interaction methods described above.

[0031] Beneficial Effects: Compared with existing technologies, this application provides an event-driven rule data interaction method, apparatus, device, and storage medium. The method includes responding to a user terminal's new rule creation operation, obtaining the rule content corresponding to the new rule creation operation; constructing rule data based on the rule content, and sending the rule data to an edge device so that the edge device can run the rule data. This application obtains the rule content of the IoT scenario through a cloud device, then constructs rule data based on the rule content, and interacts the rule data with the edge devices included in the IoT scenario. This allows the edge devices to obtain the scenario information of the IoT scenario simply by interacting with the cloud device, without the need for data interaction between various device nodes in the IoT scenario. This avoids data loss and data congestion caused by excessive interaction data. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0033] Figure 1 A flowchart of an event-driven rule data interaction method provided in an embodiment of this application.

[0034] Figure 2 This is a schematic diagram of the rule engine system.

[0035] Figure 3 A schematic diagram of an event-driven rule data interaction device provided in an embodiment of this application.

[0036] Figure 4 This is a schematic diagram of the server provided in the embodiments of this application. Specific Embodiments

[0037] The embodiments of the present application provide an event-driven rule data interaction method, device, equipment and storage medium. To make the purpose, technical solution and effects of the present application clearer and more definite, the following further elaborates on the present application by way of examples with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0038] Those skilled in the art of this technology can understand that unless specifically stated, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of the present application means that there are the described features, integers, steps, operations, elements and / or components, but does not exclude the existence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. It should be understood that when we say an element is "connected" or "coupled" to another element, it can be directly connected or coupled to other elements, or there may also be intermediate elements. In addition, the "connection" or "coupling" used here may include wireless connection or wireless coupling. The phrase "and / or" used here includes all or any unit and all combinations of one or more related listed items.

[0039] Those skilled in the art of this technology can understand that unless otherwise defined, all terms (including technical terms and scientific terms) used here have the same meaning as the general understanding of those of ordinary skill in the field to which the present application belongs. It should also be understood that terms such as those defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and will not be interpreted with an idealized or overly formal meaning unless specifically defined as here.

[0040] It should be understood that the sequence numbers and magnitudes of the steps in this embodiment do not imply the order of execution. The order of execution of each process is determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0041] Through research, it is found that with the rapid development of Internet of Things (IoT) technology, the number of devices connected to the IoT has increased sharply. Especially in the scenario of multi-device linkage, data interaction is required between the linked devices to obtain the linkage execution rules. Then, when the number of devices in the device linkage scenario is large, data interaction between the linked devices requires network connections to be established between multiple devices before data interaction can be carried out. This will result in the loss of interaction data between some devices, or, some devices interact with the same device simultaneously, leading to data blockage, and even device downtime.

[0042] To address the aforementioned issues, in this embodiment, in response to a user's request to create a new rule, the system obtains the rule content corresponding to the new rule operation; rule data is constructed based on the rule content, and the rule data is sent to the edge device so that the edge device can run the rule data. This application obtains the rule content of the IoT scenario through a cloud device, then constructs rule data based on this rule content, and interacts with the edge devices included in the IoT scenario. This allows the edge devices to obtain scenario information of the IoT scenario simply by interacting with the cloud device, eliminating the need for data interaction between device nodes in the IoT scenario. This avoids data loss and data congestion caused by excessive interaction data.

[0043] The application content will be further explained below with reference to the accompanying drawings and the description of the embodiments.

[0044] This embodiment provides an event-driven rule-based data interaction method applied to cloud devices, such as... Figure 1 As shown, the method includes:

[0045] S10. Respond to the new rule operation sent by the user terminal and obtain the rule content corresponding to the new rule operation.

[0046] Specifically, the rule creation operation can be a front-end visual operation sent from the user terminal to the cloud device. This rule creation operation can be treated as an event, used to determine the rule data interaction between the cloud device and the terminal device. In other words, the rule operation input by the user terminal can serve as the driving event for the rule data interaction between the terminal device and the cloud device. This rule operation can include rule creation, rule disabling, and rule adjustment. In this embodiment, rule adjustment is also treated as rule creation; that is, when rule data needs to be adjusted, the adjusted rule data is directly constructed by creating new rule data. Therefore, the rule operations in this embodiment include rule creation and rule disabling operations.

[0047] The "Create New Rule" operation may or may not include rule content. When the operation includes rule content, the corresponding rule content can be obtained directly by reading the included content. When the operation does not include rule content, a rule content retrieval request can be sent to the user terminal, and the rule content returned by the user terminal based on the request can be received to obtain the corresponding rule content. Alternatively, in practical applications, the "Create New Rule" operation may include a download address for the rule content, which the cloud device uses to retrieve the corresponding rule content.

[0048] Cloud devices can be equipped with rule engine systems, such as Figure 2 As shown, the rule engine system includes an application layer, a rule engine layer, a task execution layer, a data storage layer, asset control, and logging. The application layer provides logical interfaces for accessing the rule engine layer. The rule engine layer manages the business functions of rule instances and schedules the task execution layer to execute thread tasks formed based on the rule instances. The task execution layer executes the thread tasks formed by the rule engine layer in parallel. The data storage layer stores execution data generated during thread task execution, such as process data, log data, and instance data. Asset control utilizes AOP (Aspect-Oriented Programming), which can be implemented through annotations. Logging writes log information in a rolling date format, for example, writing event triggering and rule triggering log information to Elasticsearch in a rolling date format. Furthermore, rule instances can be in JSON format to support batch import / export and batch enabling / disabling of rule instances.

[0049] The application layer comprises a business interface layer, a logic control layer, and a business logic layer, arranged sequentially from top to bottom. The business interface layer provides business interfaces, such as OpenAPI interfaces and basic business operation interfaces. The logic control layer provides control interfaces for the rule engine, which may include rule editing control entry points, rule instance operation control entry points, and scene linkage control entry points. The business logic layer provides control interfaces for rule instances within the rule engine, wherein these control interfaces can receive rule instance start operations, rule instance stop operations, etc.

[0050] The rule engine layer manages the business functions of rule instances and schedules the task execution layer to execute thread tasks formed based on the rule instances. The rule engine layer includes a parser, a converter, and a starter; the parser converts rule data accessing the rule engine system into rule instances; the converter converts rule instances into thread tasks executable by the task execution layer; and the starter controls the starting and stopping of the thread tasks.

[0051] The task execution layer is used to execute the node tasks of each task node. It is scheduled by the scheduler to execute the thread tasks of the task nodes in parallel, so as to realize the parallel operation of different rule instances. For a rule instance, since there are relationships between the node tasks included in the rule instance, the task execution layer will execute each node task in sequence according to the relationship between the node tasks. For task nodes without relationships, they can also be executed in parallel, thereby improving the execution efficiency of the task nodes.

[0052] Furthermore, the rule content may include a triggering part, a condition judgment part, and an action part. The triggering part is used to receive trigger instructions, which can be formed through different triggering methods, and the triggering parameters corresponding to different triggering methods are different. Specifically, since the IoT scenario includes interaction with devices as well as interaction with users (such as a single device inspection), the triggering methods may include device triggering methods and manual triggering methods. When the triggering method is device triggering, the triggering instruction will provide relevant information about the triggering device. This relevant information can be represented as {identifier, action}, where the identifier is the device identifier of the triggering device, and the action can be attribute operations related to the object model (such as reading, writing, reporting, etc.), capability invocation, and event reporting, etc. When the triggering method is manual triggering, the trigger request can be formed by clicking a preset button. That is, when the preset button is clicked, a trigger request will be sent to the rule editing entry.

[0053] The condition judgment section is used to perform conditional judgments based on the rule data determined by the upstream triggering section. For example, it checks whether the reported execution attribute value is greater than or less than a preset threshold. It also adapts operators based on the value type of the rule data determined by the upstream triggering section, for users to use when planning business rules. In the action execution section, common business operations involve both serial and parallel operations. Further conditional judgment processing (i.e., the execution condition judgment section) can be performed during the action execution. For example, in the conference room scenario mentioned above, after requesting the air conditioner to be turned on during the action execution, if the device replies that it has successfully turned on, the air conditioner temperature can be set.

[0054] S20. Construct rule data based on the rule content, and send the rule data to the end device so that the end device can run the rule data.

[0055] Specifically, constructing rule data based on rule content refers to converting rule content into rule data according to a preset rule template, that is, converting rule content into the form of a preset rule template to obtain rule data. The preset rule template includes node information of task nodes, the relationships between task nodes, and the triggering conditions of task nodes. Node information serves as the node identifier of task nodes, the relationships between task nodes refer to the linkage between task nodes and other nodes, and the triggering conditions of task nodes refer to the execution factors of task nodes.

[0056] Therefore, when converting rule content into rule data according to a preset rule template, the task nodes included in the rule content and the topology of each task node can be obtained. The topology includes the association relationships of the task nodes and the triggering conditions of the task nodes. Then, based on the task nodes and their topology, the node rule data of the task nodes can be determined, and the set of node rule data of all task nodes is taken as the rule data corresponding to the rule content. The task nodes included in the rule content can be determined based on the action execution part of the rule content; for example, each action in the action execution part can be considered a task node. The association relationships of task nodes can be determined based on the execution order between task nodes. For example, two task nodes with adjacent execution orders are determined to have an association relationship, and the task node that precedes and is adjacent to the task node in the execution order is considered the preceding task node, and the task node that follows and is adjacent to the task node in the execution order is considered the following task node. The topology of the task nodes includes the preceding and following task nodes.

[0057] The edge device can be a super device in a linked scenario or a direct device node. Therefore, when constructing rule data based on the rule content, the trigger category of the newly created rule operation can be determined. The trigger category includes device trigger and ultrasonic device trigger, and placeholder information is configured for the device nodes involved in the rule data based on the trigger category.

[0058] Therefore, in one implementation, constructing rule data based on the rule content specifically includes:

[0059] Read the trigger category of the newly created rule operation;

[0060] If the trigger category is device trigger, the rule content is converted into rule data according to the preset rule template, and the device on the user side is used as placeholder information.

[0061] Specifically, when the trigger category is device-triggered, the endpoint device recorded in the cloud device (i.e., the rule engine system) must be consistent with the endpoint device running the rule data. In other words, the endpoint device recorded in the cloud device must have the same device information as the endpoint device in the rule data. Therefore, after converting the rule content into rule data, the endpoint device is directly used as placeholder information; that is, the device identifier of the endpoint device is used as placeholder information to maintain consistency between the two.

[0062] Therefore, in another implementation, constructing rule data based on the rule content specifically includes:

[0063] Read the trigger category of the newly created rule operation;

[0064] If the trigger category is a super device trigger, the rule content is converted into rule data according to the preset rule template, and the device node information matched by the end device is used as placeholder information to construct rule data containing device node information.

[0065] Specifically, when the trigger type is ultrasound device triggering, the end-side device is a super device. This end-side device is associated with device nodes to form a device group. If the device identifier of the end-side device is directly used as placeholder information, a failure of a device node associated with the end-side device will cause the entire device group corresponding to the end-side device to fail. Therefore, when the trigger type is super device triggering, the device node information matched by the end-side device is used as placeholder information. This allows the cloud device to only record the device node information matched by the end-side device. When a device node associated with the end-side device fails, a device of the same type can be used to replace the device node without affecting the normal operation of the device group managed by the end-side device. The device node information matched by the end-side device can be the device type of the device node managed by the end-side device, or the function of the device node managed by the end-side device, etc.

[0066] In this embodiment, the device node information matched by the end-side device can be the device type of the device node managed by the end-side device. Furthermore, when using the device node information matched by the end-side device as placeholder information, the method further includes: when a device node associated with the end-side device fails, replacing the device node with a device of the same type. For example, if super device A manages device node B, and device node B fails during operation, then device node B can be replaced with a device of the same type, C, so that super device A can continue to execute rule data.

[0067] In one implementation, after constructing rule data based on the rule content and sending the rule data to the end-side device so that the end-side device runs the rule data, the method further includes:

[0068] The receiving end-side device reports the operation process in batches so that the cloud can track the operation process of the end-side device.

[0069] Specifically, the edge device generates an operation flow during the execution of the rule data. To facilitate the cloud device's tracking of the operation flow corresponding to the rule data, the edge device synchronizes the operation flow to the cloud device when it generates it. The edge device can report the operation flow to the cloud device upon generation (where multiple operation flows generated simultaneously are reported in batches), or it can report the operation flow to the cloud device in batches at preset intervals. In this embodiment, the edge device reports the operation flow to the cloud device in batches.

[0070] In one implementation, the rule data running on the edge device is periodically synchronized with the cloud device. For example, the edge device sends a rule data synchronization request to the cloud device at preset intervals. The cloud device obtains the rule data running on the edge device based on this synchronization request and compares the obtained rule data with its locally stored rule data. If they match, the rule data on the edge device remains unchanged; if they do not match, the rule data running on the edge device is corrected based on the locally stored rule data. Furthermore, the cloud device can also disable the rule data running on the edge device based on a disable rule operation sent by the user. In other words, the method also includes:

[0071] In response to the user's command to disable a rule, a command to delete the rule is sent to the end device.

[0072] Based on the deletion rule instruction, the control terminal device stops running the rule data and deletes the rule information corresponding to the rule data.

[0073] Specifically, the disable rule operation can prohibit all rule data running on the end-side device, or it can disable some rule data running on the end-side device, or it can disable some rules within the rule data, etc. When the cloud device responds to the disable rule operation sent by the user, it sends a delete rule command to the end-side device, causing the end-side device to stop running the rule data corresponding to the delete rule command and delete the rule data corresponding to the rule command. This application can reduce the rule data running on the end-side device through the delete rule command, so that when some rules become invalid, the end-side device can quickly stop running the invalid rules and avoid the problem of accidental operation.

[0074] Furthermore, during the execution of rule data on the edge device, communication anomalies may occur between the edge device and the cloud device. In this case, the edge device will continue to execute the rule data and record the execution flow formed during the communication anomaly period. Upon recovery of the communication anomaly, the execution flow formed during the communication anomaly period will be reported to the cloud so that the cloud device can track the execution flow during the communication anomaly period. Based on this, the method further includes:

[0075] Log information generated by saving the running rule data when communication anomalies occur through the end-side device;

[0076] When communication returns to normal, the receiving end device sends log information and synchronizes the operation process formed during the communication anomaly period based on the log information.

[0077] Specifically, log information is used to record the operational flow formed by the running rule data during the communication anomaly period. When communication returns to normal, the end device sends the log information to the cloud device, allowing the cloud device to synchronize the operational flow formed during the communication anomaly period based on the log information. Furthermore, to avoid excessive log information consuming large amounts of storage resources, a space threshold can be set. When the storage space occupied by the log information reaches the threshold, the end device actively re-establishes a connection with the cloud device. If re-establishing the connection fails, the end device can send an anomaly notification to the user, informing the user of the communication anomaly with the cloud device, and receive feedback from the user. If the feedback indicates "continue running" and uses a cyclic overwrite method to store log information (i.e., replacing the oldest stored log information with newly generated log information), the end device continues to run the rule data. If the feedback indicates "pause running," the end device pauses running. This avoids excessive log information consuming storage space and also prevents errors caused by the end device failing to recognize instructions to disable all or part of the rule data due to communication anomalies between the end device and the cloud device.

[0078] Of course, in practical applications, the duration of communication anomalies can also be monitored. When the duration of communication anomalies reaches the preset duration, an anomaly notification can be sent to the user terminal to inform the user terminal that there is a communication anomaly with the cloud device, or the running rule data can be directly suspended.

[0079] In summary, this embodiment provides an event-driven rule data interaction method, apparatus, device, and storage medium. The method includes responding to a user terminal's new rule creation operation, obtaining rule content corresponding to the new rule creation operation; constructing rule data based on the rule content, and sending the rule data to an edge device so that the edge device can run the rule data. This application obtains rule content of the IoT scenario through a cloud device, then constructs rule data based on the rule content, and interacts the rule data with the edge devices included in the IoT scenario. This allows the edge devices to obtain scenario information of the IoT scenario simply by interacting with the cloud device, without the need for data interaction between device nodes in the IoT scenario, thereby avoiding data loss and data congestion caused by excessive interaction data.

[0080] Based on the above event-driven rule data interaction method, this embodiment provides an event-driven rule data interaction device, such as... Figure 3 As shown, the event-driven rule data interaction device specifically includes:

[0081] The acquisition module 100 is used to respond to the new rule operation sent by the user terminal and acquire the rule content corresponding to the new rule operation;

[0082] The construction module 200 is used to construct rule data based on the rule content and send the rule data to the end-side device so that the end-side device can run the rule data.

[0083] Based on the above event-driven rule data interaction method, this embodiment provides a computer-readable storage medium that stores one or more programs that can be executed by one or more processors to implement the steps in the event-driven rule data interaction method as described in the above embodiment.

[0084] Based on the above event-driven rule-based data interaction method, this application also provides a server-side, such as... Figure 4 As shown, the server is equipped with a rules engine system and includes at least one processor, memory, and may also include a communication interface and a bus. The processor, memory, and communication interface can communicate with each other via the bus. The communication interface can transmit information. The processor can invoke logical instructions in the memory to execute the methods described in the above embodiments.

[0085] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0086] As a computer-readable storage medium, the memory can be configured to store software programs, computer-executable programs, such as program instructions or modules corresponding to the methods in the embodiments of this disclosure. The processor executes functional applications and data processing by running the software programs, instructions, or modules stored in the memory, thereby implementing the methods in the above embodiments.

[0087] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on server usage. Furthermore, the memory may include high-speed random access memory (RAM) and non-volatile memory. Examples include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks; these can also be transient storage media.

[0088] Furthermore, the specific process of loading and executing the aforementioned storage medium and multiple instruction processors in the server has been described in detail in the above method, and will not be repeated here.

[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An event-driven rule-based data interaction method, characterized in that, The event-driven rule-based data interaction method specifically includes: In response to a user's request to create a new rule, obtain the rule content corresponding to the new rule creation request; Rule data is constructed based on the rule content, and the rule data is sent to the end device so that the end device can run the rule data; Specifically, constructing rule data based on the rule content includes: Read the trigger category of the newly created rule operation; If the trigger category is device trigger, the rule content is converted into rule data according to the preset rule template, and the device identifier of the end device is used as placeholder information; If the trigger category is a super device trigger, the rule content is converted into rule data according to the preset rule template, and the device node information matched by the end device is used as placeholder information to construct rule data containing device node information.

2. The event-driven rule-based data interaction method according to claim 1, characterized in that, When the device node information matched by the end-side device is used as placeholder information, the method further includes: When the device node associated with the end-side device fails, the device node is replaced by a device of the same type as the device node.

3. The event-driven rule-based data interaction method according to claim 1, characterized in that, After constructing rule data based on the rule content and sending the rule data to the end-side device so that the end-side device runs the rule data, the method further includes: The receiving end-side device reports the operation process in batches so that the cloud can track the operation process of the end-side device.

4. The event-driven rule-based data interaction method according to claim 1, characterized in that, The method further includes: In response to the user's command to disable a rule, a command to delete the rule is sent to the end device. Based on the deletion rule instruction, the control terminal device stops running the rule data and deletes the rule information corresponding to the rule data.

5. The event-driven rule-based data interaction method according to claim 1, characterized in that, The method further includes: Log information generated by saving the running rule data when communication anomalies occur through the end-side device; When communication returns to normal, the receiving end device sends log information and synchronizes the operation process formed during the communication anomaly period based on the log information.

6. An event-driven rule-based data interaction device, characterized in that, The event-driven rule-based data interaction device specifically includes: The acquisition module is used to respond to the new rule operation sent by the user terminal and acquire the rule content corresponding to the new rule operation; A construction module is used to construct rule data based on the rule content and send the rule data to the end-side device so that the end-side device can run the rule data; Specifically, constructing rule data based on the rule content includes: Read the trigger category of the newly created rule operation; If the trigger category is device trigger, the rule content is converted into rule data according to the preset rule template, and the device identifier of the end device is used as placeholder information; If the trigger category is a super device trigger, the rule content is converted into rule data according to the preset rule template, and the device node information matched by the end device is used as placeholder information to construct rule data containing device node information.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps in the event-driven rule data interaction method as described in any one of claims 1-5.

8. A server-side component, characterized in that, include: Processor and memory; The memory stores a computer-readable program that can be executed by the processor; When the processor executes the computer-readable program, it implements the steps of the event-driven rule-based data interaction method as described in any one of claims 1-5.

Images