An internet of things multi-protocol adaptive conversion method based on PID dynamic routing

Abstract

The application provides a PID dynamic routing-based Internet of Things multi-protocol adaptive conversion method, which comprises the following steps: defining a unified bidirectional protocol conversion interface, configuring independent pluggable protocol converter modules for different device types, and establishing a mapping relationship between a device PID set and the converters. After receiving a standard protocol request, the application acquires a device PID according to a device serial number, matches a corresponding protocol converter through dynamic routing, converts the standard protocol message into a device private protocol message through forward conversion, and delivers the device private protocol message; after receiving a device private protocol response, the application multiplexes the corresponding converter to complete reverse standardization conversion, and realizes full-link bidirectional protocol adaptive conversion. The application can realize protocol decoupling adaptation of heterogeneous Internet of Things devices, does not need to change the core process when adding new devices, effectively improves the system expansibility and device universality, and guarantees stable and standardized data interaction of the Internet of Things.

Description

Technical Field

[0001] This application relates to the field of IoT protocol conversion technology, and in particular to an IoT multi-protocol adaptive conversion method based on PID dynamic routing. Background Technology

[0002] With the popularization of IoT technology, various IoT terminal devices from different manufacturers and of different models are being connected to the network on a large scale. Most of these different terminal devices use custom proprietary communication protocols for data interaction, resulting in heterogeneous and diverse device protocols. In contrast, cloud platforms, upper-layer applications, and open interfaces generally use unified standardized protocols for data interaction, creating protocol barriers between the standardized cloud and heterogeneous device terminals. Protocol conversion has become a core element for IoT gateway systems to achieve unified device access and data interoperability.

[0003] Existing IoT protocol conversion methods mostly employ hard-coded, fixed conversion logic, static configuration mapping, or fixed plugin adaptation. These methods result in high coupling between the protocol conversion logic and device type, making it impossible to dynamically route and adaptively convert based on device product identifiers at runtime. Adding new device types requires modifying core code or redeploying configurations, leading to poor scalability. Furthermore, existing solutions struggle to reliably achieve bidirectional protocol conversion across the entire request-response chain, making them unsuitable for business scenarios involving batch command issuance to multiple devices. Overall, their adaptability and scalability fail to meet the application requirements of large-scale IoT device access. Summary of the Invention

[0004] In view of this, the embodiments of this application provide an IoT multi-protocol adaptive conversion method based on PID dynamic routing, which can realize protocol decoupling and adaptation of heterogeneous IoT devices. Adding new devices does not require changes to the core process, effectively improving system scalability and device universality, and ensuring stable and standardized IoT data interaction.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide an IoT multi-protocol adaptive conversion method based on PID dynamic routing, comprising the following steps: A predefined bidirectional protocol conversion interface is provided, which includes a forward conversion method and a reverse conversion method. The forward conversion method is used to convert cloud standard JSON format IoT protocol messages into device private protocol messages, and the reverse conversion method is used to convert device private protocol response messages into cloud standard JSON format IoT protocol messages. For different types of IoT devices, corresponding protocol converter modules are set up respectively, and each of the protocol converter modules is adapted to implement the bidirectional protocol conversion interface, resulting in a pluggable converter component cluster. Multiple sets of product identifier (PID) sets are pre-constructed, and a unique mapping relationship is established between each set of PID sets and the corresponding protocol converter module of the device type. Each set of PID sets stores the product identifiers of all known devices under the corresponding device category. Receive standard protocol control requests from the cloud, extract the device serial number (SN) from the request, and obtain the product identifier (PID) of the target device based on multi-level source return rules; The obtained product identifier (PID) is input into the dynamic routing engine, which performs matching and retrieval in a pre-built set of multiple PIDs to locate the corresponding target protocol converter module and complete its instantiation. The forward conversion method of the instantiated target protocol converter module is called to convert the standard protocol message into a private protocol message that the device can recognize and send it to the corresponding IoT device. The system receives a private protocol response message from an IoT device, locates the same target protocol converter module again by matching the product identifier (PID), and calls the reverse conversion method to convert the private protocol response message into a standard protocol message, thus completing the adaptive protocol conversion.

