A method and system for converting uniform access data of a multi-protocol internet of things device

Abstract

The application discloses a kind of multi-protocol Internet of Things equipment unified access data conversion method and system, it is related to Internet of Things field, its method includes: in response to the device description message reported by Internet of Things equipment when accessing through multi-protocol adaptation layer, device description message is parsed, and device capability information is obtained;Standard MQTT topic namespace corresponding to Internet of Things equipment is generated based on device capability information and device model, and data conversion rule corresponding to device model is dynamically loaded to rule engine;Based on rule engine, raw data message is converted into standard MQTT message format, and data in standard MQTT message format is published;In response to device control instruction, device control instruction is reversely converted into native protocol format control message of Internet of Things equipment based on rule engine, and native protocol format control message is issued to Internet of Things equipment through multi-protocol adaptation layer.The application can effectively reduce the complexity of device access and data management mode.

Description

Technical Field

[0001] This application relates to the field of the Internet of Things (IoT), and in particular to a method and system for unified access data conversion for multi-protocol IoT devices. Background Technology

[0002] With the rapid development and widespread application of IoT technology, various smart devices are experiencing explosive growth. From smart homes and industrial monitoring to smart city construction, IoT devices have permeated all aspects of social life. These devices are diverse in type and function, bringing great convenience to people's production and lives. However, with the continuous expansion of the IoT ecosystem, device access and data management are facing increasingly severe challenges.

[0003] Currently, the Internet of Things (IoT) field is characterized by the coexistence of multiple communication protocols. Devices from different manufacturers and for different application scenarios often employ different communication protocols, each with its own specific technical characteristics and applicable scope. While this multi-protocol coexistence satisfies the differentiated needs of various scenarios, it also presents significant challenges to the unified management of IoT platforms.

[0004] In existing technologies, building a comprehensive IoT management platform typically requires developing dedicated access modules and data processing logic for each communication protocol. Devices using different protocols report data in various formats; some use JSON, some use binary protocols, and others use proprietary data formats. Upper-layer application systems must interface with each protocol separately and write extensive adaptation code to obtain this data. This not only increases the complexity and workload of system development but also makes system maintenance extremely difficult. Adding a new device with a different protocol often requires a large-scale overhaul of the entire system, resulting in long development cycles and high costs.

[0005] Furthermore, data from devices using different protocols and from different manufacturers cannot be directly exchanged, creating data silos. Upper-layer application systems struggle to achieve cross-protocol and cross-device data fusion and analysis, significantly limiting the value extraction of IoT data. Simultaneously, in terms of device control, application systems need to implement control command issuance logic separately for different protocols, resulting in a bloated system architecture and poor scalability.

[0006] Therefore, current methods of device access and data management are highly complex, making it difficult to achieve unified management of heterogeneous devices and efficient utilization of data. Summary of the Invention

[0007] This application provides a unified access data conversion method and system for multi-protocol IoT devices, which effectively reduces the complexity of device access and data management methods, and realizes unified management of heterogeneous devices and efficient utilization of data.

[0008] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, a method for unified access data conversion for multi-protocol IoT devices is provided, the method comprising: In response to the device description message reported by the IoT device when it accesses through the multi-protocol adaptation layer, the device description message is parsed to obtain the device capability information, which includes the device model. Based on device capability information and device model, a standard MQTT topic namespace corresponding to the IoT device is generated, and data transformation rules corresponding to the device model are dynamically loaded into the rule engine based on the standard MQTT topic namespace; Based on the rule engine, the raw data packets reported by IoT devices through the native communication protocol are converted into standard MQTT message format to obtain data in standard MQTT message format; Data in standard MQTT message format is published via the MQTT message bus for upper-layer application systems to subscribe to and use; In response to device control commands sent by the upper-layer application system, the system uses a rule engine to reverse-convert the device control commands into control messages in the native protocol format of the IoT device, and then sends the native protocol format control messages to the IoT device through a multi-protocol adaptation layer.

[0009] In one possible implementation of the first aspect, the device capability information also includes communication protocol type, attribute list, service list, and event list. A standard MQTT topic namespace corresponding to the IoT device is generated based on the device capability information and device model. Data transformation rules corresponding to the device model are dynamically loaded into the rule engine based on the standard MQTT topic namespace, including: Generate an attribute reporting topic for each attribute in the device capability information based on the attribute list. The format of the attribute reporting topic is a combination of a preset prefix, device model and attribute identifier. Generate service invocation topics and service response topics for each service in the device capability information based on the service list; Generate an event notification topic for each event in the device capability information based on the event list; The attribute reporting topic, service call topic, service response topic, and event notification topic are associated with the device model of the IoT device for storage, resulting in a standard MQTT topic namespace. Based on the standard MQTT topic namespace, the data transformation rules corresponding to the device model are dynamically loaded into the rule engine.

[0010] In another possible implementation of the first aspect, based on a rule engine, the raw data packets reported by IoT devices via native communication protocols are converted into standard MQTT message format to obtain data in standard MQTT message format, including: The original data message is parsed at the protocol layer to obtain the payload data; Load the corresponding data transformation rules from the rules engine based on the device model of the IoT device; Based on data transformation rules, service type identification is performed on the payload data to determine the service type corresponding to the payload data. Extract target attribute values ​​or event parameters from the net load data based on the service type; The extracted target attribute values ​​or event parameters are converted into units and values ​​to obtain processed data. The processed data is then encapsulated into a unified standard JSON data model, which includes a protocol version number, timestamp, device identifier, and data fields. The data fields store the mapping relationship between attribute keys and attribute values ​​in key-value pairs.

[0011] In another possible implementation of the first aspect, when the native communication protocol is WiFi, the corresponding raw data packet is a device-private TCP protocol packet; when the native communication protocol is Zigbee, the corresponding raw data packet is a Zigbee device message; and when the native communication protocol is Bluetooth, the corresponding raw data packet includes BLE broadcast data, connection state change data, and feature value change data.

[0012] In another possible implementation of the first aspect, in response to device control commands sent by the upper-layer application system, the device control commands are converted back into control messages in the native protocol format of the IoT device based on the rule engine, and the native protocol format control messages are then sent to the IoT device through a multi-protocol adaptation layer, including: In response to device control commands sent by the upper-layer application system, the rule engine determines the communication protocol type and target data conversion rules of the IoT device based on the device model in the device control command. The device control command adopts the standard JSON format. Based on the target data conversion rules, the device control commands are reverse-converted into control messages in the native protocol format of the IoT device. The native protocol format control messages are sent to IoT devices through the protocol adapter corresponding to the communication protocol type in the multi-protocol adaptation layer.

[0013] In another possible implementation of the first aspect, before identifying the service type of the payload data based on data transformation rules and determining the service type corresponding to the payload data, the method further includes: When an IoT device is connected for the first time and a device profile is created, obtain the data conversion rule script corresponding to the IoT device. Perform lexical and syntactic analysis on the data transformation rule script to generate an abstract syntax tree; The abstract syntax tree is post-order traversed and flattened into a one-dimensional parsing instruction array. Each instruction in the one-dimensional parsing instruction array includes an opcode field, a relative memory offset field, and a destination register number field. The one-dimensional parsing instruction array is bound to the device model of the IoT device and stored in a read-only memory area.

[0014] In another possible implementation of the first aspect, the original data message is parsed at the protocol layer to obtain the payload data, including: By stripping the network protocol stack shell of the original data packet, the binary payload data is extracted. Write the binary payload data to a pre-allocated circular memory buffer in zero-copy mode; Approximate a slice ruler header before the physical memory starting address of the binary payload data. The slice ruler header includes the payload starting memory offset, byte order identifier, and total payload length. Based on the slice ruler header and binary payload data, a standardized memory block to be processed is formed to obtain the net payload data.

[0015] In another possible implementation of the first aspect, service type identification is performed on the payload data based on data transformation rules to determine the service type corresponding to the payload data, including: Based on the device model to which the standardized memory block to be processed belongs, read the corresponding parsing instruction array from the read-only memory area; Start a lightweight microkernel sandbox and read the slice ruler header through the lightweight microkernel sandbox to calibrate the memory base address of the binary payload data. The lightweight microkernel sandbox includes an instruction pointer and multiple virtual registers. The instruction pointer is controlled to execute instructions in the parsed instruction array sequentially, and pointer addressing is performed on the physical memory address of the binary payload data according to the relative memory offset field of each instruction; Based on the opcode field of each instruction, read operations and bitwise operations are performed on the addressed data to obtain the operation result; The result of the operation is stored in the virtual register corresponding to the target register number specified in the opcode field; After the parsing instruction array is completed, the extracted valid data is read from multiple virtual registers.

[0016] Secondly, this application provides an electronic device, comprising: The memory is configured to store instructions; and The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned unified access data conversion method for multi-protocol IoT devices.

[0017] Thirdly, this application provides a unified access data conversion system for multi-protocol IoT devices, comprising: Electronic devices; Internet of Things (IoT) devices connect to electronic devices.

[0018] The above technical solutions achieve unified management and efficient data utilization of heterogeneous IoT devices. A multi-protocol adaptation layer enables unified access for devices using different communication protocols. When a device connects, the system automatically parses the device description message, extracting device capability information and model number, laying the foundation for subsequent data conversion. This allows for flexible support of multiple mainstream IoT protocols without requiring separate development of access logic for each protocol, significantly reducing system development complexity. A dynamic rule loading mechanism based on standard MQTT topic namespaces is introduced. Standardized MQTT topic namespaces are automatically generated based on the device model, and corresponding data conversion rules are dynamically loaded into the rule engine. This decouples data conversion rules from device types. When a new device model needs to be connected, only the corresponding conversion rules need to be configured, without modifying the core code, greatly improving system scalability and maintenance efficiency. The rule engine's bidirectional conversion capabilities enable seamless conversion between native protocols and the standard MQTT format. Uplink data conversion uniformly converts the raw data packets of various heterogeneous devices into the standard MQTT message format, eliminating data silos. This allows upper-layer application systems to obtain all device data simply by subscribing to standard MQTT topics, without needing to worry about underlying protocol differences. The reverse conversion of downlink control commands ensures that application systems can control devices using different protocols in a unified manner, simplifying application development logic. Using the MQTT message bus as the data publish-subscribe center fully leverages the advantages of the MQTT protocol: lightweight, low latency, and support for massive connections. Upper-layer application systems can flexibly subscribe to the required device data topics, enabling cross-protocol and cross-device data fusion and analysis, fully unlocking the value of IoT data.

[0019] In summary, this technical solution effectively solves the challenges of managing multi-protocol IoT devices through a standardized data conversion mechanism and a unified message bus architecture, thereby simplifying the system architecture, improving development efficiency, and maximizing the utilization of data value.

[0020] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0021] Figure 1 A flowchart illustrating a unified access data conversion method for multi-protocol IoT devices provided in this application embodiment; Figure 2 This application provides a schematic diagram of a process for parsing the original data packet at the protocol layer to obtain the payload data, as provided in an embodiment of the present application. Figure 3 This is a schematic diagram of a unified access data conversion system for multi-protocol Internet of Things devices provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0023] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0024] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0025] Figure 1 This illustration schematically depicts a flowchart of a unified access data conversion method for multi-protocol IoT devices according to an embodiment of this application. For example... Figure 1 As shown in the figure, this application embodiment provides a unified access data conversion method for multi-protocol IoT devices, which may include the following steps.

[0026] S110. In response to the device description message reported by the IoT device when it accesses through the multi-protocol adaptation layer, parse the device description message to obtain device capability information, wherein the device capability information includes the device model. S120. Generate a standard MQTT topic namespace corresponding to the IoT device based on the device capability information and device model, and dynamically load the data transformation rules corresponding to the device model into the rule engine based on the standard MQTT topic namespace. S130. Based on the rule engine, the raw data packets reported by IoT devices through the native communication protocol are converted into standard MQTT message format to obtain data in standard MQTT message format; S140. Publish data in standard MQTT message format via the MQTT message bus for upper-layer application systems to subscribe and use; S150: In response to the device control command sent by the upper-layer application system, the device control command is converted into the native protocol format control message of the IoT device based on the rule engine, and the native protocol format control message is sent to the IoT device through the multi-protocol adaptation layer.

[0027] In this embodiment, the multi-protocol adaptation layer may include a WiFi adapter, a Zigbee adapter, and a Bluetooth adapter. Before the device description message reported by the IoT device when it accesses the network via the multi-protocol adaptation layer, the method further includes: Detect whether IoT devices carry a device description message when they connect; When an IoT device does not carry a device description message, extract the device model code reported by the IoT device; Search for a matching device file template from the local or remote device file database based on the device model code; When a matching device profile template is found, the device capability information of the IoT device is automatically generated based on the device profile template. When no matching device profile template is found, the system receives input information or uploaded configuration files through the web management interface and generates device capability information based on the input information or configuration files.

[0028] Parse the device description message to obtain device capability information, including: The device description message is validated for compliance, and the device capability information is extracted from the validated device description message. The device capability information includes device model, manufacturer information, communication protocol type, attribute definition, service definition, and event definition. The attribute definition includes attribute key value, attribute name, data type, value range, access mode, and unit information. The service definition includes service key value, service name, call type, input parameters, and output parameters. The event definition includes event key value, event name, event type, and output data.

