Cross-Platform Device Management Method and System Based on Protocol Converter

Abstract

The present invention relates to the technical field of data processing, and provides a cross-platform device management method and system based on a protocol converter, including registering a unique identifier of a target device in a first cloud platform, and connecting a corresponding target device in a second cloud platform; when the first cloud platform needs to obtain real-time information of the target device, sending the unique identifier to the protocol converter for parsing, and finding the corresponding target device to obtain real-time information; when the first cloud platform needs to control the target device, sending a control instruction containing the unique identifier to the protocol converter to obtain the unique identifier and control parameters; and controlling the corresponding target device in the second cloud platform based on the unique identifier. Through the 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 device 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] This application relates to the technical field of data processing, and particularly to a cross-platform device management method and system based on a protocol converter. Background Art

[0002] With the rapid development of Internet of Things technology, the management of intelligent devices has gradually shifted from traditional local operations to a remote management mode based on cloud platforms. Cloud platforms provide a convenient solution 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 prior art, 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 generality for information interaction between different devices and can, to a certain extent, achieve the docking of devices with cloud platforms. Another solution is to implement protocol conversion through specific hardware gateways. These gateways can support simple conversion and data transfer 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 prior art, in practical applications, the adaptation of standardized protocols requires a large amount of development work, and the protocol differences between different devices and platforms will significantly increase the system complexity. Although hardware gateways can support basic protocol conversion, they show 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 that they cannot support efficient data synchronization between multiple platforms, resulting in insufficient real-time performance of device information and response speed of instruction 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 the existing solutions cannot support efficient data synchronization between multiple platforms, resulting in insufficient real-time performance of device information and response speed of instruction control, this 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 includes: registering a unique identifier of a target device in a first cloud platform, and connecting a corresponding target device in a second cloud platform; wherein, both the first cloud platform and the second cloud platform are connected to a 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 to find the corresponding target device in the second cloud platform; obtaining the real-time information of the target device based on the second cloud platform, and sending the real-time information to the protocol converter to be converted into a protocol format supported by the first cloud platform, and then uploading it to the first cloud platform; when the first cloud platform needs to control the target device, the first cloud platform issues 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; finding the corresponding target device in the second cloud platform based on the unique identifier, and converting the control parameters into a protocol format supported by the second cloud platform and uploading it 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 a target device in a first cloud platform and connecting a corresponding target device in a 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 in the second cloud platform.

[0008] As a preferred solution, the protocol converter is based on a 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; 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 step of the obtaining module for parsing the unique identifier to obtain the target device corresponding in the second cloud platform includes: parsing the unique identifier through the obtaining module, and extracting device identification information and device association information based on the parsing result; inputting the device identification information into a preset device comparison database, and performing item-by-item comparison with the device identification data set pre-stored in the second cloud platform to screen out a candidate device set; performing item-by-item matching processing on the device association information and the candidate device set to generate a device matching table; screening the device operation status information in the device matching table through a preset device operation status filtering rule to obtain a device status table; screening 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; performing cross-verification on the device status table and the device attribute table, and analyzing the corresponding target device based on the verification result.

[0010] As a preferred solution, the step of the data conversion module for converting the real-time information into the 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 rule to obtain a basic data field and an extended data field, and using the field mapping rule to perform format matching on the basic data field to generate a preliminary conversion data table; extracting device environment parameters and historical performance data from the extended data field as associated attribute information, and using the associated attribute information to supplement the preliminary conversion data table to generate a supplemented conversion data table; performing item-by-item verification on the supplemented conversion data table and the field rules, if the verification passes, the conversion of the real-time information is completed; if the verification fails, the unpassed fields in the supplemented conversion data table are adjusted according to the field rules until the supplemented conversion data table meets the protocol requirements.