[0006] Secondly, embodiments of this application also provide an IoT multi-protocol adaptive conversion device based on PID dynamic routing, the device comprising: The interface definition module is used to predefine a bidirectional protocol conversion interface. The bidirectional protocol conversion interface includes a forward conversion method and a reverse conversion method. The forward conversion method is used to convert cloud standard JSON format IoT protocol messages into device private protocol messages. The reverse conversion method is used to convert device private protocol response messages into cloud standard JSON format IoT protocol messages. The protocol adaptation module is used to set up corresponding protocol converter modules for different types of IoT devices. Each of the protocol converter modules is adapted to implement the bidirectional protocol conversion interface, resulting in a pluggable converter component cluster. The configuration module is used to pre-build multiple sets of product identifier (PID) sets, establish a unique mapping relationship between each set of PID sets and the corresponding device type protocol converter module, and store the product identifiers of all known devices under the corresponding device category in each set of PID sets. The identifier acquisition module is used to receive standard protocol control requests sent from the cloud, extract the device serial number (SN) from the request, and obtain the product identifier (PID) of the target device based on multi-level source return rules. The routing retrieval module is used to input the obtained product identifier (PID) into the dynamic routing engine, perform matching and retrieval in a pre-built set of multiple PIDs, locate the corresponding target protocol converter module, and complete its instantiation. The forward conversion module is used to call the forward conversion method of the instantiated target protocol converter module to convert standard protocol messages into private protocol messages that can be recognized by the device and send them to the corresponding IoT device. The reverse conversion module receives the private protocol response message returned by the IoT device, locates the same target protocol converter module again by matching the product identifier (PID), and calls the reverse conversion method to convert the private protocol response message into a standard protocol message, thus completing the protocol adaptive conversion.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the IoT multi-protocol adaptive conversion method based on PID dynamic routing as described in any of the first aspects.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the IoT multi-protocol adaptive conversion method based on PID dynamic routing as described in any one of the first aspects.

[0009] The embodiments of this application have the following beneficial effects: By setting up a unified bidirectional protocol conversion interface and configuring independent pluggable protocol converter modules for each device type, coupled with a pre-built PID set and a runtime PID dynamic routing matching mechanism, automated end-to-end bidirectional conversion between IoT standard protocols and device-specific protocols is achieved. This architecture enables the protocol conversion logic of various devices to be deployed independently and modularly. When adding a new device type, only the corresponding converter and PID set mapping relationship need to be adapted, without modifying the core routing and conversion process. This achieves complete decoupling of the protocol conversion logic, effectively improving the device adaptability and functional expansion capability of the protocol conversion system, and ensuring the standardized and normalized conversion operation of control request and response messages of various IoT devices. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating steps S101-S107 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the IoT multi-protocol adaptive conversion device based on PID dynamic routing provided in the embodiments of this application; Figure 6 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] 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 accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0018] See Figure 1 , Figure 1 This is a flowchart illustrating steps S101-S107 of the IoT multi-protocol adaptive conversion method based on PID dynamic routing provided in this application embodiment. It will be combined with... Figure 1 Steps S101-S107 are explained below.

[0019] In step S101, a bidirectional protocol conversion interface is predefined. The bidirectional protocol conversion interface includes a forward conversion method and a reverse conversion method. The forward conversion method is used to convert cloud standard JSON format IoT protocol messages into device private protocol messages. The reverse conversion method is used to convert device private protocol response messages into cloud standard JSON format IoT protocol messages. In step S102, corresponding protocol converter modules are set up for different types of IoT devices, and each of the protocol converter modules is adapted to implement the bidirectional protocol conversion interface to obtain a pluggable converter component cluster. In step S103, multiple sets of product identifier (PID) sets are pre-constructed, and a unique mapping relationship is established between each set of PID sets and the protocol converter module of the corresponding device type. Each set of PID sets stores the product identifiers of all known devices under the corresponding device category. In step S104, a standard protocol control request is received from the cloud, the device serial number (SN) is extracted from the request, and the product identifier (PID) of the target device is obtained based on the multi-level source return rules. In step S105, the obtained product identifier (PID) is input into the dynamic routing engine, and a matching search is performed in the pre-built set of multiple PIDs to locate the corresponding target protocol converter module and complete its instantiation. In step S106, the forward conversion method of the instantiated target protocol converter module is called to convert the standard protocol message into a private protocol message that the device can recognize and send it to the corresponding IoT device. In step S107, the private protocol response message returned by the IoT device is received, and the same target protocol converter module is located again by matching the product identifier (PID). The reverse conversion method is called to convert the private protocol response message into a standard protocol message, thus completing the protocol adaptive conversion.

[0020] In this embodiment, the interface standardization definition process is first performed to unify the technical specifications for bidirectional protocol conversion, clarify the functional boundaries of the two core conversion logics of forward and reverse conversion, and provide a unified execution standard for protocol conversion of all subsequent devices, thus achieving decoupling of conversion logic at the architectural level. Based on this, for different types of IoT devices such as smart door locks, feeders, sockets, power strips, dimmer switches, circuit breakers, and third-party devices, dedicated protocol converter modules are independently developed. Each module implements a unified bidirectional conversion interface, forming a modular, pluggable converter component cluster, where each component is independent and does not interfere with each other.

