Low-code iot network configuration method and system, electronic device and storage medium

Abstract

The application discloses a low-code Internet of Things network configuration method and system, electronic equipment and a storage medium, and relates to the technical field of Internet of Things engineering. The method comprises the following steps: receiving an original data packet and determining the protocol type corresponding to the original data packet; constructing a data processing flow in a graphical configuration interface; transmitting the original data packet into a southbound receiving node and converting the original data packet into a decimal value; calling a standard data model, mapping the decimal value to a target field, and sending the target field to an Internet of Things platform; receiving a control instruction issued by the Internet of Things platform and constructing an instruction processing flow; parsing the control instruction into a control type identifier and a control parameter in a northbound command node through a second starting node; generating a communication message through a function node according to the control type identifier and the control parameter, and sending the communication message to an Internet of Things device. The above scheme can reduce the workload of configuration and maintenance of the data processing flow.

Description

Technical Field

[0001] This application relates to the technical field of Internet of Things (IoT) engineering, specifically to a low-code IoT network configuration method, system, electronic device, and storage medium. Background Technology

[0002] With the development of IoT technology, devices need to complete a series of processing steps when connecting to a platform, including data reception, protocol parsing, data conversion, and command issuance. To standardize these processes, the industry typically uses a serialized data processing node approach to construct the data flow link.

[0003] Currently, mainstream IoT platforms employ a fixed data processing workflow, processing device-reported data by connecting receiving nodes, protocol parsing nodes, and data conversion nodes. When processing device-issued commands, this is accomplished through command parsing nodes and protocol encapsulation nodes. Developers need to write specific program code in each processing node to implement the data processing logic; for example, writing parsing code in the protocol parsing node and conversion rules in the data conversion node.

[0004] However, this pre-defined, fixed processing flow lacks flexibility. Each processing node requires dedicated developers to write code based on specific protocols and data formats. When adjustments to the data processing flow or the addition of new processing nodes are needed, not only must the connections between nodes be modified, but the processing code for each node must also be redeveloped and debugged. This significantly increases the workload of configuring and maintaining the data processing flow. Summary of the Invention

[0005] This application provides a low-code IoT network configuration method, system, electronic device, and storage medium that can reduce the workload of configuration and maintenance of data processing procedures.

[0006] The first aspect of this application provides a low-code IoT network configuration method, specifically including:

[0007] Receive raw data packets sent by IoT devices, and determine the protocol type corresponding to the raw data packets based on the protocol identifier of the raw data packets;

[0008] In the graphical configuration interface, when dragging behavior is detected, a data processing flow is constructed. The data processing flow includes a first start node, a southward receiving node, a decoding node, a mapping node, and a northward reporting node connected in sequence.

[0009] The original data packet is transmitted to the southbound receiving node through the first starting node, and the original data packet is converted into a decimal value in the decoding node;

[0010] In the mapping node, a standard data model is retrieved from the IoT platform based on the protocol type, and the decimal value is mapped to a target field based on the standard data model. The target field is then sent to the IoT platform through the northbound reporting node.

[0011] The system receives control commands generated based on the target field from the IoT platform and constructs a command processing flow in the graphical configuration interface. The command processing flow includes a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence.

[0012] The control command is parsed into a control type identifier and control parameters in the northbound command node via the second start node;

[0013] The control type identifier and control parameters are used to generate a communication message through the function node, and the communication message is sent to the IoT device through the southbound sending node.

[0014] By adopting the above technical solution and providing a graphical configuration interface for visually constructing the data processing flow, developers can complete the serial configuration of data processing nodes through simple drag-and-drop operations, without having to write specific program code for each processing node. By uniformly converting raw data packets into decimal values ​​in the decoding node and automatically retrieving standard data models based on protocol type in the mapping node to complete data mapping, the development difficulty for devices with different protocol types is reduced. Simultaneously, this solution also supports building bidirectional data processing flows, processing not only data reported by devices but also control commands issued by the platform. Communication messages are automatically generated and sent to devices through function nodes, improving the data processing capabilities of the IoT platform. This solution uses a low-code graphical configuration method, enabling developers to quickly build and adjust data processing flows, significantly reducing the development cost and maintenance workload for IoT device access.

[0015] Optionally, in the graphical configuration interface, when dragging behavior is detected, a data processing flow is constructed, including:

[0016] When a dragging action is detected where a node component in the component library area of ​​the graphical configuration interface is dragged to the process configuration area, the node icon corresponding to the node component is displayed in the process configuration area.

[0017] When detecting the connection operation between adjacent node icons in the process configuration area, a data flow relationship is established between adjacent node icons, and the connection line between the node icons is displayed in the graphical configuration interface.

[0018] Verify whether the node connection order between adjacent node icons conforms to the preset standard processing flow, which includes: the first starting node connects to the south receiving node, the south receiving node connects to the decoding node, the decoding node connects to the mapping node, and the mapping node connects to the north reporting node.

[0019] When the node connection sequence conforms to the preset standard processing flow, the preset standard processing flow is used as the data processing flow, and the connection line is displayed as the first preset color in the graphical configuration interface.

[0020] When the node connection order does not conform to the preset standard processing flow, an error message is displayed in the graphical configuration interface, and the connection line is displayed in a second preset color.

[0021] By adopting the above technical solution, a component library area and a process configuration area are set up in the graphical configuration interface, allowing developers to intuitively select the required node components and place them in the process configuration area by dragging and dropping. The system automatically establishes data flow relationships and displays them visually with connecting lines by monitoring the connection operations between node icons in real time. Simultaneously, it intelligently verifies the connection order of nodes to ensure it conforms to the preset standard processing flow. When the connection order is compliant, the system displays the connecting line in the first preset color to indicate correctness; when it detects non-compliance with the standard processing flow, it promptly reports the problem to the developers using a connecting line in the second preset color and error message, effectively avoiding data processing anomalies caused by incorrect node connection order. This visual configuration method, combined with an intelligent verification mechanism, not only simplifies the operation of developers in building data processing flows but also effectively prevents misconfigurations, further improving the configuration efficiency and data processing reliability of the IoT platform.

[0022] Optionally, the verification of whether the node connection order between adjacent node icons conforms to a preset standard processing flow includes:

[0023] Obtain the node connection rules defined in the preset standard processing flow, wherein the node connection rules include the preceding node type and the following node type of each node;

[0024] Iterate through all the node icons in the process configuration area and obtain the node type of each node icon;

[0025] Obtain the first preceding node type and the first following node type that are allowed to be connected to the node type corresponding to each node icon from the node connection rules;

[0026] Verify whether the type of the second preceding node adjacent to each of the node icons matches the type of the first preceding node, and whether the type of the second following node matches the type of the first following node;

[0027] When the type of the second preceding node adjacent to any node icon does not match the type of the first preceding node, or the type of the second following node does not match the type of the first following node, it is determined that the node connection order does not conform to the preset standard processing flow.

[0028] When the type of the second preceding node of all adjacent node icons matches the type of the first preceding node, and the type of the second following node matches the type of the first following node, the node connection order is determined to conform to the preset standard processing flow.

[0029] By adopting the above technical solution, a standard node connection rule base is formed by predefining the allowed preceding and following node types for each node type. When developers configure node connections, the system automatically traverses all node icons in the process configuration area and performs bidirectional matching verification between the actual connection relationship of each node and the preset rules. Through rigorous verification of the preceding and following types of nodes, it ensures that each node in the data processing flow forms a reasonable data flow relationship with its adjacent nodes. This fine-grained connection rule verification mechanism can not only promptly detect incorrect configurations in the node connection order but also accurately locate specific error positions, helping developers quickly identify and correct configuration problems. This ensures the correctness of the data processing flow and the reliability of data flow, improving the configuration accuracy and operational stability of the IoT platform.

