Method, apparatus and device for managing and controlling isomerotopic internet of things equipment and medium

Abstract

This application relates to a method, apparatus, device, and medium for managing heterogeneous IoT devices, belonging to the field of IoT device management. The method for managing heterogeneous IoT devices includes: dynamically adapting protocols for devices, dynamically parsing and converting messages reported by the devices into a unified format; determining device status based on multi-dimensional feature information; issuing control commands to devices in a tracking manner; and dynamically adjusting topic subscriptions and load balancing. This embodiment of the heterogeneous IoT device management method effectively solves the problems of protocol heterogeneity, inconsistent device status, poor remote control reliability, and performance bottlenecks caused by massive device access in existing MQTT device management platforms.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) device management, and in particular to a method, apparatus, device, and medium for controlling heterogeneous IoT devices. Background Technology

[0002] Currently, the various types of IoT devices sold to users by IoT device operators, such as portable WiFi, IoT gateways, and sensors, are generally manufactured by different companies. Each company is responsible for the firmware development and MQTT communication interface implementation of the devices it sells. The IoT device operator is responsible for building a unified MQTT device management platform (hereinafter referred to as the platform) to receive data reported by all devices and issue remote control commands to the devices.

[0003] However, because the MQTT protocol itself only provides basic capabilities such as connection, publish, subscribe, and heartbeat, and does not define higher-level capabilities such as device access specifications, command confirmation mechanisms, and heterogeneous data parsing, the MQTT device management platform encounters the following problems as the types and number of connected devices rapidly increase: 1. Protocol heterogeneity: Devices in different factories use different MQTT topic and payload formats. The platform needs to develop separate parsing logic for each device, resulting in high maintenance costs and poor scalability. 2. Inconsistent device status: Due to differences in device firmware implementation, the heartbeat interval of some devices is unstable and the WillMessage implementation is not standardized, making it difficult for the platform to accurately determine the online / offline status of the devices; 3. Poor reliability of remote control: When issuing control commands to the device, it is difficult to confirm whether the command has been successfully executed because the device may be offline or the network is unstable, and there is a lack of end-to-end confirmation mechanism. 4. Performance bottlenecks with massive device access: When the number of connected devices reaches millions, the MQTT Broker faces performance bottlenecks in connection management, topic subscription, and message distribution.

[0004] Although some cloud vendors' IoT platforms provide device access SDKs and Thing Model mechanisms, which require devices to report data in a fixed Thing Model format, this unified device access solution requires the device to integrate a specific SDK or follow strict Thing Model specifications. However, factories are generally unwilling to modify firmware to adapt to platform specifications because this would increase costs, reduce product competitiveness, and prevent firmware upgrades for existing mass-produced devices. Summary of the Invention

[0005] To address the problems existing in current MQTT device management platforms, this application provides a method, apparatus, device, and medium for controlling heterogeneous IoT devices.

[0006] In one aspect of this disclosure, a method for managing heterogeneous Internet of Things (IoT) devices is proposed, comprising: Dynamic protocol adaptation is performed for the device, dynamically parsing and converting the messages reported by the device into a unified format; Determine device status based on multi-dimensional feature information; Send control commands to the equipment in a tracking manner; Dynamically adjust topic subscriptions and load balancing.

[0007] By adopting the above technical solutions, the problems of protocol heterogeneity, inconsistent device status, poor reliability of remote control, and performance bottlenecks in the access of massive numbers of devices in the existing MQTT device management platform are effectively solved.

[0008] Preferably, the dynamic protocol adaptation for the device includes: Establish and maintain a device type configuration library, which contains configuration information for at least one device type. The configuration information includes device identifier, matching rules, MQTT topic mapping rules, and payload parsing rules. In response to device-reported messages, match the corresponding device type configuration information for the device; In response to the addition of a new device type, add configuration information for the new device type to the configuration library.

