Low-code Internet of Things configuration method and system, electronic equipment and storage medium

Abstract

The invention discloses a low-code Internet of Things 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 steps of receiving an original data packet, and determining a protocol type corresponding to the original data packet; constructing a data processing flow in the graphical configuration interface; transmitting the original data packet into a southbound receiving node, and converting the original data packet into a decimal numerical value; calling a standard data model, mapping the decimal numerical value into 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; analyzing the control instruction into a control type identifier and a control parameter in a northbound command node through a second starting node; and generating a communication message from the control type identifier and the control parameter through the function node, and sending the communication message to the Internet of Things equipment. By adopting the scheme, the workload of configuration and maintenance of the data processing flow can be reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things engineering, and in particular to a low-code Internet of Things network configuration method and system, an electronic device and a storage medium. BACKGROUND

[0002] With the development of Internet of Things technology, a device access platform needs to complete a series of processing procedures such as data reception, protocol analysis, data conversion and instruction issuing. In order to standardize these processing procedures, the industry usually adopts the way of connecting data processing nodes in series to construct a data flow transfer link.

[0003] The mainstream Internet of Things platform currently adopts a fixed data processing flow, and processes the data reported by the device through the connection of a receiving node, a protocol analysis node and a data conversion node. When issuing instructions to the device, it is completed through a command analysis node and a protocol encapsulation node. Developers need to write specific program codes in each processing node to realize the data processing logic, such as writing analysis codes in the protocol analysis node and writing conversion rules in the data conversion node.

[0004] However, this preset fixed processing flow lacks flexibility, and each processing node needs to be specially programmed by a developer according to the specific protocol and data format. When the data processing flow needs to be adjusted or a processing node needs to be added, not only the connection relationship between the nodes needs to be modified, but also the processing code of each node needs to be redeveloped and debugged, which greatly increases the workload of configuring and maintaining the data processing flow. SUMMARY

[0005] The present application provides a low-code Internet of Things network configuration method and system, an electronic device and a storage medium, which can reduce the workload of configuring and maintaining the data processing flow.

[0006] In a first aspect of the present application, a low-code Internet of Things network configuration method is provided, which specifically comprises: receiving an original data packet sent by an Internet of Things device, and determining a protocol type corresponding to the original data packet based on a protocol identifier of the original data packet; In a graphical configuration interface, when a drag behavior is detected, a data processing flow is constructed, the data processing flow comprising a first start node, a southbound receiving node, a decoding node, a mapping node and a northbound reporting node connected in sequence; passing the original data packet into the southbound receiving node through the first start node, and converting the original data packet into a decimal value in the decoding node; In the mapping node, a standard data model is invoked in the Internet of Things platform based on the protocol type, and the decimal number is mapped into a target field based on the standard data model, and the target field is sent to the Internet of Things platform through the northward reporting node; Receiving the control instruction generated based on the target field issued by the Internet of Things platform, and constructing an instruction processing flow in the graphical configuration interface, the instruction processing flow comprising a second start node, a northward command node, a function node and a southward sending node connected in sequence; The control instruction is parsed into a control type identifier and a control parameter in the northward command node through the second start node; The control type identifier and the control parameter are used to generate a communication message through the function node, and the communication message is sent to the Internet of Things device through the southward sending node.

[0007] By adopting the above technical solution, the visual construction of data processing flow is realized through the provision of a graphical configuration interface, and the developer can complete the serial configuration of data processing nodes through simple drag-and-drop operations without the need to write specific program codes for each processing node. By uniformly converting the original data packet into a decimal number in the decoding node and automatically invoking the standard data model based on the protocol type in the mapping node to complete data mapping, the development difficulty of accessing different protocol type devices is reduced. At the same time, the present scheme also supports the construction of a bidirectional data processing flow, which can not only process the data reported by the device, but also process the control instruction issued by the platform, generate a communication message through the function node and issue it to the device, thereby improving the data processing capability of the Internet of Things platform. The present scheme adopts a low-code graphical configuration method, so that the developer can quickly construct and adjust the data processing flow, thereby greatly reducing the development cost and maintenance workload of the Internet of Things device access.

[0008] Optionally, in the graphical configuration interface, when a drag behavior is detected, a data processing flow is constructed, comprising: When a drag behavior of a node component in a component library area of the graphical configuration interface is detected and dragged to a flow configuration area, a node icon corresponding to the node component is displayed in the flow configuration area; When a connection operation between adjacent node icons in the flow configuration area is detected, a data flow transfer relationship is established between the adjacent node icons, and a 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 a preset standard processing flow, the standard processing flow comprising: a first start node connected to a southward receiving node, a southward receiving node connected to a decoding node, a decoding node connected to a mapping node, and a mapping node connected to a northward reporting node; when the node connection order conforms to the preset standard processing flow, taking the preset standard processing flow as a data processing flow, and displaying the connection line as a first preset color in the graphical configuration interface; when the node connection order does not conform to the preset standard processing flow, displaying an error prompt information in the graphical configuration interface, and displaying the connection line as a second preset color.

[0009] By adopting the above technical solutions, the component library area and the flow configuration area are arranged in the graphical configuration interface, so that the developer can intuitively select the required node components by the drag-and-drop method and place them in the flow configuration area. The system automatically establishes the data flow relationship and displays it with a visual connection line by monitoring the connection operation between the node icons in real time, and intelligently checks the connection order of the nodes to ensure that it conforms to the preset standard processing flow. When the connection order is compliant, the system displays the connection line in a first preset color to indicate correctness; when it is found that it does not conform to the standard processing flow, the system timely feeds back the problem to the developer through the connection line in a second preset color and an error prompt information, effectively avoiding data processing abnormalities caused by incorrect node connection order. This visual configuration method combined with the intelligent checking mechanism not only simplifies the operation of the developer to build the data processing flow, but also effectively prevents the occurrence of incorrect configuration, further improving the configuration efficiency of the Internet of Things platform and the reliability of data processing.

[0010] Optionally, the verification of whether the node connection order between the adjacent node icons conforms to the preset standard processing flow comprises: obtaining node connection rules defined in the preset standard processing flow, the node connection rules including the pre-node types and post-node types of each node; traversing all node icons in the flow configuration area to obtain the node types of each node icon; obtaining, from the node connection rules, the first pre-node type and the first post-node type allowed to be connected by each node icon corresponding to the node type; verifying whether the second pre-node type adjacent to each node icon conforms to the first pre-node type, and whether the second post-node type conforms to the first post-node type; when the second pre-node type adjacent to any node icon does not conform to the first pre-node type, or the second post-node type does not conform to the first post-node type, it is determined that the node connection order does not conform to the preset standard processing flow; When the second preceding node type of all node icons adjacent to the node icon is consistent with the first preceding node type, and the second following node type is consistent with the first following node type, it is determined that the node connection order is consistent with a preset standard processing flow.

[0011] By adopting the technical solution, the standard node connection rule library is formed by defining the preceding and following node types allowed to be connected for each node type in advance. When the developer performs node connection configuration, the system automatically traverses all node icons in the flow configuration area, and performs bidirectional matching verification on the actual connection relationship of each node and the preset rule. By strictly checking the preceding type and the following type of the node, it is ensured that each node in the data processing flow forms a reasonable data flow relationship with its adjacent nodes. The fine-grained connection rule verification mechanism can not only timely find the incorrect configuration of the node connection order, but also accurately locate the specific error position, helping the developer to quickly identify and correct the configuration problem, thereby ensuring the correctness of the data processing flow and the reliability of the data flow, and improving the configuration accuracy and the running stability of the Internet of Things platform.