[0021] To achieve dynamic routing matching, this embodiment pre-builds and maps PID sets, creating a dedicated PID set for each device type. Each set contains the product identifier strings of all devices within that category. Simultaneously, each PID set is uniquely bound to the corresponding device's converter module. During operation, the system receives standard JSON-formatted IoT control requests from the cloud, extracts the device's unique serial number (SN) from the request message, and accurately obtains the PID identifier corresponding to the target device through a multi-level origin pull mechanism.

[0022] The system then initiates dynamic routing matching logic, inputting the acquired PID into the dynamic routing engine. It iterates through pre-built PID sets to perform precise retrieval and matching, locating the corresponding target protocol converter and instantiating it. Through the forward conversion method of the instantiated converter, the unified standard protocol message from the cloud is parsed and reconstructed into a device-recognizable private protocol message, which is then sent to the terminal IoT device via the communication layer. After receiving the message and performing the corresponding operation, the device returns a response message in a private protocol format. The system again matches the same converter module through PID routing and calls the reverse conversion method to standardize the private protocol response message, converting it into a cloud-recognizable JSON standard protocol message. This completes the bidirectional adaptive protocol conversion from request to response. This embodiment can fully adapt to various device control scenarios such as remote unlocking of smart door locks and timed task settings for feeders.

[0023] In some embodiments, when the forward conversion method is executed, a unique message identifier msgId is generated and output synchronously; The message identifier msgId is used by the device communication layer to realize message type identification and accurate matching of requests and responses; the system is pre-configured with a special message identifier policy library, which is used to perform differentiated processing for the business scenarios corresponding to the preset special msgId. The differentiated processing includes at least one of skipping the reverse response conversion and enabling multiple response receiving mode.

[0024] In this embodiment, during forward protocol conversion, a globally unique message identifier (msgId) is generated and output synchronously. This identifier is bound to each protocol conversion request. In the operational logic of the device communication layer, msgId serves as the core matching criterion, used to accurately distinguish different types of device messages, achieving a one-to-one correspondence between cloud requests and device responses. This avoids message corruption and matching errors in scenarios with multiple concurrent requests, ensuring the stability of concurrent conversions across multiple devices and commands.

[0025] Meanwhile, the system has a built-in pre-configured special message identifier policy library, which presets differentiated automated processing logic for specific business scenarios corresponding to different special msgIds. Taking the serial port transparent transmission scenario corresponding to msgId=1572 as a typical example, the response message returned by the device in this scenario already conforms to the cloud standard protocol format and does not require secondary conversion. The system can automatically skip the reverse response conversion step according to the preset policy. For some business scenarios that require receiving device feedback data multiple times, the system can enable a multiple response receiving mode based on the corresponding msgId, fully collect multiple batches of response messages from the device and complete unified processing, adapting to various unconventional and customized device communication interaction needs.

[0026] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application. The step of obtaining the product identifier (PID) of the target device based on multi-level source return rules can be achieved through steps S201-S203, which will be explained in conjunction with each step.

[0027] In step S201, the local thread-safe concurrent mapping cache is queried first, and the corresponding PID information is retrieved based on the device serial number SN. If the cache is hit, the PID is obtained directly. In step S202, if the local cache is not hit, a query request is sent to the upstream device management service to query the device basic information through the device serial number SN and obtain the corresponding product identifier PID; In step S203, if the device management service query fails or returns a null value, a query request is initiated to the upstream capability configuration service to obtain the device PID. The capability configuration service supports a parent PID inheritance mechanism. If the target device is a mounted sub-device, it automatically inherits the product identifier PID of the associated parent device for route matching.

[0028] This embodiment employs a three-level origin-fetching architecture, retrieving device PID identifiers level by level to ensure efficient and accurate identifier acquisition. The first level is a local cache lookup. The system uses a thread-safe concurrent mapping structure to build a local PID cache, pre-storing the mapping relationship between device SN and corresponding PID. When the device PID needs to be retrieved, the system prioritizes searching the local cache. If the cache is hit, the PID data can be read directly without initiating any network requests, significantly improving identifier acquisition efficiency and adapting to high-concurrency business scenarios.

[0029] If the local cache does not contain SN-PID mapping data for the corresponding device, the second-level query logic is automatically triggered. The system initiates an HTTP query request to the upstream JVSS device management service to retrieve the device's basic registration information using the device's unique serial number (SN) and extract the corresponding product identifier (PID). When the JVSS service query times out, experiences a service error, or returns empty data, the system automatically switches to the third-level query chain, initiating a query request to the upstream CAPS capability configuration service to obtain the device's complete product information and corresponding PID.