[0009] By adopting the above technical solution, there is no need to hardcode the parsing logic for each device. When adding a new device type, only a JSON file needs to be configured. No code modification is required, resulting in low maintenance costs, good scalability, and effectively reducing the access cost of heterogeneous devices. Various existing devices can be connected without modifying the device firmware, and no cooperation from the device factory is required for upgrades, which reduces the difficulty of platform promotion and operation.

[0010] Preferably, adding configuration information for new device types to the configuration library includes: Analyze the messages reported by newly added devices; Based on the analysis results, a suitable configuration information template is recommended; Confirm or optimize the configuration information template to generate configuration information for the newly added device type.

[0011] By adopting the above technical solution, maintenance personnel only need to confirm or optimize the configuration information template to complete the information configuration of new device types, without having to manually write parsing rules.

[0012] Preferably, the multi-dimensional feature information includes: the time when the device last sent data, the TCP connection status, Will Message triggering, and historical behavior patterns.

[0013] By adopting the above technical solution, the accuracy of equipment status judgment is improved by relying on multi-dimensional feature information, and the misjudgment of "the equipment is actually online but the platform shows it as offline" is effectively avoided.

[0014] Preferably, the determination of device status based on multi-dimensional feature information includes: Obtain feature information in at least two dimensions; Set weights for the feature information in each dimension; Weighted fusion calculation of feature information from multiple dimensions; The device status is determined based on the calculation results.

[0015] By adopting the above technical solution, a high accuracy rate in judging equipment status can be achieved.

[0016] Preferably, the tracking-based control commands issued to the device include: In response to the issuance of control commands to the device, a unique command ID is assigned to the control command; Construct control command messages, setting the message subject, message body, response subject, and associated data; Send control command messages to the device and update the command status; Receive a message from the receiving device carrying the instruction ID and execution result, and update the instruction status.

[0017] By adopting the above technical solution, the entire lifecycle of instructions from issuance to execution can be tracked, and the instruction execution confirmation rate reaches 100%. Compared with the traditional solution (which can only confirm that the instruction has been sent), maintenance personnel can accurately know whether each instruction has been successfully executed by the device, thereby achieving end-to-end traceability of instructions.

[0018] Preferably, the dynamic adjustment of topic subscriptions and load balancing includes: Different devices are grouped into several groups based on device type and geographical location; Configure several Broker nodes for each group; Monitor the health status and load of Broker nodes; Adjust the grouping strategy in response to abnormal health conditions and / or load pressure.

[0019] By adopting the above technical solution, for scenarios with massive device access, the platform dynamically groups devices according to dimensions such as device type and geographical location. Each group independently subscribes to MQTT topics, avoiding single-point broker overload. Simultaneously, it supports horizontal scaling of the broker cluster. When the health status and load pressure of a broker node are abnormal, such as when its connection count exceeds a threshold, the platform automatically creates a new broker node. When a new broker node is added, it automatically migrates the connections of some devices, achieving load balancing.

[0020] In another aspect of this disclosure, a control device for heterogeneous Internet of Things (IoT) devices is provided, comprising: The dynamic protocol adaptation module is configured to enable dynamic protocol adaptation for the device, dynamically parsing and converting messages reported by the device into a unified format. The device status determination module is configured to determine the device status based on feature information from multiple dimensions. The control command issuance module is configured to issue control commands to the device in a tracking manner. The topic subscription and load balancing module is configured to dynamically adjust topic subscriptions and load balancing.

[0021] By adopting the above technical solutions, the problems of protocol heterogeneity, inconsistent device status, poor reliability of remote control, and performance bottlenecks in the access of massive numbers of devices in the existing MQTT device management platform are effectively solved.

[0022] In another aspect of this disclosure, an electronic device is provided, including a processor and a memory, the memory storing executable instructions, the processor being configured to invoke the executable instructions stored in the memory to execute the control method for heterogeneous Internet of Things devices described in any of the preceding claims.