[0012] Optionally, the converting the original data packet into a decimal value in the decoding node comprises: based on the protocol type, calling a preset decoding rule template; extracting data payload from the original data packet; obtaining a start byte position and an interception length configured in the decoding rule template; according to the start byte position and the interception length, intercepting a target data segment from the data payload; converting the target data segment into a decimal value according to a data format configured in the decoding rule template, the data format comprising any one of signed integer data, unsigned integer data, floating point data, and string data.

[0013] By adopting the technical solution, the standardization and templating of the data analysis process are realized by preconfiguring the decoding rule templates corresponding to different protocol types. In the decoding process, the system can automatically call the corresponding decoding rule template according to the protocol type, and accurately extract the target data segment in the data payload according to the start byte position and the interception length defined in the template. By presetting 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 of different protocol type devices. The templated decoding scheme not only reduces the development difficulty of protocol analysis, but also improves the accuracy and efficiency of data analysis, so that the Internet of Things platform can more flexibly process various types of device data, and provides a unified data basis for subsequent data processing and analysis.

[0014] Optionally, the mapping the decimal numerical value to a target field based on the standard data model comprises: determining a field type and a value range corresponding to the target field based on a field mapping relationship in the standard data model and the decimal numerical value; format-converting the decimal numerical value according to the field type and verifying whether the converted numerical value is within the value range; when the converted numerical value is within the value range, taking the converted numerical value as the target field; when the converted numerical value is not within the value range, displaying out-of-range value prompt information in the graphical configuration interface.

[0015] By using the above technical solution, the intelligent conversion of device data to platform standard fields is realized through the field mapping relationship predefined in the standard data model. The system can not only automatically perform data format conversion according to the type of the target field, but also perform value range verification on the converted numerical value, ensuring that the data conforms to the standard specification defined by the platform. When it is found that the data is out of the preset value range, the system will feed back the out-of-range value information to the developer in a timely manner through the graphical interface, effectively preventing abnormal data from entering the Internet of Things platform. This mapping mechanism with data verification function not only ensures the standardization of data format, but also ensures the rationality of data value, improves the accuracy and reliability of Internet of Things platform data processing, and provides high-quality standardized data support for upper-layer applications.

[0016] Optionally, the sending of the communication message to the corresponding Internet of Things device through the southbound sending node further comprises: monitoring the sending state of the communication message, and if the communication message fails to be sent, generating a feedback path in the graphical configuration interface, the feedback path comprising a southbound receiving feedback node, a feedback analysis node and a northbound feedback node connected in sequence; identifying the reason for the failure of the message sending in the feedback analysis node; generating corresponding state feedback information in the feedback analysis node according to the reason, and sending the state feedback information to the Internet of Things platform through the northbound feedback node; wherein the feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and the display format of the connection line in the feedback path is different from that of the connection line in the instruction processing flow.

[0017] By adopting the technical scheme, the sending state of the communication message is monitored in real time, and the feedback path is automatically generated for failure analysis and state feedback when sending fails. The system can identify the specific reason for the failure of sending the message in the feedback analysis node, and generate corresponding state feedback information and report it to the Internet of Things platform in real time, so that the platform can timely master the device instruction execution situation. By displaying the instruction processing flow and the feedback path in different display formats in the graphical configuration interface in parallel, the system realizes visual monitoring of instruction issuing and state feedback, which facilitates developers to intuitively identify and locate communication failures. This two-way instruction processing mechanism not only improves the reliability of the Internet of Things platform for device control instructions, but also enhances the fault diagnosis and problem tracing capabilities of the platform, providing strong support for remote control and operation and maintenance management of Internet of Things devices.

[0018] Optionally, the reason includes at least one of network failure, device offline, and protocol mismatch, and the generating of the corresponding state feedback information in the feedback analysis node according to the reason includes: counting the reasons for the failure of sending each communication message and the number of sending failures in the feedback analysis node, and accumulating the number of network failures, the number of device offline, and the number of protocol mismatches according to the types of the reasons; calculating the network failure probability by calculating the proportion of the number of network failures in the number of sending failures, calculating the device offline probability by calculating the proportion of the number of device offline in the number of sending failures, and calculating the protocol mismatch probability by calculating the proportion of the number of protocol mismatches in the number of sending failures; determining the display level of the corresponding state feedback information according to the size relationship of the network failure probability, the device offline probability, and the protocol mismatch probability, and displaying the network link state information, the device state information, and the protocol state information in the graphical configuration interface in the order from top to bottom according to the display level.

[0019] By adopting the technical scheme, the sending state of the communication message is monitored in real time, and the feedback path is automatically generated for failure analysis and state feedback when sending fails. The system can identify the specific reason for the failure of sending the message in the feedback analysis node, and generate corresponding state feedback information and report it to the Internet of Things platform in real time, so that the platform can timely master the device instruction execution situation. By displaying the instruction processing flow and the feedback path in different display formats in the graphical configuration interface in parallel, the system realizes visual monitoring of instruction issuing and state feedback, which facilitates developers to intuitively identify and locate communication failures. This two-way instruction processing mechanism not only improves the reliability of the Internet of Things platform for device control instructions, but also enhances the fault diagnosis and problem tracing capabilities of the platform, providing strong support for remote control and operation and maintenance management of Internet of Things devices.

[0020] In a second aspect of the application, a low-code IoT network configuration system is provided, specifically comprising: A data acquisition module is configured to receive an original data packet sent by an IoT device and determine a protocol type corresponding to the original data packet based on a protocol identifier of the original data packet. A flow construction module is configured to construct a data processing flow in a graphical configuration interface when a drag operation is detected, the data processing flow comprising a first start node, a southbound receiving node, a decoding node, a mapping node, and a northbound reporting node connected in sequence. A data conversion module is configured to pass the original data packet into the southbound receiving node through the first start node and convert the original data packet into a decimal value in the decoding node. The data conversion module is further configured to call a standard data model in an IoT platform based on the protocol type in the mapping node, 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 flow construction module is further configured to receive a control instruction generated based on the target field and issued by the IoT platform, and construct an instruction processing flow in the graphical configuration interface, the instruction processing flow comprising a second start node, a northbound command node, a function node, and a southbound sending node connected in sequence. The data conversion module is further configured to parse the control instruction into a control type identifier and a control parameter in the northbound command node through the second start node. A data application module is configured to generate a communication message through the function node based on the control type identifier and the control parameter, and send the communication message to the IoT device through the southbound sending node.

[0021] By adopting the above technical solution, the visual construction of the data processing flow is realized through the provision of the graphical configuration interface. The developer can complete the serial configuration of the data processing nodes through a simple drag operation without the need to write specific program codes for each processing node. By uniformly converting the original data packet into a decimal value in the decoding node and automatically calling a standard data model based on the protocol type in the mapping node to complete data mapping, the development difficulty when different protocol type devices are accessed is reduced. Meanwhile, the present scheme also supports the construction of a bidirectional data processing flow, which can not only process the data reported by the device but also process the control instruction issued by the platform. The function node is used to automatically generate a communication message and issue it to the device, thereby improving the data processing capability of the IoT platform. The present scheme adopts a low-code graphical configuration mode, which enables the developer to quickly construct and adjust the data processing flow, thereby greatly reducing the development cost and maintenance workload of the IoT device access.

[0022] In a third aspect of the present application, an electronic device is provided, comprising a processor, a memory, a user interface and a network interface, the memory is configured to store instructions, the user interface and the network interface are configured to communicate with other devices, and the processor is configured to execute the instructions stored in the memory to enable the electronic device to perform the method according to any one of the preceding aspects.

[0023] In a fourth aspect of the present application, a computer readable storage medium is provided, which stores instructions, when the instructions are executed, the method according to any one of the preceding aspects is performed. BRIEF DESCRIPTION OF DRAWINGS

