Cross-platform equipment management method and system based on protocol converter

Abstract

The invention relates to the technical field of data processing, and provides a cross-platform equipment management method and system based on a protocol converter, and the method comprises the steps: registering a unique identifier of target equipment in a first cloud platform, and connecting the corresponding target equipment in a second cloud platform; when the first cloud platform needs to obtain the real-time information of the target equipment, sending a unique identifier to the protocol converter for analysis, and finding the corresponding target equipment to obtain the real-time information; when the first cloud platform needs to control the target equipment, a control instruction containing the unique identifier is sent to the protocol converter, and the unique identifier and a control parameter are obtained; and finding a corresponding target device in the second cloud platform based on the unique identifier for control. Through deployment of the protocol converter, real-time information synchronization and instruction control between the first cloud platform and the second cloud platform are realized, protocol conversion and equipment positioning are supported, the management efficiency is improved, and the problems of multi-platform data synchronization and insufficient response are solved.

Description

Technical Field

[0001] The present application relates to the technical field of data processing, and in particular to a cross-platform device management method and system based on a protocol converter. Background Art

[0002] With the rapid development of IoT technology, the management of smart devices has gradually shifted from traditional local operations to remote management based on cloud platforms. Cloud platforms provide convenient solutions for device monitoring, data transmission, and control. However, due to significant differences in protocols, data formats, and control methods between different cloud platforms, cross-platform device management has become a complex technical challenge.

[0003] In the existing technology, cross-platform device management is mainly achieved through standardized protocols (such as RESTful API, SNMP, MODBUS, etc.) or proprietary protocols. Standardized protocols provide a certain degree of commonality for information exchange between different devices, and can achieve the connection between devices and cloud platforms to a certain extent. Another solution is to achieve protocol conversion through specific hardware gateways. These gateways can support simple conversion and data transmission of multiple protocols, thereby achieving interoperability between devices.

[0004] Regarding the above technical solutions, although the interconnection between devices and cloud platforms can be achieved through standardized protocols and hardware gateways in the existing technology, in actual applications, the adaptation of standardized protocols requires a lot of development work, and the protocol differences between different devices and platforms will significantly increase the complexity of the system. Although the hardware gateway can support basic protocol conversion, it shows obvious performance bottlenecks when dealing with complex scenarios (such as real-time data synchronization and concurrent access of a large number of devices). There is a problem of being unable to support efficient data synchronization between multiple platforms, resulting in the real-time nature of device information and insufficient response speed of command control, which limits the application of the system in large-scale Internet of Things scenarios. Summary of the invention

[0005] In order to improve the problem that existing solutions cannot support efficient data synchronization between multiple platforms, resulting in insufficient real-time performance of device information and insufficient response speed of command control, the present application provides a cross-platform device management method and system based on a protocol converter.

[0006] The present invention provides a cross-platform device management method based on a protocol converter, which is applied to the management of different platforms. The device management method comprises: a unique identifier of a target device is registered in a first cloud platform, and a corresponding target device is connected in a second cloud platform; wherein the first cloud platform and the second cloud platform are both connected to the protocol converter; when the first cloud platform needs to obtain real-time information of the target device, the first cloud platform sends the unique identifier to the protocol converter for parsing, and finds the corresponding target device in the second cloud platform; based on the second cloud platform, the real-time information of the target device is obtained, and the real-time information is sent to the protocol converter for conversion into a protocol format supported by the first cloud platform, and then uploaded to the first cloud platform; when the first cloud platform needs to control the target device, the first cloud platform sends a control instruction containing the unique identifier to the protocol converter, and the protocol converter parses the control instruction to obtain the unique identifier and control parameters; based on the unique identifier, the corresponding target device in the second cloud platform is found, and the control parameters are converted into a protocol format supported by the second cloud platform and uploaded to the second cloud platform, and the second cloud platform controls the corresponding target device according to the control parameters.

[0007] As a preferred solution, the step of registering a unique identifier of the target device in the first cloud platform and connecting a corresponding target device in the second cloud platform includes: pre-registering the unique identifier of the target device in the device registration module of the first cloud platform, and pre-connecting the target device to the second cloud platform.

[0008] As a preferred solution, the protocol converter is based on a containerized deployment strategy, and the protocol converter includes an acquisition module, a data conversion module and an instruction conversion module; the acquisition module, the data conversion module and the instruction conversion module all run independently in a container manner; the acquisition module is used to parse the unique identifier to obtain the corresponding target device in the second cloud platform; the data conversion module is used to convert the real-time information into a protocol format supported by the first cloud platform; the instruction conversion module is used to convert the control parameters into a protocol format supported by the second cloud platform.

[0009] As a preferred solution, the acquisition module is used to parse the unique identifier to obtain the corresponding target device in the second cloud platform, including: parsing the unique identifier through the acquisition module, and extracting device identification information and device association information based on the analysis result; inputting the device identification information into a preset device comparison database, and comparing it item by item with the device identification data set pre-stored in the second cloud platform to screen out a candidate device set; matching the device association information with the candidate device set item by item to generate a device matching table; filtering the device operation status information in the device matching table through a preset device operation status filtering rule to obtain a device status table; filtering the device connection attribute information in the device matching table according to a preset device connection attribute verification rule to obtain a device attribute table; cross-validating the device status table with the device attribute table, and analyzing the corresponding target device based on the verification result.

[0010] As a preferred solution, the data conversion module is used to convert the real-time information into a protocol format supported by the first cloud platform, comprising: parsing the field rules and field mapping rules of the protocol format supported by the first cloud platform through the data conversion module; decomposing the real-time information according to the field mapping rules to obtain basic data fields and extended data fields, and using the field mapping rules to match the format of the basic data fields to generate a preliminary conversion data table; extracting device environment parameters and historical performance data from the extended data fields as associated attribute information, and using the associated attribute information to supplement the preliminary conversion data table to generate a supplemented conversion data table; verifying the supplemented conversion data table against the field rules item by item, and if the verification passes, the conversion of the real-time information is completed; if the verification fails, adjusting the fields that fail to pass in the supplemented conversion data table according to the field rules until the supplemented conversion data table meets the protocol requirements.