[0029] This embodiment also includes the following steps: Establish an equipment model database in the equipment service management center, which stores multiple equipment model files; Each device model file includes the manufacturer identifier, model identifier, hardware specifications, service definition, data conversion rule script, and firmware upgrade package; When a new IoT device is detected to be connected, extract the manufacturer's identifier and model identifier of the new IoT device; Search the equipment model database for matching equipment model files based on the manufacturer's identifier and model identifier; When a matching device model file is found, the service definition and data conversion rule script in the device model file are automatically loaded. The system automatically registers and configures new IoT devices based on the loaded service definition and data transformation rule scripts.

[0030] When an IoT device connects through the multi-protocol adapter layer, it first reports a device description message. The multi-protocol adapter layer includes various protocol adapters such as WiFi adapters, Zigbee adapters, and Bluetooth adapters, each of which is responsible for handling device access requests for its corresponding protocol.

[0031] Upon receiving the device description message, a compliance verification is immediately performed, checking whether the message format conforms to the predefined device description specifications, verifying the completeness of required fields, and confirming the correct data type. After successful verification, the detailed content of the device description message is parsed. The parsing process first extracts the device model field, which typically uses a combination of manufacturer code and product code; for example, "XM-TH01" indicates a temperature and humidity sensor model from a specific manufacturer. Next, manufacturer information is extracted, including basic information such as manufacturer name and contact information. Then, the communication protocol type field is identified to determine whether the device uses WiFi, Zigbee, or Bluetooth, etc. The attribute definition section is then parsed, detailing the various attribute characteristics of the device. For example, for a temperature and humidity sensor, the attribute definition includes temperature and humidity attributes. Next, the service definition section is parsed, describing the various service functions supported by the device. For example, the service definition for a smart bulb device includes switch control service and brightness adjustment service. Finally, the event definition section is parsed, describing the various events the device may generate. By fully parsing the device description message, complete capability information of the device is obtained, providing a complete metadata foundation for subsequent topic namespace generation and data conversion rule loading.

[0032] Based on the parsed device capability information and device model, a standard MQTT topic namespace is generated. First, an attribute reporting topic is generated for each attribute according to the attribute list. Attribute reporting topics follow a unified format, consisting of a preset prefix, device model, and attribute identifier. The preset prefix is ​​typically "iot / device / ", used to identify that this is a topic related to an IoT device. For example, for a temperature and humidity sensor with model number "XM-TH01", its temperature attribute reporting topic can be generated as "iot / device / XM-TH01 / property / temperature". Next, service call topics and service response topics are generated for each service according to the service list.

[0033] The service invocation topic is used to receive service invocation requests from upper-layer applications, and its format can be "iot / device / {device model} / service / {service key-value} / invoke". The service response topic is used to publish service execution results, and its format can be "iot / device / {device model} / service / {service key-value} / response". Then, an event notification topic is generated for each event based on the event list, and its format can be "iot / device / {device model} / event / {event key-value}".

[0034] After generating a complete topic namespace, all topics are associated with device models and stored, establishing a mapping table between topics and devices to form a standard MQTT topic namespace. Data transformation rules are then dynamically loaded based on this namespace. The rule engine maintains a rule repository that stores data transformation rule scripts corresponding to various device models. A matching transformation rule script is retrieved from the rule repository based on the device model. If a rule for that model already exists in the repository, it is loaded directly; otherwise, basic transformation rules are automatically generated based on the device capability information, or the administrator is prompted to configure custom rules. The loaded transformation rules include data parsing rules, numerical conversion rules, and format mapping rules, which guide the subsequent data transformation process.

[0035] When IoT devices report raw data packets via native communication protocols, the rules engine initiates a data transformation process. First, the raw data packets are parsed at the protocol layer, stripping away the network protocol stack and extracting the binary payload data. Different protocols have significantly different packet structures. WiFi devices typically use proprietary TCP protocol packets, which consist of a TCP header, an application layer protocol header, and a data payload. During parsing, the 20-byte fixed portion of the TCP header and any possible option fields are removed first. Then, the protocol header is parsed according to the application layer protocol specification, ultimately extracting the net payload data.

[0036] Messages from Zigbee devices follow the Zigbee protocol stack specification, containing physical layer frames, MAC layer frames, network layer frames, and application layer data. The parsing process requires stripping away the protocol headers of each layer, starting with the preamble and start-of-frame delimiter at the physical layer, then the frame control field, sequence number, and address information at the MAC layer, followed by the frame control, destination address, and source address at the network layer, finally obtaining the payload data at the application layer.

[0037] Bluetooth protocol device data includes BLE broadcast data, connection state change data, and feature change data. During BLE broadcast data parsing, the AD structure is extracted from the broadcast data packet. The data type is identified based on the AD type field, and manufacturer data or service data is extracted.

[0038] During feature value change data parsing, the specific feature is located based on the feature UUID, and the feature value byte stream is extracted. After extracting the payload data, the corresponding data transformation rule is loaded from the rule engine according to the device model. The transformation rule is stored in script form, containing a data field mapping table, numerical transformation functions, and formatting templates.

[0039] Service type identification is performed on the payload data based on conversion rules. By analyzing the function code or command field in the data packet, it is determined whether the data belongs to attribute reporting, event notification, or service response. For example, the function code of a temperature and humidity sensor data packet is 0x03, indicating attribute reporting, and 0x05, indicating an alarm event.

[0040] After identifying the service type, target attribute values ​​or event parameters are extracted from the payload data based on the type. For attribute reporting, each attribute value is extracted according to the data type and byte offset in the attribute definition. For example, the temperature value occupies 2 bytes, is located at offset 4, and is stored in big-endian order, yielding the original value 2350. Next, unit conversion and numerical conversion are performed; the original temperature value 2350 needs to be divided by 100 to obtain the actual temperature 23.50℃.

[0041] The converted data is encapsulated into a unified standard JSON data model. The model includes a protocol version field ("version") with a value of "1.0"; a timestamp field ("timestamp") recording the Unix timestamp used to generate the data; a device identifier field ("deviceId") recording the unique identifier of the device; and a data field ("data") storing the mapping between attribute keys and values ​​in key-value pairs, for example, {"temperature": 23.50, "humidity": 65}. The resulting standard MQTT message format data is complete, standardized, and easy to parse, providing a unified data interface for upper-layer applications.

[0042] After data in the standard MQTT message format is generated, it is published through the MQTT message bus. The MQTT message bus adopts a publish-subscribe model, which decouples data producers and consumers. The publishing process first determines the target topic based on the data type. If the data is an attribute report, the corresponding attribute report topic is selected; if the data is an event notification, the corresponding event notification topic is selected; if the data is a service response, the corresponding service response topic is selected.

[0043] After determining the topic, use standard JSON formatted data as the message payload and set the message's Quality of Service (QoS) level. The MQTT protocol supports three QoS levels: QoS 0 (at most one delivery, message may be lost); QoS 1 (at least one delivery, message may be duplicated); and QoS 2 (exact one delivery, message is neither lost nor duplicated). Choose the appropriate QoS level based on the importance of the data. For ordinary periodic attribute reporting data, use QoS 0 to improve transmission efficiency; for important alarm event data, use QoS 1 to ensure message delivery; and for critical control response data, use QoS 2 to guarantee message reliability and uniqueness.

[0044] Setting a message retention flag allows the MQTT broker to store the latest messages for that topic. New subscribers will receive the retained messages immediately upon subscription, suitable for device status data. When publishing a message, the MQTT client sends the message to the MQTT broker, which distributes the message to all subscribers to that topic based on topic matching rules. Upper-layer application systems can subscribe to topics of interest based on business needs, supporting both exact match and wildcard match subscription methods. Exact match allows subscription to specific data from a specific device. Wildcard subscription supports single-level wildcard "+" and multi-level wildcard "#". For example, subscribing to "iot / device / + / property / temperature" retrieves temperature data for all devices, while subscribing to "iot / device / XM-TH01 / #" retrieves all data from a specific device. This flexible subscription mechanism allows upper-layer application systems to easily obtain the required device data without worrying about underlying protocol differences or data format conversions, greatly simplifying application development complexity.

[0045] When an upper-layer application system needs to control an IoT device, it sends a device control command. The control command uses standard JSON format and includes fields such as device identifier, service key value, and input parameters. Upon receiving the control command, the rule engine first extracts the device identifier from the command and queries the device file based on the device identifier to obtain the device model information. It then determines the device's communication protocol type based on the device model; for example, this smart bulb uses the WiFi protocol. Simultaneously, it loads the data conversion rule corresponding to the device model from the rule engine. This conversion rule includes reverse conversion logic, defining how to convert the standard JSON format control command into the device's native protocol format. The reverse conversion process first parses the service key value and input parameters in the control command, determining the corresponding native protocol command code and parameter format based on the service definition. For example, the command code for a switch control service is 0x10, and the parameter format is a 1-byte switch state, where 0 represents off and 1 represents on. The JSON format parameter {"state": true} is converted to the byte value 0x01. Then, a complete control message is constructed according to the device's native protocol specifications. The message includes a header, command code, parameters, and checksum. The header contains information such as a start flag, device address, and data length. The checksum uses CRC16 or a simple XOR check to ensure the integrity of data transmission. The completed native protocol format control message is a string of hexadecimal byte sequences, such as "AA 01 03 10 01 B5".

[0046] Next, control messages are sent through a multi-protocol adapter layer, selecting the appropriate protocol adapter based on the device's communication protocol type. For WiFi devices, a TCP connection is established through the WiFi adapter, and the control message is sent to the device's IP address and port. For Zigbee devices, the control message is encapsulated into a Zigbee data frame through the Zigbee adapter and routed through the Zigbee network to the target device's short address. For Bluetooth devices, the control message is written into the device's characteristic value through the Bluetooth adapter, triggering the device to execute corresponding operations. After receiving the control message, the device executes the corresponding control action and may return an execution result. The returned result data also undergoes a data conversion process, converting it into a standard MQTT message format and publishing it to the service response topic for upper-layer application systems to subscribe to and retrieve, forming a complete control loop.

[0047] In this embodiment, the multi-protocol adaptation layer realizes unified access to devices supporting various communication protocols such as WiFi, Zigbee and Bluetooth, automatically parses device description messages, extracts device capability information, lays a foundation for subsequent data processing, ensures the accuracy and pertinence of data processing, effectively avoids the problem of separately developing access logic for each protocol, and greatly reduces the complexity of system development. By dynamically generating a standard MQTT topic namespace based on device models and dynamically loading corresponding data conversion rules into the rule engine, the decoupling of data conversion rules and device types is realized. When it is necessary to access a new model of device, only the corresponding conversion rules need to be configured, and no core code needs to be modified, which greatly improves the scalability and maintenance efficiency of the system. Through the bidirectional conversion capability of the rule engine, the original data messages of various heterogeneous devices are uniformly converted into the standard MQTT message format, which eliminates data silos, so that the upper application system only needs to subscribe to standard MQTT topics to obtain all device data without caring about differences in underlying protocols, which simplifies application development logic. The reverse conversion of downlink control instructions ensures that the application system can control devices of different protocols in a unified manner. The MQTT message bus is used as the data publish-subscribe center, which gives full play to the advantages of the MQTT protocol of being lightweight, low-latency and supporting massive connections. The upper application system can flexibly subscribe to required device data topics, realize cross-protocol and cross-device data fusion analysis, and fully exploit the value of Internet of Things data. In conclusion, through the standardized data conversion mechanism and unified message bus architecture, the problem of access management for multi-protocol Internet of Things devices is effectively solved, and the simplification of system architecture, improvement of development efficiency and maximized utilization of data value are realized.

[0048] In one implementation of this embodiment, the device capability information further includes communication protocol type, attribute list, service list and event list. Generating a standard MQTT topic namespace corresponding to the Internet of Things device based on the device capability information and the device model, and dynamically loading the data conversion rules corresponding to the device model into the rule engine based on the standard MQTT topic namespace includes the following steps: S210, generating an attribute reporting topic for each attribute in the device capability information according to the attribute list, wherein the format of the attribute reporting topic is a combination of a preset prefix, the device model and an attribute identifier; S220, generating a service invocation topic and a service response topic for each service in the device capability information according to the service list; S230, generating an event notification topic for each event in the device capability information according to the event list; S240. Associate the attribute reporting topic, service call topic, service response topic, and event notification topic with the device model of the IoT device to obtain a standard MQTT topic namespace, and dynamically load the data transformation rules corresponding to the device model into the rule engine based on the standard MQTT topic namespace.

[0049] Based on the attribute list in the device capability information, an attribute reporting topic is generated for each attribute. The attribute list records in detail all measurable attributes of the device, and each attribute includes complete descriptive information such as attribute key value, attribute name, and data type.

[0050] The generation of attribute reporting topics follows a unified naming convention, employing a hierarchical structure of "preset prefix / device model / property / attribute identifier". The preset prefix is ​​typically set to "iot / device", used to identify the root node of the namespace for IoT device data topics. The device model directly uses the model field extracted from the device capability information, ensuring that devices of the same model use the same topic prefix. The attribute identifier uses the attribute key value defined in the attribute list, which is unique within the device model range.