[0024] Figure 1 is a low-code IoT network configuration system architecture schematic diagram provided by an embodiment of the present application; Figure 2 is a low-code IoT network configuration method flow schematic diagram provided by an embodiment of the present application; Figure 3 is a node selection schematic diagram provided by an embodiment of the present application; Figure 4 is a data processing flow schematic diagram provided by an embodiment of the present application; Figure 5 is a low-code IoT network configuration system structure schematic diagram provided by an embodiment of the present application; Figure 6 is a structure schematic diagram of an electronic device disclosed by an embodiment of the present application.

[0025] Explanation of reference numerals: 901, processor; 902, communication bus; 903, user interface; 904, network interface; 905, memory. DETAILED DESCRIPTION

[0026] In order to enable a person skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments.

[0027] In the description of the embodiments of the present application, the words such as “for example” or “for instance” are used to represent an example, illustration or description. Any embodiment or design scheme described as “for example” or “for instance” in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as “for example” or “for instance” are intended to present the relevant concept in a specific manner.

[0028] In the description of the embodiments of the present application, the term "a plurality of" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms "first", "second", etc. are used only for the purpose of description and should not be understood as indicating or implying relative importance or implying the indicated technical features. Therefore, the features defined with "first", "second", etc. can be explicitly or implicitly included one or more of the features. The terms "include", "contain", "have" and their variants mean "include but not limited to", unless otherwise specifically emphasized.

[0029] Figure 1 A low-code IoT network configuration system architecture is shown.

[0030] As shown in Figure 1 , the system architecture can include an IoT device 011, a network 012, and an electronic device 013. The network 012 is used to provide a data transmission link between the IoT device 011 and the electronic device 013. The network 012 can include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0031] The IoT device 011 can perform bidirectional data interaction with the electronic device 013 through the network 012. The IoT device 011 is mainly responsible for collecting and reporting raw data packets, and receiving and executing control instructions issued by the platform. The IoT device 011 is hardware, which can be an intelligent terminal device with data collection and communication functions, supporting multiple communication protocol types.

[0032] The electronic device 013 provides a graphical configuration interface, which supports developers to build data processing flow and instruction processing flow through drag-and-drop method. The platform is responsible for decoding conversion and field mapping of raw data packets reported by the device, and processing analysis and issuance of control instructions. The electronic device 013 can realize standardized processing and bidirectional conversion of data based on the preset decoding rule template and standard data model, and finally complete the access and control of device data. These configurations and processing results can be used for subsequent device management and business applications.

[0033] It should be noted that the electronic device can be hardware or software. When the electronic device is hardware, it can be implemented as a distributed platform cluster composed of multiple servers, or as a single server. When the electronic device is software, it can be implemented as multiple software or software modules (for example, multiple software or software modules used to provide distributed services), or as a single software or software module. Herein, no specific limitation is made.

[0034] It should be understood that Figure 1The number of the Internet of Things device 011, the network 012 and the electronic device 013 in the figure is only illustrative. According to the implementation needs, it can be any number of Internet of Things devices 011, networks 012 and electronic devices 013. In particular, in the development debugging stage, the above system architecture can not include the network 012, but only include the Internet of Things device 011 or the electronic device 013.

[0035] Next, taking the electronic device side as an example, a low-code Internet of Things network configuration method provided by the application is described.

[0036] The application provides a low-code Internet of Things network configuration method, which refers to Figure 2 , Figure 2 is a flowchart of a low-code Internet of Things network configuration method provided by an embodiment of the application, including steps S101 to S107, which are as follows: S101: receiving an original data packet sent by an Internet of Things device, and determining a protocol type corresponding to the original data packet based on a protocol identifier of the original data packet.

[0037] In the embodiment of the application, the original data packet represents a binary data stream generated by the Internet of Things device based on a built-in communication protocol, including a protocol header, a protocol identifier, a data payload and a check code, etc. The protocol identifier is a specific field used to identify the protocol type adopted by the data packet, which can be a protocol name, a version number or a unique identifier; the protocol type is a communication specification adopted by the Internet of Things device for data transmission, including standard protocols such as Modbus, MQTT, TCP or private protocols.

[0038] Specifically, first, the original data packet from the Internet of Things device is received through the network interface, and then the protocol header part is read from the original data packet to obtain the protocol identifier. Then, a pre-configured protocol mapping table is queried, which stores the correspondence between the protocol identifier and the protocol type. By matching the parsed protocol identifier with the records in the protocol mapping table, the protocol type corresponding to the original data packet is determined.

[0039] S102: in the graphical configuration interface, when a drag behavior is detected, a data processing flow is constructed, which includes a first start node, a southbound receiving node, a decoding node, a mapping node and a northbound reporting node connected in sequence.

[0040] In the embodiment of the application, the graphical configuration interface refers to a human-computer interaction interface for realizing visual configuration of the Internet of Things device data processing flow, including a component library area and a flow configuration area, wherein the component library area is used to display various types of node components that can be selected, and the flow configuration area is used to construct a specific data processing flow by dragging.

[0041] Specifically, referring to Figure 3 , Figure 3 is a schematic diagram of node selection provided by an embodiment of the present application, in combination with Figure 3 It can be known that a plurality of types of node components are preset in the component library area, including a first start node, a southbound receiving node, a decoding node, a mapping node, and a northbound reporting node. When it is monitored that a developer drags a node component from the component library area to the flow configuration area, a node icon corresponding to the node component is displayed at a target position of the drag release. Subsequently, a connection operation in the flow configuration area is monitored, and when it is detected that a connection is made between adjacent node icons, a data flow conversion relationship between the nodes is automatically established, and is visually displayed in the form of a connection line in the interface. The system will verify in real time whether the connection order of the nodes conforms to a 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 the nodes are connected in the standard order, the construction of the data processing flow is completed.

[0042] On the basis of the above embodiment, as an optional embodiment, referring to Figure 4 , Figure 4 is a schematic diagram of a data processing flow provided by an embodiment of the present application, S102: when a drag behavior is detected in the graphical configuration interface, the step of constructing a data processing flow can specifically include the following steps: S201: when it is monitored that a node component in the component library area of the graphical configuration interface is dragged to the flow configuration area, a node icon corresponding to the node component is displayed in the flow configuration area.

[0043] Specifically, first, a plurality of types of node components are preset in the component library area, including a data acquisition node, a protocol analysis node, a data conversion node, and the like. The system continuously monitors the selected state of the node components in the component library area, and when it is detected that a node component is selected, the type information and style information of the node component are recorded. In the process of dragging, the moving track of the pointer device is calculated in real time, and a semi-transparent node preview icon is displayed at the position of the pointer. When the flow configuration area is dragged to, it is judged whether the release position is in a valid placement area. If the release position is valid, a node icon instance corresponding to the type of the selected node component is created at the release position, and the preset style information is applied; if the release position is invalid, the current drag operation is cancelled. Finally, the created node icon is displayed in the flow configuration area, and the configuration interface of the node component is activated, waiting for subsequent parameter setting and connection operation.

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

[0045] Specifically, first, the port state of the node icon in the process configuration area is monitored. When it is detected that 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 pointing device is tracked in real time, and a dynamic guide line is drawn from the output port of the source node to the current pointing position. At the same time, the distance between the pointing position and the input ports of other target nodes is calculated, and when the distance is less than a preset threshold, the nearest input port is automatically adsorbed. When it is detected that the input port of the target node is released, the node types of the source node and the target node are obtained, and a preset node connection rule library is queried. The node connection rule library defines the pre-node types and post-node types allowed to be connected for each node type. By comparing whether the source node belongs to the pre-node types allowed by the target node and whether the target node belongs to the post-node types allowed by the source node, the legality of the connection is verified. If the verification is passed, a data flow transfer relationship is established between the source node and the target node, and a connection line with a preset style is drawn in the graphical configuration interface; if the verification fails, the connection operation is cancelled, and an error prompt information is given.