[0011] As a preferred scheme, the instruction conversion module is used to convert the control parameters into the protocol format supported by the second cloud platform, including: parsing the command field rules and command format requirements of the protocol format supported by the second cloud platform through the instruction conversion module, and gradually decomposing the control parameters based on the command field rules to obtain basic control commands and advanced control logic; matching each command item in the basic control command one by one according to the command field rules to generate a preliminary command conversion table, optimizing and expanding the preliminary command conversion table based on the advanced control logic to generate an extended control command table; verifying the extended control command table and the command format requirements item by item, if the verification passes, completing the conversion of the control parameters; if the verification fails, adjusting the failed command items in the extended control command table using the command format requirements until the verification passes.

[0012] As a preferred solution, the first cloud platform uses the MQTT protocol and the second cloud platform uses the HTTPS protocol.

[0013] The present application also provides a cross-platform device management system based on a protocol converter, comprising: a registration unit, used to register a unique identifier of a target device in a first cloud platform, and a corresponding target device is connected to a second cloud platform; wherein the first cloud platform and the second cloud platform are both connected to the protocol converter; an acquisition unit, used to send the unique identifier to the protocol converter for parsing when the first cloud platform needs to obtain real-time information of the target device, and find the corresponding target device in the second cloud platform; a conversion unit, used to obtain the real-time information of the target device based on the second cloud platform, and send the real-time information to the protocol converter to convert it into a protocol format supported by the first cloud platform, and then upload it to the first cloud platform; a parsing unit, used to send a control instruction containing the unique identifier to the protocol converter when the first cloud platform needs to control the target device, and the protocol converter parses the control instruction to obtain the unique identifier and control parameters; a control unit, used to find the corresponding target device in the second cloud platform based on the unique identifier, and convert the control parameters into a protocol format supported by the second cloud platform and upload it to the second cloud platform, and the second cloud platform controls the corresponding target device according to the control parameters.

[0014] Compared with the prior art, the present application has the following beneficial effects: cross-platform data synchronization and fast response speed. Through the deployment of protocol converters and efficient protocol parsing technology, seamless cross-platform connection of device management and control between the first cloud platform and the second cloud platform is achieved. The protocol converter is used as a communication intermediary to support efficient conversion of two different protocol standards, and the synchronization of real-time information of the device and the reliable transmission of control instructions are achieved. Combined with the device unique identifier mapping mechanism, the accurate positioning and rapid response of the device in a multi-platform environment are ensured. Through data stream parsing and optimization algorithms, the protocol converter can effectively reduce delays, improve the efficiency of data synchronization and instruction issuance, and is suitable for complex IoT scenarios. It improves the existing solutions that cannot support efficient data synchronization between multiple platforms, resulting in the real-time nature of device information and insufficient response speed of instruction control. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0016] The structures, proportions, sizes, etc. illustrated in the drawings of this specification are only used to match the contents disclosed in the specification so as to facilitate understanding and reading by persons familiar with this technology. They are not used to limit the conditions under which the present invention can be implemented, and therefore have no substantive technical significance. Any structural modification, change in proportion or adjustment of size, without affecting the effects and purposes that can be achieved by the present invention, should still fall within the scope of the technical contents disclosed by the present invention.

[0017] Figure 1 It is a flowchart of a cross-platform device management method based on a protocol converter provided by an embodiment of the present invention; Figure 2 The present invention is a block diagram showing the structure of a cross-platform device management system based on a protocol converter according to an embodiment of the present invention.

[0018] Description of reference numerals: 10. A cross-platform device management system based on a protocol converter; 11. A registration unit; 12. An acquisition unit; 13. A conversion unit; 14. A parsing unit; 15. A control unit. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] The flowcharts shown in the accompanying drawings are only examples and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may also be decomposed, combined or partially merged, so the actual execution order may change according to actual conditions.

[0021] It should also be understood that the terms used in this application specification are only for the purpose of describing specific embodiments and are not intended to limit the application. As used in this application specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0022] It should be further understood that the term “and / or” used in the specification and appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0023] The technical solution of the present invention is further described below with reference to the accompanying drawings and through specific implementation methods.

[0024] Embodiment 1: like Figure 1 As shown, the present application provides a cross-platform device management method based on a protocol converter, which is applied to the management of different platforms. The device management method includes steps S100 to S500.

[0025] Step S100: A unique identifier of a target device is registered in a first cloud platform, and a corresponding target device is connected to a second cloud platform; wherein both the first cloud platform and the second cloud platform are connected to a protocol converter.

[0026] In this step, the target device registers a unique identifier (ID) in the first cloud platform, and each unique identifier corresponds to a target device in the second cloud platform. Specifically, the device information is uploaded through the device management interface provided by the first cloud platform, and a unique identifier is generated for the device during the registration process. The unique identifier is composed of the device serial number (SN) and the platform identifier (PlatformID). In the second cloud platform, the target device and the cloud platform are connected to the network through a gateway device or other communication module, and its unique identifier and data flow path are bound through a protocol.

[0027] For example, when a smart thermostat is registered on the first cloud platform, its device information includes the device type (thermostat), SN (12345XYZ), and manufacturer, etc.; in the second cloud platform, it is connected to the server through the gateway and marked as associated with the device with SN "12345XYZ".

[0028] Step S200: When the first cloud platform needs to obtain real-time information of the target device, the first cloud platform sends the unique identifier to the protocol converter for parsing to find the corresponding target device in the second cloud platform.

[0029] In this step, when the first cloud platform needs to obtain the real-time information of the target device, the platform sends a request packet containing a unique identifier to the protocol converter through its API interface. After receiving the request, the protocol converter parses the unique identifier and searches for the corresponding target device address and access rights in the second cloud platform through the device mapping table. Specifically, the device mapping table of the protocol converter stores the association between the device ID of the first cloud platform and the device path of the second cloud platform, and obtains the real-time information of the second cloud platform device by parsing the protocol packet.

[0030] For example, the first cloud platform requests to obtain the real-time temperature data of the thermostat. After the protocol converter receives the query instruction with ID "12345XYZ", it confirms that the device path of the second cloud platform is " / devices / thermostat / 12345XYZ" through the mapping table. Subsequently, the protocol converter sends a real-time information query instruction to the second cloud platform through the MQTT protocol to obtain the temperature data of the thermostat (such as 22°C).