[0030] Optionally, converting the original data packet into a decimal value in the decoding node includes:

[0031] Based on the protocol type, a preset decoding rule template is invoked;

[0032] Extract the data payload from the original data packet;

[0033] Obtain the starting byte position and truncation length configured in the decoding rule template;

[0034] Based on the starting byte position and the truncation length, extract the target data segment from the data payload;

[0035] The target data fragment is converted into a decimal value according to the data format configured in the decoding rule template. The data format includes any one of signed integer data, unsigned integer data, floating-point data, and string data.

[0036] By adopting the above technical solution and pre-configuring decoding rule templates corresponding to different protocol types, the data parsing process is standardized and templated. During decoding, the system can automatically call the corresponding decoding rule template according to the protocol type and accurately extract the target data segment from the data payload according to the start byte position and truncation length defined in the template. By pre-setting the data format in the decoding rule template, the system can automatically convert data of different formats into standard decimal values, effectively solving the problem of inconsistent data formats between devices with different protocol types. This templated decoding scheme not only reduces the development difficulty of protocol parsing but also improves the accuracy and efficiency of data parsing, enabling the IoT platform to handle various types of device data more flexibly and providing a unified data foundation for subsequent data processing and analysis.

[0037] Optionally, mapping the decimal value to the target field based on the standard data model includes:

[0038] Based on the field mapping relationship in the standard data model and the decimal value, determine the field type and value range corresponding to the target field;

[0039] The decimal value is converted according to the field type, and the converted value is verified to be within the range of values.

[0040] When the converted value is within the range of values, the converted value is used as the target field;

[0041] When the converted value is outside the range of values, a value exceeding the limit prompt message is displayed in the graphical configuration interface.

[0042] By adopting the above technical solution and utilizing the predefined field mapping relationships in the standard data model, the system achieves intelligent conversion of device data to platform standard fields. The system not only automatically converts data formats based on the target field type but also verifies the value range of the converted values ​​to ensure that the data conforms to the platform's defined standards. When data exceeds the preset value range, the system promptly provides feedback to developers via a graphical interface, effectively preventing abnormal data from entering the IoT platform. This mapping mechanism with data verification capabilities ensures both the standardization of data formats and the rationality of data values, improving the accuracy and reliability of IoT platform data processing and providing high-quality standardized data support for upper-layer applications.

[0043] Optionally, after sending the communication message to the corresponding IoT device through the southbound sending node, the process further includes:

[0044] Monitor the sending status of the communication message. If the communication message fails to be sent, generate a feedback path in the graphical configuration interface. The feedback path includes a southbound receiving feedback node, a feedback analysis node, and a northbound feedback node connected in sequence.

[0045] The reason for message transmission failure is identified in the feedback analysis node;

[0046] Based on the stated reasons, corresponding status feedback information is generated in the feedback analysis node, and the status feedback information is sent to the IoT platform through the northbound feedback node.

[0047] The feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and the display format of the connecting lines in the feedback path is different from that of the connecting lines in the instruction processing flow.

[0048] By adopting the above technical solution, the system monitors the transmission status of communication messages in real time and automatically generates feedback paths for fault analysis and status feedback when transmission fails. The system can identify the specific reasons for message transmission failure at the feedback analysis node and generate corresponding status feedback information, which is then reported to the IoT platform in real time, enabling the platform to promptly grasp the execution status of device commands. By displaying the command processing flow and feedback path in parallel in different display formats within a graphical configuration interface, the system achieves visualized monitoring of command issuance and status feedback, facilitating developers to intuitively identify and locate communication faults. This bidirectional command processing mechanism not only improves the reliability of the IoT platform's control commands for devices but also enhances the platform's fault diagnosis and problem tracing capabilities, providing strong support for the remote control and operation and maintenance management of IoT devices.

[0049] Optionally, the cause includes at least one of network failure, device offline, and protocol mismatch, and the step of generating corresponding status feedback information in the feedback analysis node according to the cause includes:

[0050] In the feedback analysis node, the reasons for each communication message transmission failure and the number of transmission failures are counted, and the number of network failures, device offlines, and protocol mismatches are accumulated according to the type of the reasons.

[0051] The network failure probability is obtained by calculating the proportion of the number of network failures in the number of transmission failures; the device offline probability is obtained by calculating the proportion of the number of device offlines in the number of transmission failures; and the protocol mismatch probability is obtained by calculating the proportion of the number of protocol mismatches in the number of transmission failures.

[0052] Based on the relationship between the network failure probability, the device offline probability, and the protocol mismatch probability, the corresponding display level of status feedback information is determined, and the network link status information, device status information, and protocol status information are displayed in the graphical configuration interface in the order from top to bottom according to the display level.

[0053] By adopting the above technical solution, the causes of communication message transmission failures are classified, statistically analyzed, and probabilistically, achieving precise quantification of fault causes. The system can automatically calculate the probability of occurrence of three fault types: network failure, device offline, and protocol incompatibility. Based on the probability magnitude, it determines the display priority of status feedback information and displays various fault status information in a hierarchical manner within the graphical configuration interface. This statistical analysis-based fault display method not only helps developers quickly identify the main causes of communication failures but also reflects the stability of system operation through probability distribution, providing data support for fault diagnosis and system optimization. This solution enhances the fault analysis capabilities and operational decision-making capabilities of the IoT platform, improving the intelligence level of device management and operational efficiency.

[0054] A second aspect of this application provides a low-code Internet of Things (IoT) network configuration system, specifically comprising:

[0055] The data acquisition module is used to receive raw data packets sent by IoT devices and determine the protocol type corresponding to the raw data packets based on the protocol identifier of the raw data packets;

[0056] The process construction module is used to construct a data processing process when dragging behavior is detected in the graphical configuration interface. The data processing process includes a first start node, a southward receiving node, a decoding node, a mapping node, and a northward reporting node connected in sequence.

[0057] The data conversion module is used to transmit the original data packet to the southbound receiving node through the first starting node, and convert the original data packet into a decimal value in the decoding node;

[0058] The data conversion module is also used in the mapping node to retrieve a standard data model from the IoT platform based on the protocol type, map the decimal value to a target field based on the standard data model, and send the target field to the IoT platform through the northbound reporting node.

[0059] The process construction module is also used to receive control instructions generated based on the target field issued by the IoT platform, and to construct an instruction processing flow in the graphical configuration interface. The instruction processing flow includes a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence.

[0060] The data conversion module is also used to parse the control command into a control type identifier and control parameters in the northbound command node through the second start node;

[0061] The data application module is used to generate a communication message by using the control type identifier and control parameters through the function node, and to send the communication message to the IoT device through the southbound sending node.

[0062] By adopting the above technical solution and providing a graphical configuration interface for visually constructing the data processing flow, developers can complete the serial configuration of data processing nodes through simple drag-and-drop operations, without having to write specific program code for each processing node. By uniformly converting raw data packets into decimal values ​​in the decoding node and automatically retrieving standard data models based on protocol type in the mapping node to complete data mapping, the development difficulty for devices with different protocol types is reduced. Simultaneously, this solution also supports building bidirectional data processing flows, processing not only data reported by devices but also control commands issued by the platform. Communication messages are automatically generated and sent to devices through function nodes, improving the data processing capabilities of the IoT platform. This solution uses a low-code graphical configuration method, enabling developers to quickly build and adjust data processing flows, significantly reducing the development cost and maintenance workload for IoT device access.