[0046] S203: Verify whether the node connection order between adjacent node icons meets a preset standard processing flow, and the standard processing flow includes: a first start node connects a southward receiving node, the southward receiving node connects a decoding node, the decoding node connects a mapping node, and the mapping node connects a northward reporting node.

[0047] Specifically, first, a preset standard processing flow is loaded from a configuration database, and node connection rules contained in the standard processing flow are obtained, the node connection rules stipulate that a first start node can only be connected to a southbound receiving node, a front node of the southbound receiving node must be the first start node and a back node must be a decoding node, a front node of the decoding node must be the southbound receiving node and a back node must be a mapping node, a front node of the mapping node must be the decoding node and a back node must be a northbound reporting node, and a front node of the northbound reporting node must be the mapping node. Then all node icons in the flow configuration area are traversed, and node type information of each node icon is extracted. For each node icon, the first front node type and the first back node type allowed to be connected are queried from the node connection rules. Then the types of the front node and the back node actually connected to the node, i.e., the second front node type and the second back node type, are obtained. By comparing whether the second front node type matches the first front node type allowed by the rules and whether the second back node type matches the first back node type allowed by the rules, the compliance of the node connection is verified. If it is found that the actual connection of any node does not match the rules, it is determined that the node connection order of the entire flow does not comply with the standard processing flow. Only when the connections of all nodes comply with the rule requirements, it can be confirmed that the node connection order complies with the preset standard processing flow.

[0048] On the basis of the above embodiment, as an optional embodiment, S203: verifying whether the node connection order between adjacent node icons complies with the preset standard processing flow, can specifically include the following steps: S301: obtaining node connection rules defined in the preset standard processing flow, the node connection rules including front node types and back node types of nodes.

[0049] Specifically, first, a configuration file of the standard processing flow is read from a system configuration database, and the configuration file is stored in a structured data format, such as a JSON or XML format. Then, connection constraint information of each node type is extracted through the node connection rules in the configuration file. For each node type, a list of front node types allowed to be connected to the node type and a list of back node types are obtained.

[0050] S302: traversing all node icons in the flow configuration area to obtain node types of the node icons.

[0051] Specifically, first, a canvas object of the flow configuration area is obtained, and all node icons currently configured are obtained from the canvas object. According to the position order of the node icons in the canvas object, each node icon is accessed in turn. For each node icon, a type identification field in node icon attribute information is read to obtain node types of the node icons.

[0052] S303: Obtain the first preceding node type and the first succeeding node type allowed to be connected by the node type corresponding to each node icon from the node connection rule.

[0053] Specifically, first, according to 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 rule is queried based on the node type. The first preceding node type list allowed to be connected by the node type is extracted from the connection constraint configuration, and the first preceding node type list defines all node types that can be the input source of the current node icon. At the same time, the first succeeding node type list allowed to be connected is extracted, and the first succeeding node type list defines all node types that can receive the output of the current node icon.

[0054] S304: Verify whether the second preceding node type adjacent to each node icon conforms to the first preceding node type, and whether the second succeeding node type conforms to the first succeeding node type.

[0055] Specifically, first, each node icon in the flow configuration area is traversed, and its adjacent nodes are obtained through the connection line information. For each node icon, the upstream node connected through the input connection line is obtained, and the type of the node is the second preceding node type; the downstream node connected through the output connection line is obtained, and the type of the node is the second succeeding node type. Then, the first preceding node type and the first succeeding node type allowed to be connected by the node obtained in step S303 are read. The second preceding node type is compared with the first preceding node type, and it is checked whether the type of the actually connected upstream node is allowed to be connected. Similarly, the second succeeding node type is compared with the first succeeding node type, and it is checked whether the type of the actually connected downstream node is allowed to be connected.

[0056] S305: When the second preceding node type adjacent to any node icon does not conform to the first preceding node type, or the second succeeding node type does not conform to the first succeeding node type, it is determined that the node connection order does not conform to the preset standard processing flow.

[0057] Specifically, first check all the node verification results obtained in step S304. Traverse each record in the verification result set, and for each node icon, determine the matching of the second preceding node type and the first preceding node type, and the matching of the second succeeding node type and the first succeeding node type. When any of the following conditions is found, it is determined that the standard processing procedure is not met: the second preceding node type is not within the allowed range of the first preceding node type, or the second succeeding node type is not within the allowed range of the first succeeding node type. Once any non-compliant connection is found, the verification process is terminated immediately, the verification status is marked as failed, and the specific node location causing the failure and the reason for non-compliance are recorded for subsequent error prompting and processing.

[0058] S306: When the second preceding node type adjacent to all node icons meets the first preceding node type, and the second succeeding node type meets the first succeeding node type, it is determined that the node connection order meets the preset standard processing procedure.

[0059] Specifically, first check all the node verification results obtained in step S304. Traverse 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 second preceding node type of each node completely matches the requirements of the first preceding node type. At the same time, check whether the second succeeding node type of each node completely matches the requirements of the first succeeding node type. After completing the verification of all nodes, if no non-compliant connection is found, the verification status is marked as passed, indicating that the node connection order of the entire data processing procedure meets the preset standard processing procedure.

[0060] S204: When the node connection order meets the preset standard processing procedure, the preset standard processing procedure is used as the data processing procedure, and the connection line is displayed as the first preset color in the graphical configuration interface.

[0061] Specifically, first determine the verification result of the node connection order, and when the verification is passed, determine the currently configured node connection relationship as an effective data processing procedure. In the data structure of the data processing procedure, record the data flow relationship between nodes, including the complete processing link from the first starting node to the northward reporting node. Then update the display style of the connection line in the graphical configuration interface, and uniformly modify the color of the connection line between all nodes to the first preset color.

[0062] S205: When the node connection order does not meet the preset standard processing procedure, display error prompt information in the graphical configuration interface, and display the connection line as the second preset color.

[0063] Specifically, first, the verification result of the node connection sequence is analyzed to obtain the specific reason for the verification failure and the related node information. The content of the error prompt information generated according to the verification result includes the node position that does not conform to the rule, the current error connection relationship, the expected correct connection relationship and the like. Then, the error prompt information is displayed at a suitable position in the graphical configuration interface, which can be in various display forms such as a pop-up window prompt, a floating prompt or an embedded prompt. At the same time, the display color of all connection lines that do not conform to the rule is updated to a second preset color, including modifying the style attribute of the connection line, setting the color value of the warning and highlighting the connection position that needs to be corrected.

[0064] S103: The original data packet is transmitted into the southbound receiving node through the first start node, and the original data packet is converted into a decimal value in the decoding node.

[0065] Specifically, first, the original data packet received is transmitted into the southbound receiving node through the first start node for preprocessing. Then, based on the protocol type determined in step S101, a corresponding decoding rule template is called from the template library. Next, the data payload part is parsed from the original data packet, excluding the protocol header, check code and other non-data fields. The data starting point 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 length. For the extracted target data segment, the data format type configured in the decoding rule template is read, which can be signed integer data (such as int16, int32), unsigned integer data (such as uint16, uint32), floating point data (such as float32, float64) or string data. According to the data format type, a corresponding decoding algorithm is selected to convert the binary data into a decimal value.

[0066] On the basis of the above embodiment, as an optional embodiment, S103: the step of converting the original data packet into a decimal value in the decoding node can specifically include the following steps: S401: Based on the protocol type, a preset decoding rule template is called.

[0067] Specifically, first, all preset decoding rule template sets are obtained from the configuration database, and each template contains protocol identification, decoding parameters and data format definition and the like. Then, according to the protocol type determined in step S101, a matching decoding rule template is searched for in the template set. The searching process compares the protocol identification, version number and the like, to ensure that the selected template completely matches the protocol of the current data packet.