[0011] As a preferred solution, the step in which the instruction conversion module is used to convert the control parameters into the protocol format supported by the second cloud platform includes: parsing, by the instruction conversion module, the command field rules and command format requirements of the protocol format supported by the second cloud platform, gradually decomposing the control parameters based on the command field rules to obtain basic control commands and advanced control logics; matching each command item in the basic control commands 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 logics to generate an extended control command table; verifying each item of the extended control command table against the command format requirements, and if the verification passes, completing the conversion of the control parameters; if the verification fails, adjusting the unpassed 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 is the MQTT protocol and the second cloud platform is the HTTPS protocol.

[0013] This application also provides a cross-platform device management system based on a protocol converter, including: a registration unit, configured to register the unique identifier of a target device in the first cloud platform and connect to the corresponding target device in the second cloud platform; wherein, both the first cloud platform and the second cloud platform are connected to the protocol converter; an acquisition unit, configured to 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; a conversion unit, configured to obtain the real-time information of the target device based on the second cloud platform, and after sending the real-time information to the protocol converter to be converted into the protocol format supported by the first cloud platform, upload it to the first cloud platform; an analysis unit, configured to when the first cloud platform needs to control the target device, the first cloud platform issues 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, configured to find the corresponding target device in the second cloud platform based on the unique identifier, convert the control parameters into the protocol format supported by the second cloud platform and upload them 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 technologies, seamless cross-platform connection for device management and control between the first cloud platform and the second cloud platform is achieved. Using the protocol converter as a communication intermediary, efficient conversion between two different protocol standards is supported, enabling synchronization of real-time device information and reliable transmission of control instructions. Combined with the device unique identifier mapping mechanism, accurate positioning and fast response of devices in a multi-platform environment are ensured. Through data stream parsing and optimization algorithms, the protocol converter can effectively reduce latency and improve the efficiency of data synchronization and instruction issuance, making it applicable to complex Internet of Things scenarios and improving the problem that existing solutions cannot support efficient data synchronization between multiple platforms, resulting in insufficient real-time performance of device information and response speed of instruction control. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0016] The structures, proportions, sizes, etc. shown in the drawings of this specification are only used to cooperate with the content disclosed in the specification for those familiar with this technology to understand and read, and are not used to limit the limiting conditions under which the present invention can be implemented. Therefore, they do not have substantial technical significance. Any modification of the structure, change of the proportional relationship, or adjustment of the size, without affecting the effects that the present invention can produce and the purposes that can be achieved, should still fall within the scope that can be covered by the technical content disclosed in the present invention.

[0017] Figure 1 is a flowchart showing the process of a cross-platform device management method based on a protocol converter provided by an embodiment of the present invention;

[0018] Figure 2 is a schematic block diagram showing the structure of a cross-platform device management system based on a protocol converter provided by an embodiment of the present invention.

[0019] DESCRIPTION OF REFERENCE NUMERALS:

[0020] 10. Cross-platform device management system based on protocol converter; 11. Registration unit; 12. Acquisition unit; 13. Conversion unit; 14. Analysis unit; 15. Control unit. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0021] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0022] The flowchart shown in the accompanying drawings is only an example, and does not necessarily include all contents and operations / steps, nor does it necessarily need to be executed in the described order. For example, some operations / steps can be decomposed, combined or partially merged, so the actual execution order may be changed according to the actual situation.

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

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

[0025] The technical solutions of the present invention will be further described below in conjunction with the accompanying drawings and through specific embodiments.

[0026] Embodiment 1:

[0027] As Figure 1 shown, this 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.

[0028] Step S100: Register the unique identifier of the target device in the first cloud platform, and connect the corresponding target device in the second cloud platform; wherein, both the first cloud platform and the second cloud platform are connected to the protocol converter.

[0029] In this step, the target device registers a unique identifier (ID) in the first cloud platform, and each unique identifier corresponds to the target device in the second cloud platform one by one. 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. This unique identifier is composed of the device serial number (SN) and the platform identifier (PlatformID). In the second cloud platform, through the gateway device or other communication modules, the target device realizes network connection with the cloud platform, and binds its unique identifier and data flow path through the protocol.

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