[0031] Step S300: Acquire real-time information of the target device based on the second cloud platform, send the real-time information to the protocol converter to convert it into a protocol format supported by the first cloud platform, and then upload it to the first cloud platform.

[0032] In this step, the protocol converter performs protocol parsing and data reorganization on the target device real-time information obtained from the second cloud platform, converts it into a protocol format supported by the first cloud platform, and returns it to the first cloud platform through the API interface. Specifically, the protocol converter first parses the encoding format of the second cloud platform data (such as JSON, XML), extracts device status parameters (such as temperature, power, etc.), and then encapsulates it according to the protocol format of the first cloud platform (such as HTTPRESTAPI, Protobuf).

[0033] For example, the data format returned by the thermostat is a JSON object, including "temperature: 22°C, timestamp: 1672531200". The protocol converter transcodes it into the Protobuf message format supported by the first cloud platform and passes it to the first cloud platform to ensure correct information transmission.

[0034] Step S400: When the first cloud platform needs to control the target device, the first cloud platform sends a control instruction containing a unique identifier to the protocol converter, and the protocol converter parses the control instruction to obtain the unique identifier and control parameters.

[0035] In this step, when the first cloud platform needs to control the target device, the control instruction is sent to the protocol converter through the API interface. The protocol converter parses the control instruction, extracts the unique identifier and control parameters, converts them into the protocol format supported by the second cloud platform, and sends them to the path corresponding to the target device. Specifically, the protocol converter identifies the unique identifier carried in the control instruction, compares it with the device mapping table, determines the target device path, and repackages the control parameters (such as switch status, threshold adjustment).

[0036] For example, the control instruction issued by the first cloud platform is "Device 12345XYZ, adjust the temperature to 25°C", and the protocol converter parses the target device path as " / devices / thermostat / 12345XYZ". The temperature control instruction is transcoded into an MQTT command and uploaded to the second cloud platform. After receiving the instruction, the target device adjusts the temperature.

[0037] Step S500: Find the corresponding target device in the second cloud platform based on the unique identifier, convert the control parameters into a protocol format supported by the second cloud platform and upload it to the second cloud platform, and the second cloud platform controls the corresponding target device according to the control parameters.

[0038] In this step, after the protocol converter forwards the control instructions of the first cloud platform to the second cloud platform, the second cloud platform controls the state of the target device according to the instructions, and feeds back the device operation results to the first cloud platform through the protocol converter. Specifically, the protocol converter monitors the execution feedback of the second cloud platform in real time, confirms whether the operation is successful by parsing its data packets, and re-encodes the operation results and sends them to the first cloud platform.

[0039] For example, after receiving the control instruction to adjust the temperature, the thermostat adjusts the device temperature from 22°C to 25°C, and publishes the operation result "success" to the protocol converter through MQTT. After parsing, the protocol converter returns the status update information to the first cloud platform.

[0040] In this embodiment, through the deployment of the protocol converter and the efficient protocol parsing technology, this embodiment realizes the cross-platform seamless connection of device management and control between the first cloud platform and the second cloud platform. Specifically, the protocol converter, as a communication intermediary, supports the efficient conversion of two different protocol standards (such as HTTP and MQTT), and realizes the synchronization of real-time information of the device and the reliable transmission of control instructions. Combined with the device unique identifier mapping mechanism, it ensures the accurate positioning and rapid response of the device in a multi-platform environment. In addition, through data stream parsing and optimization algorithms, the protocol converter can effectively reduce delays, improve the efficiency of data synchronization and instruction issuance, and is suitable for complex Internet of Things scenarios. In practical applications, this embodiment can help enterprises solve the problem of protocol differences in traditional device management systems, reduce the cost of multi-platform device access, and at the same time, by supporting the efficient management of large-scale devices, significantly improve the scalability and reliability of the system, and improve the existing solution. The problem of insufficient real-time device information and instruction control response speed cannot be supported by efficient data synchronization between multiple platforms.

[0041] The structures, proportions, sizes, etc. illustrated in the drawings of this specification are only used to match the contents disclosed in the specification so as to facilitate understanding and reading by persons familiar with this technology. They are not used to limit the conditions under which the present invention can be implemented, and therefore have no substantive technical significance. Any structural modification, change in proportion or adjustment of size, without affecting the effects and purposes that can be achieved by the present invention, should still fall within the scope of the technical contents disclosed by the present invention.

[0042] Embodiment 2: In step S100, the unique identifier of the target device is pre-registered in the device registration module of the first cloud platform, and the target device is pre-connected to the second cloud platform. The first cloud platform and the second cloud platform are both connected to a protocol converter.

[0043] By registering the unique identifier of the target device in the first cloud platform in advance and completing the connection of the target device in the second cloud platform, the data interaction between the device and the two cloud platforms is ensured to be unique and accurate. Specifically, in the first cloud platform, the device registration module accepts the device information (such as device model, serial number SN, communication protocol type, etc.) input by the user through the API interface, automatically generates the unique identifier of the device, and stores it in the device management database of the first cloud platform. In the second cloud platform, through the Internet of Things communication module (such as MQTT gateway or HTTP gateway), the device accesses the cloud platform and binds its unique identifier to complete the connection operation between the device and the platform.

[0044] For example, when a smart water meter is registered in the first cloud platform, the user enters the device model as "WaterMeter-V1", the serial number SN as "WM001", and the protocol type as "MQTT" through the API interface. The system automatically generates a unique identifier "ID-WM001" and stores it in the device database of the first cloud platform. At the same time, the smart water meter is connected to the second cloud platform through the MQTT protocol, completes the connection operation, and establishes an association with "ID-WM001" in the first cloud platform.

[0045] Among them, the protocol converter adopted is a protocol converter based on the containerized deployment strategy. The protocol converter includes an acquisition module, a data conversion module and an instruction conversion module. The acquisition module, the data conversion module and the instruction conversion module all run independently in a container manner.