[0030] The CAPS capability configuration service has a built-in parent PID inheritance mechanism, specifically designed to adapt to application scenarios where gateways are connected to sub-devices. For various sub-devices connected to the main gateway device, where the sub-devices themselves do not have independent protocol converters, the system queries the PID of the parent device associated with the sub-device through the CAPS service, directly inherits the parent device's PID as the routing basis, and reuses the corresponding protocol converter module of the parent device to complete the protocol conversion. This is typically used in networking scenarios where sub-devices are connected to gateways, achieving compatibility and adaptation for sub-device protocol conversion.

[0031] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application. The method further includes steps S301-S302, which will be explained in conjunction with each step.

[0032] In step S301, a cache refresh operation is performed through a scheduled task or a manual API interface to periodically traverse and clear the local concurrent mapping cache data; In step S302, the valid device SN and PID mapping relationship obtained through multi-level source lookup is updated to the local cache.

[0033] This embodiment configures two types of cache refresh triggering methods: automatic triggering via scheduled tasks and manual triggering via API interface, which can flexibly adapt to the cache update needs of different operation and maintenance scenarios. The system can periodically traverse all key-value pairs in the local concurrent mapping cache through a background scheduled task, clearing expired and invalid SN-PID mapping data to avoid routing mismatches caused by outdated or incorrect cache data. Simultaneously, it supports operation and maintenance personnel to manually trigger cache refresh operations through a dedicated API interface, suitable for special scenarios such as device model iteration and PID identifier changes.

[0034] During daily operations, all valid device SN and PID mappings obtained through secondary and tertiary source lookup queries are synchronized and updated to the local cache in real time. When a new device goes online for the first time or when the device PID information changes, the system retrieves the latest data through service queries and overwrites the local cache. Subsequent protocol conversion requests for this device can directly hit the local cache without repeatedly initiating remote service queries, thus continuously ensuring the system's response efficiency and operational stability.

[0035] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S404 provided in the embodiments of this application. The method is adapted to the scenario of batch instructions for scheduled tasks. When adapted to the scenario of batch instructions for scheduled tasks, the corresponding batch processing steps can be implemented through steps S401-S404, which will be explained in conjunction with each step.

[0036] In step S401, when a batch device control request is received, a private protocol message list containing multiple sub-instructions is generated by a forward conversion method; In step S402, the message list is split into multiple independent sub-instructions, which are sent to the IoT device one by one in sequence and the device response is awaited. In step S403, for each device response message corresponding to a sub-instruction, the reverse conversion method is independently invoked to complete the standardized conversion; In step S404, the execution result of each sub-instruction is checked in real time. If a sub-instruction is detected to have failed to execute, the subsequent issuance of all unexecuted sub-instructions is terminated.

[0037] For example, in typical scenarios such as batch configuration of scheduled tasks for smart feeders, the cloud will send multiple device control commands at once. After receiving the batch control requests, the system calls the forward conversion method of the corresponding device converter to generate a private protocol message list containing multiple sub-commands, rather than a single command message. The system has built-in automatic splitting logic to decompose the batch message list into multiple independent device control sub-commands, which are then queued for execution in the order they were generated.

[0038] During execution, the system sends sub-instructions to the target IoT device one by one. After each sub-instruction is sent, subsequent operations are paused, awaiting the device's response message to ensure the orderly execution of instructions. For each device-specific protocol response message corresponding to a sub-instruction, the system independently performs PID routing matching and reverse protocol conversion, converting the execution result of each sub-instruction into a standard protocol format, enabling refined parsing of batch instruction execution results.

[0039] Meanwhile, the system has real-time result verification and short-circuit protection capabilities. During the execution of each instruction, the system identifies the execution status of the sub-instructions in real time. If the current sub-instruction fails to execute, such as when the number of timed tasks for the feeder reaches the device limit, the device is offline, or the instruction parameters are abnormal, the system immediately triggers the short-circuit protection mechanism to directly terminate the issuance of all subsequent unexecuted sub-instructions, thereby avoiding the issuance of invalid instructions and simplifying the batch task execution process.

[0040] In some embodiments, the method further includes: When the reverse conversion method fails, the message parsing is abnormal, or the route matching fails, the overall business process is not interrupted, and the original private protocol response message returned by the device is directly forwarded to the cloud.

[0041] Here, during the entire process of bidirectional protocol conversion, the system can autonomously identify various abnormal fault scenarios, mainly including errors in the execution of the reverse conversion method, parsing errors caused by garbled device private response message formats, and PID routing matching failures with no corresponding converter. When any of the above abnormal scenarios are triggered, the system will not terminate the overall business process, nor will it directly return error information to interrupt device control services.