[0031] Step S200: 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.

[0032] 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 the unique identifier to the protocol converter through its API interface. After receiving the request, the protocol converter parses the unique identifier and looks up the corresponding target device address and access permission in the second cloud platform through the device mapping table. Specifically, the device mapping table of the protocol converter stores the association relationship 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 device in the second cloud platform by parsing the protocol packet.

[0033] For example, when the first cloud platform requests to obtain the real-time temperature data of the thermostat, after receiving the query instruction with ID "12345XYZ", the protocol converter 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).

[0034] Step S300: Based on the second cloud platform to obtain the real-time information of the target device, and after sending the real-time information to the protocol converter to convert it into the protocol format supported by the first cloud platform, upload it to the first cloud platform.

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

[0036] For example, the data format returned by the thermostat is a JSON object, and the content includes "temperature: 22°C, timestamp: 1672531200". After the protocol converter transcodes it into the Protobuf message format supported by the first cloud platform, it is transmitted to the first cloud platform to ensure error-free information transmission.

[0037] 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.

[0038] 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, and converts them into the protocol format supported by the second cloud platform, and then 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 to determine the target device path, and repackages the control parameters (such as switch status, threshold adjustment).

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

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

[0041] In this step, after the protocol converter forwards the control instruction of the first cloud platform to the second cloud platform, the second cloud platform controls the status of the target device according to the instruction, and feeds back the device operation result to the first cloud platform through the protocol converter. Specifically, the protocol converter listens to the execution feedback of the second cloud platform in real time, confirms whether the operation is successful by parsing its data packet, and re-encodes and sends the operation result to the first cloud platform.

[0042] 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 status update information to the first cloud platform.

[0043] In this embodiment, through the deployment of protocol converters and efficient protocol parsing technologies, this embodiment achieves seamless cross-platform connection of device management and control between the first cloud platform and the second cloud platform. Specifically, as a communication intermediary, the protocol converter supports efficient conversion between two different protocol standards (such as HTTP and MQTT), realizes the synchronization of real-time device information and the reliable transmission of control instructions. Combined with the device unique identifier mapping mechanism, it ensures the accurate positioning and quick response of devices in a multi-platform environment. In addition, through data stream parsing and optimization algorithms, the protocol converter can effectively reduce latency and improve the efficiency of data synchronization and instruction distribution, making it suitable for complex Internet of Things scenarios. In practical applications, this embodiment can help enterprises solve the protocol difference problems existing in traditional device management systems, reduce the access costs of multi-platform devices, and at the same time, by supporting the efficient management of a large number of devices, significantly improve the scalability and reliability of the system, and improve the problems that the existing solutions cannot support efficient data synchronization between multiple platforms, resulting in insufficient real-time performance of device information and response speed of instruction control.

[0044] The structures, proportions, sizes, etc. shown in the drawings of this specification are only used to cooperate with the content disclosed in the specification for those familiar with this technology to understand and read, and are not used to limit the limiting conditions under which the present invention can be implemented. Therefore, they do not have technical essential significance. Any modification of the structure, change of the proportional relationship, or adjustment of the size, without affecting the effects that the present invention can produce and the purposes that can be achieved, should still fall within the scope that can be covered by the technical content disclosed in the present invention.

[0045] Embodiment 2:

[0046] 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. Among them, both the first cloud platform and the second cloud platform are connected to the protocol converter.

[0047] By pre-registering the unique identifier of the target device in the first cloud platform and completing the connection of the target device in the second cloud platform, it ensures the uniqueness and accuracy of data interaction of the device between the two cloud platforms. Specifically, in the first cloud platform, the device registration module accepts the device information input by the user (such as device model, serial number SN, communication protocol type, etc.) through the API interface, automatically generates the device unique identifier, 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.

[0048] 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 as "ID-WM001" and stores it in the device database of the first cloud platform. At the same time, the smart water meter accesses the second cloud platform through the MQTT protocol, completes the connection operation, and establishes an association with "ID-WM001" in the first cloud platform.