[0046] By adopting a protocol converter with a containerized deployment strategy, the acquisition module, data conversion module, and instruction conversion module can run in the form of independent containers, thereby improving modularity and flexibility. Specifically, the acquisition module is responsible for receiving device identification requests from the first cloud platform, parsing device information, and locating the target device in the second cloud platform; the data conversion module converts device data from the format of the second cloud platform to the format supported by the first cloud platform through field mapping rules and protocol conversion logic; the instruction conversion module parses the control instructions of the first cloud platform and repackages them into control commands supported by the second cloud platform. This containerization strategy allows each module to be independently updated, expanded, and maintained, and multiple containers communicate through standardized interfaces to avoid coupling between modules.

[0047] For example, the acquisition module of the protocol converter runs in a Docker container and listens to the device identifier resolution request sent by the first cloud platform. When the identifier "ID-WM001" is received, the module confirms that its corresponding second cloud platform path is " / devices / WM001" through the device mapping table. The data conversion module runs in another container and is responsible for converting the device status data (JSON format) returned by the second cloud platform into the Protobuf format supported by the first cloud platform. The instruction conversion module runs in a third container and encapsulates the "open valve" instruction issued by the first cloud platform into an MQTT command and uploads it to the second cloud platform.

[0048] The step in which the acquisition module parses the unique identifier to obtain the corresponding target device in the second cloud platform includes: parsing the unique identifier through the acquisition module, and extracting device identification information and device association information based on the parsing result.

[0049] The acquisition module parses the unique identifier, including extracting device identification information and device association information. Specifically, after receiving the unique identifier, the acquisition module parses the device serial number (SN number) and registration time and other related information, and locates the target device from the preset device comparison database based on this information.

[0050] For example, for the unique identifier "ID-WM001", the acquisition module extracts the device serial number "WM001" after parsing, and the associated information is the registration time "2023-01-01" and the device type "smart water meter". The acquisition module confirms that the device path is " / devices / WM001" through the device comparison database and returns the parsing result.

[0051] The device identification information is input into a preset device comparison database, and compared item by item with the device identification data set pre-stored in the second cloud platform to screen out a candidate device set.

[0052] By inputting the device identification information into the device comparison database and comparing it with the device identification set in the second cloud platform, a candidate device set is screened out. Specifically, the device comparison database stores the serial numbers and basic attribute information of all connected devices. The module compares the matching degree of the input identification information with the database records item by item and generates a preliminary candidate device set.

[0053] For example, the acquisition module inputs the identification information "WM001" into the device comparison database, and filters out a candidate device set containing the serial number "WM001", whose paths are " / devices / WM001" and " / devices / WM002".

[0054] The device association information is matched with the candidate device set item by item to generate a device matching table.

[0055] The device matching table is generated by matching the device association information (such as registration time, device type, etc.) with the devices in the candidate device set one by one. Specifically, the module compares each item according to the priority of the association information (such as device type > registration time), adds the fully matched devices to the device matching table, and marks the matching degree.

[0056] For example, the candidate device set contains two devices, namely "WM001" and "WM002". The system compares the associated information "Device Type: Smart Water Meter" and "Registration Time: 2023-01-01", and finds that the device "WM001" is a complete match, and generates a device matching table: "Device ID: WM001, Matching Degree: 100%".

[0057] The device operation status information in the device matching table is filtered using a preset device operation status filtering rule to obtain a device status table.

[0058] The device status information in the device matching table is filtered through the preset device operation status filtering rules to generate the device status table. Specifically, the devices in the matching table are filtered according to the filtering rules (such as the device online status has a higher priority than the offline status), and the devices that meet the operation conditions are added to the device status table.

[0059] For example, the device matching table contains devices "WM001" and "WM002", where the status of "WM001" is "online" and the status of "WM002" is "offline". Based on the filtering rules, the system only adds "WM001" to the device status table.

[0060] The device connection attribute information in the device matching table is screened according to the preset device connection attribute verification rule to obtain a device attribute table.

[0061] The device connection attribute information in the device matching table is screened through the preset device connection attribute verification rules to generate a device attribute table. Specifically, the module screens out devices that meet the requirements based on the device's communication protocol type, network delay and other attributes.

[0062] For example, the communication protocol supported by device "WM001" in the device matching table is "MQTT", and the network delay is "50ms", which meets the preset rules; the protocol supported by device "WM002" is "HTTP", and the network delay is "150ms", which does not meet the requirements. Finally, "WM001" is added to the device attribute table.

[0063] The device status table and the device attribute table are cross-validated, and the corresponding target device is analyzed based on the validation results. Specifically, the rule-based matching algorithm analyzes the target device runtime status information contained in the device status table item by item, extracts the real-time load index, working mode identification and state stability parameters of the target device, and then generates the device operation status analysis matrix.

[0064] The matching algorithms for rules include: Status information matching: According to the set device load threshold rules, identify and filter the device information whose operating load exceeds the predetermined threshold.

[0065] Mode identification analysis: Use the decision tree algorithm to classify and analyze the working mode identification to identify the behavioral characteristics of the device in different working states.

[0066] Stability assessment: Evaluate the equipment's state stability parameters through regression analysis and calculate the equipment's state stability score to determine whether the equipment meets normal operating standards.

[0067] Based on the association analysis algorithm, the target device connection attribute information contained in the device attribute table is parsed item by item, the communication protocol type, network connection strength index and security authentication level of the target device are extracted, and then the device connection attribute analysis matrix is ​​generated.

[0068] Association analysis algorithms include: Protocol type classification: The communication protocol type used by the target device is determined through the support vector machine (SVM) classification algorithm, and further classified according to the protocol type.

[0069] Network connection strength analysis: Use the weighted average method to weight the signal strength index of the device and evaluate the network quality of the target device.

[0070] Security authentication analysis: Verify the security authentication information of the target device through encryption algorithms (such as SHA-256) to ensure that the device meets the predetermined standards in terms of security authentication.

[0071] According to the preset equipment attribute operation cross rules, the real-time load indicators and network connection strength indicators in the equipment operation status analysis matrix and the equipment connection attribute analysis matrix are matched and processed to generate a load connection verification table.

[0072] Using a multi-objective optimization algorithm, the state stability parameters in the equipment operation state analysis matrix and the equipment communication protocol types recorded in the load connection verification table are verified item by item to generate an equipment operation stability verification table.

[0073] Based on the consistency verification algorithm, the security authentication level in the device connection attribute analysis matrix is ​​compared one by one with the state stability parameters in the device operation stability verification table, the device set that meets the verification conditions is screened out, and the device verification matching table is generated.