[0023] In another aspect of this disclosure, a readable medium is provided that stores a program, which, when executed by a processor, implements the management and control method for heterogeneous Internet of Things devices as described in any of the preceding claims.

[0024] Beneficial technical effects: 1. By dynamically adapting protocols for devices, the messages reported by the devices are dynamically parsed and converted into a unified format. There is no need to hardcode the parsing logic for each device. When adding a new device type, only a JSON file needs to be configured. No code modification is required. The maintenance cost is low and the scalability is good. It effectively reduces the access cost of heterogeneous devices. Various existing devices can be connected without modifying the device firmware. No device factory cooperation is required for upgrades, which reduces the difficulty of platform promotion and operation.

[0025] 2. By using multi-dimensional feature information to determine the device status, the accuracy of device status judgment is improved, effectively avoiding the misjudgment that "the device is actually online but the platform shows it as offline".

[0026] 3. Tracking-based control commands for devices enable full lifecycle tracking from command issuance to execution, achieving a 100% command execution confirmation rate. Compared to traditional solutions (which can only confirm that the command has been sent), maintenance personnel can accurately know whether each command has been successfully executed by the device, thus achieving end-to-end command traceability.

[0027] 4. By dynamically adjusting topic subscriptions and load balancing, the platform's horizontal scalability has been improved, effectively eliminating performance bottlenecks caused by massive device access. Attached Figure Description

[0028] Figure 1 This is a flowchart of the management and control method for heterogeneous Internet of Things devices provided in the embodiments of this application.

[0029] Figure 2 This is a flowchart of dynamic protocol adaptation for a device provided in an embodiment of this application.

[0030] Figure 3 This is a flowchart of adding configuration information for a new device type to the configuration library, provided in an embodiment of this application.

[0031] Figure 4 This is a flowchart of the device status determination provided in the embodiments of this application.

[0032] Figure 5 This is a flowchart of the control command issuance and tracking provided in the embodiments of this application.

[0033] Figure 6 This is a flowchart illustrating the dynamic adjustment of topic subscription and load balancing provided in the embodiments of this application.

[0034] Figure 7 This is a schematic diagram of the structure of the control device for heterogeneous Internet of Things devices provided in the embodiments of this application.

[0035] Figure 8 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0036] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar structures, and therefore detailed descriptions of them will be omitted. Furthermore, the drawings are merely illustrative of this disclosure and are not necessarily drawn to scale.

[0037] The following is in conjunction with the appendix Figures 1-8This application will be described in further detail.

[0038] In one aspect of this disclosure, a method for managing heterogeneous Internet of Things (IoT) devices is proposed, such as... Figure 1 As shown, the management and control method for the heterogeneous IoT devices includes: S1. Perform dynamic protocol adaptation for the device, dynamically parse the messages reported by the device and convert them into a unified format.

[0039] After the messages reported by the device are dynamically parsed and converted into a unified internal message format (such as a standardized JSON structure), the unified format messages are sent to the message queue (RocketMQ) for subsequent business processing.

[0040] Specifically, such as Figure 2 As shown, the dynamic protocol adaptation for the device described in S1 includes: S11. Establish and maintain a device type configuration library. The configuration library has configuration information for at least one device type. The configuration information includes device identifier, matching rules, MQTT topic mapping rules, and payload parsing rules.

[0041] Operations and maintenance personnel add device types through the management console. The device identifier includes the device manufacturer and model, and the matching rule is a Client ID matching rule (regular expression). The MQTT topic mapping rule maps the topics reported by the device (e.g., / device / {id} / data) to a unified internal platform topic. The payload parsing rule is defined as a JSON Path or Protobuf, used to map the device's raw data to standard platform fields (temperature, signal strength, battery level, etc.).

[0042] The above configuration information is stored in the device configuration library in JSON format. By configuring the above content, when the device connects to the platform, the platform matches the corresponding device type configuration according to the device's Client ID and loads the parsing rules into the memory cache.