[0068] S402: The data payload is extracted from the original data packet.

[0069] In the embodiments of the present application, the data payload refers to the actual service data part carried in the original data packet, excluding the protocol header, protocol identifier, check code and other protocol related fields, and is used to store specific data content to be transmitted.

[0070] Specifically, according to the decoding rule template called in step S401, the data packet structure definition is obtained, including the protocol header length, payload start position, payload length identifier and the like. Then the actual start position of the data payload is obtained by skipping the protocol header and protocol identifier and the like. Then the original data packet is intercepted through the start position and the preset payload length, and in the interception process, the byte sequence starting from the start position and having the length of the payload length in the original data packet is copied to a new data payload buffer by using the byte array copy operation, so as to obtain the data payload.

[0071] S403: Obtain the start byte position and the interception length configured in the decoding rule template.

[0072] Specifically, first, the data positioning parameter part in the decoding rule template obtained in step S401 is read, and the data positioning parameter part contains the configuration items of the position information and length information of the target data. Then the start byte position is obtained from the position information, and then the interception length is obtained from the length information.

[0073] S404: Intercept the target data segment from the data payload according to the start byte position and the interception length.

[0074] Specifically, the start byte position in the data payload is located as the starting point of data extraction. A new byte array is created as the storage space of the target data segment, and the size of the byte array is the interception length. The byte sequence starting from the start position and having the length of the interception length in the data payload is copied to the newly created storage space by using the byte array copy operation, so as to obtain the target data segment.

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

[0076] Specifically, first, the data format configuration information is read from the decoding rule template to determine the specific data type of the target data segment. Then, according to different data format types, corresponding conversion algorithms are selected: for signed integer data, the processing of the sign bit needs to be considered to convert the two's complement representation 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 IEEE754 standard to restore it to a decimal floating-point number; for string type data, the byte sequence needs to be converted into a readable string according to the specified character encoding (such as ASCII, UTF-8, etc.).

[0077] S104: In the mapping node, the standard data model is invoked in the Internet of Things platform based on the protocol type, and the decimal value is mapped to the target field based on the standard data model, and the target field is sent to the Internet of Things platform through the northward reporting node.

[0078] In the embodiments of the present application, the standard data model refers to the device data structure specification predefined by the Internet of Things platform, which contains field definition, data type, value range and other configuration information of device attributes, events, services and other data, and is used to standardize the format and content of device reported data. The Internet of Things platform refers to a cloud service system for managing and connecting Internet of Things devices, which contains device management, data processing, protocol adaptation and other functional modules, and is used to realize unified access, storage and processing of device data.

[0079] Specifically, first, based on the protocol type determined in step S101, the standard data model configuration of the corresponding device is obtained from the Internet of Things platform. Then, the field mapping relationship in the standard data model is parsed to determine which target field the decoded decimal value should be mapped to, and the type and valid value range of the target field are obtained. Next, the decimal value is converted according to the type of the target field, such as converting integer to floating-point, adjusting precision bits, converting units, etc. The converted value is verified in range to determine whether it is 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 to construct a data structure conforming to the standard data model format. If it is found that the value is out of range, a value out of range prompt information is displayed in the graphical configuration interface, prompting the specific out of range reason and the allowed value range. Finally, the processed target field data is sent to the Internet of Things platform through the northward reporting node to complete the standardization of the data reporting process.

[0080] On the basis of the above embodiments, as an optional embodiment, S104: based on the standard data model, the decimal value is mapped to the target field, which can specifically include the following steps: S501: Determine the field type and value range corresponding to the target field based on the field mapping relationship in the standard data model and the decimal numerical value.

[0081] In the embodiments of the present application, the field mapping relationship refers to the corresponding rules between the data fields defined in the standard data model and the device raw data, including field identification, data type, unit conversion, value limit, and other configuration information, which are used to guide the data conversion and verification process.

[0082] Specifically, first, the definition list of all field mapping relationships is obtained from the standard data model configuration, each mapping relationship contains field name, data type, unit of measurement, valid value range, and other attributes. Then, according to the decoded decimal numerical value, the matching target field configuration is found in the mapping relationship list. Then the field type is extracted from the matching mapping relationship, which can be integer, floating point, enumeration, and other types. At the same time, the value range configuration corresponding to the field type is obtained, including minimum value, maximum value, step value, and other constraint conditions.

[0083] S502: Format conversion is performed on the decimal numerical value according to the field type, and it is verified whether the converted numerical value is within the value range.

[0084] Specifically, first, according to the field type determined in step S501, select the corresponding conversion method. Different types of conversion processing methods include: adding decimal places when converting integer to floating point; rounding when converting floating point to integer; parsing the numerical string when converting character type to numerical type; and judging true or false value mapping relationship when converting boolean type. Then, according to the precision requirement in the field definition, the converted numerical value is adjusted in precision, such as retaining a specified number of decimal places, truncating excess decimal places, etc. If the field defines unit conversion requirements, unit conversion is required, such as millimeter to meter, kilogram to gram, etc. Then compare the converted numerical value with the value range defined by the field type, check whether it meets the minimum and maximum value limits, to verify whether the converted numerical value is within the value range.

[0085] S503: When the converted numerical value is within the value range, the converted numerical value is taken as the target field.

[0086] Specifically, first, check the format conversion result and range verification result in step S502 to confirm that the converted numerical value meets the value range requirements. Then create a new target field object, and fill the verified converted numerical value into the data content attribute of the target field object. At the same time, add necessary metadata information to the target field, including the timestamp of data generation, data quality identification, data source, and other attributes. Get the target field.

[0087] S504: When the converted numerical value is not in the value range, display a value out-of-range prompt information in the graphical configuration interface.

[0088] Specifically, first, the value out-of-range situation found in step S502 is obtained, including the specific numerical value and the corresponding field definition information. Then the content of the value out-of-range prompt information is constructed, which needs to include: the field name of the occurrence of out-of-range, the current value of the field, the minimum and maximum values allowed by the field, the out-of-range time and other information. Select a suitable prompt position in the graphical configuration interface, which can be a floating prompt box, a status bar prompt or an embedded prompt and other display forms. Display the constructed prompt information at the selected position, and use different prompt styles according to the severity level, such as yellow background for warning and red background for error.

[0089] S105: Receive the control instruction generated based on the target field issued by the Internet of Things platform, and build an instruction processing flow in the graphical configuration interface, the instruction processing flow including a second start node, a northbound command node, a function node and a southbound sending node connected in sequence.

[0090] Specifically, first, listen to the instruction issuing channel of the Internet of Things platform, and when receiving the control instruction generated based on the target field, create a new instruction processing flow in the graphical configuration interface. Then add a second start node as the starting point of the flow in the configuration interface, which is used to identify the starting position of instruction processing. Connect the northbound command node after the second start node, which is responsible for receiving and analyzing the control instruction issued by the platform, extracting instruction type, control parameter and other information. Then add a function node and connect it with the northbound command node, the function node performs data conversion, parameter verification, logic processing and other operations according to the instruction content, and converts the platform instruction into control data recognizable by the device. Finally, add a southbound sending node and connect it with the function node, the southbound sending node is responsible for encapsulating the processed control data into device protocol packets and sending them to the target device.

[0091] S106: Through the second start node, the control instruction is parsed into a control type identifier and a control parameter in the northbound command node.