[0063] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.

[0064] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions. Attached Figure Description

[0065] Figure 1 This is a schematic diagram of a low-code IoT network configuration system architecture provided in an embodiment of this application;

[0066] Figure 2 This is a flowchart illustrating a low-code IoT network configuration method provided in an embodiment of this application;

[0067] Figure 3 This is a schematic diagram illustrating a node selection method provided in an embodiment of this application;

[0068] Figure 4This is a schematic diagram of the structure of a low-code Internet of Things (IoT) network configuration system provided in an embodiment of this application;

[0069] Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0070] Explanation of reference numerals in the attached figures: 901, processor; 902, communication bus; 903, user interface; 904, network interface; 905, memory. Detailed Implementation

[0071] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification 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.

[0072] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0073] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0074] Figure 1 This paper presents a low-code IoT network configuration system architecture.

[0075] like Figure 1 As shown, the system architecture may include IoT device 011, network 012, and electronic device 013. Network 012 is used to provide a data transmission link between IoT device 011 and electronic device 013. Network 012 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0076] IoT device 011 can interact bidirectionally with electronic device 013 via network 012. IoT device 011 is primarily responsible for collecting and reporting raw data packets, while also receiving and executing control commands issued by the platform. IoT device 011 is hardware and can be a smart terminal device with data acquisition and communication functions, supporting multiple communication protocol types.

[0077] Electronic Device 013 provides a graphical configuration interface, allowing developers to build data processing and command processing workflows via drag-and-drop. The platform is responsible for decoding, converting, and mapping fields in the raw data packets reported by the device, while also handling the parsing and distribution of control commands. Based on preset decoding rule templates and standard data models, Electronic Device 013 can achieve standardized data processing and bidirectional conversion, ultimately completing the access and control of device data. These configuration and processing results can be used for subsequent device management and business applications.

[0078] It should be noted that electronic devices can be either hardware or software. When an electronic device is hardware, it can be implemented as a distributed platform cluster consisting of multiple servers, or as a single server. When an electronic device is software, it can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0079] It should be understood that Figure 1 The number of IoT devices 011, networks 012, and electronic devices 013 shown is merely illustrative. Depending on implementation needs, there can be any number of IoT devices 011, networks 012, and electronic devices 013. Specifically, during the development and debugging phase, the above system architecture may exclude network 012 and include only IoT devices 011 or electronic devices 013.

[0080] The following section uses an electronic device as an example to illustrate a low-code IoT network configuration method provided in this application.

[0081] This application provides a low-code IoT network configuration method, referencing... Figure 2 , Figure 2 This is a flowchart illustrating a low-code IoT network configuration method provided in an embodiment of this application, including steps S101 to S107, as follows:

[0082] S101: Receive raw data packets sent by IoT devices and determine the protocol type corresponding to the raw data packets based on the protocol identifier of the raw data packets.

[0083] In this embodiment, the raw data packet represents a binary data stream generated by an IoT device based on its built-in communication protocol, including fields such as protocol header, protocol identifier, data payload, and checksum. The protocol identifier is a specific field used to identify the protocol type used by the data packet, and can be a protocol name, version number, or unique identifier. The protocol type refers to the communication standard used by the IoT device for data transmission, including standard protocols such as Modbus, MQTT, and TCP, or proprietary protocols.

[0084] Specifically, the system first receives raw data packets from IoT devices via a network interface, then reads the protocol header from these packets to obtain the protocol identifier. Next, it queries a pre-configured protocol mapping table, which stores the correspondence between protocol identifiers and protocol types. By matching the parsed protocol identifier with the records in the protocol mapping table, the protocol type corresponding to the raw data packet is determined.

[0085] S102: In the graphical configuration interface, when dragging behavior is detected, a data processing flow is constructed. The data processing flow includes the first start node, the southward receiving node, the decoding node, the mapping node, and the northward reporting node connected in sequence.

[0086] In this embodiment of the application, the graphical configuration interface refers to the human-computer interaction interface used to realize the visual configuration of the data processing flow of IoT devices, including a component library area and a process configuration area. The component library area is used to display various selectable node components, and the process configuration area is used to construct specific data processing flows by dragging and dropping.

[0087] For details, please refer to Figure 3 , Figure 3 This is a schematic diagram of node selection provided in an embodiment of this application, combined with... Figure 3 As can be seen, the component library area pre-defines various types of node components, including the first start node, southbound receiving node, decoding node, mapping node, and northbound reporting node. When a developer drags a node component from the component library area to the process configuration area, the corresponding node icon is displayed at the target location of the drag. Subsequently, the connection operations in the process configuration area are monitored. When a connection is detected between adjacent node icons, the data flow relationship between these nodes is automatically established and visually displayed in the interface as connecting lines. The system verifies in real time whether the connection order of the nodes conforms to the preset standard processing flow, that is, the first start node must be connected to the southbound receiving node, the southbound receiving node must be connected to the decoding node, the decoding node must be connected to the mapping node, and the mapping node must be connected to the northbound reporting node. When all nodes are connected in the standard order, the data processing flow is constructed.

[0088] Based on the above embodiments, as an optional embodiment, the data processing flow provided in this application includes, S102: In the graphical configuration interface, when dragging behavior is detected, the step of constructing a data processing flow may specifically include the following steps:

[0089] S201: When a dragging behavior is detected where a node component in the component library area of ​​the graphical configuration interface is dragged to the process configuration area, the node icon corresponding to the node component is displayed in the process configuration area.

[0090] Specifically, the system first pre-defines various types of node components in the component library area, including data acquisition nodes, protocol parsing nodes, and data conversion nodes. The system continuously monitors the selection status of node components in the component library area. When a node component is selected, it records its type and style information. During dragging, the system calculates the movement trajectory of the pointer device in real time and displays a semi-transparent node preview icon at the pointer position. When dragged to the process configuration area, the system checks if the release position is within a valid placement area. If the release position is valid, a node icon instance corresponding to the selected node component type is created at the release position, and the preset style information is applied; if the release position is invalid, the drag operation is canceled. Finally, the created node icon is displayed in the process configuration area, and the configuration interface of the node component is activated, awaiting subsequent parameter settings and connection operations.

[0091] S202: When connecting adjacent node icons in the detection process configuration area, establish a data flow relationship between adjacent node icons and display the connection line between node icons in the graphical configuration interface.

[0092] Specifically, the process first monitors the port status of node icons in the process configuration area. When a user clicks on the output port of a node, the connection drawing mode is activated. During the connection process, the movement trajectory of the pointer device is tracked in real time, and a dynamic guide line is drawn from the source node's output port to the current pointer position. Simultaneously, the distance between the pointer position and the input ports of other target nodes is calculated. When the distance is less than a preset threshold, the pointer automatically snaps to the nearest input port. When a release is detected at the input port of a target node, the node types of the source and target nodes are obtained, and a preset node connection rule base is queried. The node connection rule base defines the allowed preceding and following node types for each node type. The legality of the connection is verified by comparing whether the source node belongs to a allowed preceding node type of the target node, and whether the target node belongs to a allowed following node type of the source node. If the verification is successful, a data flow relationship is established between the source and target nodes, and a connection line with a preset style is drawn in the graphical configuration interface; if the verification fails, the connection operation is canceled, and an error message is displayed.