[0043] S12. In response to the device report message, match the corresponding device type configuration information for the device; or in response to the addition of a new device type, add the configuration information of the new device type to the configuration library.

[0044] As can be seen, by introducing dynamic protocol adaptation on the platform side, MQTT topic mapping rules and payload parsing rules for each device type (manufacturer + model) are defined through configuration files. The platform does not need to hardcode parsing logic for each device; it only needs to maintain the configuration file. When adding a new device type, only the configuration needs to be added, without modifying the code. This results in low maintenance costs, good scalability, and effectively reduces the cost of connecting heterogeneous devices. It can connect to various existing devices without modifying the device firmware, and does not require cooperation from device manufacturers for upgrades, thus reducing the difficulty of platform promotion and operation.

[0045] Furthermore, such as Figure 3 As shown, the configuration information for adding new device types to the configuration library as described in S12 includes: S121. Analyze the messages reported by newly added devices.

[0046] S122. Recommend a suitable configuration information template based on the analysis results.

[0047] S123. Confirm or optimize the configuration information template to generate configuration information for the newly added device type.

[0048] For example, when an unknown type of device connects for the first time, the platform records the topic and payload sample it reports. By analyzing the structural characteristics of the payload (such as JSON key names, data types, and value ranges), it automatically recommends a device type configuration information template. The operation and maintenance personnel only need to confirm or optimize the configuration information template to complete the information configuration of the new device type. There is no need to manually write parsing rules, which adds an "automatic protocol discovery" function to the platform.

[0049] S2. Determine the device status based on feature information from multiple dimensions.