[0051] For example, for an environmental monitoring station with model number "ENV-MS01", its attribute list includes attributes such as temperature, humidity, and PM2.5 concentration. The key value for the temperature attribute is "temp", and the generated reporting topic can be "iot / device / ENV-MS01 / property / temp". This standardized topic generation mechanism solves the problem of inconsistent topic names for heterogeneous device attribute data. It allows upper-layer application systems to quickly locate and subscribe to the required device attribute data through a unified topic naming rule, eliminating the need to remember and configure topic names separately for different manufacturers and models of devices, greatly simplifying the complexity of application integration.

[0052] Based on the service list in the device capability information, a service invocation topic and a service response topic are generated for each service. The service list defines the callable service functions supported by the device, and each service includes a service key value, service name, input parameter definitions, and output parameter definitions.

[0053] The service invocation topic is used to receive service invocation requests from upper-layer application systems, using the format "iot / device / {device model} / service / {service key-value} / invoke". The service response topic is used to publish service execution results, using the format "iot / device / {device model} / service / {service key-value} / response". This paired topic design implements an asynchronous communication mechanism based on a request-response pattern.

[0054] By generating independent call and response topics for each service, the problem of confusion between service call and response messages is solved, ensuring accurate matching between control commands and execution results, avoiding data corruption when multiple concurrent service calls are made, and providing a fundamental guarantee for achieving reliable device control.

[0055] Based on the event list in the device capability information, an event notification topic is generated for each event. The event list defines various types of events that the device may generate, including alarm events, status change events, and abnormal events. Each event includes an event key value, event name, event type, and output data definition.

[0056] The event notification topic uses the format "iot / device / {device model} / event / {event key value}" to publish event messages generated by the device. For example, the event list for the smart lock model "LOCK-SL08" includes unlocking events, locking events, unauthorized unlocking alarm events, low battery alarm events, etc. The key value for the unlocking event is "unlock", and the generated notification topic can be "iot / device / LOCK-SL08 / event / unlock".

[0057] By generating independent notification topics for each event type, the problem of distinguishing and processing different types of event messages is solved. This allows upper-layer application systems to selectively subscribe to the event types they are interested in based on business needs. For example, a security system can subscribe to alarm events only, and an energy efficiency management system can subscribe to status change events only. This achieves accurate push and efficient processing of event messages, avoiding interference and resource waste caused by irrelevant event messages to the application system.

[0058] The generated attribute reporting topics, service call topics, service response topics, and event notification topics are associated with the device models of IoT devices for storage, establishing a complete standard MQTT topic namespace. The associated storage uses a key-value pair data structure, with the device model as the primary key, organizing all topic information corresponding to that model into a topic set. The topic set is categorized and stored as attribute topics, service topics, and event topics, with each topic category further indexed according to specific attribute, service, or event key values.

[0059] After the associated storage is completed, data transformation rules are dynamically loaded based on the standard MQTT topic namespace. The transformation rule configuration file matching the device model is retrieved from the rule base. This configuration file defines the mapping relationship between native protocol data and standard MQTT messages. The rule configuration file is loaded into the rule engine's memory space. The rule engine parses the rule configuration and establishes a data field mapping table, a value transformation function table, and a message routing table.

[0060] This dynamic loading mechanism solves the problem of hard-coded coupling between data conversion rules and device models, enabling hot updates and version management of rules. When device firmware upgrades cause changes in data format, only the rule configuration file needs to be updated and reloaded, without restarting the system or modifying the code, which greatly improves the system's flexibility and maintainability.

[0061] This embodiment expands device capability information to include a complete description encompassing communication protocol type, attribute list, service list, and event list, providing ample metadata support for the refined generation of standard MQTT topic namespaces and resolving the issues of non-standard and inconsistent topic naming. Corresponding MQTT topics are generated based on the attribute list, service list, and event list, establishing a clear and structurally standardized topic naming system. This allows different types of data messages to be transmitted through independent topic channels, avoiding message confusion and routing errors, and providing precise data subscription capabilities for upper-layer application systems. The generated topics are associated with device models for storage, establishing a mapping relationship from device model to topic namespaces. This enables centralized management and rapid querying of topics. When a new device connects, topic resources can be quickly generated and allocated based on the device model, significantly improving device access efficiency. Based on the standard MQTT topic namespace, data conversion rules are dynamically loaded, achieving loose coupling between conversion rules and device models. This solves the system rigidity problem caused by hard-coded rules, supports hot updates and version management of rules, and enhances the system's scalability and maintainability. In summary, this technical solution effectively solves the problems of chaotic data topic management and difficult maintenance of conversion rules for multi-protocol IoT devices through a standardized topic generation mechanism and dynamic rule loading mechanism, laying a solid foundation for achieving unified access of heterogeneous devices and standardized data processing.

[0062] In one embodiment of this example, based on a rule engine, the raw data packets reported by IoT devices through the native communication protocol are converted into standard MQTT message format to obtain data in standard MQTT message format, including the following steps: S310. Perform protocol layer parsing on the original data message to obtain the payload data; S320. Load the corresponding data transformation rules from the rule engine according to the device model of the IoT device; S330. Based on data transformation rules, identify the service type of the payload data and determine the service type corresponding to the payload data. The service type includes attribute reporting, event notification or service response. S340. Extract target attribute values ​​or event parameters from the net load data based on the service type; S350. Perform unit conversion and numerical transformation on the extracted target attribute values ​​or event parameters to obtain processed data, and encapsulate the processed data into a unified standard JSON data model. The standard JSON data model includes a protocol version number, timestamp, device identifier, and data fields. The data fields store the mapping relationship between attribute keys and attribute values ​​in key-value pairs.

[0063] In this embodiment, the raw data packets reported by IoT devices via native communication protocols are converted into the standard MQTT message format, including at least one of the following scenarios: Scenario 1: Standardization of device-reported data, specifically including: The original data message is parsed at the protocol layer to obtain the payload data; Load the corresponding data transformation rules from the rules engine based on the device model of the IoT device; Attribute identification and extraction are performed on the net payload data based on data transformation rules; Perform unit conversion and numerical conversion on the extracted attribute values; The processed data is encapsulated into a unified attribute reporting standard JSON data model. The data model includes protocol version number, timestamp, device identifier and data fields, where the data fields adopt the key-value pair form of "attribute key-attribute value". Scenario 2: Standardization of device-reported events, specifically including: Perform protocol-layer parsing on the raw data packets to identify event types; Extract event parameters from net load data; The event parameters are encapsulated into a unified event notification standard JSON data model, which includes the protocol version number, timestamp, device identifier, event unique identifier, and event data field. Scenario 3: Standardization of subscription data, specifically including: Receive subscription requests from upper-layer application systems and extract device and attribute lists from them; Locate the corresponding device and read the current attribute value, then send it to the subscriber; Listen for standard format attribute reporting messages published in Scenario 1 and push them to the message queue; Retrieve a message from the message queue and check if any subscribers have subscribed to the attributes in the message; If subscribers exist, lightweight message packets are reassembled as needed; Publish lightweight message packages to subscribed topics via the MQTT message bus.

[0064] The extracted target attribute values ​​or event parameters undergo unit conversion and numerical transformation to obtain processed data, which is then encapsulated into a unified standard JSON data model, including: Obtain free standard data model structure blocks from a pre-initialized JSON object memory pool; Determine the attribute key and data type corresponding to the valid data stored in each virtual register based on the attribute definition of the IoT device; According to the memory offset mapping relationship defined in the standard data model structure block, the valid data in the virtual register is directly written to the memory location of the attribute value corresponding to the standard data model structure block. The memory pointer of the encapsulated standard data model structure block is passed to the MQTT message bus module for message publishing; After the message is published, the standard data model structure block is recycled to the JSON object memory pool.

[0065] The raw data packets are parsed at the protocol layer to obtain the payload data. The raw data packets are reported by IoT devices using native communication protocols and contain a complete network protocol stack encapsulation structure. Protocol layer parsing first identifies the protocol type of the packet; different protocols have significantly different packet structures.

[0066] For WiFi protocol devices, raw data packets are typically encapsulated using the TCP / IP protocol stack, containing an Ethernet frame header, IP header, TCP header, and application layer data. The parsing process first strips the 14-byte fixed portion of the Ethernet frame header, including a 6-byte destination MAC address, a 6-byte source MAC address, and a 2-byte type field. Next, the IP header is stripped; a standard IP header is 20 bytes. If the IP header length field indicates the presence of options, the variable-length options portion needs to be additionally stripped. Then, the TCP header is stripped; a standard TCP header is 20 bytes. If the data offset field indicates the presence of TCP options, the options portion needs to be stripped. After stripping all protocol headers, the binary payload data of the application layer is extracted.

[0067] For Zigbee protocol devices, messages conform to the IEEE 802.15.4 physical and MAC layer specifications, as well as the Zigbee network and application layer specifications. Parsing begins with processing the physical layer frame, removing the preamble and start-of-frame delimiter. Next, the MAC layer frame is parsed, stripping the frame control field, sequence number, address information, and auxiliary security headers. Then, the network layer frame is parsed, stripping the frame control, destination address, source address, and other fields. Finally, the payload data for the application support sublayer is extracted.

[0068] For Bluetooth protocol devices, BLE broadcast data includes a broadcast PDU header and a broadcast data payload. During parsing, the AD structure in the payload is extracted, and the manufacturer data or service data is identified based on the AD type field. Feature change notifications include an ATT protocol header and feature value data. During parsing, the specific feature is located based on the feature UUID, and the feature value byte stream is extracted.

[0069] By parsing the protocol layer, the various protocol encapsulations added during network transmission are effectively stripped away, and the actual business data that the device needs to report is extracted, providing a clean input for subsequent data conversion and solving the problem of data extraction difficulties caused by differences in heterogeneous protocol message structures.

[0070] The corresponding data transformation rules are loaded from the rule engine based on the device model of the IoT device. The rule engine maintains a rule library that stores data transformation rules for each device model, indexed by the device model. The data transformation rules are stored in the form of scripts or configuration files, containing data field mapping tables, numerical conversion functions, unit conversion formulas, and message format templates.

[0071] The loading process first queries the device file based on the device identifier to obtain the device model information. For example, a device with the device identifier "ENV-MS01-00123" has a model number of "ENV-MS01". Then, using the model number "ENV-MS01" as the key, the corresponding conversion rule is retrieved from the rule base. If a rule for this model number exists in the rule base, the rule content is directly loaded into the rule engine's working memory.

[0072] The rules include a field mapping table, which defines the correspondence between the position of each byte in the net load data and the device attributes. Numerical conversion functions define the conversion logic from raw values ​​to actual values; for example, the temperature conversion function can be... ,in This is the original temperature value. This is the actual temperature value. The unit conversion formula handles conversions between different unit systems; for example, the formula for converting Fahrenheit to Celsius is... The message format template defines the structure of a standard JSON data model, including the definitions of required and optional fields.

[0073] If the rule base does not contain a rule for this model, a basic conversion rule will be automatically generated based on the device capability information, or an alarm will be triggered to prompt the administrator to configure a custom rule. Through a dynamic loading mechanism, the problem of hard coupling between conversion rules and code is solved, enabling hot updates and version management of rules. When device firmware upgrades cause changes in data format, only the rule configuration needs to be updated and reloaded; a system restart is not required. This significantly improves the system's flexibility and maintainability, providing a fundamental guarantee for supporting the access of massive numbers of heterogeneous devices.

[0074] Based on data transformation rules, service type identification is performed on the payload data to determine the corresponding service type. Service types include three main categories: attribute reporting, event notification, and service response. Different service types have different processing logics and publishing topics.

[0075] Service type identification is achieved by analyzing characteristic fields in the payload data. The data transformation rules define the location and meaning of the service type identifier field. For example, the rules define the first byte of the payload data as the function code, where function code 0x03 indicates attribute reporting, 0x05 indicates event notification, and 0x06 indicates service response.

[0076] The identification process first locates the function code field according to the rules and reads the function code value. If the function code is 0x03, the data is determined to be of the attribute reporting type, indicating that the device is reporting its current attribute status value. If the function code is 0x05, the data is determined to be of the event notification type, indicating that the device has detected a specific event and is actively reporting it. If the function code is 0x06, the data is determined to be of the service response type, indicating that the device has executed the service call command issued by the upper-layer application and returned the execution result.

[0077] For some protocols, service types may be identified through the message type field in the message header or through characteristic patterns in the data content. For example, application layer data in the Zigbee protocol contains cluster IDs and command IDs; the service type can be determined by the combination of these two IDs. Accurately identifying service types solves the problem of data confusion between different types, ensuring that subsequent data extraction, transformation, and routing are executed according to correct logic. This lays the foundation for accurate data distribution and processing, and avoids data corruption and business logic errors caused by attribute data being mistakenly treated as events or service response data being mistakenly reported as attributes.

[0078] Target attribute values ​​or event parameters are extracted from the payload data based on the service type. The data extraction logic differs for different service types. For attribute reporting types, the original values ​​of each attribute are extracted according to the field mapping table in the data transformation rules, based on the byte offset and data length.