[0074] According to the sorting algorithm, the target devices in the device verification matching table are prioritized according to the real-time load index, communication protocol type priority and security authentication level, and a target device priority list is generated. The device with the highest priority is extracted from the target device priority list as the target device.

[0075] For example, the device "WM001" in the device matching table supports the communication protocol "MQTT", the signal strength is "-70dBm", the delay is "50ms", and the security authentication level is "SHA-256", which meets the preset device connection attribute verification rules and is therefore added to the device attribute table. However, the device "WM002" supports the communication protocol "HTTP", the signal strength is "-85dBm", and the delay is "150ms", which does not meet the security authentication requirements and is not included in the device attribute table.

[0076] In the equipment operation status analysis, the operating load of "WM001" in the equipment status table is "70%", which exceeds the preset load threshold, and the working mode is marked as "active communication", which is classified as a high load state; its stability parameter score is "95%", which is evaluated as a stable state after regression analysis. Based on the state stability and load matching rules, "WM001" is identified as a device that meets the operation standards.

[0077] In the device connection attribute analysis, the network connection strength of the device "WM001" was calculated as "75 points" by the weighted average method, which meets the connection quality standard; the communication protocol type is "MQTT", which is classified as a supported protocol type by SVM; the security authentication information is verified by SHA-256, which meets the device authentication requirements. Finally, the device connection attribute analysis matrix is ​​generated and cross-validated with the device operation status analysis matrix.

[0078] After further processing by the multi-objective optimization algorithm, the device "WM001" passed the load connection verification and state stability verification, generated a device verification matching table, and was finally given the highest priority in the sorting algorithm because of its real-time load of "70%", the preferred supported communication protocol type of "MQTT", and the security certification level of "SHA-256", and became the target device.

[0079] Among them, the data conversion module is used to convert the real-time information into a protocol format supported by the first cloud platform, including: parsing the field rules and field mapping rules of the protocol format supported by the first cloud platform through the data conversion module.

[0080] The data conversion module parses the field rules and field mapping rules of the protocol format supported by the first cloud platform to determine the functions of different fields and their corresponding relationships. Specifically, the data conversion module first reads the protocol field rule document of the first cloud platform and analyzes the field format, type, and data length limit. Subsequently, through the field mapping rules, the device data fields received from the second cloud platform are matched one by one with the field rules of the first cloud platform, and a mapping relationship table between fields is established for subsequent data conversion.

[0081] For example, the protocol field rules of the first cloud platform require that the device data contain the fields "temperature", "humidity", and "status", with the formats of floating point, decimal, and Boolean, respectively. The data fields returned by the second cloud platform are "temp", "hum", and "state". The data conversion module maps "temp" to "temperature", "hum" to "humidity", and "state" to "status" through the field mapping rules.

[0082] The real-time information is decomposed according to the field mapping rules to obtain basic data fields and extended data fields. The basic data fields are format matched using the field mapping rules to generate a preliminary conversion data table.

[0083] The real-time information received from the second cloud platform is decomposed through field mapping rules, and the data is split into two parts: basic data fields and extended data fields. Specifically, the basic data fields include the core operating parameters of the device (such as temperature and humidity), and the extended data fields include the operating environment parameters of the device (such as ambient temperature and network latency) and historical performance data (such as the operating status in the past 24 hours).

[0084] For example, the real-time data received from the second cloud platform is: {"temp":22.5, "hum":45.8, "state":1, "env_temp":25, "latency":120, "history":[1, 0, 1, 1]} The data conversion module breaks it down into: Basic data fields: {"temp":22.5,"hum":45.8,"state":1} Extended data field: {"env_temp":25,"latency":120,"history":[1,0,1,1]}.

[0085] The equipment environment parameters and historical performance data are extracted from the extended data field as associated attribute information, and the associated attribute information is used to supplement the preliminary conversion data table to generate a supplemented conversion data table.

[0086] The equipment environment parameters (such as ambient temperature) and historical performance data are extracted from the extended data field as associated attribute information and added to the preliminary conversion data table. Specifically, the data conversion module associates and calculates each attribute in the extended data field with the basic data field according to the field rules to generate a supplemented conversion data table.

[0087] For example, "env_temp" in the extended data field is used to calculate the environmental correction value of the device temperature: "actual temperature = temp - (env_temp - 20)". The historical performance data "history" is processed into the operating status statistics of the device in the past 24 hours (such as the percentage of operating time). The supplemented conversion data table is: {"temperature":22, "humidity":45.8, "status":1, "corrected_temp":20, "uptime_ratio":75%}.

[0088] The supplemented conversion data table and field rules are checked item by item. If the check passes, the conversion of real-time information is completed.

[0089] The supplemented conversion data table is checked item by item with the field rules of the first cloud platform to ensure that the data format, length and content meet the platform requirements. Specifically, the data conversion module checks whether the type, unit and range of each field meet the protocol requirements. If a field that does not meet the rules is found, it is marked as "failed to pass the check".

[0090] For example, if the "temperature" field is verified to be a floating point number, it complies with the protocol rules; but if the value of the "humidity" field exceeds the range specified by the protocol (such as 100%), it is marked as "verification failed" and an error report is returned: {"temperature":"pass","humidity":"fail"}.

[0091] If the check fails, the fields that fail to pass in the supplemented conversion data table are adjusted according to the field rules until the supplemented conversion data table meets the protocol requirements.

[0092] Specifically, the data conversion module recalculates the value of the out-of-range field according to the field rule, or discards the field that cannot be corrected.

[0093] For example, when the value of the "humidity" field is 150% (outside the protocol rule range), the data conversion module adjusts it to the maximum value of 100% according to the rule. If some fields such as "status" are empty, the module defaults to the initial value "0" in the protocol rule.

[0094] Among them, the instruction conversion module is used to convert the control parameters into the protocol format supported by the second cloud platform, including: parsing the command field rules and command format requirements of the protocol format supported by the second cloud platform through the instruction conversion module, and gradually decomposing the control parameters based on the command field rules to obtain basic control commands and advanced control logic.