[0049] 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 the form of containers.

[0050] By using the protocol converter based on the containerized deployment strategy, the acquisition module, the data conversion module, and the instruction conversion module can run in the form of independent containers, thus improving modularity and flexibility. Specifically, the acquisition module is responsible for receiving the device identification request from the first cloud platform, parsing the device information, and locating the target device in the second cloud platform; the data conversion module converts the device data from the format of the second cloud platform to the format supported by the first cloud platform through the field mapping rule and the protocol conversion logic; the instruction conversion module parses the control instruction of the first cloud platform and repackages it into the control command supported by the second cloud platform. This containerized strategy enables each module to be updated, extended, and maintained independently, and multiple containers communicate through standardized interfaces, avoiding coupling between modules.

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

[0052] Among them, the step of the acquisition module parsing 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 the device identification information and the device association information based on the parsing result.

[0053] 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 out associated information such as the serial number (SN number) and registration time of the device, and locates the target device from the preset device comparison database based on this information.

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

[0055] Input the device identification information into the 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 the candidate device set.

[0056] By inputting the device identification information into the device comparison database and comparing it with the device identification set in the second cloud platform, the 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.

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

[0058] Perform item-by-item matching processing on the device association information and the candidate device set to generate a device matching table.

[0059] By matching the device association information (such as registration time, device type, etc.) with the devices in the candidate device set one by one, a device matching table is generated. Specifically, the module compares item by item according to the priority of the association information (such as device type > registration time), adds the devices that match completely to the device matching table, and marks the matching degree.

[0060] For example, the candidate device set contains two devices, namely "WM001" and "WM002". The system compares the association information "device type: smart water meter" and "registration time: 2023-01-01", and finds that the device "WM001" matches completely, generating a device matching table: "device ID: WM001, matching degree: 100%".

[0061] Filter the device operation status information in the device matching table through preset device operation status filtering rules to obtain the device status table.

[0062] Through preset device operation status filtering rules, filter the device status information in the device matching table to generate the device status table. Specifically, according to the filtering rules (such as the device online status having a higher priority than the offline status), filter the devices in the matching table, and add the devices that meet the operation conditions to the device status table.

[0063] 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". According to the filtering rules, the system only adds "WM001" to the device status table.

[0064] Filter the device connection attribute information in the device matching table according to the preset device connection attribute verification rules to obtain the device attribute table.

[0065] Through the preset device connection attribute verification rules, filter the device connection attribute information in the device matching table to generate the device attribute table. Specifically, the module filters out the devices that meet the requirements according to the communication protocol type, network latency and other attributes of the devices.

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

[0067] Cross-verify the device status table and the device attribute table, and analyze the corresponding target devices based on the verification results. Specifically, use a rule-based matching algorithm to parse the target device operation status information contained in the device status table item by item, extract the real-time load index, working mode identifier and status stability parameters of the target device, and then generate a device operation status analysis matrix.

[0068] The rule-based matching algorithm includes:

[0069] Status information matching: According to the set device load threshold rules, identify and filter out the device information with a running load exceeding the predetermined threshold.

[0070] Mode identifier parsing: Use a decision tree algorithm to classify and parse the working mode identifier to identify the behavior characteristics of the device in different working states.

[0071] Stability assessment: Evaluate the state stability parameters of the device through regression analysis and calculate the state stability score of the device to determine whether the device meets the normal operation standard.

[0072] Through the association analysis algorithm, item-by-item analysis of the target device connection attribute information contained in the device attribute table is carried out to extract the communication protocol type, network connection strength index, and security authentication level of the target device, and then a device connection attribute analysis matrix is generated.

[0073] The association analysis algorithm includes:

[0074] Protocol type classification: Determine the communication protocol type adopted by the target device through the support vector machine (SVM) classification algorithm and further classify according to the protocol type.

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

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