[0079] For example, the net load data of an environmental monitoring station is a hexadecimal byte sequence "03 09 1A 41 00 32 012C". Function code 0x03 indicates attribute reporting, and byte offset 1-2 stores the original temperature value 0x091A. It is represented in big-endian order, which is 2330 in decimal. The extraction process reads the data at each byte position according to the mapping table, and performs byte order conversion and numerical parsing based on the data type.

[0080] For event notification types, extract the event identifier and event parameters. For example, the event notification data of a smoke alarm is "05 01 00 78". The function code 0x05 indicates an event notification, the byte offset 1 is the event identifier 0x01 indicating a smoke alarm event, and the byte offsets 2-3 are the event parameters, storing the smoke concentration value 0x0078, which is 120 in decimal.

[0081] For each service response type, the service identifier and response parameters are extracted. By employing different extraction strategies based on the service type, the issue of inconsistent data field locations and meanings is resolved, ensuring accurate extraction of all data reported by the device. This provides correct input for subsequent numerical conversion and format encapsulation, avoiding data errors caused by field misalignment or data truncation.

[0082] The extracted target attribute values ​​or event parameters undergo unit conversion and numerical transformation to obtain processed data, which is then encapsulated into a unified standard JSON data model. Unit conversion and numerical transformation are performed according to the conversion functions and formulas defined in the data transformation rules.

[0083] For the original temperature value of 2330, according to the conversion function The actual temperature value was calculated. ℃. For a raw humidity value of 65, if the rule defines that the humidity value does not require conversion, then 65 is directly used as the actual humidity value, with the unit being %RH. If the device reports other units, then unit conversion is required. The conversion formula is: ,in The concentration value is expressed in mg / m³. The concentration value is expressed in μg / m³.

[0084] After the numerical conversion is completed, the processed data is encapsulated into a standard JSON data model. A free standard data model structure block is obtained from a pre-initialized JSON object memory pool. This structure block has a fixed-size memory space pre-allocated, containing the memory locations of necessary fields such as the protocol version number, timestamp, device identifier, and data fields.

[0085] The protocol version number field is filled with the currently used protocol version, such as "1.0". The timestamp field is filled with the Unix timestamp generated by the data, obtained by reading the system clock to get the current time in seconds. The device identifier field is filled with the device's unique identifier, such as "ENV-MS01-00123". The data fields store the mapping relationship between attribute keys and attribute values ​​in key-value pairs, and the key value of each attribute is determined according to the device's attribute definition.

[0086] According to the memory offset mapping relationship defined in the standard data model structure block, each attribute value is directly written to the corresponding memory location to form a complete JSON data structure: {"version":"1.0","timestamp":1735401249,"deviceId":"ENV-MS01-00123","data":{"temp":23.30,"humi":65,"pm25":50}}.

[0087] After encapsulation, the memory pointer of the standard data model structure block is passed to the MQTT message bus module for message publishing.

[0088] After a message is published, the standard data model structure block is recycled to the JSON object memory pool, achieving efficient memory reuse and avoiding performance overhead and memory fragmentation issues caused by frequent memory allocation and deallocation operations. Through unified data model encapsulation, the problem of inconsistent data formats across heterogeneous devices is solved, allowing upper-layer application systems to use unified data parsing logic to process data from all devices without needing to write different parsing code for different devices. This greatly simplifies application development complexity and improves system maintainability and scalability.

[0089] In periodic attribute reporting scenarios, devices report their current status at fixed time intervals. After parsing and extracting the payload data at the protocol layer, conversion rules are loaded, the attribute reporting type is identified, the original values ​​of each attribute are extracted, unit conversions and numerical conversions are performed, and the data is encapsulated into a standard JSON data model for attribute reporting. This model contains a complete snapshot of the device status. Upper-layer applications can subscribe to the corresponding attribute reporting topic to obtain the device status in real time and realize device monitoring functions.

[0090] In event-driven scenarios, devices immediately report when a specific event is detected. After parsing the payload data, the event notification type is identified, and the event identifier and event parameters are extracted and encapsulated into a standard JSON data model for event notifications. This model contains a unique event identifier and event data fields. Upper-layer applications can subscribe to the event notification topic to receive alarm information in a timely manner, enabling anomaly handling and emergency response functions.