[0093] S203: Verify whether the node connection order between adjacent node icons conforms to the preset standard processing flow. The standard processing flow includes: the first starting node connects to the southward receiving node, the southward receiving node connects to the decoding node, the decoding node connects to the mapping node, and the mapping node connects to the northward reporting node.

[0094] Specifically, the process first loads a pre-defined standard processing flow from the configuration database, obtaining the node connection rules contained within the standard processing flow. These rules stipulate that the first starting node can only connect to southbound receiving nodes; the preceding node of a southbound receiving node must be the first starting node, and its following node must be a decoding node; the preceding node of a decoding node must be a southbound receiving node, and its following node must be a mapping node; the preceding node of a mapping node must be a decoding node, and its following node must be a northbound reporting node; and the preceding node of a northbound reporting node must be a mapping node. Then, it iterates through all node icons in the process configuration area, extracting the node type information for each icon. For each node icon, it queries the node connection rules to find the allowed first preceding node type and first following node type. Next, it obtains the types of the actually connected preceding and following nodes, i.e., the second preceding node type and the second following node type. The compliance of the node connection is verified by comparing whether the second preceding node type matches the allowed first preceding node type in the rules, and whether the second following node type matches the allowed first following node type in the rules. If any node's actual connection is found to be inconsistent with the rules, the node connection order of the entire process is determined to be inconsistent with the standard processing flow. Only when the connections of all nodes meet the rule requirements can the node connection order be confirmed to conform to the preset standard processing flow.

[0095] Based on the above embodiments, as an optional embodiment, S203: the step of verifying whether the node connection order between adjacent node icons conforms to the preset standard processing flow may specifically include the following steps:

[0096] S301: Obtain the node connection rules defined in the preset standard processing flow. The node connection rules include the predecessor node type and successor node type of each node.

[0097] Specifically, the system first reads the configuration file for the standard processing flow from the system configuration database. This configuration file is stored in a structured data format, such as JSON or XML. Then, based on the node connection rules in the configuration file, the connection constraint information for each node type is extracted. For each node type, the system obtains a list of preceding node types and a list of succeeding node types that are allowed to connect to this node type.

[0098] S302: Traverse all node icons in the process configuration area and obtain the node type of each node icon.

[0099] Specifically, first, the canvas object of the process configuration area is obtained, and then all currently configured node icons are retrieved from the canvas object. Each node icon is accessed sequentially according to its position in the canvas object. For each node icon, the type identifier field in the node icon's attribute information is read to obtain the node type of each icon.

[0100] S303: Obtain the first preceding node type and the first following node type that are allowed to be connected to the node type corresponding to each node icon from the node connection rules.

[0101] Specifically, firstly, based on the node type information obtained in step S302, each node icon is processed one by one. For each node icon, the connection constraint configuration in the node connection rules is queried based on the node type. From the connection constraint configuration, a list of the first preceding node types allowed to connect is extracted. This list defines all node types that can serve as input sources for the current node icon. Simultaneously, a list of the first following node types allowed to connect is extracted. This list defines all node types that can receive the output of the current node icon.

[0102] S304: Verify whether the type of the second preceding node adjacent to each node icon matches the type of the first preceding node, and whether the type of the second following node matches the type of the first following node.

[0103] Specifically, firstly, each node icon in the process configuration area is traversed, and its adjacent nodes are obtained through the connection line information. For each node icon, the upstream node connected to it via the input connection line is obtained; the type of this node is the second preceding node type. The downstream node connected to it via the output connection line is also obtained; the type of this node is the second following node type. Then, the first preceding node type and the first following node type that the node is allowed to connect to, obtained in step S303, are read. The second preceding node type is compared with the first preceding node type to check whether the type of the actually connected upstream node is allowed to connect. Similarly, the second following node type is compared with the first following node type to check whether the type of the actually connected downstream node is allowed to connect.

[0104] S305: When the type of the second preceding node adjacent to any node icon does not match the type of the first preceding node, or the type of the second following node does not match the type of the first following node, the node connection order is determined to be inconsistent with the preset standard processing flow.

[0105] Specifically, first, check all node verification results obtained in step S304. Iterate through each record in the verification result set, and for each node icon, determine the matching status of the second preceding node type with the first preceding node type, and the matching status of the second following node type with the first following node type. If any of the following conditions are found, it is determined to be non-compliant with the standard processing procedure: the second preceding node type is not within the allowed range of the first preceding node type, or the second following node type is not within the allowed range of the first following node type. Once any non-compliant connection is found, immediately terminate the verification process, mark the verification status as failed, and record the specific node location that caused the failure and the reason for non-compliance for subsequent error prompts and processing.

[0106] S306: When the type of the second preceding node of all adjacent node icons matches the type of the first preceding node, and the type of the second following node matches the type of the first following node, the node connection order is determined to conform to the preset standard processing flow.

[0107] Specifically, first, check all node verification results obtained in step S304. Iterate through each record in the verification result set, and for each node icon, verify the legality of its connection relationship one by one. Check whether the type of the second preceding node of each node completely matches the requirements of the first preceding node type. Simultaneously check whether the type of the second following node of each node completely matches the requirements of the first following node type. After verifying all nodes, if no non-compliant connections are found, mark the verification status as passed, indicating that the node connection order of the entire data processing flow conforms to the preset standard processing flow.

[0108] S204: When the node connection sequence conforms to the preset standard processing flow, the preset standard processing flow is used as the data processing flow, and the connection line is displayed as the first preset color in the graphical configuration interface.

[0109] Specifically, the first step is to verify the node connection order. If the verification passes, the currently configured node connection relationship is determined as a valid data processing flow. The data structure of the data processing flow records the data flow relationships between each node, including the complete processing link from the first starting node to the northbound reporting node. Then, the display style of the connection lines in the graphical configuration interface is updated, uniformly changing the color of the connection lines between all nodes to the first preset color.

[0110] S205: When the node connection sequence does not conform to the preset standard processing flow, an error message is displayed in the graphical configuration interface, and the connection line is displayed in the second preset color.

[0111] Specifically, the process first parses the verification results of the node connection order to obtain the specific reasons for the verification failure and related node information. Based on the verification results, an error message is generated, including: the location of the non-compliant node, the current incorrect connection relationship, and the expected correct connection relationship. Then, the error message is displayed in a suitable location within the graphical configuration interface, using various display formats such as pop-up windows, floating prompts, or embedded prompts. Simultaneously, the display color of all non-compliant connection lines is updated to a second preset color, including modifying the connection line style attributes, setting warning color values, and highlighting the connection positions that need correction.

[0112] S103: The original data packet is passed to the southbound receiving node through the first starting node, and the original data packet is converted into a decimal value in the decoding node.

[0113] Specifically, the received raw data packets are first preprocessed by the first starting node and transmitted to the southbound receiving node. Then, based on the protocol type determined in step S101, the corresponding decoding rule template is retrieved from the template library. Next, the data payload is parsed from the raw data packets, excluding non-data fields such as protocol headers and checksums. The starting point of the data is located according to the starting byte position configured in the decoding rule template, and the target data segment is extracted according to the specified truncation length. For the extracted target data segment, the data format type configured in the decoding rule template is read; this could be signed integer data (e.g., int16, int32), unsigned integer data (e.g., uint16, uint32), floating-point data (e.g., float32, float64), or string data. The appropriate decoding algorithm is selected based on the data format type to convert the binary data into decimal values.

[0114] Based on the above embodiments, as an optional embodiment, S103: the step of converting the original data packet into a decimal value in the decoding node may specifically include the following steps:

[0115] S401: Based on the protocol type, call the preset decoding rule template.