[0095] The command conversion module parses the command field rules and command format requirements of the protocol format supported by the second cloud platform to confirm the field name, data type and command structure of the control command. Specifically, the command field parsing algorithm based on pattern recognition parses the command semantic field in the control parameter, extracts the control target, operation action and execution mode of the basic control command, and generates a basic control command analysis table.

[0096] The command field parsing algorithm for pattern recognition includes: Control target identification: Use the hidden Markov model (HMM) to perform time series analysis on the control target, predict the target control type of the target device based on the input control parameter sequence, and generate a mapping table between the target device type and the control target.

[0097] Operation action analysis: Through the rule-based action recognition algorithm, the grammatical rules of the operation action are identified, the action is classified according to the mark of the command field, and the operation action analysis table is generated.

[0098] Execution mode judgment: Using the decision tree algorithm, the execution mode field in the control parameters is combined with the previously extracted control objectives and operation actions to determine the specific type of execution mode (such as periodic execution, immediate execution, or conditional triggering) and generate an execution mode recognition matrix.

[0099] Based on the instruction semantic mapping rules, the instruction logic fields in the control parameters are associated and mapped with the basic control command analysis table, the logical conditions, action triggering rules and exception handling strategies of the advanced control logic are extracted, and the advanced control logic analysis matrix is ​​generated.

[0100] Instruction semantic mapping rules include: Logical condition mapping: Use fuzzy logic control algorithm to analyze the logical conditions in the control parameters (such as trigger conditions, limit judgment, etc.) and generate a logical condition analysis table.

[0101] Action trigger rule mapping: The action trigger rules in the control instructions are analyzed through Bayesian networks, and probability inference is applied to different trigger conditions to generate a trigger rule optimization matrix.

[0102] Exception handling strategy mapping: Use graph theory algorithms (such as the shortest path algorithm) to analyze the conditional relationships in the exception handling strategy, build an exception handling logic diagram, and optimize the exception path.

[0103] By using a multi-level instruction matching and optimization algorithm, the control targets in the basic control command analysis table are mapped item by item with the logical conditions in the advanced control logic analysis matrix to generate a control target mapping table.

[0104] Multi-level instruction matching and optimization algorithms include: Step-by-step matching algorithm: First, based on the matching evaluation, the control objectives and logical conditions are matched item by item to generate a preliminary control objective mapping.

[0105] Optimization adjustment algorithm: Use objective function optimization strategies (such as genetic algorithms) to adjust the preliminary control target mapping results to ensure the optimal match of the control target.

[0106] According to the command decomposition and conversion rules, the control targets in the control target mapping table are matched with the operation actions one by one, the specific operation actions of the target device are extracted, and the operation actions are sorted according to the execution mode to generate a control action priority list.

[0107] Command decomposition and conversion rules include: Execution sequence optimization algorithm: The time series of operation actions is optimized through the dynamic programming algorithm to ensure that the operation actions are executed according to the predetermined time sequence.

[0108] Priority assessment model: Use a priority assessment algorithm (such as a weighted scoring method) to assign a priority to each operation action based on factors such as device status, command urgency, and execution mode, and generate a control action priority list.

[0109] Through trigger condition verification and safety assessment, the trigger conditions of the operation actions in the control action priority list are verified one by one to generate a control action trigger table.

[0110] Trigger condition verification includes: Condition consistency verification: Use a parallel processing algorithm to match the triggering conditions of the operation action with the real-time status of the device to ensure that the triggering conditions are met.

[0111] Security assessment: Use security analysis models (such as graph-based security path analysis) to evaluate the execution risk and security of each operation action to ensure that the execution of control commands will not cause system instability or security vulnerabilities.

[0112] By using the exception handling optimization strategy, the exception handling strategy in the advanced control logic analysis matrix is ​​compared with the control action trigger table item by item, the operation actions with possible conflicts are screened out, and the execution mode of the operation actions is adjusted according to the optimization rules to generate an optimized control action execution table.

[0113] Exception handling optimization strategies include: Conflict analysis algorithms: Identify and eliminate conflict conditions that may cause device instability or operation failure through conflict detection algorithms (such as graph-based conflict path finding).

[0114] Priority readjustment: Utilize the dynamic priority adjustment algorithm to adjust the priority and execution order of operation actions according to the exception handling optimization strategy to ensure that the system can still run stably under abnormal circumstances.

[0115] Verify the operation actions recorded in the optimized control action execution table with the control targets in the control target mapping table to generate the final basic control commands and advanced control logic, thereby completing the conversion of control parameters. For example, the control parameters in the device "Device001" are: the target operation is "lower the temperature", the trigger condition is "indoor temperature>30℃", and the exception handling strategy is "trigger an alarm signal when the thermostat is closed abnormally". The command conversion module parses the control parameters through the command field parsing algorithm of pattern recognition, generates a basic control command analysis table, extracts the control target as "thermostat", the operation action is "adjust the temperature to the target value", and the execution mode is "immediate execution".

[0116] In the control target identification, the module uses the hidden Markov model (HMM) to identify that the target control type of the "thermostat" device is "temperature control adjustment" and generates a mapping table between the target device and the control target: {"Device001": "temperature control adjustment"}. Subsequently, the operation action parsing algorithm parses the operation semantic field "lower temperature" and generates an operation action parsing table: {"action": "adjust temperature", "target value": "target value"}. Next, the execution mode judgment algorithm identifies the execution mode as "immediate execution" based on the immediate execution mode field in the control parameters.

[0117] In the command semantic mapping rules, the fuzzy logic control algorithm analyzes the trigger condition "indoor temperature>30℃" and generates a logical condition analysis table: {"condition": "temperature>30", "trigger": "adjust temperature"}; the Bayesian network analysis trigger rule is "automatically cool down to 25℃ after the room temperature reaches 30℃", and generates a trigger rule optimization matrix. Through the mapping of the exception handling strategy, the graph theory algorithm is used to analyze the exception path and construct a logic diagram, which is marked as: {"abnormal": "failed to close the thermostat", "processing": "trigger alarm"}.

[0118] The multi-level instruction matching and optimization algorithm matches the control target "temperature control" and the logical condition "temperature>30" item by item, and generates a control target mapping table: {"target": "temperature control", "action": "adjust the temperature to 25℃"}. The genetic algorithm is used to optimize the target mapping to ensure that it fully matches the trigger condition.