[0091] In on-demand query scenarios, the upper-layer application sends a subscription request, specifying the list of devices and attributes to be subscribed to. The system locates the corresponding device, reads the current attribute value, and sends it to the subscriber, enabling real-time querying of device status. Simultaneously, it listens for attribute reporting messages, pushes these messages to a message queue, retrieves them from the queue, and checks if a subscriber already exists for that attribute. If a subscriber exists, a lightweight message packet is reassembled, with the format {“Device ID#Attribute KEY”:Value}, for example, {“ENV-MS01-00123#temp”:23.30}, and published to the subscription topic via the MQTT message bus. Lightweight message packets reduce data transmission volume, lower network bandwidth usage, and improve message push efficiency, making them particularly suitable for mobile applications and low-bandwidth network environments.

[0092] This embodiment effectively removes the various protocol encapsulations added during network transmission by parsing the original data packets at the protocol layer, extracting the actual business data that the device needs to report. This solves the problem of data extraction difficulties caused by differences in heterogeneous protocol packet structures. Dynamically loading data conversion rules based on device model decouples the conversion rules from the code, solving the system rigidity problem caused by hard-coded rules. It supports hot updates and version management of rules, significantly improving the system's flexibility and maintainability. Service type identification based on conversion rules ensures that different types of data can be processed according to the correct logic, solving the problem of data obfuscation and avoiding data corruption and business logic errors. Using different extraction strategies based on service type ensures accurate extraction of various data reported by the device, solving the problem of inconsistent data field positions and meanings. Through unit conversion and numerical conversion, the device's original data is converted into standard units and standard values, eliminating the incomparability problem caused by different units used by different devices. Encapsulating the processed data into a unified standard JSON data model solves the problem of inconsistent data formats among heterogeneous devices, allowing upper-layer application systems to use a unified data parsing logic to process data from all devices, greatly simplifying the complexity of application development. Through scenario-based implementation, differentiated data processing strategies are provided for different business scenarios, meeting various application needs such as periodic monitoring, event-driven response, and on-demand querying, thereby improving the applicability and usability of the system.

[0093] In one embodiment of this example, when the native communication protocol is WiFi, the corresponding original data packet is a device-private TCP protocol packet; when the native communication protocol is Zigbee, the corresponding original data packet is a Zigbee device message; and when the native communication protocol is Bluetooth, the corresponding original data packet includes BLE broadcast data, connection state change data, and feature value change data.

[0094] Specifically, when the native communication protocol is WiFi, a TCP long connection pool is used for management, parsing the device's private TCP protocol packets and converting them into MQTT Publish messages through a protocol mapping table. When the native communication protocol is Zigbee, the Zigbee2MQTT framework is integrated, receiving Zigbee device messages through the Zigbee coordinator, supporting the Zigbee 3.0 standard and vendor extension clusters, and automatically converting them into MQTT messages. When the native communication protocol is Bluetooth, the BLE GATT service scanning mechanism is used to establish a bridge between Bluetooth devices and MQTT, and the BLE2MQTT module enables real-time conversion of BLE broadcast data, connection state change data, and feature value change data.

[0095] When the native communication protocol is WiFi, the corresponding raw data packets are device-private TCP protocol packets. WiFi devices typically communicate with the platform using TCP long connections. To efficiently manage a large number of concurrent connections, a TCP long connection pool management mechanism is used. The connection pool pre-establishes and maintains a certain number of TCP connections. When a WiFi device connects, an idle connection is allocated from the connection pool. When the device disconnects, the connection is returned to the connection pool, avoiding the performance overhead caused by frequent connection establishment and disconnection operations.

[0096] Device-specific TCP protocol messages typically contain custom headers and payloads. The header defines control information such as message type, data length, and sequence number. The parsing process first reads the header, verifies the integrity and validity of the message, checks if the data length field matches the actual received data length, and verifies the checksum field to ensure that the data has not been tampered with during transmission.

[0097] After successful verification, the service type of the data is determined based on the message type field, such as a heartbeat message, data reporting message, or response message. For data reporting messages, the data payload is extracted, which contains the service data to be reported by the device. A protocol mapping table is used to convert private protocols to MQTT messages; this table defines the correspondence between fields of the private protocol and attributes of the MQTT message.

[0098] The conversion process extracts the values ​​of each field from the private protocol message according to the mapping table and fills them into the corresponding positions in the MQTT Publish message to generate a standard MQTT message format. This mapping and conversion mechanism solves the incompatibility problem between WiFi device private protocols and the standard MQTT protocol, enabling WiFi devices using private protocols to seamlessly access the MQTT message bus and achieve data interoperability with devices using other protocols. This avoids the workload of developing separate interface adapters for each private protocol, improving the system's versatility and scalability.

[0099] When the native communication protocol is Zigbee, the corresponding raw data packets are Zigbee device messages. Zigbee devices communicate with the Zigbee coordinator through the Zigbee network. The coordinator, as the central node of the network, is responsible for network setup, device addition, and data forwarding. To enable Zigbee device access, the Zigbee2MQTT open-source framework is integrated. This framework provides complete conversion capabilities from the Zigbee protocol to the MQTT protocol.

[0100] The Zigbee coordinator receives messages from Zigbee devices. These messages conform to the Zigbee application layer protocol specification and include cluster IDs, command IDs, and attribute data. The Zigbee 3.0 standard defines a series of general clusters, such as switch clusters, dimming clusters, and temperature measurement clusters. Different types of devices support different cluster combinations. The Zigbee2MQTT framework has built-in support for Zigbee 3.0 standard clusters and can automatically identify and parse messages from standard clusters.

[0101] For vendor-extended clusters, the framework supports defining the structure and parsing rules of extended clusters through configuration files, enabling support for non-standard clusters. When the coordinator receives a Zigbee device message, the Zigbee2MQTT framework uses the cluster ID and command ID in the message to find the corresponding parsing rules, extract attribute data, and convert the data into JSON format.

[0102] The converted data includes information such as device identifier, device type, attribute name, and attribute value. The framework automatically encapsulates the converted JSON data into an MQTT Publish message and publishes it to a predefined MQTT topic. The topic format is typically "zigbee2mqtt / {device-friendly name}".

[0103] By integrating the Zigbee2MQTT framework, the difficulties in access caused by the high complexity of the Zigbee protocol and the diversity of device types are solved. The mature open-source framework is used to quickly realize standardized access of Zigbee devices, support mainstream Zigbee devices on the market, significantly reduce development costs and time, and improve the system's compatibility with the Zigbee ecosystem.

[0104] When the native communication protocol is Bluetooth, the corresponding raw data packets include BLE broadcast data, connection state change data, and feature value change data. Bluetooth Low Energy devices use the GATT service architecture, publishing device information via broadcast and exchanging data via connection.

[0105] To enable Bluetooth device access, a BLE GATT service scanning mechanism is employed. The platform's Bluetooth adapter continuously scans for broadcast packets from surrounding BLE devices. These broadcast packets contain information such as device address, device name, service UUID, and manufacturer data. Upon detecting a device, the device type is determined based on its service UUID. For devices requiring access, a GATT connection is established, and the device's service list and feature list are retrieved.

[0106] Features are the basic data units of the GATT service. Each feature has a unique UUID and specific attributes, such as readable, writable, and notification-enabled. For features with notification attributes, users can subscribe to feature value change notifications. When a device's feature value changes, the device will proactively push a notification message.

[0107] The BLE2MQTT module is used to convert Bluetooth data into MQTT messages. This module listens for BLE broadcast data, connection state change events, and characteristic value change notifications. When BLE broadcast data is received, the module parses the manufacturer or service data in the broadcast packet, extracts the attribute values ​​reported by the device, converts the data into JSON format, and publishes it to the MQTT topic.

[0108] When a connection status change is detected, such as a successful device connection or disconnection, a status change event message is generated and published to the device status topic for upper-layer applications to monitor the device's online status. When a feature value change notification is received, the feature value data is read, the data type is determined based on the feature UUID, data parsing and transformation are performed, and the data is encapsulated into an MQTT message for publication.

[0109] By establishing a bridge between Bluetooth devices and MQTT, the access difficulties caused by the short communication distance and limited number of connections of Bluetooth devices are solved. This enables Bluetooth devices to interact with other devices and application systems through the MQTT message bus, expanding the application scenarios of Bluetooth devices and improving the system's support for the Bluetooth ecosystem.

[0110] This embodiment effectively solves the technical challenge of unified access for multi-protocol devices by designing dedicated access and conversion mechanisms for three mainstream IoT communication protocols: WiFi, Zigbee, and Bluetooth. For WiFi devices, TCP long connection pool management and protocol mapping table conversion are used to resolve the incompatibility issue between proprietary protocols and the standard MQTT protocol, achieving efficient connection management and protocol conversion. For Zigbee devices, the Zigbee2MQTT framework is integrated, utilizing a mature open-source solution to quickly achieve standardized access for Zigbee devices, supporting the Zigbee 3.0 standard and vendor extension clusters, thus solving the access difficulties caused by the high complexity of the Zigbee protocol and the diversity of device types. For Bluetooth devices, the BLE GATT service scanning mechanism and BLE2MQTT bridging module are adopted to solve the access difficulties caused by the short communication distance and limited number of connections of Bluetooth devices, enabling real-time conversion and publication of BLE broadcast data, connection state change data, and feature value change data. Through this multi-protocol adaptation strategy, the system can simultaneously support device access via WiFi, Zigbee, and Bluetooth protocols, covering the most mainstream communication protocols in the IoT field. This meets the device access needs of different application scenarios, provides a solid technical foundation for building a unified IoT management platform, and significantly improves the system's compatibility and applicability.

[0111] In one embodiment of this example, in response to a device control command sent by an upper-layer application system, the device control command is converted back into a control message in the native protocol format of the IoT device based on a rule engine, and the native protocol format control message is sent to the IoT device through a multi-protocol adaptation layer, including the following steps: S510: In response to the device control command sent by the upper-layer application system, the communication protocol type and target data conversion rules of the IoT device are determined based on the device model in the device control command using the rule engine. The device control command adopts the standard JSON format. S520: Based on the target data conversion rules, the device control commands are reverse-converted into the native protocol format control messages of the IoT devices. S530 sends native protocol format control messages to IoT devices through the protocol adapter corresponding to the communication protocol type in the multi-protocol adaptation layer.

[0112] In response to device control commands sent by the upper-layer application system, the rule engine determines the communication protocol type and target data conversion rules of the IoT device based on the device model in the control command. The device control commands sent by the upper-layer application system adopt a unified standard JSON format, ensuring that different application systems use the same control interface and reducing the complexity of system integration.

[0113] The standard JSON format control command contains the necessary field information, including the device identifier field "deviceId" to uniquely identify the target device, the service key value field "service" to specify the type of service to be invoked, the input parameter field "params" to pass the parameters required for the service call, and the optional request identifier field "requestId" to track the execution status of the control command.

[0114] After receiving the control command, the rules engine first extracts the value of the device identifier field, "AC-CT05-00456," from the command. Based on the device identifier, it queries the device file database to obtain the device's complete file information. The device file information includes key information such as device model, communication protocol type, device status, and registration time. The device model field, for example, "AC-CT05," is extracted from the file information; this model number identifies the device's product category and specifications.

[0115] Further query the device model database based on the device model to obtain the communication protocol type of that device model. The device model database stores the technical parameters of each device model, including the communication protocol type field, which clearly identifies the communication protocol used by the device, such as "WiFi", "Zigbee" or "BLE".

[0116] After determining the communication protocol type, the corresponding target data transformation rule is loaded from the rule engine's rule base based on the device model. The target data transformation rule is a reverse transformation rule that defines how to convert standard JSON format control commands into the device's native protocol format. The rule content includes a service mapping table, defining the correspondence between standard service key values ​​and native protocol command codes; a parameter mapping table, defining the mapping between JSON parameter fields and native protocol parameter bytes; and a message construction template, defining the structure of the native protocol message and the assembly order of each field.

[0117] This device model-based rule loading mechanism solves the problem of different control command formats for different device models, enabling unified management and flexible configuration of control logic. When a new device model needs to be supported, only the conversion rule for that model needs to be added to the rule base, without modifying the core control process code. This greatly improves the scalability and maintainability of the system and provides technical support for supporting the unified control of a large number of heterogeneous devices.

[0118] Based on the target data conversion rules, device control commands are reverse-converted into control messages in the native protocol format of IoT devices. The reverse conversion process first parses the service key-value field in the control command; for example, "setTemp" represents the temperature setting service. Then, according to the service mapping table in the target data conversion rules, the corresponding native protocol command code is looked up. The service mapping table is stored in key-value pair format, for example, {"setTemp": 0x10, "setMode": 0x11, "setPower": 0x12}. The lookup result yields command code 0x10.

[0119] Next, the input parameter field "params" in the control command is parsed. This field contains all the parameters required for the service call. For the temperature setting service, the parameter is {"temperature": 26}, indicating that the target temperature is 26 degrees Celsius. Based on the parameter mapping table in the target data conversion rules, the representation of the parameter "temperature" in the native protocol message is determined. The parameter mapping table defines the parameter's data type, byte length, byte order, and value range.

[0120] For example, the mapping rule for temperature parameters can be: data type is unsigned integer, byte length is 1 byte, value range is 16-30, and unit is degrees Celsius. The parameter value 26 in JSON format is converted to the byte value 0x1A. If the parameter value exceeds the range, boundary checks and exception handling are performed; for example, if the temperature value is less than 16, it is automatically adjusted to 16, and if it is greater than 30, it is automatically adjusted to 30, ensuring the validity of the control command.

[0121] After parameter conversion, a complete native protocol format control message is assembled according to the message construction template. The message construction template defines the message structure, including the order and length of the message header, command code, parameters, checksum, etc. For example, the control message structure of an air conditioning device can be: start flag (1 byte, fixed value 0xAA), device address (1 byte), data length (1 byte), command code (1 byte), parameters (variable length), and checksum (1 byte, using XOR checksum).

[0122] Fill in each field according to the template. The start flag is filled with 0xAA. The device address is obtained from the device file, for example, 0x01. The data length is calculated as the total number of bytes for the command code and parameters; in this example, it's 2 bytes. The command code is filled with 0x10, and the parameters with 0x1A. Calculate the checksum by XORing all bytes of the device address, data length, command code, and parameters to obtain the checksum 0x08. The final assembled native protocol format control message is the hexadecimal byte sequence "AA 01 02 10 1A08".

[0123] This rule-based reverse conversion mechanism solves the problem of incompatibility between standard control commands and device proprietary protocols, realizes automated conversion of control commands, avoids the workload of writing control logic separately for each device, ensures that control commands can be correctly identified and executed by the device, and improves the reliability and accuracy of device control.

[0124] The native protocol format control messages are sent to IoT devices via protocol adapters corresponding to the communication protocol type in the multi-protocol adaptation layer. The multi-protocol adaptation layer contains various protocol adapters, each responsible for handling device communication according to a specific protocol. Based on the communication protocol type determined in the preceding steps, the corresponding protocol adapter is selected for message sending.

[0125] For WiFi protocol devices, a WiFi adapter is used, which maintains a TCP connection with the WiFi device. The system searches for a connection corresponding to the target device in the TCP long connection pool. If the connection is active, it is used directly to send control messages. If the connection is broken or does not exist, an attempt is made to re-establish the TCP connection. Control messages are sent only after the connection is successfully established. During the sending process, the byte sequence of the native protocol format control message is written into the TCP socket's send buffer, triggering the underlying network protocol stack to encapsulate the data into TCP packets and transmit them to the device via the WiFi network. Upon receiving the control message, the device parses the message content, executes the corresponding control action, and may return an execution result message confirming that the control command was successfully executed.

[0126] For Zigbee protocol devices, a Zigbee adapter is used, which communicates with the Zigbee device through a Zigbee coordinator. The native protocol format control messages are converted into Zigbee application layer data frames, the target device's short address or IEEE address is set, the cluster ID and command ID are specified, and the parameter portion of the control message is used as the command payload. The data frame is sent through the Zigbee coordinator's API interface. The coordinator is responsible for routing the data frame to the target device, transmitting it through multiple hops in the Zigbee network, and finally reaching the target device. Upon receiving the data frame, the device identifies the control command type based on the cluster ID and command ID, extracts the parameters from the command payload, and executes the control action.

[0127] For Bluetooth protocol devices, a Bluetooth adapter is used to manage the GATT connection with the BLE device. An established GATT connection is located based on the device identifier. If a connection exists, the characteristic UUID corresponding to the control service is located. The byte sequence of the native protocol format control message is written to this characteristic value, triggering the characteristic value write operation. Upon receiving the characteristic value write request, the BLE device reads the characteristic value data, parses the control message, and executes the control action. If the device supports characteristic value write responses, it will return the write result, confirming that the control command has been received and processed.

[0128] By using a unified scheduling and distribution mechanism for multi-protocol adaptation layers, the problem of different control methods for devices with different protocols is solved, and transparent control commands are delivered. Upper-layer application systems do not need to care about the details of the underlying communication protocols; they only need to send control commands in standard JSON format, and the system automatically completes protocol conversion and message delivery, which greatly simplifies the implementation complexity of device control and improves the ease of use and maintainability of the system.

[0129] This embodiment unifies the control interface of upper-layer application systems by adopting standard JSON format device control commands, resolving the inconsistency of control interfaces between different application systems, reducing the complexity of system integration, and enabling various application systems to control all devices in the same way, thus improving system interoperability. Based on a rule engine, the communication protocol type and target data conversion rules are determined according to the device model, enabling dynamic configuration and flexible management of control logic. This solves the problem of hard-coded coupling between control logic and device type. When supporting new device models, only the corresponding conversion rules need to be added, without modifying the core code, significantly improving system scalability. Based on the target data conversion rules, standard control commands are reverse-converted into native protocol format control messages, resolving the incompatibility between standard control commands and device-specific protocols. This achieves automated conversion of control commands, ensuring that control commands can be correctly recognized and executed by the device, improving the reliability and accuracy of device control. Through a unified scheduling and distribution mechanism of the multi-protocol adaptation layer, the corresponding protocol adapter is selected for message distribution based on the device's communication protocol type, resolving the issue of differentiated control methods for devices with different protocols. This achieves transparent distribution of control commands, eliminating the need for upper-layer application systems to concern themselves with the details of the underlying communication protocol, greatly simplifying the implementation complexity of device control. In summary, this technical solution effectively solves the technical challenge of unified control of multi-protocol IoT devices through standardized control interfaces, dynamic rule configuration, and automated protocol conversion. It enables unified management and efficient control of heterogeneous devices, providing a solid technical foundation for building an intelligent IoT management platform.

[0130] In one embodiment of this invention, before identifying the service type of the payload data based on data transformation rules and determining the service type corresponding to the payload data, the following steps are included: S610. When an IoT device is connected for the first time and completes the creation of its device profile, obtain the data conversion rule script corresponding to the IoT device. S620. Perform lexical and syntactic analysis on the data transformation rule script to generate an abstract syntax tree; S630. Perform a post-order traversal of the abstract syntax tree and flatten the abstract syntax tree into a one-dimensional parsing instruction array, wherein each instruction in the one-dimensional parsing instruction array includes an opcode field, a relative memory offset field, and a destination register number field. S640: Bind the one-dimensional parsing instruction array to the device model of the IoT device and store it in the read-only memory area.

[0131] This includes performing lexical and syntactic analysis on the data transformation rule script to generate an abstract syntax tree, including: Lexical scanning is performed on the data transformation rule script to identify keywords, identifiers, operators, and literals in the script, and to generate a sequence of lexical units; Syntactic analysis is performed on lexical unit sequences based on predefined grammar rules to construct expression trees and statement trees; Perform semantic analysis on expression trees and statement trees to verify variable declarations, type matching, and scope rules; The validated expression tree and statement tree are combined into a complete abstract syntax tree. The node types of the abstract syntax tree include operation nodes, variable nodes, and constant nodes.

[0132] Perform a post-order traversal of the abstract syntax tree and flatten it into a one-dimensional array of parsing instructions, including: A depth-first search algorithm is used to perform a post-order traversal of the abstract syntax tree; During the traversal, when an operation node is accessed, the corresponding opcode is generated based on the operation type of the operation node; When a variable node is accessed, the relative memory offset is calculated based on the variable node's position in the original data packet. When a constant node is accessed, its value is preloaded into the specified virtual register. Assign a target register number to each generated opcode to store the result of the operation. Following the access order of the post-order traversal, the generated opcode, relative memory offset, and target register number are added to the parsed instruction array in sequence; Instruction optimization is performed on the parsed instruction array to eliminate redundant memory read operations and duplicate register allocations.

[0133] When an IoT device connects for the first time and completes device profile creation, the corresponding data conversion rule script is retrieved. Initial device connection refers to the device's first connection to the IoT platform, at which point the platform has not yet established a complete management profile for the device.

[0134] During device access, the platform first receives a device description message reported by the device, parses the message to obtain basic device information, including device identifier, device model, manufacturer information, firmware version, etc. Based on this information, the platform creates a new device profile record in the device profile database, recording the device's registration time, initial status, and configuration parameters.

[0135] After the device profile is created, the platform needs to configure data transformation rules for the device to support subsequent data parsing and transformation operations. The data transformation rules are stored as scripts, written in a domain-specific language designed to describe data parsing logic, characterized by simplicity, readability, and maintainability.

[0136] The process of obtaining data transformation rule scripts first involves searching for matching script files in the rule script library based on the device model. The rule script library is organized by device model, with each model corresponding to one or more script files. The script files can be named in the format "device model_version number.script", for example, "ENV-MS01_v1.2.script".

[0137] The search process supports both exact matching and fuzzy matching. Exact matching prioritizes scripts that exactly match the device model. If no matching is found, fuzzy matching searches for scripts with the same model prefix. If a matching script exists in the rule script library, its content is read from the library. The script content is in text format and includes data field definitions, parsing rules, conversion functions, and other information. If no matching script exists in the rule script library, a basic script template is automatically generated based on the device capability information. This basic script template contains standard data field definitions and default parsing rules, which administrators can modify and improve upon.

[0138] This scripted rule management mechanism solves the system rigidity problem caused by hard-coding data conversion rules, realizes the external configuration and dynamic loading of rules. When the device firmware upgrade causes the data format to change, only the script file needs to be updated, without recompiling and deploying the system. This greatly improves the system's flexibility and maintainability, and provides technical support for supporting rapidly iterating IoT devices.

[0139] The data transformation rule script undergoes lexical and syntactic analysis to generate an abstract syntax tree. Lexical analysis is the first stage of the compilation process, responsible for decomposing the script text into a series of lexical units. The lexical scanner reads the script content character by character, identifying different types of lexical units according to predefined lexical rules.

[0140] Lexical unit types include keywords, identifiers, operators, literals, delimiters, and comments. Keywords are reserved words with special meanings in scripting languages; for example, "field" defines a field, "extract" extracts data, and "convert" performs numerical conversions. Identifiers are user-defined names used to represent variables, fields, or functions. Operators include arithmetic operators, comparison operators, and logical operators. Literals represent constant values, including integer literals, floating-point literals, and string literals.

[0141] The lexical scanner organizes the identified lexical units into a sequence of lexical units, each containing type, value, and position information. After lexical analysis, the syntax analysis phase begins. The syntax analyzer analyzes the sequence of lexical units based on predefined syntax rules to verify the correctness of the script's syntactic structure.

[0142] The syntax rules are defined using context-free grammars, describing the syntactic structure of the scripting language. The parser employs recursive descent parsing or LR parsing, constructing expression trees and statement trees based on the syntax rules. The expression tree represents the computational structure of arithmetic or logical expressions, with internal nodes representing operators and leaf nodes representing operands.

[0143] After syntax analysis is complete, semantic analysis is performed to verify the semantic correctness of the script. Semantic analysis checks whether variables have been declared before use, whether the types in expressions match, and whether the variable scope is valid. If semantic analysis passes, the validated expression tree and statement tree are combined into a complete abstract syntax tree.

[0144] Abstract Syntax Trees (ABSTs) are intermediate representations of scripts, preserving semantic information while removing syntactic details, facilitating subsequent optimization and code generation. ABST node types include operation nodes, variable nodes, and constant nodes. Operation nodes represent computational operations, variable nodes represent data fields, and constant nodes represent literal values.

[0145] By generating an abstract syntax tree through lexical and syntactic analysis, the problem of script text being difficult to execute directly is solved. The script is converted into a structured intermediate representation, laying the foundation for subsequent compilation optimization and instruction generation, and ensuring that data transformation rules can be executed efficiently and accurately.

[0146] The abstract syntax tree (API) is traversed in post-order traversal, and then flattened into a one-dimensional array of parsing instructions. Post-order traversal is a tree traversal method that visits the left subtree first, then the right subtree, and finally the root node. A depth-first search algorithm is used to implement post-order traversal, with recursion or a stack data structure used for traversal control.

[0147] The characteristic of post-order traversal is that when a node is visited, all its child nodes have already been visited. This order is well-suited for expression evaluation and code generation because operands must be prepared before operators. During traversal, corresponding parsing instructions are generated based on the type of the visited node.

[0148] When an operation node is accessed, it represents an operation, such as addition, subtraction, multiplication, division, or bitwise operations. A corresponding opcode is generated based on the operation type of the operation node. The opcode is the core part of the instruction, identifying the operation to be performed. Opcodes are represented using enumerated values; for example, ADD represents addition, SUB represents subtraction, and LOAD represents loading data from memory.

[0149] When a variable node is accessed, it represents a data field that needs to be extracted from the original datagram. The relative memory offset is calculated based on the variable node's position in the original datagram; the relative memory offset refers to the byte offset of the field relative to the start address of the datagram.

[0150] When a constant node is accessed, it represents a literal value. The value of the constant node is preloaded into a specified virtual register, which is a temporary storage unit used to store intermediate results during instruction execution. Virtual registers are identified by numbers.

[0151] Each generated opcode is assigned a destination register number, which stores the result of the operation. Register allocation uses a greedy algorithm, prioritizing the reuse of already freed registers to reduce the total number of registers in use.

[0152] Following the post-order traversal access order, the generated opcode, relative memory offset, and destination register number are sequentially added to the parsed instruction array, forming a one-dimensional instruction sequence. Each instruction in the instruction array includes an opcode field, a relative memory offset field, and a destination register number field.

[0153] After the instruction array is generated, instruction optimization is performed to eliminate redundant memory read operations and duplicate register allocations. The optimization process scans the instruction array to identify whether consecutive LOAD instructions read the same memory location; if so, duplicate LOAD instructions are eliminated, and already loaded registers are reused. Unused intermediate result registers are identified and released for use by subsequent instructions.

[0154] By flattening the abstract syntax tree into a one-dimensional parsing instruction array, the problem of inefficient execution of tree structures is solved. The complex tree structure is transformed into a linear sequence of instructions, which facilitates the sequential execution and fast parsing of instructions, providing a technical foundation for achieving high-performance data conversion.

[0155] The one-dimensional parsing instruction array is bound to the device model of the IoT device and stored in a read-only memory area. The binding process establishes a mapping relationship between the device model and the parsing instruction array, ensuring that the corresponding instruction array can be quickly located based on the device model during subsequent data parsing.

[0156] The binding relationships are stored using a hash table data structure, with the device model as the key and the memory address of the instruction array as the value. The hash table supports constant-time lookup operations, ensuring efficient instruction loading.

[0157] After binding is complete, the parsed instruction array is stored in a read-only memory area. The read-only memory area is a special region of system memory whose contents cannot be modified after initialization and are write-protected. Storing the instruction array in the read-only memory area has several advantages.

[0158] First, the contents of a read-only memory region remain unchanged during system operation, avoiding the risk of accidental modification or corruption of the instruction array and ensuring the stability and reliability of data parsing logic. Second, read-only memory regions are typically mapped to fixed addresses in physical memory, resulting in fast access speeds without the need for complex memory management and address translation, thus improving the efficiency of instruction loading and execution. Third, read-only memory regions can be shared by multiple processing threads or processes without the need for mutex lock protection, avoiding performance bottlenecks caused by concurrent access.

[0159] The stored procedure first allocates sufficient memory space in the read-only memory region. The size of the space is calculated based on the length of the instruction array, with each instruction occupying a fixed number of bytes. After allocation, the contents of the instruction array are copied line by line to the read-only memory region. The copying process uses a memory copy function to ensure data integrity and correctness. After copying, the memory page's protection attribute is set to read-only to prevent subsequent write operations.

[0160] By storing the instruction array in a read-only memory region, the problems of easy tampering and low access efficiency of instruction data are solved, ensuring the security and execution efficiency of data transformation rules and providing technical support for achieving high-performance and highly reliable data parsing. At the same time, the use of read-only memory regions reduces the overhead of memory fragmentation and garbage collection, optimizes system memory management, and improves overall performance.

[0161] This embodiment solves the technical challenge of dynamically loading and efficiently executing data conversion rules by acquiring and compiling the data conversion rule script upon initial device access. Employing a script-based rule management approach enables externalized rule configuration, resolving system rigidity issues caused by hard-coded rules. When device firmware upgrades or data formats change, only the script file needs updating, eliminating the need for system recompilation and deployment, significantly improving system flexibility and maintainability. By generating an abstract syntax tree through lexical and syntactic analysis, the script text is converted into a structured intermediate representation, addressing the difficulty of directly executing script text and laying the foundation for subsequent compilation optimization and instruction generation. Furthermore, by performing a post-order traversal and flattening of the abstract syntax tree into a one-dimensional parsing instruction array, the problem of inefficient execution of tree-like structures is solved. The complex tree structure is transformed into a linear instruction sequence, facilitating sequential instruction execution and rapid parsing, significantly improving the execution efficiency of data conversion. By binding the parsed instruction array to the device model and storing it in a read-only memory area, the problems of easy tampering and low access efficiency of instruction data are solved, ensuring the security and execution efficiency of data conversion rules. The write protection feature of the read-only memory area prevents accidental modification of instructions, the fixed memory address mapping improves access speed, and the shared access feature avoids the performance overhead of concurrency control. Instruction optimization eliminates redundant operations, further improving instruction execution efficiency and reducing the number of memory accesses and registers used. In summary, this technical solution, through a complete process of script compilation, abstract syntax tree transformation, instruction array generation, and read-only memory storage, achieves efficient compilation and secure execution of data conversion rules, providing a solid technical foundation for supporting real-time data parsing of massive heterogeneous IoT devices, and significantly improving system performance, security, and scalability.

[0162] In one embodiment of this example, refer to Figure 2 The protocol layer parsing of the original data message yields the payload data, including the following steps: S710: Strip the network protocol stack shell of the original data packet to extract the binary payload data; S720: Writes binary payload data to a pre-allocated circular memory buffer in zero-copy mode; S730: Append a slice ruler header before the physical memory starting address of the binary payload data. The slice ruler header includes the payload starting memory offset, byte order identifier and total payload length. S740: Based on the slice ruler header and binary payload data, a standardized memory block to be processed is formed to obtain the net payload data.

[0163] Specifically, a slice ruler header is appended before the physical memory starting address of the binary payload data, including: The protocol-specific byte order is determined based on the communication protocol type of the original data message; When the communication protocol type is WiFi, the byte order flag of the TCP packet is detected to determine whether the byte order is big-endian or little-endian. When the communication protocol type is Zigbee, the byte order is determined to be little-endian according to the Zigbee protocol specification; When the communication protocol type is Bluetooth, the byte order is determined to be little-endian according to the Bluetooth HCI event format; Calculate the starting offset and total length of the binary payload data in the circular memory buffer; Write the slice ruler header in a fixed-length region before the physical memory starting address of the binary payload data; The data structure of the slice ruler header includes a start offset field, a byte order identifier field, and a total length field. The start offset field occupies four bytes, the byte order identifier field occupies one byte, and the total length field occupies four bytes.

[0164] By stripping away the network protocol stack shell from the original data packet, the binary payload data is extracted. When the original data packet arrives at the platform from the IoT device via the network, it carries a complete network protocol stack encapsulation structure, including multi-layered protocol headers at the physical layer, data link layer, network layer, transport layer, and application layer. These protocol headers are used to implement routing, addressing, flow control, and reliability assurance functions for network transmission, but they are redundant information for data parsing and need to be stripped to extract the actual business data.

[0165] The stripping process employs different processing strategies depending on the type of communication protocol. For WiFi protocol devices, the original data packets are encapsulated using the TCP / IP protocol stack. The stripping process first locates the beginning of the Ethernet frame, reads the 14 bytes of the Ethernet frame header, including a 6-byte destination MAC address, a 6-byte source MAC address, and a 2-byte type field. The type field is verified to be 0x0800, indicating the IPv4 protocol.

[0166] Next, locate the start of the IP header, read the first 20 bytes, and extract fields such as version number, header length, and total length. Determine the actual length of the IP header based on the header length field. If options fields exist, the variable-length options section needs to be read additionally. Then, locate the start of the TCP header, read the first 20 bytes, and determine the actual length of the TCP header based on the data offset field. If TCP options exist, the options section needs to be read additionally. After stripping away all protocol headers, the remaining data is the application layer's binary payload data.

[0167] For Zigbee protocol devices, the raw data packets conform to IEEE 802.15.4 and the Zigbee protocol stack specification. The stripping process first processes the physical layer frames, removing the preamble and start-of-frame delimiter. Then, it processes the MAC layer frames, reading the frame control field, sequence number, address information, and auxiliary security header. The length of the address field is determined based on the address pattern in the frame control field, and the MAC layer header is stripped. Next, it processes the network layer frames, stripping the network layer header. Finally, it extracts the payload data from the application support sublayer.

[0168] For Bluetooth protocol devices, BLE data packets contain multiple layers of encapsulation, including HCI, L2CAP, and ATT layers. The stripping process first processes HCI event packets, reading fields such as event type and parameter length, and then stripping the HCI header. Next, it processes L2CAP data packets, reading the length and channel ID fields, and then stripping the L2CAP header. Finally, it processes ATT protocol data, reading the opcode and handle fields, and extracting attribute value data.

[0169] By stripping the protocol layers, the various protocol encapsulation layers added during network transmission are effectively removed, and the actual business data that the device needs to report is extracted. This solves the problem of low data processing efficiency caused by protocol header redundancy, provides clean input for subsequent data parsing, and avoids interference from protocol header information with the data parsing logic.

[0170] The binary payload data is written to a pre-allocated circular memory buffer in zero-copy mode. Zero-copy mode is an efficient data transfer technique that avoids multiple copy operations between kernel space and user space, and directly references and transfers data in memory, significantly reducing CPU overhead and memory bandwidth usage.

[0171] A circular memory buffer is a special data structure that organizes memory space in a circular queue manner. It has a fixed capacity and manages data read and write operations through read and write pointers. The circular buffer is pre-allocated during system initialization, and the allocated memory space is contiguous and of a fixed size. The circular buffer maintains two pointers: a write pointer pointing to the next writable position and a read pointer pointing to the next readable position. When the write pointer reaches the end of the buffer, it automatically wraps back to the beginning of the buffer, creating a circular usage effect.

[0172] The zero-copy write process first checks the available space in the circular buffer. The available space can be calculated as follows: if the write pointer is greater than or equal to the read pointer, the available space is the total buffer capacity minus the write pointer position plus the read pointer position; if the write pointer is less than the read pointer, the available space is the read pointer position minus the write pointer position. If the available space is insufficient to hold the binary payload data, the buffer full handling logic is triggered. This can either block and wait for the read pointer to advance to release space, or discard the old data to free up space.

[0173] If sufficient space is available, the memory address and length information of the binary payload data are recorded in the metadata area of ​​the circular buffer without performing an actual data copy. The metadata area stores descriptive information about the data blocks, including the start address, length, and status flags of the data blocks. The write pointer advances the corresponding length, pointing to the next writable location.

[0174] By adopting the zero-copy mode, the performance bottleneck caused by traditional data copying is solved. It avoids repeated copying of data between multiple memory areas, reduces the number of memory accesses and CPU cycle consumption, and significantly improves the throughput and response speed of data processing. It is particularly suitable for high-concurrency, high-traffic IoT data access scenarios.

[0175] A slice ruler header is appended before the physical memory starting address of the binary payload data. The slice ruler header includes the payload's starting memory offset, byte order identifier, and total payload length. The slice ruler header is a metadata structure used to describe the key attributes of the data block, facilitating subsequent data parsing and processing.

[0176] The process of attaching the slice header first determines the protocol-specific byte order based on the communication protocol type of the original data packet. Byte order refers to the storage order of multi-byte data in memory, and there are two types: big-endian and little-endian. Big-endian stores the most significant byte at the lowest address, while little-endian stores the least significant byte at the lowest address. Different communication protocols use different byte order conventions, and correctly identifying the byte order is crucial for accurately parsing multi-byte data.

[0177] When the communication protocol type is WiFi, the byte order flag of the TCP packet is checked to determine whether the byte order is big-endian or little-endian. The TCP / IP protocol stack usually uses network byte order, i.e., big-endian, but some devices' proprietary protocols may use little-endian, which needs to be determined by the flag in the packet or the protocol specification.

[0178] When the communication protocol type is Zigbee, the byte order is determined to be little-endian according to the Zigbee protocol specification. The Zigbee protocol explicitly stipulates that multi-byte data is stored in little-endian order. When the communication protocol type is Bluetooth, the byte order is determined to be little-endian according to the Bluetooth HCI event format. The Bluetooth core specification stipulates that multi-byte data in the HCI layer uses little-endian order.

[0179] After determining the byte order, calculate the starting offset and total length of the binary payload data in the circular memory buffer. The starting offset is the byte offset of the data block relative to the starting address of the buffer, calculated using the current position of the write pointer. The total length is the number of bytes of payload data, determined by the length of the remaining data after stripping the protocol header.

[0180] A fixed-length region is written before the physical memory starting address of the binary payload data to form a slice ruler header. This fixed-length region is reserved before each data block to store metadata information. The slice ruler header data structure includes a start offset field, a byte order identifier field, and a total length field. The start offset field can occupy four bytes and is represented by an unsigned 32-bit integer. The byte order identifier field can occupy one byte and is represented by an enumerated value, where 0 indicates big-endian and 1 indicates little-endian. The total length field can occupy four bytes and is represented by an unsigned 32-bit integer, indicating the number of bytes in the payload data.

[0181] By adding slice ruler headers, the problem of parsing difficulties caused by the lack of descriptive information in data blocks is solved. It provides the necessary metadata support for data parsing, enabling the parsing process to accurately locate the position of data blocks, identify byte order, and determine data length, thus avoiding parsing errors and data misalignment caused by missing metadata.

[0182] Based on the slice scale header and binary payload data, standardized memory blocks to be processed are formed to obtain the net payload data. The standardized memory block to be processed is a unified data representation that combines metadata and actual data to form a self-describing data unit.

[0183] The formation process treats the slice ruler header and the immediately following binary payload data as a single unit. The slice ruler header is located at the beginning of the memory block, followed by the binary payload data. The total size of the normalized memory block to be processed is the length of the slice ruler header plus the length of the payload data. The starting address of the memory block is the same as the starting address of the slice ruler header, and the entire contents of the memory block can be accessed through this address.

[0184] The standardized memory block to be processed has good self-descriptive properties. After receiving the memory block, any processing module first reads the slice ruler header and parses out three key attributes: the starting offset, the byte order identifier, and the total length. Then, it correctly parses the payload data based on these attributes. For example, the parsing module reads the byte order identifier field; if it is 0, it parses the multi-byte data in big-endian order; if it is 1, it parses the multi-byte data in little-endian order.

[0185] By forming standardized memory blocks to be processed, the complexity caused by inconsistent data block formats is resolved. This achieves standardized data representation, enabling different processing modules to access and parse data in a unified manner. It reduces coupling between modules and improves the system's modularity and maintainability. The payload data, which consists of these standardized memory blocks, serves as input for subsequent data transformation processes, ensuring the accuracy and efficiency of data parsing.

[0186] This embodiment effectively removes the layers of protocol encapsulation added during network transmission by stripping the network protocol stack shell of the original data packet, extracting the actual business data that the device needs to report. This solves the problem of low data processing efficiency caused by protocol header redundancy and provides clean input for subsequent data parsing. A zero-copy mode is used to write the binary payload data into a pre-allocated circular memory buffer, solving the performance bottleneck problem caused by traditional data copying. This avoids repeated copying of data between multiple memory areas, reduces memory access counts and CPU cycle consumption, and significantly improves data processing throughput and response speed, making it particularly suitable for high-concurrency, high-traffic IoT data access scenarios. By appending a slice ruler header before the physical memory starting address of the binary payload data, the parsing difficulty caused by the lack of descriptive information in data blocks is solved. This provides necessary metadata support for data parsing, enabling the parsing process to accurately locate the data block position, identify the byte order, and determine the data length, avoiding parsing errors and data misalignment caused by missing metadata. Determining the protocol-specific byte order according to different communication protocol types ensures the correct parsing of multi-byte data and solves the problem of data parsing errors caused by inconsistent byte order. By forming standardized memory blocks to be processed based on slice ruler headers and binary payload data, the complexity caused by inconsistent data block formats is resolved. This achieves standardized data representation, enabling different processing modules to access and parse data in a unified manner, reducing coupling between modules and improving the system's modularity and maintainability. In summary, this technical solution, through a complete process of protocol layer stripping, zero-copy writing, metadata appending, and standardized encapsulation, achieves efficient and accurate protocol layer parsing, providing high-quality input data for subsequent data conversion and processing, and significantly improving system performance and reliability.

[0187] In one embodiment of this invention, service type identification is performed on the payload data based on data transformation rules to determine the service type corresponding to the payload data, including the following steps: S810: Based on the device model to which the standardized memory block to be processed belongs, read the corresponding parsing instruction array from the read-only memory area; S820 starts a lightweight microkernel sandbox and reads the slice ruler header through the lightweight microkernel sandbox to calibrate the memory base address of the binary payload data. The lightweight microkernel sandbox includes an instruction pointer and multiple virtual registers. S830 controls the instruction pointer to execute instructions in the parsed instruction array sequentially, and performs pointer addressing on the physical memory address of the binary payload data according to the relative memory offset field of each instruction; S840: Perform read operations and bitwise operations on the addressed data according to the opcode field of each instruction to obtain the operation result; S850. Store the operation result in the virtual register corresponding to the target register number specified in the opcode field; S860: After the parsing instruction array is executed, the extracted valid data is read from multiple virtual registers.

[0188] The process of controlling the instruction pointer to execute instructions sequentially in the parsed instruction array includes: The instruction pointer is initialized to point to the first address of the parsed instruction array; Read the instruction currently pointed to by the instruction pointer and extract the opcode field of the instruction; The instruction type is determined based on the opcode field. Instruction types include byte read instructions, shift instructions, bit AND instructions, bit OR instructions, and type conversion instructions. When the instruction type is a read byte instruction, the absolute memory address is calculated based on the relative memory offset field of the instruction, and the specified length of byte data is read from the absolute memory address; When the instruction type is a shift instruction, a left or right shift operation is performed on the data in the destination register; When the instruction type is a bitwise AND instruction or a bitwise OR instruction, a bitwise operation is performed on the data in the destination register and the specified mask value. When the instruction type is a type conversion instruction, the byte data in the destination register is interpreted and converted according to the specified data type; Store the result of the instruction execution into the virtual register specified by the instruction's target register number field; Increment the instruction pointer to point to the next instruction in the parsed instruction array; Repeat the above steps until the instruction pointer reaches the end of the parsed instruction array.

[0189] Based on the device model to which the standardized memory block belongs, the corresponding parsing instruction array is read from the read-only memory region. The standardized memory block is associated with a device identifier upon its creation; this identifier allows querying the device file to obtain the device model information. The device model is a unique identifier for the device type; devices of the same model have the same data format and parsing rules.

[0190] The reading process first extracts the device identifier from the metadata of the standardized memory block to be processed. The device identifier is usually stored in the form of a string, such as "ENV-MS01-00123". Based on the device identifier, the device file database is queried to obtain the device file record, and the device model field, such as "ENV-MS01", is extracted from the file record.

[0191] Then, using the device model as the key, the corresponding parsing instruction array is searched in the hash table maintained in the read-only memory area. The hash table uses open addressing or chaining to resolve collisions, and the time complexity of the search operation is constant. After a successful search, the starting address and length of the parsing instruction array in the read-only memory area are obtained.

[0192] The instruction array is stored as a contiguous block of memory, with each instruction occupying a fixed number of bytes. The array length represents the total number of instructions, and the memory range of the entire instruction array can be determined by the starting address and the array length. Read-only memory regions offer fast access speeds, eliminate the need for complex memory management and address translation, and their contents cannot be modified, ensuring the integrity and security of the instruction array.

[0193] By reading the parsing instruction array from the read-only memory area, the problems of low instruction loading efficiency and poor security are solved. The fixed address mapping of read-only memory improves the access speed, and the write protection feature prevents the instructions from being maliciously tampered with, providing a basic guarantee for efficient and secure data parsing.

[0194] The lightweight microkernel sandbox is launched, and the slice ruler header is read from it to calibrate the memory base address of the binary payload data. The lightweight microkernel sandbox is an isolated execution environment used to safely execute parsing instruction arrays, preventing erroneous operations during parsing from affecting other parts of the system.

[0195] The sandbox adopts a microkernel architecture design with streamlined core functions, including only basic functions such as instruction execution, memory access, and register management, avoiding the bloat and complexity of traditional virtual machines. The lightweight microkernel sandbox includes an instruction pointer and multiple virtual registers. The instruction pointer is used to track the current instruction execution position, and the virtual registers are used to store intermediate and final results during instruction execution.

[0196] The sandbox startup process first initializes the instruction pointer, setting it to the starting address of the parsed instruction array. Then, it initializes all virtual registers, clearing their values ​​to ensure a clean execution environment. Next, it configures the sandbox's memory access permissions, restricting access to only the memory region corresponding to the standardized memory block to be processed, and prohibiting access to other memory regions to prevent out-of-bounds access and illegal memory operations.

[0197] After the sandbox starts, the slice ruler header is read from the sandbox. The slice ruler header is located at the beginning of the standardized memory block to be processed. The reading process extracts the values ​​of the start offset field, byte order identifier field, and total length field. The start offset field indicates the position of the binary payload data in the circular memory buffer, the byte order identifier field indicates the byte order of the data, and the total length field indicates the number of bytes of payload data.

[0198] The memory base address for calibrating the binary payload data refers to the absolute memory address of the payload data calculated based on the starting offset. The calculation formula is: the memory base address equals the starting address of the circular memory buffer plus the starting offset. The calibrated memory base address serves as the reference point for subsequent instruction addressing, and all relative memory offsets are calculated based on this base address.

[0199] By launching a lightweight microkernel sandbox and calibrating the memory base address, the problems of lack of isolation protection and inaccurate address positioning in the parsing process are solved. The sandbox provides a safe execution environment, preventing the impact of parsing errors on the system. Memory base address calibration ensures that instructions can accurately access payload data, improving the reliability and accuracy of parsing.

[0200] The instruction pointer executes the instructions in the parsed instruction array sequentially, using the relative memory offset field of each instruction to locate the physical memory address of the binary payload data. Instruction execution follows a sequential execution mode; the instruction pointer starts from the beginning of the parsed instruction array and reads and executes instructions one by one until the end of the array is reached.

[0201] Each instruction contains an opcode field, a relative memory offset field, and a destination register number field. The instruction format is standardized for easy parsing and execution. The instruction execution process first initializes the instruction pointer, setting it to the first address of the parsed instruction array. Then, it enters the instruction execution loop, reads the instruction currently pointed to by the instruction pointer, and extracts the instruction's opcode field.

[0202] The opcode field identifies the type of instruction and the operation to be performed. Instruction types include byte read instructions, bit shift instructions, bitwise AND instructions, bitwise OR instructions, and type conversion instructions. When the instruction type is a byte read instruction, the absolute memory address is calculated based on the relative memory offset field. The calculation formula is: absolute memory address equals memory base address plus relative memory offset.

[0203] After calculating the absolute memory address, read bytes of data of a specified length from that address. The instruction includes a data length field, indicating the number of bytes to be read. The read operation determines the order in which bytes are read based on the byte order identifier field; if it is big-endian, the most significant byte is read first; if it is little-endian, the least significant byte is read first. The read bytes are stored in a temporary buffer, awaiting subsequent bitwise operations.

[0204] When the instruction type is a shift instruction, it performs a left or right shift operation on the data in the destination register. Shift instructions include a shift direction field and a shift number field. The shift direction field indicates whether to shift left or right, and the shift number field indicates the number of bits to shift.

[0205] When the instruction type is a bitwise AND instruction or a bitwise OR instruction, it performs bitwise operations on the data in the destination register and the specified mask value. The mask value is given as an immediate value in the instruction. When the instruction type is a type conversion instruction, it interprets and converts the byte data in the destination register according to the specified data type. Data types include unsigned integers, signed integers, floating-point numbers, etc.

[0206] By using pointer addressing and instruction execution, the problem of automating data extraction and transformation is solved. The instruction-driven execution mode enables the programmability of data parsing logic, eliminating the need to write dedicated parsing code for each data format and greatly improving the system's flexibility and scalability.

[0207] Based on the opcode field of each instruction, read operations and bitwise operations are performed on the addressed data to obtain the result. Read operations and bitwise operations are the core steps of data parsing, through which meaningful data fields are extracted from the original binary data.

[0208] The read operation reads bytes of data at a specified position and length from the binary payload data based on the relative memory offset and data length of the instruction. The read process takes into account the byte order. If the byte order is big-endian, bytes are read from high address to low address, and the most significant byte is placed first when assembling the multi-byte data. If the byte order is little-endian, bytes are read from low address to high address, and the least significant byte is placed first when assembling the multi-byte data.

[0209] Bitwise operations include bit shifting, bitwise AND, bitwise OR, and bitwise XOR, used to extract specific bit fields from byte data or to mask data. The execution of bitwise operations strictly follows the instruction's opcode and operands; operands can come from registers or immediate values ​​in the instruction.

[0210] The result of the operation is the data obtained after the instruction is executed. It can be the extracted field value, the converted numerical value, or the intermediate result of the operation. The data type of the result is determined by the type conversion field of the instruction. By performing read operations and bitwise operations, the problem of parsing complex data formats is solved. It supports the extraction and conversion of complex data formats such as multi-byte data, bit fields, and nested structures, and realizes fine-grained control over data parsing, ensuring the accuracy and completeness of the extracted data.

[0211] The result of the operation is stored in the virtual register corresponding to the target register number specified in the opcode field. The virtual register is a core component of the lightweight microkernel sandbox, used to store data during instruction execution. Each virtual register has a unique number, the range of which is determined by the number of registered registers configured.

[0212] The stored procedure determines the virtual register to be written to based on the destination register number field of the instruction. The write operation directly assigns the result of the operation to the destination register, overwriting the original value. If the data type of the result does not match the width of the register, type expansion or truncation is performed.

[0213] The use of virtual registers follows the write-before-read principle. During instruction execution, the result of the operation is first written to the register, and subsequent instructions can read the register value as an operand. By storing the result of the operation in a virtual register, the problem of temporary storage of intermediate results is solved. Virtual registers provide high-speed data access capabilities, avoid frequent memory read and write operations, and significantly improve the efficiency of instruction execution. At the same time, the use of registers simplifies data transfer between instructions, allowing complex data conversion logic to be implemented through the combination of multiple instructions.

[0214] After the parsing instruction array has finished executing, the extracted valid data is read from multiple virtual registers. The parsing instruction array is considered complete when the instruction pointer reaches the end of the array, and all instructions have been executed. At this point, the virtual registers store the various data extracted and transformed during the parsing process; this data is the valid data, corresponding to the various attribute values ​​or event parameters reported by the device.

[0215] The reading process determines the attributes or parameters corresponding to the data stored in each virtual register according to the defined parsing rules. The parsing rules have already established the mapping relationship between virtual registers and attributes during the compilation phase. The reading process traverses all virtual registers, extracts the value of each register, and determines the attribute key corresponding to that value based on the mapping relationship.

[0216] The extracted valid data is organized into key-value pairs, forming a data dictionary structure. This data dictionary serves as input for subsequent data encapsulation, generating a standard JSON data model. By reading valid data from a virtual register, the collection and organization of parsing results are resolved. The virtual register provides a unified data output interface, simplifying the process of obtaining parsing results and ensuring that all extracted data is collected completely and accurately, providing a reliable data source for subsequent data encapsulation and publication.

[0217] This embodiment solves the problems of low instruction loading efficiency and poor security by reading the parsing instruction array from the read-only memory area according to the device model. The fixed address mapping of read-only memory improves access speed, and write protection prevents malicious tampering of instructions, providing a fundamental guarantee for efficient and secure data parsing. By starting a lightweight microkernel sandbox and calibrating the memory base address, the problems of lack of isolation protection and inaccurate address positioning in the parsing process are solved. The sandbox provides a secure execution environment, preventing the impact of parsing errors on the system, and memory base address calibration ensures that instructions can accurately access the payload data, improving the reliability and accuracy of parsing. By controlling the instruction pointer to execute the instructions in the parsing instruction array sequentially, the problem of automating data extraction and transformation is solved. The instruction-driven execution mode realizes the programmability of data parsing logic, eliminating the need to write dedicated parsing code for each data format, greatly improving the system's flexibility and scalability. By performing read operations and bitwise operations, the problem of parsing complex data formats is solved, supporting the extraction and transformation of complex data formats such as multi-byte data, bit fields, and nested structures, realizing fine-grained control of data parsing, and ensuring the accuracy and integrity of extracted data. By storing the computation results in a virtual register, the problem of temporary storage of intermediate results is solved. The virtual register provides high-speed data access capabilities, avoids frequent memory read and write operations, and significantly improves instruction execution efficiency. By reading valid data from the virtual register, the problem of collecting and organizing parsed results is solved, ensuring that all extracted data can be collected completely and accurately. In summary, this technical solution, through a complete process of instruction array-driven, sandboxed execution, and register-based result storage, achieves efficient, secure, and flexible data parsing, providing strong technical support for real-time data processing of massive heterogeneous IoT devices.

[0218] This application also provides an electronic device, including: The memory is configured to store instructions; and The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned unified access data conversion method for multi-protocol IoT devices.

[0219] Reference Figure 3 This application also provides a unified access data conversion system for multi-protocol IoT devices, including: Electronic devices; Internet of Things (IoT) devices connect to electronic devices.

[0220] In this embodiment, the electronic device can be a tablet computer, desktop computer, laptop computer, handheld computer, wearable device, laptop computer, ultra-mobile personal computer (UMPC), netbook, or other device with a processor. Of course, the electronic device can also be a server. This application embodiment does not impose any special limitations on the specific form of the electronic device.

[0221] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0222] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0223] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0224] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0225] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0226] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0227] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0228] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0229] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for unified access data conversion for multi-protocol IoT devices, characterized in that, include: In response to the device description message reported by the IoT device when it accesses through the multi-protocol adaptation layer, the device description message is parsed to obtain the device capability information, which includes the device model. Based on device capability information and device model, a standard MQTT topic namespace corresponding to the IoT device is generated, and data transformation rules corresponding to the device model are dynamically loaded into the rule engine based on the standard MQTT topic namespace; Based on the rule engine, the raw data packets reported by IoT devices through the native communication protocol are converted into standard MQTT message format to obtain data in standard MQTT message format; Data in standard MQTT message format is published via the MQTT message bus for upper-layer application systems to subscribe to and use; In response to device control commands sent by upper-layer application systems, the rule engine converts the device control commands into control messages in the native protocol format of IoT devices, and then sends the native protocol format control messages to IoT devices through a multi-protocol adaptation layer. Specifically, based on the rule engine, the raw data packets reported by IoT devices through native communication protocols are converted into standard MQTT message format to obtain data in standard MQTT message format, including: The original data message is parsed at the protocol layer to obtain the payload data; Load the corresponding data transformation rules from the rules engine based on the device model of the IoT device; When an IoT device is connected for the first time and a device profile is created, obtain the data conversion rule script corresponding to the IoT device. Perform lexical and syntactic analysis on the data transformation rule script to generate an abstract syntax tree; A depth-first search algorithm is used to perform a post-order traversal of the abstract syntax tree; During the traversal, when an operation node is accessed, the corresponding opcode is generated based on the operation type of the operation node; When a variable node is accessed, the relative memory offset is calculated based on the variable node's position in the original data packet. When a constant node is accessed, its value is preloaded into the specified virtual register. Assign a target register number to each generated opcode to store the result of the operation. Following the access order of the post-order traversal, the generated opcode, relative memory offset, and target register number are sequentially added to the one-dimensional parsed instruction array; Instruction optimization is performed on the one-dimensional parsed instruction array to eliminate redundant memory read operations and duplicate register allocations; Bind the one-dimensional parsing instruction array to the device model of the IoT device and store it in the read-only memory area; Based on data transformation rules, service type identification is performed on the payload data to determine the service type corresponding to the payload data. Extract target attribute values ​​or event parameters from the net load data based on the service type; The extracted target attribute values ​​or event parameters are converted into units and values ​​to obtain processed data. The processed data is then encapsulated into a unified standard JSON data model, which includes a protocol version number, timestamp, device identifier, and data fields. The data fields store the mapping relationship between attribute keys and attribute values ​​in key-value pairs.