[0116] Specifically, firstly, the system retrieves a set of all preset decoding rule templates from the configuration database. Each template contains information such as protocol identifier, decoding parameters, and data format definitions. Then, based on the protocol type determined in step S101, a matching decoding rule template is searched for in the template set. The search process compares key information such as protocol identifier and version number to ensure that the selected template completely matches the protocol of the current data packet.

[0117] S402: Extract the data payload from the raw data packet.

[0118] In this embodiment of the application, the data payload refers to the actual business data portion carried in the original data packet, excluding protocol-related fields such as protocol header, protocol identifier, and checksum, and is used to store the specific data content to be transmitted.

[0119] Specifically, based on the decoding rule template called in step S401, the data packet structure definition is obtained, including information such as the protocol header length, payload start position, and payload length identifier. Then, the actual start position of the data payload is obtained by skipping fields such as the protocol header and protocol identifier. Next, the original data packet is truncated using the start position and the preset payload length. During the truncating process, a byte array copy operation is used to copy the byte sequence in the original data packet, starting from the start position and with a length equal to the payload length, into a new data payload buffer to obtain the data payload.

[0120] S403: Obtain the starting byte position and truncation length configured in the decoding rule template.

[0121] Specifically, firstly, the data positioning parameter section is read from the decoding rule template obtained in step S401. The data positioning parameter section contains configuration items for the location and length information of the target data. Then, the starting byte position is obtained from the location information, and the truncation length is obtained from the length information.

[0122] S404: Extract the target data segment from the data payload based on the starting byte position and the truncation length.

[0123] Specifically, the starting byte position is located in the data payload as the starting point for data extraction. A new byte array is created as the storage space for the target data fragment, with the size of the truncation length. Through a byte array copy operation, the byte sequence starting from the starting position and with a length equal to the truncation length in the data payload is copied to the newly created storage space to obtain the target data fragment.

[0124] S405: Convert the target data fragment into a decimal value according to the data format configured in the decoding rule template. The data format includes any one of signed integer data, unsigned integer data, floating-point data, and string data.

[0125] Specifically, the data format configuration information is first read from the decoding rule template to determine the specific data type of the target data segment. Then, the appropriate conversion algorithm is selected according to different data format types: for signed integer data, the handling of the sign bit needs to be considered, and the binary two's complement representation is converted into a signed decimal value; for unsigned integer data, the binary sequence is directly converted into a positive integer; for floating-point data, the sign bit, exponent bit, and mantissa bit need to be parsed according to the IEEE 754 standard to restore it to a decimal floating-point number; for string data, the byte sequence needs to be converted into a readable string according to the specified character encoding (such as ASCII, UTF-8, etc.).

[0126] S104: In the mapping node, the standard data model is retrieved from the IoT platform based on the protocol type, and the decimal value is mapped to the target field based on the standard data model. The target field is then sent to the IoT platform through the northbound reporting node.

[0127] In this embodiment, the standard data model refers to the device data structure specification predefined by the IoT platform, which includes field definitions, data types, value ranges, and other configuration information for device attributes, events, services, and other data. It is used to standardize the format and content of the data reported by the device. The IoT platform refers to a cloud service system used to manage and connect IoT devices, which includes functional modules such as device management, data processing, and protocol adaptation, and is used to realize unified access, storage, and processing of device data.

[0128] Specifically, firstly, based on the protocol type determined in step S101, the standard data model configuration for the corresponding device is obtained from the IoT platform. Then, the field mapping relationships in the standard data model are parsed to determine which target field the decoded decimal value should be mapped to, and the type and valid value range of that target field are obtained. Next, the decimal value is format-converted according to the type of the target field, such as converting integers to floating-point numbers, adjusting precision bits, and converting units. The converted value is then range-verified to determine if it falls within the value range defined by the standard data model. When the value is within the valid range, it is assigned to the target field, constructing a data structure conforming to the standard data model format. If the value is found to be out of range, an out-of-range warning message is displayed in the graphical configuration interface, indicating the specific reason for the out-of-range and the allowed value range. Finally, the processed target field data is sent to the IoT platform through the northbound reporting node, completing the standardized data reporting process.

[0129] Based on the above embodiments, as an optional embodiment, S104: the step of mapping decimal values ​​to target fields based on a standard data model may specifically include the following steps:

[0130] S501: Based on the field mapping relationship in the standard data model and the decimal value, determine the field type and value range corresponding to the target field.

[0131] In the embodiments of this application, the field mapping relationship refers to the correspondence rules between data fields defined in the standard data model and the original data of the device. It includes configuration information such as field identifier, data type, unit conversion, and value restrictions, which are used to guide the data conversion and verification process.

[0132] Specifically, first, a list of all field mapping relationships is retrieved from the standard data model configuration. Each mapping relationship includes attributes such as field name, data type, unit of measurement, and valid value range. Then, based on the decoded decimal value, the matching target field configuration is searched in the mapping relationship list. Next, the field type is extracted from the matching mapping relationship, which may be of various types such as integer, floating-point, or enumeration. Simultaneously, the value range configuration corresponding to the field type is obtained, including constraints such as minimum value, maximum value, and step value.

[0133] S502: Convert the decimal value according to the field type and verify whether the converted value is within the range.

[0134] Specifically, first, based on the field type determined in step S501, the corresponding conversion method is selected. Conversion processing methods for different types include: adding decimal places when converting integer to floating-point; rounding when converting floating-point to integer; parsing the numeric string when converting character to numeric; and determining the true / false value mapping relationship when converting Boolean. Then, according to the precision requirements in the field definition, the precision of the converted value is adjusted, such as retaining a specified number of decimal places or truncating excess decimal places. If the field defines unit conversion requirements, unit conversion is required, such as millimeters to meters, kilograms to grams, etc. Next, the converted value is compared with the value range defined by the field type to check whether it meets the minimum and maximum value restrictions, thus verifying that the converted value is within the range.

[0135] S503: When the converted value is within the range, the converted value will be used as the target field.

[0136] Specifically, first, check the format conversion result and range validation result in step S502 to confirm that the converted value meets the value range requirements. Then, create a new target field object and fill the data content attribute of the target field object with the validated converted value. At the same time, add necessary metadata information to the target field, including the timestamp of data generation, data quality identifier, data source, and other attributes. The target field is then obtained.

[0137] S504: When the converted value is outside the range, display a value exceeding the limit prompt message in the graphical configuration interface.

[0138] Specifically, first, obtain the value exceeding the limit situation discovered in step S502, including the specific value exceeding the limit and the corresponding field definition information. Then, construct the content of the value exceeding the limit prompt message, which needs to include: the name of the field that exceeded the limit, the current value of the field, the minimum and maximum allowed values ​​of the field, the time of exceeding the limit, etc. Select an appropriate prompt location in the graphical configuration interface, which can be a floating prompt box, status bar prompt, or embedded prompt, etc. Display the constructed prompt message in the selected location, and use different prompt styles according to the severity level, such as a yellow background for warnings and a red background for errors.

[0139] S105: Receives control commands generated based on target fields from the IoT platform and constructs a command processing flow in the graphical configuration interface. The command processing flow includes a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence.

[0140] Specifically, the system first listens to the command transmission channel of the IoT platform. When a control command generated based on the target field is received, a new command processing flow is created in the graphical configuration interface. Then, a second start node is added in the configuration interface as the starting point of the flow, used to identify the beginning of command processing. A northbound command node is connected after the second start node. The northbound command node is responsible for receiving and parsing the control commands issued by the platform, extracting information such as command type and control parameters. Next, a function node is added and connected to the northbound command node. The function node performs data conversion, parameter verification, and logic processing based on the command content, converting the platform command into control data that the device can recognize. Finally, a southbound sending node is added and connected to the function node. The southbound sending node is responsible for encapsulating the processed control data into a device protocol message and sending it to the target device.