[0050] The feature information of the multiple dimensions includes: the time when the device last sent data, the TCP connection status (i.e. the current connection status of the Broker connection manager), the Will Message trigger (whether the device's Will Message has been received), and historical behavior patterns (such as the reporting patterns of the device in the past 24 hours).

[0051] When a device sends a CONNECT request to the MQTT Broker, it carries information such as the Client ID and Will Message. After the Broker triggers the connection event, the platform records the device connection information (connection time, IP address, KeepAlive time). Then, the platform starts a "heartbeat monitoring timer", but does not use heartbeat timeout as the sole criterion for judgment.

[0052] When a device reports data, it publishes a PUBLISH message according to the theme and format preset by its firmware. For example, a portable WiFi device publishes to / device / SN123456 / status with a payload of {"bat":85,"rssi":-67,"4g_signal":3}. After receiving the message, the MQTT Broker calls the S1 dynamic protocol adaptation service based on the message's theme and Client ID.

[0053] That is, firstly, the device type configuration is matched according to the Client ID, then the key fields are extracted according to the Payload parsing rules (JSON Path) in the configuration, and the original fields are mapped to the platform standard fields: bat → battery_level, rssi → signal_strength, and a unified internal message format (such as a standardized JSON structure) is generated. Finally, the message in the unified format is sent to the message queue (RocketMQ) for subsequent business processing.

[0054] The following section details how to determine device status based on multi-dimensional feature information.

[0055] like Figure 4 As shown, the device status determination based on multi-dimensional feature information in S2 includes: S21. Obtain feature information in at least two dimensions.

[0056] By relying on multi-dimensional feature information to determine the device status, the accuracy of device status determination is improved compared to single-dimensional feature information, effectively avoiding misjudgments such as "the device is actually online but the platform shows it as offline".

[0057] S22. Set weights for the feature information of each dimension.

[0058] For example, the time of the device's last data transmission and the TCP connection status are each assigned a weight of 0.3, while WillMessage triggering and historical behavior patterns are each assigned a weight of 0.2. By weighted fusion calculation of feature information from multiple dimensions, high accuracy in device status judgment is achieved.

[0059] S23. Perform weighted fusion calculation on feature information of multiple dimensions.

[0060] S24. Determine the equipment status based on the calculation results.

[0061] As an example, if a TCP connection exists and the last reported time (i.e., the time when the device last sent data) is within 3 heartbeat cycles, the device is considered online.

[0062] If a TCP connection exists, but the last reporting time exceeds 3 heartbeat cycles, the device is determined to be online but silent (status marked as "silent online").

[0063] If a Will Message is received, the device is considered offline.

[0064] If the TCP connection does not exist and the last reported time exceeds 5 heartbeat cycles, the device is determined to be offline.

[0065] If historical behavior patterns show that the device reports at a fixed time every day, and the current time is within the expected reporting window but no report is made, then the device may be offline.

[0066] The platform maintains a "device status inference engine" that periodically (e.g., every 30 seconds) makes a comprehensive judgment on the status of each device, and the judgment results are updated in real time to the device shadow for query by business systems.

[0067] The heterogeneous IoT device management method in this embodiment addresses the problem of unstable device heartbeats. Instead of relying on a single heartbeat timeout judgment, the platform integrates multiple dimensions of features (last reporting time, Will Message triggering status, TCP connection status, and historical behavior patterns) to infer the device status and comprehensively judge the device's true online status. The accuracy is significantly higher than that of traditional heartbeat timeout solutions.

[0068] S3. Tracking control commands are issued to the equipment.

[0069] Specifically, such as Figure 5 As shown, the tracking-based issuance of control commands to the device in S3 includes: S31. In response to issuing control commands to the device, assign a unique command ID to the control command.

[0070] Users initiate device control commands (such as "restart portable WiFi" or "modify APN configuration") through the management console or API. The platform command management service generates a unique command ID (UUID), records the command details to the command log, and sets the status to "pending issuance".

[0071] S32. Construct a control command message, setting the message subject, message body, response subject, and associated data.

[0072] Specifically, the platform constructs control command messages and sets the following fields for MQTT messages: Topic: Control topic for device subscription (e.g., / device / {id} / command, obtained according to device type configuration); Payload: Includes instruction ID, instruction type, and instruction parameters; Response Topic: / device / {id} / command / response / {command_id} (MQTT 5.0 feature); Correlation Data: Command ID (used to associate requests and responses).

[0073] S33. Send control command messages to the device and update the command status.

[0074] The platform publishes messages through the MQTT Broker, updating the command status to "sent".

[0075] S34. Receive the message from the receiving device carrying the instruction ID and execution result, and update the instruction status.

[0076] After the platform publishes a message via the MQTT Broker, the device implements a response mechanism. Upon receiving and executing a control command, the device publishes a response message to the Response Topic, carrying the command ID and execution result (success / failure / error code). The platform listens to the response topic, updates the command status to "executed" upon receiving a response, and records the execution result and completion time. If no response is received within the timeout period (e.g., 30 seconds), the platform automatically retryes (up to 3 times). If there is still no response, it is marked as "execution timeout".

[0077] By adopting the above technical solution, the entire lifecycle of instructions from issuance to execution can be tracked, and the instruction execution confirmation rate reaches 100%. Compared with the traditional solution (which can only confirm that the instruction has been sent), maintenance personnel can accurately know whether each instruction has been successfully executed by the device, thereby achieving end-to-end traceability of instructions.

[0078] As can be seen, the management and control method for heterogeneous IoT devices in this embodiment draws on the confirmation mechanism of message queues, assigns a unique ID to each control command, and realizes the complete lifecycle tracking of the command from "issuance → delivery → execution → confirmation" through the MQTT response topic and correlation data mechanism, thus solving the problem of not knowing whether the command was successfully executed in the traditional solution.

[0079] S4. Dynamically adjust topic subscriptions and load balancing.

[0080] Specifically, such as Figure 6 As shown, the dynamic adjustment of topic subscriptions and load balancing described in S4 includes: S41. Divide different devices into several groups based on device type and geographical location.

[0081] The platform dynamically groups massive numbers of devices according to the dimension of "device type + geographical location" (such as "portable WiFi - East China" and "IoT gateway - South China").

[0082] S42. Configure several Broker nodes for each group.

[0083] Each device group corresponds to a set of MQTT Broker nodes, and the device connects to the Broker node corresponding to its group. The number of Broker nodes configured in each group depends on the actual situation.

[0084] S43. Monitor the health status and load pressure of Broker nodes.

[0085] Specifically, the health status and load pressure can be measured by CPU, memory, and number of connections. The health status and load pressure of the Broker node are determined by monitoring the CPU, memory, and number of connections of the Broker node.

[0086] S44. Adjust the grouping strategy in response to abnormal health conditions and / or load pressure.

[0087] Specifically, when the CPU usage of a node remains too high, it indicates that the node's processing capacity is insufficient, and load balancing should be triggered to distribute some devices or messages to other nodes.

[0088] Similarly, when memory usage is too high, it indicates that the node is carrying too many sessions or message caches. Some devices should be migrated to other nodes or expired sessions should be cleaned up.

[0089] Each Broker node has a maximum connection limit. When the number of connections on a node exceeds a preset threshold (e.g., 10,000), some devices should be migrated to other nodes to ensure that the number of connections is evenly distributed.

[0090] When abnormal CPU, memory, or connection count of a Broker node is detected, such as persistently high CPU usage, excessive memory usage, or connection count exceeding a preset threshold, the platform triggers load balancing, automatically creates a new Broker node, and then migrates the connections of some devices in that group to the new node (through dynamic DNS resolution or the Session Expiry mechanism of MQTT 5.0). And update the device group mapping relationship synchronously.

[0091] By adopting the above technical solution, for scenarios with massive device access, the platform dynamically groups devices according to dimensions such as device type and geographical location. Each group independently subscribes to MQTT topics, avoiding single-point broker overload. Simultaneously, it supports horizontal scaling of the broker cluster. When the health status and load pressure of a broker node are abnormal, such as when its connection count exceeds a threshold, the platform automatically creates a new broker node. When a new broker node is added, it automatically migrates the connections of some devices, achieving load balancing.

[0092] As can be seen, the management and control method for heterogeneous IoT devices in this embodiment effectively solves the problems of protocol heterogeneity, inconsistent device status, poor reliability of remote control, and performance bottlenecks of massive device access in existing MQTT device management platforms through S1-S4.

[0093] It should be noted that the execution order of S2-S4 is not limited to that described in this article. It can also be that the three steps S2, S3, and S4 are executed simultaneously, or that S3 is executed first, followed by S2, and finally S4. In fact, the three steps S2, S3, and S4 are executed independently of each other, so there is no causal relationship between the execution order of the three steps.

[0094] In this embodiment of the disclosure, the method for managing heterogeneous IoT devices further includes: detection of abnormal device behavior, which builds a baseline model based on the historical reported data of the device. When the device's reporting frequency, data value range, or connection behavior deviates from the baseline (such as a device suddenly reporting data at 10 times the normal frequency), the platform automatically triggers an alarm and can choose to isolate the device (disconnect or reject the message) to prevent abnormal devices from affecting the stability of the platform.

[0095] In this embodiment of the disclosure, the management and control method for heterogeneous IoT devices further includes: instruction priority and flow control, that is, assigning priority (high / medium / low) to different types of instructions. The platform dynamically adjusts the delivery strategy according to the current status of the device and the network quality. For example, high-priority instructions (such as "emergency shutdown") bypass flow restriction and are delivered immediately, using QoS 2 to ensure reliable delivery; low-priority instructions (such as "query status") are delivered in a concentrated manner during the device's silent period to avoid frequent device wake-up.

[0096] In this embodiment of the disclosure, the method for managing heterogeneous IoT devices further includes: device shadow and cloud collaborative caching, which involves maintaining a "device shadow" for each device on the platform side, caching the latest status of the devices, and a queue of unexecuted instructions. When a device is offline, the instructions sent to that device are temporarily stored in the device shadow; when the device comes back online, the platform automatically pushes the cached instructions to the device, ensuring that control instructions during the offline period are not lost.

[0097] In another aspect of the embodiments of this disclosure, a control device for heterogeneous Internet of Things (IoT) devices is provided, such as... Figure 7 As shown, the control device for the heterogeneous IoT devices includes: The dynamic protocol adaptation module is configured to enable dynamic protocol adaptation for the device, dynamically parsing and converting messages reported by the device into a unified format. The device status determination module is configured to determine the device status based on feature information from multiple dimensions. The control command issuance module is configured to issue control commands to the device in a tracking manner. The topic subscription and load balancing module is configured to dynamically adjust topic subscriptions and load balancing.

[0098] The dynamic protocol adaptation module, device status judgment module, control command issuance module, topic subscription and load balancing module together constitute the platform business unit, which is responsible for handling business logic, such as protocol parsing, status judgment, command tracing, load balancing, etc. Therefore, the platform business unit is not only composed of the dynamic protocol adaptation module, device status judgment module, control command issuance module, topic subscription and load balancing module.

[0099] In addition to the platform business unit, the control device for the heterogeneous IoT devices also includes a platform access unit and a platform data unit.

[0100] Specifically, the platform access unit is responsible for establishing connections with the device, sending and receiving messages, and monitoring the device status, including: The MQTT Broker cluster module supports horizontally scalable MQTT Brokers (such as EMQX and VerneMQ) and is responsible for device connection management and message routing. A dynamic topic routing module is used to route messages to the corresponding processing nodes based on device type and grouping information. The connection status monitoring module is used to monitor the device's CONNECT, DISCONNECT, and Will Message events.

[0101] Specifically, the platform data unit is responsible for storing persistent data such as configuration, status, and logs. It includes: The device shadow storage module is used to maintain the latest status of each device; The device configuration library module is used to store topic mappings and resolution rules for various device types; The instruction log storage module is used to record the history of all instructions issued, delivered, and executed.

[0102] It is evident that by cooperating with the platform business unit, platform access unit, and platform data unit, the existing problems of protocol heterogeneity, inconsistent device status, poor remote control reliability, and performance bottlenecks in accessing massive numbers of devices in the MQTT device management platform are effectively solved.

[0103] In another aspect of the embodiments of this disclosure, an electronic device is also provided, which includes, but is not limited to, mobile terminals such as mobile phones, tablet computers, and wearable devices.

[0104] like Figure 8 As shown, the electronic device includes a processor and a memory, the memory storing executable instructions.

[0105] Specifically, the processor may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0106] The memory may include a large-capacity storage device for information or instructions. For example, and not limitingly, the memory may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include removable or non-removable (or fixed) media. Where appropriate, the memory may be internal or external to the integrated gateway device. In a particular embodiment, the memory is a non-volatile solid-state memory. In a particular embodiment, the memory includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (Electrically Programmable ROM, EPROM), an electrically erasable programmable PROM (EEPROM), an electrically alterable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0107] The processor is used to invoke executable instructions stored in the memory to execute the control method for heterogeneous IoT devices described in any of the preceding claims.