2. The method according to claim 1, characterized in that, Device capability information also includes communication protocol type, attribute list, service list, and event list. Based on the device capability information and device model, a standard MQTT topic namespace corresponding to the IoT device is generated. Data transformation rules corresponding to the device model are then dynamically loaded into the rule engine based on the standard MQTT topic namespace, including: Generate an attribute reporting topic for each attribute in the device capability information based on the attribute list. The format of the attribute reporting topic is a combination of a preset prefix, device model and attribute identifier. Generate service invocation topics and service response topics for each service in the device capability information based on the service list; Generate an event notification topic for each event in the device capability information based on the event list; The attribute reporting topic, service call topic, service response topic, and event notification topic are associated with the device model of the IoT device for storage, resulting in a standard MQTT topic namespace. Based on the standard MQTT topic namespace, the data transformation rules corresponding to the device model are dynamically loaded into the rule engine.

3. The method according to claim 1, characterized in that, When the native communication protocol is WiFi, the corresponding raw data packet is a device-private TCP protocol packet. When the native communication protocol is Zigbee, the corresponding raw data packet is a Zigbee device message. When the native communication protocol is Bluetooth, the corresponding raw data packet includes BLE broadcast data, connection state change data, and feature value change data.

4. The method according to claim 1, characterized in that, In response to device control commands sent by the upper-layer application system, the rule engine converts the device control commands back into control messages in the native protocol format of the IoT device, and then sends the native protocol format control messages to the IoT device through a multi-protocol adaptation layer, including: In response to device control commands sent by the upper-layer application system, the rule engine determines the communication protocol type and target data conversion rules of the IoT device based on the device model in the device control command. The device control command adopts the standard JSON format. Based on the target data conversion rules, the device control commands are reverse-converted into control messages in the native protocol format of the IoT device. The native protocol format control messages are sent to IoT devices through the protocol adapter corresponding to the communication protocol type in the multi-protocol adaptation layer.