[0141] S106: The control command is parsed into a control type identifier and control parameters in the northbound command node via the second start node.

[0142] Specifically, the command parsing process is first triggered by the second starting node, transmitting the received control commands to the northbound command node. Then, the northbound command node parses the command data structure and extracts the command identifier field. Next, by querying a pre-defined control command mapping table, the extracted identifier field is matched against the definitions in the table: if the identifier field starts with "set", it is identified as a setting control command; if it starts with "get", it is identified as a query control command; and if it starts with "config", it is identified as a configuration control command. Setting, query, and configuration control commands are used as control type identifiers. For different types of control commands, their contained control parameters are extracted: for setting commands, the target value and unit information are extracted; for switch commands, the switch status value is extracted; and for configuration commands, the configuration item and configuration value are extracted.

[0143] S107: Generate a communication message using the control type identifier and control parameters through the function node, and send the communication message to the IoT device through the southbound sending node.

[0144] Specifically, the function node first receives the control type identifier and control parameters parsed in step S106. Then, based on the device's communication protocol type, it selects the corresponding message construction template. For different types of control commands, the message structure is constructed according to the protocol specifications: setting commands require converting control parameters into a device-recognizable data format; query commands require constructing a query request message format; and configuration commands require organizing the message content according to the data type of the configuration item. Next, necessary protocol fields are added to the communication message, including adding a protocol header identifier, setting device address information, generating a serial number, and calculating a checksum. Simultaneously, the message length is padded or truncated to ensure compliance with the protocol's format requirements. After construction, the communication message is transmitted to the southbound sending node, which is responsible for establishing a communication connection with the IoT device, which may be through serial communication, network communication, or other methods. Finally, the communication message is sent to the IoT device through the established communication connection.

[0145] Based on the above embodiments, as an optional embodiment, after step S107: sending the communication message to the corresponding IoT device through the southbound sending node, the following steps are also included:

[0146] S601: Monitors the transmission status of communication messages. If the transmission of communication messages fails, a feedback path is generated in the graphical configuration interface. The feedback path includes a southbound receiving feedback node, a feedback analysis node, and a northbound feedback node connected in sequence.

[0147] Specifically, the system first monitors the transmission status of communication messages in step S107 in real time, including checking if the transmission process times out, whether a device response is received, and whether the response content is correct. When a communication message transmission failure is detected, a new feedback processing flow is created in the graphical configuration interface. Then, a southbound receiving feedback node is added as the starting point of the feedback path. The southbound receiving feedback node is responsible for receiving and recording specific information about the communication failure, including the failure time, failure reason, and number of retries. Next, a feedback analysis node is added and connected to the southbound receiving feedback node. The feedback analysis node analyzes the causes based on the collected failure information to determine the specific fault type, such as communication timeout, device offline, or data error. Finally, a northbound feedback node is added and connected to the feedback analysis node. The northbound feedback node is responsible for formatting the analysis results and reporting them to the IoT platform, enabling the platform to perceive the abnormal status of the device.

[0148] S602: Identify the reasons for message transmission failure in the feedback analysis node.

[0149] Specifically, the feedback analysis node first receives communication failure information transmitted from the southbound receiving feedback node. Then, the failure information is categorized and analyzed: the communication connection status is checked to determine if a physical link interruption has occurred; the transmission time is analyzed to confirm if a communication timeout has occurred; the device response data is verified to check for checksum errors; and the protocol version is compared to confirm if protocol incompatibility has occurred. Next, based on the analysis results, the specific failure cause type is determined: if the link is broken before transmission, it is determined to be a connection anomaly; if there is no response for a long time after transmission, it is determined to be a device timeout; if the response data verification fails, it is determined to be a data error; and if the protocol parsing is abnormal, it is determined to be a protocol mismatch.

[0150] S603: Generate corresponding status feedback information in the feedback analysis node based on the cause, and send the status feedback information to the IoT platform through the northbound feedback node.

[0151] Specifically, the failure reasons identified in step S602 are first statistically categorized in the feedback analysis node. Based on different failure reason types, the number of network failures (e.g., connection interruption, data loss), device offline occurrences (e.g., timeout, device disconnection), and protocol mismatch occurrences (e.g., verification errors, parsing failures) are accumulated. Then, the probability of each type of failure is calculated based on the accumulated failure counts: the network failure probability is obtained by dividing the number of network failures by the total number of failures; the device offline probability is obtained by dividing the number of device offline occurrences by the total number of failures; and the protocol mismatch probability is obtained by dividing the number of protocol mismatch occurrences by the total number of failures. Next, the three failure probabilities are compared, and the failure type with the highest probability is set to the highest display level, the next highest to the middle level, and the lowest to the lowest level. According to the priority of the display level, status feedback information is generated, including network link status information (e.g., "Network connection abnormal, it is recommended to check network configuration"), device status information (e.g., "Device offline, it is recommended to check device power supply"), and protocol status information (e.g., "Protocol version mismatch, it is recommended to update protocol configuration"). Finally, the generated status feedback information is sent to the IoT platform through the northbound feedback node.

[0152] Based on the above embodiments, as an optional embodiment, S603: the step of generating corresponding status feedback information in the feedback analysis node according to the cause may specifically include the following steps:

[0153] S701: In the feedback analysis node, the reasons for each communication message sending failure and the number of sending failures are counted. The number of network failures, device offline times and protocol mismatch times are accumulated according to the type of reason.

[0154] Specifically, a fault statistics counter is first created in the feedback analysis node to record the number of failures for three types: network faults, device offline, and protocol mismatch. Then, the transmission failure records for each communication message are analyzed: when a network-level fault such as a communication link interruption or packet loss is detected, the network fault counter is incremented by 1; when an abnormal device status is detected, such as a device timeout or active disconnection, the device offline counter is incremented by 1; and when a protocol parsing error occurs, such as a data verification failure or protocol version mismatch, the protocol mismatch counter is incremented by 1.

[0155] S702: Calculate the network failure probability by calculating the proportion of network failures to the total number of transmission failures; calculate the device offline probability by calculating the proportion of device offlines to the total number of transmission failures; and calculate the protocol mismatch probability by calculating the proportion of protocol mismatches to the total number of transmission failures.

[0156] Specifically, first, obtain the number of various types of faults and the total number of transmission failures counted in step S701. Then, calculate the probability of occurrence for each of the three types of faults: divide the number of network faults by the total number of failures to obtain the proportion of network faults among all failures, i.e., the network fault probability; divide the number of device offlines by the total number of failures to obtain the proportion of device offlines among all failures, i.e., the device offline probability; divide the number of protocol mismatches by the total number of failures to obtain the proportion of protocol mismatches among all failures, i.e., the protocol mismatch probability.

[0157] S703: Based on the relationship between the probability of network failure, the probability of device offline, and the probability of protocol mismatch, determine the display level of the corresponding status feedback information, and display the network link status information, device status information, and protocol status information in the graphical configuration interface in the order from top to bottom according to the display level.