[0108] In one example, the electronic device also includes a transceiver and a bus. For example, Figure 8As shown, the processor, memory, and transceiver are connected via a bus and communicate with each other.

[0109] A bus may be hardware, software, or both. For example, and not limitingly, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industrial Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, a bus may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0110] In another aspect of the embodiments of this disclosure, a readable medium is provided, the readable medium storing a program that, when executed by a processor, implements the management and control method for heterogeneous Internet of Things devices as described in any of the preceding claims.

[0111] The aforementioned storage medium may include, for example, a memory for computer program instructions, which can be executed by a processor of an electronic device to complete the control method for heterogeneous Internet of Things devices provided in the embodiments of this disclosure. Optionally, the storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), compact disc ROM (CD-ROM), magnetic tape, floppy disk, and optical data storage device.

[0112] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," "third," and similar terms used in this application specification and claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. The terms "an" or "a" and similar terms do not indicate a quantity limitation, but rather indicate the presence of at least one. The terms "comprising" or "including" and similar terms mean that the elements or objects preceding "comprising" or "including" encompass the elements or objects listed following "comprising" or "including" and their equivalents, and do not exclude other elements or objects. "Above," "below," "left," "right," etc., are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0113] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for controlling heterogeneous Internet of Things (IoT) devices, characterized in that, include: Dynamic protocol adaptation is performed for the device, dynamically parsing and converting the messages reported by the device into a unified format; Determine device status based on multi-dimensional feature information; Send control commands to the equipment in a tracking manner; Dynamically adjust topic subscriptions and load balancing.