[0092] Specifically, first, the second start node triggers the instruction parsing process, and the received control instruction is transmitted to the northbound command node. Then, the data structure of the instruction is parsed in the northbound command node, and the command identification field in the instruction is extracted. Then, by querying the preset control instruction mapping table, the extracted identification field is matched with the definition in the mapping table: if the identification field starts with "set", it is determined to be a setting type control instruction; if the identification field starts with "get", it is determined to be a query type control instruction; if the identification field starts with "config", it is determined to be a configuration type control instruction. The setting type control instruction, the query type control instruction, and the configuration type control instruction are used as control type identifiers. For different types of control instructions, their contained control parameters are extracted: for setting type instructions, the target value and unit information of the setting are extracted; for switch type instructions, the switch state value is extracted; for configuration type instructions, the configuration item and the configuration value are extracted.

[0093] S107: The control type identifier and the control parameter are used to generate a communication message through the function node, and the communication message is sent to the Internet of Things device through the southbound sending node.

[0094] Specifically, first, the control type identifier and the control parameter parsed in step S106 are received in the function node. Then, according to the communication protocol type of the device, a corresponding message construction template is selected. For different types of control instructions, the message structure is constructed according to the protocol specification: the control parameter of the setting type instruction needs to be converted into a data format recognizable by the device; the query type instruction needs to construct the message format of the query request; the configuration type instruction needs to organize the message content according to the data type of the configuration item. Then, necessary protocol fields are added to the communication message, including: adding a protocol header identifier, setting device address information, generating a sequence number, calculating a check code, etc. At the same time, the message length is padded or truncated to ensure that it meets the format requirements specified by the protocol. After construction is completed, the communication message is transmitted to the southbound sending node, which is responsible for establishing a communication connection with the Internet of Things device, which can be serial communication, network communication, etc. Finally, the communication message is sent to the Internet of Things device through the established communication connection.

[0095] Based on the above embodiment, as an optional embodiment, after step S107: the communication message is sent to the corresponding Internet of Things device through the southbound sending node, the following steps are further included: S601: Monitor the sending state of the communication message. If the communication message fails to be sent, a feedback path is generated in the graphical configuration interface, and the feedback path includes a southbound receiving feedback node, a feedback analysis node, and a northbound feedback node connected in sequence.

[0096] Specifically, first, the sending state of the communication message in step S107 is monitored in real time, including checking whether the sending process is timed out, whether a device response is received, whether the response content is correct, and the like. When it is detected that the communication message sending fails, 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, and the southbound receiving feedback node is responsible for receiving and recording specific information of communication failure, including failure time, failure reason, retry times, and the like. Next, a feedback analysis node is added and connected with the southbound receiving feedback node, and the feedback analysis node performs cause analysis according to the collected failure information, and judges specific fault types such as communication timeout, device offline, data error, and the like. Finally, a northbound feedback node is added and connected with the feedback analysis node, and the northbound feedback node is responsible for formatting and reporting the analysis result to the Internet of Things platform, so that the platform perceives the abnormal state of the device.

[0097] S602: Identifying the cause of message sending failure in the feedback analysis node.

[0098] Specifically, first, the sending state of the communication message in step S107 is monitored in real time, including checking whether the sending process is timed out, whether a device response is received, whether the response content is correct, and the like. When it is detected that the communication message sending fails, 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, and the southbound receiving feedback node is responsible for receiving and recording specific information of communication failure, including failure time, failure reason, retry times, and the like. Next, a feedback analysis node is added and connected with the southbound receiving feedback node, and the feedback analysis node performs cause analysis according to the collected failure information, and judges specific fault types such as communication timeout, device offline, data error, and the like. Finally, a northbound feedback node is added and connected with the feedback analysis node, and the northbound feedback node is responsible for formatting and reporting the analysis result to the Internet of Things platform, so that the platform perceives the abnormal state of the device.

[0099] S603: Generating corresponding state feedback information in the feedback analysis node according to the cause, and sending the state feedback information to the Internet of Things platform through the northbound feedback node.

[0100] Specifically, first, the failure causes identified in step S602 are statistically classified in the feedback analysis node. According to different failure cause types, the number of network failures (such as connection interruption, data loss), the number of device offline (such as timeout without response, device disconnection), and the number of protocol mismatches (such as check error, parsing failure) are respectively accumulated. Then, based on the accumulated number of failures, the probabilities of various failures are calculated: 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 by the total number of failures; and the protocol mismatch probability is obtained by dividing the number of protocol mismatches by the total number of failures. Then, the three failure probabilities are compared, and the failure type with the largest probability is set as the highest display level, the second is set as the middle level, and the smallest is set as the lowest level. According to the priority order of the display level, the state feedback information containing network link state information (such as "network connection is abnormal, please check network configuration"), device state information (such as "device is offline, please check device power supply"), and protocol state information (such as "protocol version mismatch, please update protocol configuration") is generated. Finally, the generated state feedback information is sent to the Internet of Things platform through the northbound feedback node.

[0101] On the basis of the above embodiment, as an optional embodiment, S603: generating corresponding state feedback information in the feedback analysis node according to the causes, can specifically include the following steps: S701: In the feedback analysis node, the reasons for the failure of each communication message sending and the number of sending failures are counted, and the number of network failures, the number of device offline, and the number of protocol mismatches are respectively accumulated according to the type of the reason.

[0102] Specifically, first, a failure statistical counter is created in the feedback analysis node, which is used to record the number of failures of three types of network failure, device offline, and protocol mismatch. Then, the sending failure record of each communication message is analyzed: when detecting communication link interruption, data packet loss, and other network-level failures, the network failure counter is incremented by 1; when finding device timeout without response, active disconnection, and other device state abnormalities, the device offline counter is incremented by 1; when data check failure, protocol version mismatch, and other protocol parsing errors occur, the protocol mismatch counter is incremented by 1.

[0103] S702: Calculate the network failure probability by calculating the proportion of the number of network failures in the number of sending failures, calculate the device offline probability by calculating the proportion of the number of device offline in the number of sending failures, and calculate the protocol mismatch probability by calculating the proportion of the number of protocol mismatches in the number of sending failures.

[0104] Specifically, first, the number of each type of failure and the total number of sending failures counted in step S701 are obtained. Then, the occurrence probabilities of the three types of failures are calculated respectively: the network failure number is divided by the total failure number to obtain the proportion of network failure in all failures, i.e. the network failure probability; the device offline number is divided by the total failure number to obtain the proportion of device offline in all failures, i.e. the device offline probability; the protocol mismatch number is divided by the total failure number to obtain the proportion of protocol mismatch in all failures, i.e. the protocol mismatch probability.

[0105] S703: According to the size relationship of the network failure probability, the device offline probability and the protocol mismatch probability, the display level of the corresponding state feedback information is determined, and the network link state information, the device state information and the protocol state information are displayed in the graphical configuration interface in the order of the display level from top to bottom.

[0106] Specifically, first, the three failure probability values calculated in step S702 are obtained, and the probability values are compared in size. Then, according to the comparison result, the display level is determined: the state information corresponding to the failure type with the largest probability is set to the highest display level (L1 level); the state information corresponding to the failure type with the second largest probability is set to the middle display level (L2 level); the state information corresponding to the failure type with the smallest probability is set to the lowest display level (L3 level). Then, a hierarchical display area is constructed in the graphical configuration interface, and the display positions of the state information of different levels are allocated. In the order from top to bottom, the state information of each level is displayed in turn: the network link state information includes network connection state, failure description and processing suggestion; the device state information includes device online state, response and maintenance suggestion; the protocol state information includes protocol matching degree, version information and update suggestion. In the display process, different styles are used to highlight the level difference, such as using different font sizes, color depths or background styles.

[0107] S604: Wherein the feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and the display format of the connection line in the feedback path is different from the display format of the connection line in the instruction processing flow.