[0119] By executing the sequential optimization algorithm and the priority evaluation model, a control action priority list is generated, and the operation actions are sorted into: 1) "adjust the temperature to 25°C", 2) "trigger an alarm signal". After the trigger condition is verified, the instruction conversion is completed and the control action trigger table is generated to ensure that the target device completes the operation under efficient and safe conditions.

[0120] Each command item in the basic control command is matched one by one according to the command field rule to generate a preliminary command conversion table, and the preliminary command conversion table is optimized and extended based on the advanced control logic to generate an extended control command table.

[0121] According to the command field rule, each command item in the basic control command is matched one by one to generate a preliminary command conversion table. Specifically, the module parses the control command field item by item and converts it into a format supported by the second cloud platform.

[0122] For example, the control command issued by the first cloud platform is {"operation":"start"}. The module maps it to the second cloud platform format: {"cmd":"on", "value":null} according to the command field rule, and generates a preliminary command conversion table: {"operation":"start"}->{"cmd":"on"}.

[0123] Based on the advanced control logic, the preliminary command conversion table is optimized and extended to generate an extended control command table. Specifically, the module adds additional instruction parameters (such as delayed start) or combines multiple command items to implement the advanced control logic.

[0124] For example, if the initial command conversion table is {"cmd":"on"}, the module adds the delayed start parameter "delay=5s" in the extended logic, and finally generates the extended control command table: {"cmd":"on","delay":5}.

[0125] The extended control command table and the command format requirements are verified item by item. If the verification passes, the conversion of the control parameters is completed.

[0126] Verify the extended control command table and the command format requirements of the second cloud platform item by item to ensure that all fields meet the format specifications. If some command items do not meet the requirements, mark and adjust them.

[0127] For example, if the field "delay" in the extended control command table is found to be in integer format, and the second cloud platform requires it to be in string format "5s", the module adjusts it to "delay":"5s" and uploads it after verification.

[0128] If the verification fails, the command format is used to require that the failed command item in the extended control command table be adjusted until the verification passes.

[0129] Specifically, the module corrects the format, value range and data type one by one.

[0130] For example, if the field "cmd" in the control command table is {"cmd":1} (wrong format), the module corrects it to {"cmd":"on"} according to the command format requirements, ultimately ensuring that the command table meets the cloud platform requirements.

[0131] In step S100, the first cloud platform is preferably the MQTT protocol, and the second cloud platform is preferably the HTTPS protocol. In other embodiments, other forms of protocols may be preferred, such as the tcp protocol, modbus protocol, websocket protocol, etc.

[0132] In this embodiment, through the containerized deployment and modular design of the protocol converter, functions such as data conversion, control command transmission and device status synchronization in cross-platform device management are realized. The scheme adopts independent containerized operation mode of acquisition module, data conversion module and instruction conversion module to ensure efficient operation and flexible maintenance of each module. The acquisition module accurately locates the target device by parsing the unique identifier and comparing the device association information, and further verifies the status and attributes of the device through multi-level filtering rules. The data conversion module decomposes, formats, supplements and verifies the real-time data of the device through field rules and mapping rules to ensure that the device data obtained from the second cloud platform can be transmitted in the protocol format supported by the first cloud platform. The instruction conversion module converts the control commands of the first cloud platform into protocol commands supported by the second cloud platform by parsing the command field rules and format requirements, thereby achieving high efficiency and accuracy of device control.

[0133] Through the containerized deployment strategy, each functional module of the protocol converter can run independently and is highly flexible. It can be expanded or adjusted according to needs, which significantly improves the scalability and resource utilization of the system. In addition, based on the combination of multiple protocols such as MQTT and HTTPS, the real-time information synchronization and control command issuance of devices can be completed efficiently, meeting the needs of multi-platform collaboration in complex IoT scenarios. This embodiment not only solves technical problems such as cross-platform protocol incompatibility, data synchronization delays, and untimely control command responses, but also ensures the accuracy and reliability of data and commands through a multi-level verification mechanism, providing enterprises with efficient, reliable and low-cost solutions for device management in a multi-cloud platform environment.

[0134] Embodiment 3: like Figure 2 As shown, the present application also provides a cross-platform device management system 10 based on a protocol converter, including a registration unit 11, an acquisition unit 12, a conversion unit 13, a parsing unit 14 and a control unit 15.

[0135] The registration unit 11 is mainly used to register a unique identifier of a target device in the first cloud platform, and a corresponding target device is connected to the second cloud platform; wherein both the first cloud platform and the second cloud platform are connected to a protocol converter.

[0136] The acquisition unit 12 is mainly used for sending the unique identifier to the protocol converter for parsing to find the corresponding target device in the second cloud platform when the first cloud platform needs to acquire the real-time information of the target device.

[0137] The conversion unit 13 is mainly used to obtain real-time information of the target device based on the second cloud platform, and send the real-time information to the protocol converter to convert it into a protocol format supported by the first cloud platform, and then upload it to the first cloud platform.

[0138] The parsing unit 14 is mainly used for sending a control instruction containing a unique identifier to a protocol converter when the first cloud platform needs to control the target device. The protocol converter parses the control instruction to obtain the unique identifier and control parameters.

[0139] The control unit 15 is mainly used to find the corresponding target device in the second cloud platform based on the unique identifier, and convert the control parameters into a protocol format supported by the second cloud platform and upload it to the second cloud platform. The second cloud platform controls the corresponding target device according to the control parameters.

[0140] In this embodiment, by integrating the registration unit 11, the acquisition unit 12, the conversion unit 13, the parsing unit 14 and the control unit 15, the system fully realizes the efficiency and reliability of cross-platform device management. The registration unit 11 is responsible for generating and registering a unique identifier for the target device in the first cloud platform, and completing the connection of the target device in the second cloud platform to ensure the consistency of data interaction between the two cloud platforms. The acquisition unit 12 accurately locates the target device in the second cloud platform by parsing the unique identifier sent by the first cloud platform, thereby realizing the rapid acquisition of real-time information of the device. On this basis, the conversion unit 13 converts the real-time data of the device obtained from the second cloud platform into the protocol format supported by the first cloud platform through a protocol converter and then uploads it, thereby ensuring the format compatibility of data between different cloud platforms. The parsing unit 14 parses the control instructions issued by the first cloud platform, and extracts the unique identifier and control parameters according to the parsing results, providing core support for cross-platform device control. The control unit 15 quickly locates the target device through the unique identifier, converts the control instructions of the first cloud platform into the protocol format supported by the second cloud platform and uploads it, thereby realizing accurate cross-platform device control.