[0042] This embodiment has a fallback pass-through logic. In the event of conversion anomaly or matching failure, the original private protocol response message returned by the device is directly passed through to the cloud platform. This ensures that the cloud can receive the device feedback data normally, maintain the normal operation of core services such as device control and status query, effectively avoid the business interruption problem caused by the abnormality of the protocol conversion module, and improve the overall fault tolerance of the system.

[0043] In some embodiments, for scenarios where there are multiple versions of chip solutions and multiple protocol adaptations for the same device category, the pre-built PID set supports subset splitting configuration; For the same equipment category, there are multiple independent PID subsets. Each subset is matched with a corresponding protocol converter module, which executes the corresponding protocol adaptive conversion logic for equipment of the same category but with different hardware solutions.

[0044] In practical IoT device applications, the same product category often has multiple hardware chip solutions and iterative protocol versions. Taking feeder devices as an example, there are three different technical solutions: a general solution, an XM530 solution, and a JVSS external solution. The private communication protocols of feeder devices differ between these solutions, making it impossible to process them using a unified conversion logic. To address this scenario, this solution optimizes and splits the traditional single PID set, configuring multiple independent PID subsets for the same device category.

[0045] Each PID subset separately records the device product identifier corresponding to the corresponding hardware solution and protocol version. Each subset is also independently bound to a dedicated protocol converter module, with different subsets corresponding to different protocol conversion logic. When devices of the same product category but different solutions request access, the system accurately matches the corresponding subset and dedicated converter using the PID, and executes the appropriate protocol conversion logic accordingly. This achieves fine-grained protocol adaptation for heterogeneous devices of the same product category without requiring modification to the core routing and conversion code, significantly improving the system's device compatibility and scalability.

[0046] In summary, the embodiments of this application have the following beneficial effects: By pre-building PID sets and using a runtime dynamic matching mechanism, rapid access adaptation for new device types can be achieved without modifying the core routing code, effectively decoupling the conversion logic and enabling modular expansion. A multi-level source PID acquisition mechanism, comprised of local caching, device management services, and capability configuration services, combined with a dynamic cache update strategy, efficiently and stably acquires device product identifiers. Furthermore, the parent PID inheritance mechanism enables protocol adaptation for gateway-mounted sub-devices, significantly improving device identifier acquisition efficiency and device compatibility coverage. Message identifier differentiation processing, automatic batch command splitting, and short-circuit protection mechanisms enable flexible adaptation to special communication scenarios and orderly and reliable execution of batch control tasks. Coupled with a protocol conversion anomaly fallback mechanism, it effectively avoids business interruptions caused by protocol parsing or routing matching anomalies. Overall, it achieves high adaptability, high stability, and high scalability in protocol conversion for multi-category heterogeneous IoT devices, meeting the actual business operation needs of various single-device control and timed batch device management.

[0047] Based on the same inventive concept, this application also provides an IoT multi-protocol adaptive conversion device based on PID dynamic routing, which corresponds to the IoT multi-protocol adaptive conversion method based on PID dynamic routing in the first embodiment. Since the principle of the device in this application is similar to the IoT multi-protocol adaptive conversion method based on PID dynamic routing, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0048] like Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of the IoT multi-protocol adaptive conversion device 500 based on PID dynamic routing provided in this application embodiment. The IoT multi-protocol adaptive conversion device 500 based on PID dynamic routing includes: The interface definition module 501 is used to predefine a bidirectional protocol conversion interface. The bidirectional protocol conversion interface includes a forward conversion method and a reverse conversion method. The forward conversion method is used to convert cloud standard JSON format IoT protocol messages into device private protocol messages. The reverse conversion method is used to convert device private protocol response messages into cloud standard JSON format IoT protocol messages. The protocol adaptation module 502 is used to set up corresponding protocol converter modules for different types of IoT devices. Each of the protocol converter modules is adapted to implement the bidirectional protocol conversion interface to obtain a pluggable converter component cluster. The configuration module 503 is used to pre-build multiple sets of product identifier (PID) sets, establish a unique mapping relationship between each set of PID sets and the corresponding device type protocol converter module, and store the product identifiers of all known devices under the corresponding device category in each set of PID sets. The identifier acquisition module 504 is used to receive standard protocol control requests sent from the cloud, extract the device serial number SN from the request, and obtain the product identifier PID of the target device based on multi-level source return rules. The routing retrieval module 505 is used to input the obtained product identifier (PID) into the dynamic routing engine, perform matching and retrieval in a pre-built set of multiple PIDs, locate the corresponding target protocol converter module, and complete its instantiation. The forward conversion module 506 is used to call the forward conversion method of the instantiated target protocol converter module to convert the standard protocol message into a private protocol message that the device can recognize and send it to the corresponding IoT device. The reverse conversion module 507 is used to receive the private protocol response message returned by the IoT device, locate the same target protocol converter module again by matching the product identifier PID, and call the reverse conversion method to convert the private protocol response message into a standard protocol message, thus completing the protocol adaptive conversion.