[0108] Specifically, first, the display area is divided in the graphical configuration interface, and the instruction processing flow and the feedback path are placed side by side, and then the connection line in the instruction processing flow is set to a first display format: using solid line style, thicker line width, forward arrow mark, embodying the main data flow direction. At the same time, the connection line in the feedback path is set to a second display format: using dashed line style, thinner line width, reverse arrow mark, highlighting the transmission direction of the feedback information.

[0109] Reference Figure 5The application also provides a structural diagram of a low-code Internet of Things network configuration system, which specifically comprises: A data acquisition module is configured to receive an original data packet sent by an Internet of Things device and determine a protocol type corresponding to the original data packet based on a protocol identifier of the original data packet. A flow construction module is configured to construct a data processing flow in a graphical configuration interface when detecting a drag behavior, the data processing flow comprising a first start node, a southbound receiving node, a decoding node, a mapping node and a northbound reporting node connected in sequence. A data conversion module is configured to transmit the original data packet into the southbound receiving node through the first start node and convert the original data packet into a decimal value in the decoding node. The data conversion module is further configured to call a standard data model in an Internet of Things platform based on the protocol type in the mapping node, map the decimal value to a target field based on the standard data model, and send the target field to the Internet of Things platform through the northbound reporting node. The flow construction module is further configured to receive a control instruction generated based on the target field and issued by the Internet of Things platform, and construct an instruction processing flow in the graphical configuration interface, the instruction processing flow comprising a second start node, a northbound command node, a function node and a southbound sending node connected in sequence. The data conversion module is further configured to parse the control instruction into a control type identifier and a control parameter in the northbound command node through the second start node. A data application module is configured to generate a communication message through the function node based on the control type identifier and the control parameter, and send the communication message to the Internet of Things device through the southbound sending node.

[0110] Optionally, the flow construction module is specifically configured to: When detecting a drag behavior of dragging a node component in a component library area of the graphical configuration interface to a flow configuration area, display a node icon corresponding to the node component in the flow configuration area. When detecting a connection operation between adjacent node icons in the flow configuration area, establish a data flow conversion relationship between the adjacent node icons, and display a connection line between the node icons in the graphical configuration interface. Verify whether a node connection sequence between the adjacent node icons conforms to a preset standard processing flow, the standard processing flow comprising: connecting the first start node to the southbound receiving node, connecting the southbound receiving node to the decoding node, connecting the decoding node to the mapping node, and connecting the mapping node to the northbound reporting node. when the node connection order conforms to the preset standard processing flow, taking the preset standard processing flow as a data processing flow, and displaying the connection line as a first preset color in the graphical configuration interface; when the node connection order does not conform to the preset standard processing flow, displaying an error prompt information in the graphical configuration interface, and displaying the connection line as a second preset color.

[0111] Optionally, the flow construction module is further used for: obtaining a node connection rule defined in the preset standard processing flow, the node connection rule including a front node type and a back node type of each node; traversing all node icons in the flow configuration area to obtain a node type of each node icon; obtaining, from the node connection rule, a first front node type and a first back node type allowed to be connected by the node type corresponding to each node icon; verifying whether a second front node type adjacent to each node icon conforms to the first front node type and whether a second back node type conforms to the first back node type; when the second front node type adjacent to any node icon does not conform to the first front node type or the second back node type does not conform to the first back node type, determining that the node connection order does not conform to the preset standard processing flow; when the second front node type adjacent to all node icons conforms to the first front node type and the second back node type conforms to the first back node type, determining that the node connection order conforms to the preset standard processing flow.

[0112] Optionally, the data conversion module is used for: based on the protocol type, calling a preset decoding rule template; extracting a data payload from the original data packet; obtaining a start byte position and an interception length configured in the decoding rule template; according to the start byte position and the interception length, intercepting a target data segment from the data payload; converting the target data segment into a decimal value according to a data format configured in the decoding rule template, the data format including any one of signed integer data, unsigned integer data, floating point data, and string data.

[0113] Optionally, the data conversion module is further used for: determine a field type and a value range corresponding to the target field according to a field mapping relationship in the standard data model and the decimal number value; convert the decimal number value according to the field type, and verify whether the converted number value is within the value range; when the converted number value is within the value range, take the converted number value as the target field; when the converted number value is not within the value range, display out-of-range value prompt information in the graphical configuration interface.

[0114] Optionally, a low-code Internet of Things network configuration system further includes a state feedback module, which is specifically configured to: monitor a sending state of the communication message, and if the communication message fails to be sent, generate a feedback path in the graphical configuration interface, the feedback path including a southbound receiving feedback node, a feedback analysis node and a northbound feedback node connected in sequence; identify a reason for the communication message failing to be sent in the feedback analysis node; generate corresponding state feedback information in the feedback analysis node according to the reason, and send the state feedback information to the Internet of Things platform through the northbound feedback node; wherein the feedback path and the instruction processing flow are displayed in parallel in the graphical configuration interface, and a display format of a connection line in the feedback path is different from a display format of a connection line in the instruction processing flow.

[0115] Optionally, the state feedback module is further specifically configured to: count a reason for each communication message failing to be sent and a number of times of sending failure in the feedback analysis node, and accumulate network fault times, device offline times and protocol mismatch times according to types of the reasons, respectively; calculate a network fault probability by calculating a proportion of the network fault times in the number of times of sending failure, calculate a device offline probability by calculating a proportion of the device offline times in the number of times of sending failure, and calculate a protocol mismatch probability by calculating a proportion of the protocol mismatch times in the number of times of sending failure; determine a display level of corresponding state feedback information according to a size relationship among the network fault probability, the device offline probability and the protocol mismatch probability, and display network link state information, device state information and protocol state information in the graphical configuration interface in a sequence from top to bottom according to the display level.

[0116] It should be noted that the apparatus provided in the above examples is only used as an example for the division of the above functional modules in realizing its functions, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions. In addition, the apparatus and method embodiments provided in the above examples belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be described here.

[0117] The embodiment further discloses an electronic device, which refers to Figure 6 , Figure 6 is a structural schematic diagram of an electronic device disclosed by the embodiment of the present application. The electronic device 013 can 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.

[0118] The communication bus 902 is used to realize the connection and communication between the components.

[0119] The user interface 903 can include a display screen (Display) and a camera (Camera), and the optional user interface 903 can further include a standard wired interface and a wireless interface.

[0120] The network interface 904 can optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0121] The processor 901 can include one or more processing cores. The processor 901 connects various parts within the server through various interfaces and lines, performs various functions of the server and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 905, and calling data stored in the memory 905. Alternatively, the processor 901 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array. The processor 901 can integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes operating systems, user interfaces, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; and the modem is used for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 901, but can be realized by a separate chip.

[0122] The memory 905 can include a random access memory (RAM) and a read-only memory (ROM). Optionally, the memory 905 includes a non-transitory computer-readable storage medium. The memory 905 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 905 can include a program storage area and a data storage area, wherein the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 905 can also be at least one storage device located away from the aforementioned processor 901. Referring to Figure 6 The memory 905 as a computer storage medium can include an operating system, a network communication module, a user interface module, and an application program of a low-code Internet of Things configuration.

[0123] In Figure 6In the electronic device shown, the user interface 903 is mainly used to provide an interface for user input, and obtain data input by the user; and the processor 901 can be used to call an application of a low-code IoT network configuration stored in the memory 905, which, when executed by one or more processors 901, causes the electronic device 013 to perform the method of one or more of the above-described embodiments.

[0124] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all described as a series of action combinations, but those skilled in the art should know that the present application is not limited to the order of the actions described, because according to the present application, certain steps can be performed in other order or at the same time. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0125] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0126] In several embodiments provided by the present application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only schematic. The division of the units is only a logical function division. There can be another division manner in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different parts can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical or other forms.

[0127] The units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0128] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware, or in the form of software functional unit.