5. The method according to claim 1, characterized in that, The original data message is parsed at the protocol layer to obtain the payload data, including: By stripping the network protocol stack shell of the original data packet, the binary payload data is extracted. Write the binary payload data to a pre-allocated circular memory buffer in zero-copy mode; Approximate a slice ruler header before the physical memory starting address of the binary payload data. The slice ruler header includes the payload starting memory offset, byte order identifier, and total payload length. Based on the slice ruler header and binary payload data, a standardized memory block to be processed is formed to obtain the net payload data.

6. The method according to claim 5, characterized in that, Service type identification is performed on the payload data based on data transformation rules to determine the service type corresponding to the payload data, including: Based on the device model to which the standardized memory block to be processed belongs, read the corresponding parsing instruction array from the read-only memory area; Start a lightweight microkernel sandbox and read the slice ruler header through the lightweight microkernel sandbox to calibrate the memory base address of the binary payload data. The lightweight microkernel sandbox includes an instruction pointer and multiple virtual registers. The instruction pointer is controlled to execute instructions in the parsed instruction array sequentially, and pointer addressing is performed on the physical memory address of the binary payload data according to the relative memory offset field of each instruction; Based on the opcode field of each instruction, read operations and bitwise operations are performed on the addressed data to obtain the operation result; The result of the operation is stored in the virtual register corresponding to the target register number specified in the opcode field; After the parsing instruction array is completed, the extracted valid data is read from multiple virtual registers.

7. An electronic device, used in the method according to any one of claims 1-6, characterized in that, include: The memory is configured to store instructions; as well as The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the multi-protocol IoT device unified access data conversion method according to any one of claims 1 to 6.

8. A unified access data conversion system for multi-protocol IoT devices, characterized in that, include: The electronic device according to claim 7; an Internet of Things (IoT) device connected to the electronic device.

Images