[0049] Those skilled in the art should understand that Figure 5 The implementation functions of each unit in the IoT multi-protocol adaptive conversion device 500 based on PID dynamic routing shown can be understood by referring to the relevant description of the IoT multi-protocol adaptive conversion method based on PID dynamic routing described above. Figure 5 The functions of each unit in the IoT multi-protocol adaptive conversion device 500 based on PID dynamic routing shown can be implemented by a program running on a processor or by specific logic circuits.

[0050] In one possible implementation, when the forward conversion method is executed, the forward conversion module 506 synchronously generates and outputs a unique message identifier msgId; The message identifier msgId is used by the device communication layer to realize message type identification and accurate matching of requests and responses; the system is pre-configured with a special message identifier policy library, which is used to perform differentiated processing for the business scenarios corresponding to the preset special msgId. The differentiated processing includes at least one of skipping the reverse response conversion and enabling multiple response receiving mode.

[0051] In one possible implementation, the identifier acquisition module 504 is specifically used for: Prioritize querying the local thread-safe concurrent mapping cache, retrieve the corresponding PID information based on the device serial number (SN), and directly obtain the PID if the cache is hit; If the local cache is not found, a query request is sent to the upstream device management service to query the device's basic information through the device serial number (SN) and obtain the corresponding product identifier (PID). If the device management service query fails or returns a null value, a query request is initiated to the upstream capability configuration service to obtain the device PID. The capability configuration service supports a parent PID inheritance mechanism. If the target device is a mounted sub-device, it automatically inherits the product identifier PID of the associated parent device for route matching.

[0052] In one possible implementation, the identifier acquisition module 504 is further configured to: Execute cache refresh operations through scheduled tasks or manual API interfaces, and periodically traverse and clear local concurrent mapping cache data; Update the local cache with the mapping relationship between valid device SN and PID obtained through each multi-level source query.

[0053] In one possible implementation, the device further includes a batch processing module 508, which is adapted to a scheduled task batch instruction scenario. When adapted to a scheduled task batch instruction scenario, the batch processing module 508 is specifically used for: When receiving a batch of device control requests, a private protocol message list containing multiple sub-instructions is generated using a forward conversion method; The message list is split into multiple independent sub-instructions, which are then sent sequentially to the IoT devices and the system waits for the devices to respond. For each sub-instruction, the reverse conversion method is independently invoked to complete the standardized conversion; The execution result of each sub-instruction is verified in real time. If a sub-instruction fails to execute, the subsequent issuance of all unexecuted sub-instructions is terminated.

[0054] In one possible implementation, the device further includes a failure handling module 509, which is configured to: When the reverse conversion method fails, the message parsing is abnormal, or the route matching fails, the overall business process is not interrupted, and the original private protocol response message returned by the device is directly forwarded to the cloud.

[0055] In one possible implementation, for scenarios where there are multiple versions of chip solutions and multiple protocol adaptations for the same type of device, the pre-built PID set supports subset splitting configuration; For the same equipment category, there are multiple independent PID subsets. Each subset is matched with a corresponding protocol converter module, which executes the corresponding protocol adaptive conversion logic for equipment of the same category but with different hardware solutions.

[0056] The aforementioned IoT multi-protocol adaptive conversion device based on PID dynamic routing, through a pre-built PID set and runtime dynamic matching mechanism, can quickly adapt to new device types without modifying the core routing code, effectively decoupling the conversion logic and enabling modular expansion. Relying on a multi-level source PID acquisition mechanism consisting of local caching, device management services, and capability configuration services, combined with a dynamic cache update strategy, it can efficiently and stably acquire device product identifiers. Simultaneously, through a parent PID inheritance mechanism, it achieves protocol adaptation for gateway-mounted sub-devices, significantly improving device identifier acquisition efficiency and device compatibility coverage. With the help of message identifier differentiation processing, automatic batch command splitting, and short-circuit protection mechanisms, it achieves flexible adaptation to special communication scenarios and orderly and reliable execution of batch control tasks. Combined with a protocol conversion anomaly fallback mechanism, it effectively avoids business interruptions caused by protocol parsing or routing matching anomalies. Overall, it achieves high adaptability, high stability, and high scalability in protocol conversion for multi-category heterogeneous IoT devices, meeting the actual business operation needs of various single-device control and timed batch device management.