[0158] Specifically, firstly, the three fault probability values ​​calculated in step S702 are obtained, and these probability values ​​are compared. Then, the display level is determined based on the comparison results: the status information corresponding to the fault type with the highest probability is set to the highest display level (L1 level); the status information corresponding to the fault type with the second highest probability is set to the middle display level (L2 level); and the status information corresponding to the fault type with the lowest probability is set to the lowest display level (L3 level). Next, a hierarchical display area is constructed in the graphical configuration interface, and display positions are assigned to the status information of different levels. The status information of each level is displayed in order from top to bottom: network link status information includes network connection status, fault description, and handling suggestions; device status information includes device online status, response status, and maintenance suggestions; protocol status information includes protocol compatibility, version information, and update suggestions. During the display process, different styles are used to highlight the differences between levels, such as using different font sizes, color shades, or background styles.

[0159] S604: The feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and the display format of the connecting lines in the feedback path is different from that of the connecting lines in the instruction processing flow.

[0160] Specifically, firstly, the display area is divided in the graphical configuration interface, placing the instruction processing flow and feedback path side by side. Then, the connecting lines in the instruction processing flow are set to the first display format: using solid lines, thicker line width, and positive arrows to indicate the main data flow direction. At the same time, the connecting lines in the feedback path are set to the second display format: using dashed lines, thinner line width, and reverse arrows to highlight the direction of feedback information transmission.

[0161] refer to Figure 4This application also provides a schematic diagram of a low-code IoT network configuration system, which specifically includes:

[0162] The data acquisition module is used to receive raw data packets sent by IoT devices and determine the protocol type corresponding to the raw data packets based on the protocol identifier of the raw data packets;

[0163] The process construction module is used to construct a data processing process when dragging behavior is detected in the graphical configuration interface. The data processing process includes a first start node, a southward receiving node, a decoding node, a mapping node, and a northward reporting node connected in sequence.

[0164] The data conversion module is used to transmit the original data packet to the southbound receiving node through the first starting node, and convert the original data packet into a decimal value in the decoding node;

[0165] The data conversion module is also used in the mapping node to retrieve a standard data model from the IoT platform based on the protocol type, map the decimal value to a target field based on the standard data model, and send the target field to the IoT platform through the northbound reporting node.

[0166] The process construction module is also used to receive control instructions generated based on the target field issued by the IoT platform, and to construct an instruction processing flow in the graphical configuration interface. The instruction processing flow includes a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence.

[0167] The data conversion module is also used to parse the control command into a control type identifier and control parameters in the northbound command node through the second start node;

[0168] The data application module is used to generate a communication message by using the control type identifier and control parameters through the function node, and to send the communication message to the IoT device through the southbound sending node.

[0169] Optionally, the process construction module is specifically used for:

[0170] When a dragging action is detected where a node component in the component library area of ​​the graphical configuration interface is dragged to the process configuration area, the node icon corresponding to the node component is displayed in the process configuration area.

[0171] When detecting the connection operation between adjacent node icons in the process configuration area, a data flow relationship is established between adjacent node icons, and the connection line between the node icons is displayed in the graphical configuration interface.

[0172] Verify whether the node connection order between adjacent node icons conforms to the preset standard processing flow, which includes: the first starting node connects to the south receiving node, the south receiving node connects to the decoding node, the decoding node connects to the mapping node, and the mapping node connects to the north reporting node.

[0173] When the node connection sequence conforms to the preset standard processing flow, the preset standard processing flow is used as the data processing flow, and the connection line is displayed as the first preset color in the graphical configuration interface.

[0174] When the node connection order does not conform to the preset standard processing flow, an error message is displayed in the graphical configuration interface, and the connection line is displayed in a second preset color.

[0175] Optionally, the process construction module is further specifically used for:

[0176] Obtain the node connection rules defined in the preset standard processing flow, wherein the node connection rules include the preceding node type and the following node type of each node;

[0177] Iterate through all the node icons in the process configuration area and obtain the node type of each node icon;

[0178] Obtain the first preceding node type and the first following node type that are allowed to be connected to the node type corresponding to each node icon from the node connection rules;

[0179] Verify whether the type of the second preceding node adjacent to each of the node icons matches the type of the first preceding node, and whether the type of the second following node matches the type of the first following node;

[0180] When the type of the second preceding node adjacent to any node icon does not match the type of the first preceding node, or the type of the second following node does not match the type of the first following node, it is determined that the node connection order does not conform to the preset standard processing flow.

[0181] When the type of the second preceding node of all adjacent node icons matches the type of the first preceding node, and the type of the second following node matches the type of the first following node, the node connection order is determined to conform to the preset standard processing flow.

[0182] Optionally, the data conversion module is specifically used for:

[0183] Based on the protocol type, a preset decoding rule template is invoked;

[0184] Extract the data payload from the original data packet;

[0185] Obtain the starting byte position and truncation length configured in the decoding rule template;

[0186] Based on the starting byte position and the truncation length, extract the target data segment from the data payload;

[0187] The target data fragment is converted into a decimal value according to the data format configured in the decoding rule template. The data format includes any one of signed integer data, unsigned integer data, floating-point data, and string data.

[0188] Optionally, the data conversion module is further specifically used for:

[0189] Based on the field mapping relationship in the standard data model and the decimal value, determine the field type and value range corresponding to the target field;

[0190] The decimal value is converted according to the field type, and the converted value is verified to be within the range of values.

[0191] When the converted value is within the range of values, the converted value is used as the target field;

[0192] When the converted value is outside the range of values, a value exceeding the limit prompt message is displayed in the graphical configuration interface.

[0193] Optionally, a low-code IoT network configuration system also includes a status feedback module, specifically used for:

[0194] Monitor the sending status of the communication message. If the communication message fails to be sent, generate a feedback path in the graphical configuration interface. The feedback path includes a southbound receiving feedback node, a feedback analysis node, and a northbound feedback node connected in sequence.

[0195] The reason for message transmission failure is identified in the feedback analysis node;

[0196] Based on the stated reasons, corresponding status feedback information is generated in the feedback analysis node, and the status feedback information is sent to the IoT platform through the northbound feedback node.

[0197] The feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and the display format of the connecting lines in the feedback path is different from that of the connecting lines in the instruction processing flow.

[0198] Optionally, the status feedback module is further specifically used for:

[0199] In the feedback analysis node, the reasons for each communication message transmission failure and the number of transmission failures are counted, and the number of network failures, device offlines, and protocol mismatches are accumulated according to the type of the reasons.

[0200] The network failure probability is obtained by calculating the proportion of the number of network failures in the number of transmission failures; the device offline probability is obtained by calculating the proportion of the number of device offlines in the number of transmission failures; and the protocol mismatch probability is obtained by calculating the proportion of the number of protocol mismatches in the number of transmission failures.

[0201] Based on the relationship between the network failure probability, the device offline probability, and the protocol mismatch probability, the corresponding display level of status feedback information is determined, and the network link status information, device status information, and protocol status information are displayed in the graphical configuration interface in the order from top to bottom according to the display level.

[0202] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0203] This embodiment also discloses an electronic device, as shown in the reference. Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. The electronic device 013 may include: at least one processor 901, at least one communication bus 902, a user interface 903, a network interface 904, and at least one memory 905.

[0204] The communication bus 902 is used to enable communication between these components.

[0205] The user interface 903 may include a display screen and a camera. Optionally, the user interface 903 may also include a standard wired interface and a wireless interface.

[0206] The network interface 904 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0207] The processor 901 may include one or more processing cores. The processor 901 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 905, and by calling data stored in the memory 905. Optionally, the processor 901 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array. The processor 901 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 901 and may be implemented as a separate chip.