[0129] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable memory. Based on such understanding, the technical solutions of the present application essentially or say the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a memory and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The aforementioned memory includes: a U disk, a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0130] The above-described are only exemplary embodiments of the present disclosure, and cannot limit the scope of the present disclosure. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure are still within the scope of the present disclosure. Other embodiments of the present disclosure will be readily apparent to those skilled in the art upon considering the disclosure. The present application is intended to cover any variations, uses or adaptive changes of the present disclosure that follow the general principles of the present disclosure and include common knowledge or conventional technical means in the technical field not recorded in the present disclosure. The scope and spirit of the present disclosure are defined by the claims.

Claims

1. A low-code IoT network configuration method, characterized by, The method is applied to an electronic device, and the method comprises: Receiving an original data packet sent by an Internet of Things device, and determining a protocol type corresponding to the original data packet based on a protocol identifier of the original data packet; When a drag behavior is detected in a graphical configuration interface, a data processing flow is constructed, the data processing flow comprising a first start node, a south receiving node, a decoding node, a mapping node and a north reporting node connected in sequence; The original data packet is transmitted into the south receiving node through the first start 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 called in an Internet of Things platform based on the protocol type, and the decimal value is mapped into a target field based on the standard data model, and the target field is sent to the Internet of Things platform through the north reporting node; A control instruction generated based on the target field and issued by the Internet of Things platform is received, and an instruction processing flow is constructed in the graphical configuration interface, the instruction processing flow comprising a second start node, a north command node, a function node and a south sending node connected in sequence; The control instruction is parsed into a control type identifier and a control parameter in the north command node through the second start node; The control type identifier and the control parameter are used to generate a communication message through the function node, and the communication message is sent to the Internet of Things device through the south sending node.

2. The low-code IoT network configuration method of claim 1, wherein, When a drag behavior is detected in a graphical configuration interface, a data processing flow is constructed, the data processing flow comprising: When a node component in a component library region of the graphical configuration interface is dragged to a flow configuration region, a node icon corresponding to the node component is displayed in the flow configuration region; When a connection operation between adjacent node icons in the flow configuration region is detected, a data flow conversion relationship is established between the adjacent node icons, and a connection line between the node icons is displayed in the graphical configuration interface; Whether a node connection order between the adjacent node icons conforms to a preset standard processing flow is verified, the standard processing flow comprising: a first start node connected to a south receiving node, the south receiving node connected to a decoding node, the decoding node connected to a mapping node, and the mapping node connected to a north reporting node; When the node connection order conforms to the preset standard processing flow, the preset standard processing flow is taken as a data processing flow, and the connection line is displayed as a first preset color in the graphical configuration interface; When the node connection order does not conform to the preset standard processing flow, an error prompt information is displayed in the graphical configuration interface, and the connection line is displayed as a second preset color.

3. The low-code IoT network configuration method of claim 2, wherein, Whether a node connection order between the adjacent node icons conforms to a preset standard processing flow is verified, the standard processing flow comprising: A node connection rule defined in the preset standard processing flow is obtained, the node connection rule comprising a front node type and a rear node type of each node; All node icons in the flow configuration region are traversed, and a node type of each node icon is obtained; The first pre-node type and the first post-node type allowed to be connected by the node type corresponding to each node icon are obtained from the node connection rule; It is verified whether the second pre-node type adjacent to each node icon conforms to the first pre-node type and whether the second post-node type conforms to the first post-node type; When the second pre-node type adjacent to any node icon does not conform to the first pre-node type or the second post-node type does not conform to the first post-node type, it is determined that the node connection order does not conform to the preset standard processing flow; When the second pre-node type adjacent to all node icons conforms to the first pre-node type and the second post-node type conforms to the first post-node type, it is determined that the node connection order conforms to the preset standard processing flow.

4. The low-code IoT network configuration method of claim 1, wherein, The conversion of the original data packet into a decimal value in the decoding node includes: Based on the protocol type, a preset decoding rule template is called; Data payload is extracted from the original data packet; The start byte position and the length of interception configured in the decoding rule template are obtained; According to the start byte position and the length of interception, a target data segment is intercepted from the data payload; The target data segment is converted into a decimal value according to the data format configured in the decoding rule template, and 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 of claim 1, wherein, The mapping of the decimal value into a target field based on the standard data model includes: Based on the field mapping relationship in the standard data model and the decimal value, the field type and the value range corresponding to the target field are determined; The decimal value is format-converted according to the field type, and it is verified whether the converted value is within the value range; When the converted value is within the value range, the converted value is taken as the target field; When the converted value is not within the value range, an out-of-range value prompt is displayed in the graphical configuration interface.

6. The low-code IoT network configuration method of claim 1, wherein, After the communication message is sent to the corresponding Internet of Things device through the southbound sending node, it further includes: The sending state of the communication message is monitored, and if the communication message fails to be sent, a feedback path is generated in the graphical configuration interface, the feedback path including a southbound receiving feedback node, a feedback analysis node, and a northbound feedback node connected in sequence; The reason for the failure of the message sending is identified in the feedback analysis node; According to the reason, corresponding state feedback information is generated in the feedback analysis node, and the state feedback information is sent to the Internet of Things 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 connection line in the feedback path is different from that of the connection line in the instruction processing flow.

7. The low-code IoT network configuration method of claim 6, wherein, The reasons include at least one of network failure, device offline and protocol mismatch, the corresponding state feedback information is generated in the feedback analysis node according to the reasons, including: In the feedback analysis node, the reasons for each communication message sending failure and the sending failure times are counted, and the network failure times, the device offline times and the protocol mismatch times are accumulated according to the types of the reasons; The network failure probability is calculated by calculating the proportion of the network failure times in the sending failure times, the device offline probability is calculated by calculating the proportion of the device offline times in the sending failure times, and the protocol mismatch probability is calculated by calculating the proportion of the protocol mismatch times in the sending failure times; According to the size relationship of the network failure probability, the device offline probability and the protocol mismatch probability, the display level of the corresponding state feedback information is determined, and the network link state information, the device state information and the protocol state information are displayed in the graphical configuration interface in the order from top to bottom according to the display level.

8. A low-code IoT network configuration system, characterized by, The system is applied to an electronic device, and the system comprises: A data acquisition module is configured to receive an original data packet sent by an Internet of Things device and determine a protocol type corresponding to the original data packet based on a protocol identifier of the original data packet; A flow construction module is configured to construct a data processing flow in a graphical configuration interface when detecting a drag behavior, the data processing flow comprising a first start node, a southward receiving node, a decoding node, a mapping node and a northward reporting node connected in sequence; A data conversion module is configured to transmit the original data packet into the southward receiving node through the first start node and convert the original data packet into a decimal value in the decoding node; The data conversion module is further configured to call a standard data model in an Internet of Things platform based on the protocol type in the mapping node, map the decimal value into a target field based on the standard data model, and send the target field to the Internet of Things platform through the northward reporting node; The flow construction module is further configured to receive a control instruction generated based on the target field and issued by the Internet of Things platform, and construct an instruction processing flow in the graphical configuration interface, the instruction processing flow comprising a second start node, a northward command node, a function node and a southward sending node connected in sequence; The data conversion module is further configured to parse the control instruction into a control type identifier and a control parameter in the northward command node through the second start node; A data application module is configured to generate a communication message through the function node based on the control type identifier and the control parameter, and send the communication message to the Internet of Things device through the southward sending node.

9. An electronic device, comprising: The electronic device comprises a processor, a memory, a user interface and a network interface, the memory is configured to store instructions, the user interface and the network interface are configured to communicate with other devices, and the processor is configured to execute the instructions stored in the memory to enable the electronic device to perform the method of 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, perform the method of any of claims 1-7.

Images