[0057] like Figure 6 As shown, Figure 6 This is a schematic diagram of the composition structure of the electronic device 600 provided in the embodiments of this application. The electronic device 600 includes: The device 600 includes a processor 601, a storage medium 602, and a bus 603. The storage medium 602 stores machine-readable instructions executable by the processor 601. When the electronic device 600 is running, the processor 601 communicates with the storage medium 602 via the bus 603. The processor 601 executes the machine-readable instructions to perform the steps of the IoT multi-protocol adaptive conversion method based on PID dynamic routing described in this application embodiment.

[0058] In practical applications, the various components in the electronic device 600 are coupled together via a bus 603. It is understood that the bus 603 is used to achieve communication between these components. In addition to a data bus, the bus 603 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 6 The general designated all buses as Bus 603.

[0059] The aforementioned electronic devices, through a pre-built PID set and a runtime dynamic matching mechanism, can quickly adapt to new device types without modifying the core routing code, effectively decoupling the conversion logic and enabling modular expansion. Relying on a multi-level source PID acquisition mechanism comprised of local caching, device management services, and capability configuration services, combined with a dynamic cache update strategy, they can efficiently and stably acquire device product identifiers. Simultaneously, through a parent PID inheritance mechanism, they achieve protocol adaptation for gateway-mounted sub-devices, significantly improving device identifier acquisition efficiency and device compatibility coverage. With the help of message identifier differentiation processing, automatic batch command splitting, and short-circuit protection mechanisms, they achieve flexible adaptation to special communication scenarios and orderly and reliable execution of batch control tasks. Combined with a protocol conversion anomaly fallback mechanism, they effectively avoid service interruptions caused by protocol parsing or routing matching anomalies. Overall, they achieve high adaptability, high stability, and high scalability in protocol conversion for multi-category heterogeneous IoT devices, meeting the actual business operation needs of various single-device control and timed batch device management.

[0060] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 601, the IoT multi-protocol adaptive conversion method based on PID dynamic routing described in this application is implemented.

[0061] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0062] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0063] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0064] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0065] The aforementioned computer-readable storage medium, through a pre-built PID set and runtime dynamic matching mechanism, can quickly adapt to new device types without modifying the core routing code, effectively decoupling the conversion logic and enabling modular expansion. Relying on a multi-level source PID acquisition mechanism comprised of local caching, device management services, and capability configuration services, combined with a dynamic cache update strategy, it can efficiently and stably acquire device product identifiers. Simultaneously, through a parent PID inheritance mechanism, it achieves protocol adaptation for gateway-mounted sub-devices, significantly improving device identifier acquisition efficiency and device compatibility coverage. With the help of message identifier differentiation processing, automatic batch command splitting, and short-circuit protection mechanisms, it achieves flexible adaptation to special communication scenarios and orderly and reliable execution of batch control tasks. Combined with a protocol conversion anomaly fallback mechanism, it effectively avoids business interruptions caused by protocol parsing or routing matching anomalies. Overall, it achieves high adaptability, high stability, and high scalability in protocol conversion for multi-category heterogeneous IoT devices, meeting the actual business operation needs of various single-device control and timed batch device management.

[0066] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0067] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0068] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0069] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0070] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A multi-protocol adaptive conversion method for the Internet of Things based on PID dynamic routing, characterized in that, Includes the following steps: A predefined bidirectional protocol conversion interface is provided, which includes a forward conversion method and a reverse conversion method. The forward conversion method is used to convert cloud standard JSON format IoT protocol messages into device private protocol messages, and the reverse conversion method is used to convert device private protocol response messages into cloud standard JSON format IoT protocol messages. For different types of IoT devices, corresponding protocol converter modules are set up respectively, and each of the protocol converter modules is adapted to implement the bidirectional protocol conversion interface, resulting in a pluggable converter component cluster. Multiple sets of product identifier (PID) sets are pre-constructed, and a unique mapping relationship is established between each set of PID sets and the corresponding protocol converter module of the device type. Each set of PID sets stores the product identifiers of all known devices under the corresponding device category. Receive standard protocol control requests from the cloud, extract the device serial number (SN) from the request, and obtain the product identifier (PID) of the target device based on multi-level source return rules; The obtained product identifier (PID) is input into the dynamic routing engine, which performs matching and retrieval in a pre-built set of multiple PIDs to locate the corresponding target protocol converter module and complete its instantiation. The forward conversion method of the instantiated target protocol converter module is called to convert the standard protocol message into a private protocol message that the device can recognize and send it to the corresponding IoT device. The system receives a private protocol response message from an IoT device, locates the same target protocol converter module again by matching the product identifier (PID), and calls the reverse conversion method to convert the private protocol response message into a standard protocol message, thus completing the adaptive protocol conversion.