[0077] According to the preset device attribute operation cross rules, match the real-time load index and network connection strength index in the device operation state analysis matrix and the device connection attribute analysis matrix to generate a load connection verification table.

[0078] Use the multi-objective optimization algorithm to verify item by item the state stability parameters in the device operation state analysis matrix and the communication protocol type of the device recorded in the load connection verification table to generate a device operation stability verification table.

[0079] Based on the consistency test algorithm, compare the security authentication level in the device connection attribute analysis matrix with the state stability parameters in the device operation stability verification table one by one, screen out the set of devices that meet the verification conditions, and generate a device verification matching table.

[0080] According to the sorting algorithm, sort the target devices in the device verification matching table according to the real-time load index, communication protocol type priority, and security authentication level to generate a target device priority list, and extract the device with the highest priority from the target device priority list as the target device.

[0081] For example, the device "WM001" in the device matching table supports the communication protocol "MQTT", the signal strength is "-70dBm", the latency is "50ms", the security authentication level is "SHA-256", and it meets the preset device connection property verification rules, so it is added to the device property table. The device "WM002" supports the communication protocol "HTTP", the signal strength is "-85dBm", the latency is "150ms", and it does not meet the security authentication requirements, so it is not included in the device property table.

[0082] In the analysis of the device operating state, the operating load of "WM001" in the device state table is "70%", which exceeds the predetermined load threshold, the working mode identifier is "active communication", and it is classified as a high-load state; its stability parameter score is "95%", and it is evaluated as a stable state through regression analysis. Based on the state stability and load matching rules, "WM001" is identified as a device that meets the operating standards.

[0083] In the analysis of the device connection properties, the network connection strength of the device "WM001" is calculated as "75 points" by the weighted average method, which meets the connection quality standard; the communication protocol type is "MQTT", and it is classified as a supported protocol type through SVM; the security authentication information passes the SHA-256 verification and meets the device authentication requirements. Finally, a device connection property analysis matrix is generated and cross-validated with the device operating state analysis matrix.

[0084] After further processing by the multi-objective optimization algorithm, the device "WM001" passes the tests in both the load connection verification and the state stability verification, generates a device verification matching table, and finally is given the highest priority in the sorting algorithm because its real-time load is "70%", the preferred supported communication protocol type is "MQTT", and the security authentication level is "SHA-256", becoming the target device.

[0085] Among them, the data conversion module is used for the step of converting real-time information into the 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.

[0086] By parsing the field rules and field mapping rules of the protocol format supported by the first cloud platform through the data conversion module, the functions and corresponding relationships of different fields are determined. 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 mapped one by one to the field rules of the first cloud platform, and a mapping relationship table between fields is established for subsequent data conversion.

[0087] For example, the protocol field rules of the first cloud platform require that device data contain the fields "temperature", "humidity", and "status", with the formats being floating-point type, decimal type, and boolean value 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.

[0088] Decompose the real-time information according to the field mapping rules to obtain the basic data fields and extended data fields, and use the field mapping rules to perform format matching on the basic data fields to generate a preliminary conversion data table.

[0089] Decompose the real-time information received from the second cloud platform through the field mapping rules, and disassemble the data 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, humidity), and the extended data fields include the operating environment parameters of the device (such as ambient temperature, network latency) and historical performance data (such as the operating status in the past 24 hours).

[0090] For example, the real-time data received from the second cloud platform is:

[0091] {"temp":22.5, "hum":45.8, "state":1, "env_temp":25, "latency":120, "history":[1, 0, 1, 1]}

[0092] The data conversion module decomposes it into:

[0093] Basic data fields: {"temp":22.5, "hum":45.8, "state":1}

[0094] Extended data fields: {"env_temp":25, "latency":120, "history":[1, 0, 1, 1]}.

[0095] Extract the device environment parameters and historical performance data from the extended data fields as associated attribute information, and use the associated attribute information to supplement the preliminary conversion data table to generate a supplemented conversion data table.