2. The method for controlling heterogeneous IoT devices according to claim 1, characterized in that: The dynamic protocol adaptation for the device includes: Establish and maintain a device type configuration library, which contains configuration information for at least one device type. The configuration information includes device identifier, matching rules, MQTT topic mapping rules, and payload parsing rules. In response to device-reported messages, match the corresponding device type configuration information for the device; In response to the addition of a new device type, add configuration information for the new device type to the configuration library.

3. The method for controlling heterogeneous IoT devices according to claim 2, characterized in that: The process of adding configuration information for new device types to the configuration library includes: Analyze the messages reported by newly added devices; Based on the analysis results, a suitable configuration information template is recommended; Confirm or optimize the configuration information template to generate configuration information for the newly added device type.

4. The method for controlling heterogeneous IoT devices according to claim 1, characterized in that: The multi-dimensional feature information includes: the time when the device last sent data, the TCP connection status, Will Message triggering, and historical behavior patterns.

5. The method for controlling heterogeneous IoT devices according to claim 1, characterized in that: The method of determining the device status based on multi-dimensional feature information includes: Obtain feature information in at least two dimensions; Set weights for the feature information in each dimension; Weighted fusion calculation of feature information from multiple dimensions; The device status is determined based on the calculation results.

6. The method for controlling heterogeneous IoT devices according to claim 1, characterized in that: The tracking-based issuance of control commands to the device includes: In response to the issuance of control commands to the device, a unique command ID is assigned to the control command; Construct control command messages, setting the message subject, message body, response subject, and associated data; Send control command messages to the device and update the command status; Receive a message from the receiving device carrying the instruction ID and execution result, and update the instruction status.

7. The method for controlling heterogeneous IoT devices according to claim 1, characterized in that: The dynamic adjustment of topic subscriptions and load balancing includes: Different devices are grouped into several groups based on device type and geographical location; Configure several Broker nodes for each group; Monitor the health status and load of Broker nodes; Adjust the grouping strategy in response to abnormal health conditions and / or load pressure.

8. A control device for heterogeneous Internet of Things (IoT) devices, characterized in that, include: The dynamic protocol adaptation module is configured to enable dynamic protocol adaptation for the device, dynamically parsing and converting messages reported by the device into a unified format. The device status determination module is configured to determine the device status based on feature information from multiple dimensions. The control command issuance module is configured to issue control commands to the device in a tracking manner. The topic subscription and load balancing module is configured to dynamically adjust topic subscriptions and load balancing.

9. An electronic device, characterized in that: The device includes a processor and a memory, the memory storing executable instructions, and the processor being used to invoke the executable instructions stored in the memory to execute the control method for heterogeneous IoT devices as described in any one of claims 1 to 7.

10. A readable medium, characterized in that: The readable medium stores a program that, when executed by a processor, implements the management and control method for heterogeneous Internet of Things devices as described in any one of claims 1 to 7.

Images