2. The method according to claim 1, characterized in that, When the forward conversion method is executed, a unique message identifier msgId is generated and output synchronously; The message identifier msgId is used by the device communication layer to realize message type identification and accurate matching of requests and responses; the system is pre-configured with a special message identifier policy library, which is used to perform differentiated processing for the business scenarios corresponding to the preset special msgId. The differentiated processing includes at least one of skipping the reverse response conversion and enabling multiple response receiving mode.

3. The method according to claim 1, characterized in that, The process of obtaining the product identifier (PID) of the target device based on multi-level source code rules includes: Prioritize querying the local thread-safe concurrent mapping cache, retrieve the corresponding PID information based on the device serial number (SN), and directly obtain the PID if the cache is hit; If the local cache is not found, a query request is sent to the upstream device management service to query the device's basic information through the device serial number (SN) and obtain the corresponding product identifier (PID). If the device management service query fails or returns a null value, a query request is initiated to the upstream capability configuration service to obtain the device PID. The capability configuration service supports a parent PID inheritance mechanism. If the target device is a mounted sub-device, it automatically inherits the product identifier PID of the associated parent device for route matching.

4. The method according to claim 3, characterized in that, The method further includes: Execute cache refresh operations through scheduled tasks or manual API interfaces, and periodically traverse and clear local concurrent mapping cache data; Update the local cache with the mapping relationship between valid device SN and PID obtained through each multi-level source query.

5. The method according to claim 1, characterized in that, The method is adapted to batch instruction scenarios for scheduled tasks. When adapted to batch instruction scenarios for scheduled tasks, the corresponding batch processing steps include: When receiving a batch of device control requests, a private protocol message list containing multiple sub-instructions is generated using a forward conversion method; The message list is split into multiple independent sub-instructions, which are then sent sequentially to the IoT devices and the system waits for the devices to respond. For each sub-instruction, the reverse conversion method is independently invoked to complete the standardized conversion; The execution result of each sub-instruction is verified in real time. If a sub-instruction fails to execute, the subsequent issuance of all unexecuted sub-instructions is terminated.

6. The method according to claim 1, characterized in that, The method further includes: When the reverse conversion method fails, the message parsing is abnormal, or the route matching fails, the overall business process is not interrupted, and the original private protocol response message returned by the device is directly forwarded to the cloud.

7. The method according to claim 1, characterized in that, For scenarios where there are multiple versions of chip solutions and multiple protocol adaptations for the same type of equipment, the pre-built PID set supports subset splitting configuration; For the same equipment category, there are multiple independent PID subsets. Each subset is matched with a corresponding protocol converter module, which executes the corresponding protocol adaptive conversion logic for equipment of the same category but with different hardware solutions.

8. An IoT multi-protocol adaptive conversion device based on PID dynamic routing, characterized in that, The device includes: The interface definition module is used to predefine a bidirectional protocol conversion interface. The bidirectional protocol conversion interface includes a forward conversion method and a reverse conversion method. The forward conversion method is used to convert cloud standard JSON format IoT protocol messages into device private protocol messages. The reverse conversion method is used to convert device private protocol response messages into cloud standard JSON format IoT protocol messages. The protocol adaptation module is used to set up corresponding protocol converter modules for different types of IoT devices. Each of the protocol converter modules is adapted to implement the bidirectional protocol conversion interface, resulting in a pluggable converter component cluster. The configuration module is used to pre-build multiple sets of product identifier (PID) sets, establish a unique mapping relationship between each set of PID sets and the corresponding device type protocol converter module, and store the product identifiers of all known devices under the corresponding device category in each set of PID sets. The identifier acquisition module is used to receive standard protocol control requests sent from the cloud, extract the device serial number (SN) from the request, and obtain the product identifier (PID) of the target device based on multi-level source return rules. The routing retrieval module is used to input the obtained product identifier (PID) into the dynamic routing engine, perform matching and retrieval in a pre-built set of multiple PIDs, locate the corresponding target protocol converter module, and complete its instantiation. The forward conversion module is used to call the forward conversion method of the instantiated target protocol converter module to convert standard protocol messages into private protocol messages that can be recognized by the device and send them to the corresponding IoT device. The reverse conversion module receives the private protocol response message returned by the IoT device, locates the same target protocol converter module again by matching the product identifier (PID), and calls the reverse conversion method to convert the private protocol response message into a standard protocol message, thus completing the protocol adaptive conversion.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the IoT multi-protocol adaptive conversion method based on PID dynamic routing as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the IoT multi-protocol adaptive conversion method based on PID dynamic routing as described in any one of claims 1 to 7.

Images