[0096] Extract device environment parameters (such as ambient temperature) and historical performance data from the extended data field as associated attribute information and supplement it to the preliminary conversion data table. Specifically, the data conversion module performs an association calculation on each attribute in the extended data field with the basic data field according to the field rules to generate the supplemented conversion data table.

[0097] 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 statistical information (such as the ratio of running time) of the device in the past 24 hours. The supplemented conversion data table is as follows:

[0098] {"temperature":22, "humidity":45.8, "status":1, "corrected_temp":20, "uptime_ratio":75%}.

[0099] Check the supplemented conversion data table item by item against the field rules. If the check passes, the conversion of real-time information is completed.

[0100] Check the supplemented conversion data table item by item against 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 conform to the rules is found, it is marked as "check failed".

[0101] For example, if the "temperature" field is checked and found to be in floating-point format, which conforms to 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 "check failed" and an error report is returned:

[0102] {"temperature":"pass", "humidity":"fail"}.

[0103] If the check fails, adjust the fields in the supplemented conversion data table that failed according to the field rules until the supplemented conversion data table meets the protocol requirements.

[0104] Specifically, the data conversion module recalculates the values of the out-of-range fields according to the field rules or discards the fields that cannot be corrected.

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

[0106] Among them, the instruction conversion module is used for the step of converting 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 logics.

[0107] By parsing the command field rules and command format requirements of the protocol format supported by the second cloud platform through the instruction conversion module, confirm the field name, data type, and command structure of the control command. Specifically, based on the command field parsing algorithm based on pattern recognition, parse the instruction semantic fields in the control parameters, extract the control target, operation action, and execution mode of the basic control command, and generate a basic control command analysis table.

[0108] The command field parsing algorithm based on pattern recognition includes:

[0109] Control target recognition: Use the Hidden Markov Model (HMM) to perform temporal analysis on the control target, predict the target control type of the target device according to the input control parameter sequence, and generate a mapping table of target device types and control targets.

[0110] Operation action parsing: Through a rule-based action recognition algorithm, identify the syntax rules of the operation action, classify the actions according to the tags of the command fields, and generate an operation action parsing table.

[0111] Execution mode judgment: Adopt a decision tree algorithm, combine the execution mode field in the control parameters with the previously extracted control target and operation action to determine the specific type of the execution mode (such as periodic execution, immediate execution, or conditional trigger), and generate an execution mode recognition matrix.

[0112] Based on the instruction semantic mapping rules, associate and map the instruction logic fields in the control parameters with the basic control command analysis table, extract the logical conditions, action trigger rules, and exception handling strategies of the advanced control logic, and generate an advanced control logic analysis matrix.

[0113] The instruction semantic mapping rules include:

[0114] Logical condition mapping: Use a fuzzy logic control algorithm to parse the logical conditions (such as trigger conditions, limit value judgments, etc.) in the control parameters, and generate a logical condition analysis table.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] Multi-level instruction matching and optimization algorithms include:

[0119] 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.

[0120] 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.

[0121] 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.

[0122] Command decomposition and conversion rules include:

[0123] 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.

[0124] 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.

[0125] 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.

[0126] Trigger condition verification includes:

[0127] 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.

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

[0129] Utilize the exception handling optimization strategy to compare the exception handling strategies in the advanced control logic analysis matrix item by item with the control action trigger table, screen out the operation actions that may have conflicts, and adjust the execution mode of the operation actions according to the optimization rules to generate an optimized control action execution table.

[0130] The exception handling optimization strategy includes:

[0131] Conflict analysis algorithm: Through a conflict detection algorithm (such as graph-based conflict path finding), identify and eliminate conflict conditions that may cause device instability or operation failure.

[0132] Priority readjustment: Use the priority dynamic adjustment algorithm to adjust the priority and execution order of operation actions according to the exception handling optimization strategy, ensuring that the system still operates stably under abnormal conditions.