[0141] It should be noted that technical personnel in the relevant technical field can clearly understand that for the convenience and conciseness of description, the specific working process of the system and each unit described above can refer to the corresponding process in the aforementioned cross-platform device management method embodiment based on protocol converter, and will not be repeated here.

[0142] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-platform device management method based on a protocol converter, applied to the management of different platforms, characterized in that: The device management method comprises: A unique identifier of a target device is registered in the first cloud platform, and a corresponding target device is connected to the second cloud platform; wherein the first cloud platform and the second cloud platform are both connected to a protocol converter; When the first cloud platform needs to obtain the real-time information of the target device, the first cloud platform sends the unique identifier to the protocol converter for parsing to find the corresponding target device in the second cloud platform; Acquire the real-time information of the target device based on the second cloud platform, send the real-time information to the protocol converter to convert it into a protocol format supported by the first cloud platform, and then upload it to the first cloud platform; When the first cloud platform needs to control the target device, the first cloud platform sends a control instruction containing the unique identifier to the protocol converter, and the protocol converter parses the control instruction to obtain the unique identifier and control parameters; Based on the unique identifier, the corresponding target device in the second cloud platform is found, and the control parameters are converted into a protocol format supported by the second cloud platform and uploaded to the second cloud platform. The second cloud platform controls the corresponding target device according to the control parameters.

2. The cross-platform device management method based on protocol converter according to claim 1, characterized in that: The step of registering a unique identifier of the target device in the first cloud platform and connecting the corresponding target device in the second cloud platform includes: The unique identifier of the target device is pre-registered in the device registration module of the first cloud platform, and the target device is pre-connected to the second cloud platform.

3. The cross-platform device management method based on protocol converter according to claim 1, characterized in that: The protocol converter is based on a containerized deployment strategy, and the protocol converter includes an acquisition module, a data conversion module, and an instruction conversion module; The acquisition module, the data conversion module and the instruction conversion module all run independently in a container manner; The acquisition module is used to parse the unique identifier to obtain the corresponding target device in the second cloud platform; The data conversion module is used to convert the real-time information into a protocol format supported by the first cloud platform; The instruction conversion module is used to convert the control parameters into a protocol format supported by the second cloud platform.

4. The cross-platform device management method based on protocol converter according to claim 3 is characterized in that: The acquisition module is used to parse the unique identifier to obtain the corresponding target device in the second cloud platform, including: Parsing the unique identifier by the acquisition module, and extracting device identification information and device association information based on the parsing result; Input the device identification information into a preset device comparison database, and compare it item by item with the device identification data set pre-stored in the second cloud platform to screen out a candidate device set; Matching the device association information with the candidate device set item by item to generate a device matching table; The device operation status information in the device matching table is filtered by a preset device operation status filtering rule to obtain a device status table; the device connection attribute information in the device matching table is filtered according to a preset device connection attribute verification rule to obtain a device attribute table; The device status table and the device attribute table are cross-validated, and the corresponding target device is analyzed based on the validation result.

5. The cross-platform device management method based on protocol converter according to claim 3 is characterized in that: The step of the data conversion module converting the real-time information into a protocol format supported by the first cloud platform includes: Parsing the field rules and field mapping rules of the protocol format supported by the first cloud platform through the data conversion module; Decomposing the real-time information according to the field mapping rules to obtain basic data fields and extended data fields, performing format matching on the basic data fields using the field mapping rules to generate a preliminary conversion data table; Extracting equipment environment parameters and historical performance data from the extended data field as associated attribute information, supplementing the preliminary conversion data table using the associated attribute information, and generating a supplemented conversion data table; Verifying the supplemented conversion data table and the field rules item by item, and if the verification passes, completing the conversion of the real-time information; If the check fails, the fields that fail to pass in the supplemented conversion data table are adjusted according to the field rules until the supplemented conversion data table meets the protocol requirements.

6. The cross-platform device management method based on protocol converter according to claim 3, characterized in that: The instruction conversion module is used to convert the control parameter into a protocol format supported by the second cloud platform, including: Parsing the command field rules and command format requirements of the protocol format supported by the second cloud platform through the instruction conversion module, and gradually decomposing the control parameters based on the command field rules to obtain basic control commands and advanced control logic; Match each command item in the basic control command one by one according to the command field rule to generate a preliminary command conversion table, and optimize and expand the preliminary command conversion table based on the advanced control logic to generate an extended control command table; Verifying the extended control command table and the command format requirements item by item, and if the verification passes, completing the conversion of the control parameters; If the verification fails, the command format requirement is used to adjust the failed command items in the extended control command table until the verification passes.

7. The cross-platform device management method based on protocol converter according to claim 1, characterized in that: The first cloud platform uses the MQTT protocol, and the second cloud platform uses the HTTPS protocol.

8. A cross-platform device management system based on a protocol converter, characterized in that: include: A registration unit, used to register a unique identifier of a target device in a first cloud platform, and a corresponding target device is connected to a second cloud platform; wherein the first cloud platform and the second cloud platform are both connected to a protocol converter; an acquisition unit, configured to, when the first cloud platform needs to acquire real-time information of the target device, send the unique identifier to the protocol converter for parsing to find the corresponding target device in the second cloud platform; a conversion unit, configured to obtain the real-time information of the target device based on the second cloud platform, and send the real-time information to the protocol converter to convert the information into a protocol format supported by the first cloud platform, and then upload the information to the first cloud platform; a parsing unit, configured to, when the first cloud platform needs to control the target device, send a control instruction containing the unique identifier to the protocol converter, and the protocol converter parses the control instruction to obtain the unique identifier and control parameters; A control unit is used to find the corresponding target device in the second cloud platform based on the unique identifier, and convert the control parameters into a protocol format supported by the second cloud platform and upload it to the second cloud platform, and the second cloud platform controls the corresponding target device according to the control parameters.

Images