[0208] The memory 905 may include random access memory (RAM) or read-only memory. Optionally, the memory 905 may include a non-transitory computer-readable storage medium. The memory 905 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 905 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 905 may also be at least one storage device located remotely from the aforementioned processor 901. (See reference...) Figure 5 The memory 905, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a low-code Internet of Things (IoT) network configuration application.

[0209] exist Figure 5In the electronic device shown, the user interface 903 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 901 can be used to call an application program that stores a low-code Internet of Things network configuration in the memory 905. When executed by one or more processors 901, the electronic device 013 performs one or more methods as described in the above embodiments.

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

[0211] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0212] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0213] 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0214] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0215] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0216] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A low-code Internet of Things (IoT) network configuration method, characterized in that, Applied to electronic devices, the method includes: Receive raw data packets sent by IoT devices, and determine the protocol type corresponding to the raw data packets based on the protocol identifier of the raw data packets; In the graphical configuration interface, when dragging behavior is detected, a data processing flow is constructed. The data processing flow includes a first start node, a southward receiving node, a decoding node, a mapping node, and a northward reporting node connected in sequence. The original data packet is transmitted to the southbound receiving node through the first starting node, and the original data packet is converted into a decimal value in the decoding node; In the mapping node, a standard data model is retrieved from the IoT platform based on the protocol type, and the decimal value is mapped to a target field based on the standard data model. The target field is then sent to the IoT platform through the northbound reporting node. The system receives control commands generated based on the target field from the IoT platform and constructs a command processing flow in the graphical configuration interface. The command processing flow includes a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence. The control command is parsed into a control type identifier and control parameters in the northbound command node via the second start node; The control type identifier and control parameters are used to generate a communication message through the function node, and the communication message is sent to the IoT device through the southbound sending node.

2. The low-code IoT network configuration method according to claim 1, characterized in that, In the graphical configuration interface, when dragging behavior is detected, a data processing flow is constructed, including: When a dragging action is detected where a node component in the component library area of ​​the graphical configuration interface is dragged to the process configuration area, the node icon corresponding to the node component is displayed in the process configuration area. When detecting the connection operation between adjacent node icons in the process configuration area, a data flow relationship is established between adjacent node icons, and the connection line between the node icons is displayed in the graphical configuration interface. Verify whether the node connection order between adjacent node icons conforms to the preset standard processing flow, which includes: the first starting node connects to the south receiving node, the south receiving node connects to the decoding node, the decoding node connects to the mapping node, and the mapping node connects to the north reporting node. When the node connection sequence conforms to the preset standard processing flow, the preset standard processing flow is used as the data processing flow, and the connection line is displayed as the first preset color in the graphical configuration interface. When the node connection order does not conform to the preset standard processing flow, an error message is displayed in the graphical configuration interface, and the connection line is displayed in a second preset color.

3. The low-code IoT network configuration method according to claim 2, characterized in that, The verification process for whether the node connection order between adjacent node icons conforms to a preset standard process includes: Obtain the node connection rules defined in the preset standard processing flow, wherein the node connection rules include the preceding node type and the following node type of each node; Iterate through all the node icons in the process configuration area and obtain the node type of each node icon; Obtain the first preceding node type and the first following node type that are allowed to be connected to the node type corresponding to each node icon from the node connection rules; Verify whether the type of the second preceding node adjacent to each of the node icons matches the type of the first preceding node, and whether the type of the second following node matches the type of the first following node; When the type of the second preceding node adjacent to any node icon does not match the type of the first preceding node, or the type of the second following node does not match the type of the first following node, it is determined that the node connection order does not conform to the preset standard processing flow. When the type of the second preceding node of all adjacent node icons matches the type of the first preceding node, and the type of the second following node matches the type of the first following node, the node connection order is determined to conform to the preset standard processing flow.

4. The low-code IoT network configuration method according to claim 1, characterized in that, The step of converting the original data packet into a decimal value in the decoding node includes: Based on the protocol type, a preset decoding rule template is invoked; Extract the data payload from the original data packet; Obtain the starting byte position and truncation length configured in the decoding rule template; Based on the starting byte position and the truncation length, extract the target data segment from the data payload; The target data fragment is converted into a decimal value according to the data format configured in the decoding rule template. The data format includes any one of signed integer data, unsigned integer data, floating-point data, and string data.

5. The low-code IoT network configuration method according to claim 1, characterized in that, The process of mapping the decimal value to the target field based on the standard data model includes: Based on the field mapping relationship in the standard data model and the decimal value, determine the field type and value range corresponding to the target field; The decimal value is converted according to the field type, and the converted value is verified to be within the range of values. When the converted value is within the range of values, the converted value is used as the target field; When the converted value is outside the range of values, a value exceeding the limit prompt message is displayed in the graphical configuration interface.

6. The low-code IoT network configuration method according to claim 1, characterized in that, After sending the communication message to the corresponding IoT device through the southbound sending node, the process further includes: Monitor the sending status of the communication message. If the communication message fails to be sent, generate a feedback path in the graphical configuration interface. The feedback path includes a southbound receiving feedback node, a feedback analysis node, and a northbound feedback node connected in sequence. The reason for message transmission failure is identified in the feedback analysis node; Based on the stated reasons, corresponding status feedback information is generated in the feedback analysis node, and the status feedback information is sent to the IoT platform through the northbound feedback node. The feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and the display format of the connecting lines in the feedback path is different from that of the connecting lines in the instruction processing flow.

7. The low-code IoT network configuration method according to claim 6, characterized in that, The reasons include at least one of network failure, device offline, and protocol incompatibility. Based on the reasons, generating corresponding status feedback information in the feedback analysis node includes: In the feedback analysis node, the reasons for each communication message transmission failure and the number of transmission failures are counted, and the number of network failures, device offlines, and protocol mismatches are accumulated according to the type of the reasons. The network failure probability is obtained by calculating the proportion of the number of network failures in the number of transmission failures; the device offline probability is obtained by calculating the proportion of the number of device offlines in the number of transmission failures; and the protocol mismatch probability is obtained by calculating the proportion of the number of protocol mismatches in the number of transmission failures. Based on the relationship between the network failure probability, the device offline probability, and the protocol mismatch probability, the corresponding display level of status feedback information is determined, and the network link status information, device status information, and protocol status information are displayed in the graphical configuration interface in the order from top to bottom according to the display level.

8. A low-code Internet of Things (IoT) network configuration system, characterized in that, The system is applied to electronic devices and includes: The data acquisition module is used to receive raw data packets sent by IoT devices and determine the protocol type corresponding to the raw data packets based on the protocol identifier of the raw data packets; The process construction module is used to construct a data processing process when dragging behavior is detected in the graphical configuration interface. The data processing process includes a first start node, a southward receiving node, a decoding node, a mapping node, and a northward reporting node connected in sequence. The data conversion module is used to transmit the original data packet to the southbound receiving node through the first starting node, and convert the original data packet into a decimal value in the decoding node; The data conversion module is also used in the mapping node to retrieve a standard data model from the IoT platform based on the protocol type, map the decimal value to a target field based on the standard data model, and send the target field to the IoT platform through the northbound reporting node. The process construction module is also used to receive control instructions generated based on the target field issued by the IoT platform, and to construct an instruction processing flow in the graphical configuration interface. The instruction processing flow includes a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence. The data conversion module is also used to parse the control command into a control type identifier and control parameters in the northbound command node through the second start node; The data application module is used to generate a communication message by using the control type identifier and control parameters through the function node, and to send the communication message to the IoT device through the southbound sending node.

9. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a processor, perform the method as described in any one of claims 1-7.

Images