[0133] Verify the operation actions recorded in the optimized control action execution table with the control objectives in the control objective mapping table to generate the final basic control commands and advanced control logic, thus completing the conversion of control parameters. For example, the control parameters in device "Device001" are: the target operation is "reduce temperature", the trigger condition is "indoor temperature > 30°C", and the exception handling strategy is "trigger an alarm signal when the thermostat is turned off abnormally". The instruction conversion module parses this control parameter through the command field parsing algorithm of pattern recognition to generate a basic control command analysis table, extracts the control objective as "thermostat", the operation action as "adjust the temperature to the target value", and the execution mode as "execute immediately".

[0134] In control objective recognition, the module uses the Hidden Markov Model (HMM) to recognize that the target control type of the "thermostat" device is "temperature control adjustment", and generates a mapping table of target devices and control objectives: {"Device001": "temperature control adjustment"}. Subsequently, the operation action parsing algorithm parses the operation semantic field "reduce temperature" to generate an operation action parsing table: {"action": "adjust temperature", "target value": "target value"}. Then, the execution mode judgment algorithm recognizes the execution mode as "execute immediately" according to the immediate execution mode field in the control parameters.

[0135] 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"}.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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:

[0141] {"operation":"start"}->{"cmd":"on"}.

[0142] 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.

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

[0144] {"cmd":"on", "delay":5}.

[0145] Verify the extended control command table item by item against the command format requirements. If the verification passes, the conversion of the control parameters is completed.

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

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

[0148] If the verification fails, adjust the failed command items in the extended control command table using the command format requirements until the verification passes.

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

[0150] 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, and finally ensures that the command table meets the requirements of the cloud platform.

[0151] 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 can be preferred, such as the tcp protocol, the modbus protocol, the websocket protocol, etc.

[0152] 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 achieved. This solution adopts an independent containerized operation mode for the acquisition module, data conversion module, and instruction conversion module to ensure the 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, format-matches, data-supplements, and validates the real-time device data 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, achieving the efficiency and accuracy of device control.

[0153] Through the containerized deployment strategy, each functional module of the protocol converter can operate independently and is highly flexible, and can be expanded or adjusted according to requirements, significantly improving the scalability and resource utilization rate of the system. In addition, based on the combination of multiple protocols such as MQTT and HTTPS, the real-time information synchronization of devices and the issuance of control commands are efficiently completed, meeting the requirements of multi-platform collaboration in complex Internet of Things scenarios. This embodiment not only solves technical problems such as cross-platform protocol incompatibility, data synchronization delay, and untimely control command response, but also ensures the accuracy and reliability of data and commands through a multi-level verification mechanism, providing an efficient, reliable, and low-cost solution for enterprise device management in a multi-cloud platform environment.

[0154] Embodiment 3:

[0155] As Figure 2 shown, the present application further 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, an analysis unit 14, and a control unit 15.

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

[0157] The acquisition unit 12 is mainly used to, 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.

[0158] The conversion unit 13 is mainly 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 the protocol format supported by the first cloud platform, and then upload it to the first cloud platform.

[0159] The parsing unit 14 is mainly used 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.

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

[0161] 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 comprehensively 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 at the same time 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, so as to quickly obtain the real-time information of the device. On this basis, the conversion unit 13 converts the real-time device data obtained from the second cloud platform into the protocol format supported by the first cloud platform through the protocol converter and then uploads it, so as to ensure the format compatibility of data between different cloud platforms. The parsing unit 14 parses the control instruction sent by the first cloud platform, and extracts the unique identifier and control parameters according to the parsing result, providing core support for cross-platform device control. The control unit 15 quickly locates the target device through the unique identifier, converts the control instruction of the first cloud platform into the protocol format supported by the second cloud platform and uploads it, so as to realize accurate cross-platform device control.

[0162] It should be noted that those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the above-described system and each unit can refer to the corresponding processes in the foregoing embodiment of the cross-platform device management method based on the protocol converter, and will not be elaborated here.

[0163] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than limiting it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate 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 both the first cloud platform and the second cloud platform are 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 the 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