Internet of Things equipment management method and system based on MQTT protocol

Abstract

The invention provides an Internet of Things equipment management method and system based on an MQTT protocol. The method comprises the following steps: sending an equipment discovery request carrying an equipment unique identifier to a cloud platform; receiving an authorization certificate and MQTT server connection information sent by the cloud platform; the authorization certificate and the MQTT server connection information are generated by the cloud platform according to the unique identifier of the equipment; according to the connection information of the MQTT server, establishing encrypted connection with the MQTT server, and performing identity authentication by using the authorization certificate during connection; a downlink management message sent by the cloud platform is received and analyzed, and the downlink management message is in a predefined JSON format and comprises a message type field used for defining behavior operation and an authorization certificate used for session verification; and verifying the authorization voucher in the downlink management message, and executing a corresponding management operation according to the message type field after the verification is passed. Through the technical scheme of the invention, the security of the remote management process can be improved.

Description

Technical Field

[0001] This invention relates to the field of data communication technology, and in particular to an Internet of Things (IoT) device management method and system based on the MQTT protocol. Background Technology

[0002] With the rapid development of IoT technology, an increasing number of IoT devices are being deployed in complex network environments across different geographical locations to perform various tasks. To ensure the stable operation of these devices, troubleshooting, and feature updates, effective remote management has become crucial.

[0003] In the current technological context, a common remote management model is implemented through a centralized cloud platform. Maintenance personnel first log into the cloud platform's management interface and then use this platform to issue commands to remote IoT devices, such as restarting devices, obtaining status updates, or updating software. To ensure security, existing technologies typically focus on protecting the security of the maintenance personnel's login process to the cloud platform, for example, by using username / password authentication or two-factor authentication.

[0004] However, in the aforementioned technical solutions, the communication process when the cloud platform issues specific management commands to IoT devices often presents security vulnerabilities. In many implementations, the command interaction between the cloud platform and the device uses a common network protocol and lacks an effective application-layer security authentication mechanism. This leads to a serious technical problem: when receiving management commands, IoT devices cannot reliably verify whether the commands actually originate from an authorized cloud platform. Due to the lack of effective authentication capabilities on the device side, any attacker who can access the device's network and simulate platform commands can potentially send malicious control commands to the device, thereby illegally restarting, tampering with configurations, or even completely paralyzing it, posing a significant security risk to the entire IoT system. Summary of the Invention

[0005] This invention provides an IoT device management method, system, electronic device, storage medium, and computer program product based on the MQTT protocol. It addresses the technical deficiency in existing technologies where IoT devices cannot effectively verify the legitimacy of the source of management commands when receiving them, thus making them vulnerable to unauthorized control. The invention enables devices to effectively verify the source of management commands before executing management operations, thereby improving the security of remote management processes.

[0006] This invention provides an IoT device management method based on the MQTT protocol, applicable to IoT devices, comprising the following steps:

[0007] Send a device discovery request carrying the device's unique identifier to the cloud platform;

[0008] Receive authorization credentials and MQTT server connection information sent by the cloud platform; the authorization credentials and MQTT server connection information are generated by the cloud platform based on the device's unique identifier;

[0009] Based on the MQTT server connection information, an encrypted connection is established with the MQTT server, and the authorization credential is used for identity authentication during the connection.

[0010] Receive and parse downlink management messages sent by the cloud platform. The downlink management messages are in a predefined JSON format and contain a message type field for defining behavioral operations and the authorization credentials for session verification.

[0011] Verify the authorization credential in the downlink management message, and perform the corresponding management operation according to the message type field after the verification is successful.

[0012] According to the present invention, an IoT device management method based on the MQTT protocol is provided, wherein performing the corresponding management operation according to the message type field includes:

[0013] When the message type field is a clock synchronization request, clock synchronization is performed according to the NTP server information carried in the downlink management message, and a response message containing the clock synchronization status is sent to the cloud platform.

[0014] When the message type field is a device rediscovery request, the current MQTT connection is disconnected, and the device discovery process is re-executed according to the delay time carried in the downlink management message, and a response message containing the rediscovery execution status is sent to the cloud platform.

[0015] When the message type field is a device upgrade request, the upgrade operation is performed according to the upgrade file path and file verification information carried in the downlink management message, and a response message containing the upgrade status is sent to the cloud platform.

[0016] When the message type field is to initiate an SSH tunneling request, an SSH tunneling connection is established based on the proxy server information and port mapping information carried in the downlink management message, and a response message containing the SSH tunneling enabled status is sent to the cloud platform.

[0017] When the message type field is a device offline request, the MQTT connection is disconnected and a response message containing the offline status is sent to the cloud platform.

[0018] When the message type field is a device restart request, a restart operation is performed, and a response message containing the restart status is sent to the cloud platform.

[0019] The IoT device management method based on the MQTT protocol provided by the present invention further includes:

[0020] After establishing the encrypted connection, an online request message containing basic device information is sent to the cloud platform, and an online response message containing initial configuration parameters is received from the cloud platform.

[0021] According to the keep-alive period in the initial configuration parameters, the device keep-alive request message is sent to the cloud platform at regular intervals so that the cloud platform can confirm the online status of the IoT device;

[0022] The device periodically reports its real-time status information to the cloud platform.

[0023] This invention provides an IoT device management method based on the MQTT protocol, applied to a cloud platform, comprising the following steps:

[0024] Receive device discovery requests sent by IoT devices, carrying the device's unique identifier;

[0025] The IoT device is verified based on the device's unique identifier, and upon successful verification, an authorization credential and MQTT server connection information are generated for MQTT connection.

[0026] The authorization credential and the MQTT server connection information are sent to the IoT device so that the IoT device can establish an encrypted connection with the MQTT server and perform identity authentication.

[0027] After the IoT device establishes an encrypted connection with the MQTT server using the authorization credential, a downlink management message is sent to the IoT device. The downlink management message is in a predefined JSON format and contains a message type field for defining behavioral operations and the authorization credential for session verification.

[0028] According to the present invention, an IoT device management method based on the MQTT protocol is provided, wherein sending a downlink management message to the IoT device includes:

[0029] When it is necessary to synchronize the clock of the IoT device, a downlink management message with the message type field set to clock synchronization request is sent, and a response message containing the clock synchronization status is received from the IoT device.

[0030] When the IoT device needs to be rediscovered, a downlink management message with the message type field set to device rediscovery request is sent, and a response message containing the rediscovery execution status is received from the IoT device.

[0031] When the IoT device needs to be upgraded, a downlink management message with the message type field set to device upgrade request is sent, and a response message containing the upgrade status is received from the IoT device; the downlink management message also carries the upgrade file path and file verification information.

[0032] When it is necessary to initiate SSH traversal for the IoT device, a downlink management message with the message type field set to initiate SSH traversal request is sent, and a response message containing the SSH traversal enabled status is received from the IoT device; the downlink management message also carries proxy server information and port mapping information.

[0033] When it is necessary to notify the IoT device to go offline, a downlink management message with the message type field set to device offline request is sent, and a response message containing the offline status is received from the IoT device.

[0034] When the IoT device needs to be restarted, a downlink management message with the message type field set to device restart request is sent, and a response message containing the restart status is received from the IoT device.

[0035] The IoT device management method based on the MQTT protocol provided by the present invention further includes:

[0036] Receive the online request message containing basic device information sent by the IoT device after establishing the encrypted connection, and respond to it with an online response message containing initial configuration parameters;

[0037] Receive device keep-alive request messages sent periodically by the IoT device according to the keep-alive period in the initial configuration parameters, and confirm the online status of the IoT device according to the device keep-alive request messages;

[0038] Receive real-time status information of the device from the IoT device on a regular, unilateral basis.

[0039] This invention also provides an IoT device management system based on the MQTT protocol, applied to IoT devices, including the following modules:

[0040] The device sending module is used to send a device discovery request carrying the device's unique identifier to the cloud platform.

[0041] The device receiving module is used to receive the authorization credential and MQTT server connection information sent by the cloud platform; the authorization credential and the MQTT server connection information are generated by the cloud platform based on the device's unique identifier;

[0042] The device processing module is used to establish an encrypted connection with the MQTT server based on the MQTT server connection information, and to use the authorization credential for identity authentication during the connection.

[0043] The device receiving module is also used to receive and parse downlink management messages sent by the cloud platform. The downlink management messages are in a predefined JSON format and contain a message type field for defining behavioral operations and the authorization credentials for session verification.

[0044] The device processing module is also used to verify the authorization credential in the downlink management message, and after the verification is successful, to perform the corresponding management operation according to the message type field.

[0045] This invention also provides an IoT device management system based on the MQTT protocol, applied to IoT devices, including the following modules:

[0046] The cloud receiving module is used to receive device discovery requests carrying unique device identifiers sent by IoT devices.

[0047] The cloud processing module is used to verify the IoT device based on the device's unique identifier, and generate authorization credentials and MQTT server connection information for MQTT connection after successful verification.

[0048] The cloud sending module is used to send the authorization credential and the MQTT server connection information to the IoT device, so that the IoT device can establish an encrypted connection with the MQTT server and perform identity authentication;

[0049] The cloud sending module is also used to send a downlink management message to the IoT device after the IoT device establishes an encrypted connection with the MQTT server using the authorization credential. The downlink management message is in a predefined JSON format and contains a message type field for defining behavioral operations and the authorization credential for session verification.

[0050] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the IoT device management method based on the MQTT protocol as described above.

[0051] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the IoT device management method based on the MQTT protocol as described above.

[0052] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements an IoT device management method based on the MQTT protocol as described above.

[0053] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0054] By enabling IoT devices to proactively send device discovery requests carrying their unique identifiers to the cloud platform, the platform can automatically discover and accurately identify each device in the network. The cloud platform then generates a dedicated authorization credential and MQTT server connection information based on this unique identifier and sends it to the device. This achieves effective control and authorization of device access, preventing unauthorized access and enabling unified scheduling of access resources. The IoT device establishes an encrypted connection with the MQTT server based on the received connection information and uses the authorization credential for authentication during connection, ensuring the confidentiality and integrity of the communication channel between the device and the cloud platform. By using a predefined JSON format for downlink management messages, including message type fields for defining actions and authorization credentials for session verification, a flexible and scalable remote command system is established, with application-level security checks added to each management command. Finally, by having IoT devices verify the authorization credentials in the downlink management message before executing instructions, and then perform the corresponding management operation according to the message type field after the verification is successful, it is ensured that the device will only respond to legitimate management instructions, effectively preventing malicious control and successfully translating the management intent in the cloud into specific physical behavior on the device. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0056] Figure 1 This is one of the flowcharts illustrating the IoT device management method based on the MQTT protocol provided by this invention.

[0057] Figure 2 This is the second flowchart of the IoT device management method based on the MQTT protocol provided by the present invention.

[0058] Figure 3This is the third flowchart of the IoT device management method based on the MQTT protocol provided by this invention.

[0059] Figure 4 This is the fourth flowchart illustrating the IoT device management method based on the MQTT protocol provided by this invention.

[0060] Figure 5 This is the fifth flowchart illustrating the IoT device management method based on the MQTT protocol provided by this invention.

[0061] Figure 6 This is the sixth flowchart illustrating the IoT device management method based on the MQTT protocol provided by this invention.

[0062] Figure 7 This is one of the structural diagrams of the IoT device management system based on the MQTT protocol provided by the present invention.

[0063] Figure 8 This is the second schematic diagram of the structure of the IoT device management system based on the MQTT protocol provided by the present invention.

[0064] Figure 9 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0066] It should be noted that in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. The terms "upper," "lower," etc., indicating orientation or positional relationships according to the accompanying drawings, are only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the system or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0067] The terms "first," "second," etc., used in this invention are used to distinguish similar objects, not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, without limiting the number of objects; for example, a first object can be one or more. Furthermore, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0068] The following is combined Figures 1-9 This invention describes the IoT device management method, system, electronic device, storage medium, and computer program product based on the MQTT protocol.

[0069] Reference Figure 1 , Figure 1 This is one of the flowcharts illustrating the IoT device management method based on the MQTT protocol provided by the present invention. The method is applied to IoT devices and includes steps 101 to 105:

[0070] Step 101: Send a device discovery request carrying the device's unique identifier to the cloud platform.

[0071] This invention provides an IoT device management function based on the MQTT protocol. In one specific embodiment, the initial step is to send a device discovery request carrying the device's unique identifier to the cloud platform. In IoT application scenarios, the number of devices is usually very large, and devices need to actively register with the cloud platform without human intervention. Therefore, designing an automated discovery process is necessary. This step is the first link in establishing a connection between the device and the cloud platform, enabling IoT devices to proactively announce their existence and request access to the management system.

[0072] In this step, the device unique identifier is a set of characters or numbers that permanently and uniquely identifies a specific IoT device hardware. In practical applications, this identifier can be the device's SN (serial number) or MAC address. Using this identifier, the cloud platform can accurately identify each individual device from a massive number of devices. A device discovery request is an initial communication action initiated by the IoT device. The purpose of this request is to notify the cloud platform that a device is attempting to establish a connection and is ready to be managed.

[0073] To implement this step, the IoT device first initiates a request to a pre-defined cloud platform address via HTTPS. This method ensures the security of the initial communication. The specific form of this request is an HTTP GET request. The request's URI parameters must include the device's unique identifier, such as its serial number (SN).

[0074] To enable the cloud platform to make more accurate judgments, the request can also include other information, such as the device's MAC address, device type, and Application Layer Protocol Negotiation (ALPN). The IoT device sends out the constructed request to initiate the entire device discovery process.

[0075] Step 102: Receive the authorization credentials and MQTT server connection information sent by the cloud platform; the authorization credentials and MQTT server connection information are generated by the cloud platform based on the device's unique identifier.

[0076] After the IoT device sends its device discovery request, this invention then receives authorization credentials and MQTT server connection information from the cloud platform. Because a device needs explicit instructions and credentials from the cloud platform after initiating its initial request before subsequent communication can proceed, without this step, any device could arbitrarily attempt to connect to the MQTT server, leading to significant security risks and management chaos. Therefore, this step constitutes a crucial link in the cloud platform's authorization and guidance of device access.

[0077] In this step, the authorization credential is a piece of specific data dynamically generated by the cloud platform for identity verification.

[0078] This credential is specifically represented by a token. Its main function is to serve as proof of device identity during the subsequent MQTT connection establishment process, ensuring that only authorized devices can successfully connect. The MQTT server connection information explicitly specifies the server address that the IoT device should connect to next. This includes the MQTT server's domain name and TCP port. The device needs this information to locate and establish a communication link.

[0079] The specific implementation of this step begins on the cloud platform. Upon receiving a discovery request from a device, the cloud platform extracts the device's unique identifier. Using this identifier, the platform queries its database to verify whether the device is authorized to access the network, for example, by checking if it complies with the license authorization. If verification is successful, the cloud platform generates a unique authorization credential (i.e., a token) for this session. Simultaneously, based on its own load or preset rules, the platform assigns a specific MQTT server to the device and determines its MQTT server connection information. Finally, the cloud platform sends the generated authorization credential and MQTT server connection information as a response to the IoT device via an HTTPS connection. Once the IoT device receives this response, the execution of this step is complete.

[0080] Step 103: Based on the MQTT server connection information, establish an encrypted connection with the MQTT server and use authorization credentials for identity authentication during connection.

[0081] After obtaining authorization information from the cloud platform, IoT devices immediately enter the connection establishment phase. This involves establishing an encrypted connection with the MQTT server based on the MQTT server connection information, and using authorization credentials for authentication during the connection process. Implementing this step is crucial because all subsequent management and monitoring interactions between the device and the cloud platform rely on a stable and secure communication link. Simply establishing an unencrypted and unauthenticated connection would completely expose transmitted data (such as device status and control commands), making it extremely vulnerable to eavesdropping or tampering. Therefore, this step aims to build a communication foundation that ensures both data privacy and device legitimacy.

[0082] In this step, an encrypted connection is a connection method that uses cryptographic techniques to protect the data transmitted between communicating parties. This invention uses the SSL / TLS protocol to implement this encrypted connection. This protocol can effectively prevent data from being stolen or tampered with by third parties during transmission. Identity authentication refers to the process by which a device needs to prove its legitimate identity to the server during connection establishment. This invention uses authorization credentials for identity authentication, ensuring that only devices authorized during the discovery phase can successfully connect.

[0083] In practice, the IoT device first parses the MQTT server connection information obtained in the previous step, extracting the MQTT server's domain name and TCP port. Then, the device starts an MQTT client and configures it to use the SSL / TLS protocol. The device initiates a connection request to the specified server domain name and port. In the MQTT protocol's connection packet, the device needs to place the authorization credential (i.e., the token) obtained in the previous step in a designated field, such as a username or password field. Upon receiving the connection request, the MQTT server first completes an SSL / TLS handshake to establish an encrypted connection. Next, the server extracts the authorization credential from the connection packet and verifies it to authenticate the device.

[0084] Step 104: Receive and parse the downlink management message sent by the cloud platform. The downlink management message is in a predefined JSON format, which contains a message type field for defining behavioral operations and authorization credentials for session verification.

[0085] After an IoT device successfully establishes an encrypted and authenticated connection with the MQTT server, it enters a state awaiting instructions from the cloud platform. This involves receiving and parsing downlink management messages sent by the cloud platform. These downlink management messages are in a predefined JSON format and contain message type fields defining behavioral operations and authorization credentials for session verification. This step is crucial for implementing device management functionality. The cloud platform needs a mechanism to send control commands to specific devices, such as restarts, upgrades, or configuration modifications. This step defines this one-way communication paradigm from the cloud to the device, enabling the platform to manage individual devices precisely and flexibly.

[0086] In this step, within the MQTT protocol, a message topic is a string used to identify the message category. Devices achieve uplink / downlink message sending and receiving separation by subscribing to different topics. The uplink channel involves devices sending messages and servers receiving them, while the downlink channel involves servers sending messages and devices receiving them. This invention primarily uses the following message topics: 1. Message topic type: Cloud.Public, i.e., messages from devices to servers; 2. Message topic type: Cloud.<device_sn> 1. **Private subscription message for the device:** A unicast message sent from the server to the device. 2. **Message topic type:** Cloud.Shell.Public: This is a message from the device to the server, used to debug the device's channels via shell commands. 3. **Message topic type:** Cloud.Shell.Public: This is a message from the device to the server, used to debug the device's channels via shell commands. 4. **Message topic type:** Cloud.Shell.Public: This is a private subscription message for the device, a unicast message sent from the server to the device.<device_sn> This refers to unicast messages related to Shell commands sent by the server to the device.

[0087] Downlink management messages are sent by the cloud platform and received by IoT devices to perform management tasks. These messages have a specific structure. They use a predefined JSON format, which is flexible and easily extensible. The message content must include a message type field that defines the action. This field is specifically the `type` field, whose value is a specific integer, such as 10001 representing a clock synchronization request. Additionally, the message contains authorization credentials for session verification, i.e., the token obtained in the previous steps.

[0088] To implement this step, after successfully establishing an MQTT connection, the networked device immediately sends a subscription request to the MQTT server. The device subscribes to one or more preset message topics, such as a private topic called Cloud for receiving unicast messages.<device_sn> When the cloud platform needs to operate the device, it constructs a downlink management message. This message is a JSON string containing multiple key-value pairs and a `data` field containing the specific parameters required for the operation. The cloud platform then publishes this JSON string as the message body to the topic subscribed to by the device. Since the IoT device has already subscribed to the topic, it immediately receives this message from the MQTT server. After receiving the message, the device parses it, extracting the various fields from the JSON structure for subsequent processing.

[0089] Step 105: Verify the authorization credentials in the downlink management message, and after successful verification, perform the corresponding management operation according to the message type field.

[0090] After receiving and parsing downlink management messages from the cloud platform, IoT devices need to process the messages and execute corresponding operations. This involves verifying the authorization credentials in the downlink management message and, upon successful verification, executing the corresponding management operation based on the message type field. This step ensures device security and achieves a closed loop for remote control. Simply receiving messages is insufficient; the device must first verify the legitimacy of the command before securely executing it. This step ensures that the device only responds to valid commands from a legitimate cloud platform, thus preventing unauthorized control and translating abstract message content into concrete device behavior.

[0091] A core action in this step is verifying the authorization credentials in the downlink management message. This is a security check process. The device compares the authorization credentials (i.e., token) carried in the message with the credentials it saved during the device discovery phase. Only when the two match perfectly can it be proven that the message indeed originated from the cloud platform with which it previously established a session. Another core action is executing the corresponding management operation based on the message type field. This is the core of command execution. The device activates predefined functional modules based on the value of the type field in the message. For example, a specific type value might trigger an upgrade process, while another value might trigger a restart process.

[0092] The specific implementation of this step is as follows. After parsing the JSON content in the downlink management message, the IoT device first extracts the value of the token field. The device compares this value with the authorization credential obtained in step 102 stored in its own memory. If the two do not match, the device discards the message and does not perform any subsequent operations. If the verification passes, the device then extracts the value of the type field. The device has an internal processing and distribution logic, similar to a state machine or selection structure. This logic dispatches the task to different processing functions based on the value of the message type field. For example, if the type value is 10006, the device will call its internal restart function. If the type value is 10003, the device will call the upgrade processing function and use parameters such as file_path and md5 carried in the data field of the message to perform the corresponding management operation.

[0093] By verifying the authorization credentials in the downlink management messages, a crucial security barrier is added to the entire communication link at the application layer. This ensures that even in the extreme case of MQTT connection hijacking, illegal commands cannot pass verification and are therefore unable to be executed, greatly enhancing device security. Furthermore, by executing corresponding management operations based on the message type field, the cloud platform can command devices to perform various complex management tasks by changing a simple numeric field. This makes remote device management highly flexible and practical, successfully translating cloud-based management intentions into physical actions on the device.

[0094] In one possible implementation, refer to Figure 2 , Figure 2 This is the second flowchart of the IoT device management method based on the MQTT protocol provided by the present invention. In step 105, the corresponding management operation is performed according to the message type field, which specifically includes the following steps:

[0095] Step 201: When the message type field is a clock synchronization request, perform clock synchronization based on the NTP server information carried in the downlink management message, and send a response message containing the clock synchronization status to the cloud platform.

[0096] Step 202: When the message type field is Device rediscovery request, disconnect the current MQTT connection, re-execute the device discovery process according to the delay time carried in the downlink management message, and send a response message containing the rediscovery execution status to the cloud platform.

[0097] Step 203: When the message type field is a device upgrade request, perform the upgrade operation according to the upgrade file path and file verification information carried in the downlink management message, and send a response message containing the upgrade status to the cloud platform.

[0098] Step 204: When the message type field is "Start SSH tunneling request", establish an SSH tunneling connection based on the proxy server information and port mapping information carried in the downlink management message, and send a response message containing the SSH tunneling enabled status to the cloud platform.

[0099] Step 205: When the message type field is a device offline request, perform the MQTT connection disconnection operation and send a response message containing the offline status to the cloud platform.

[0100] Step 206: When the message type field is a device restart request, perform the restart operation and send a response message containing the restart status to the cloud platform.

[0101] In the above implementation, the specific implementation of the management operation based on the message type field in step 105 can include the following situations, each of which corresponds to a specific management scenario and requirement.

[0102] The first specific implementation is step 201: when the message type field is a clock synchronization request, clock synchronization is performed according to the NTP server information carried in the downlink management message, and a response message containing the clock synchronization status is sent to the cloud platform.

[0103] In this step, the NTP server information is a set of server addresses provided by the cloud platform for Network Time Protocol (NTP) synchronization. This information is contained in an array named `array_ntp`, where each element can be the NTP server's domain name (ntp_domain), IPv4 address (ntp_ip), or IPv6 address (ntp_ipv6). The clock synchronization status is an identifier indicating the result of the device performing a clock synchronization operation; its value is a 32-bit integer, with 0 representing success and 1 representing failure.

[0104] In practice, when the device detects that the value of the `type` field in the received downlink management message is 10001, it initiates the clock synchronization process. The device parses the `data` field of the message body to extract the NTP server information. The device can choose to use any server from the `array_ntp` set for clock synchronization. If the device cannot access these NTP servers due to network restrictions or other reasons, it can use an alternative solution: directly using the `timestamp` field (a UTC-formatted timestamp) from the downlink management message as the current standard time to set the local clock. After clock adjustment is complete, the device constructs a response message. The `data` field of this response message contains the clock synchronization status (`status` field) and its own MAC address (`mac` field). The device then sends this response message to the cloud platform. Furthermore, as a preferred solution, the device immediately resets its internal keep-alive timer after successful time synchronization and immediately sends another device keep-alive request message to the server to ensure that the cloud platform can update its online status time in a timely manner.

[0105] The second specific implementation is step 202: when the message type field is a device rediscovery request, disconnect the current MQTT connection, re-execute the device discovery process according to the delay time carried in the downlink management message, and send a response message containing the rediscovery execution status to the cloud platform.

[0106] In this step, the delay time is a value specified by the cloud platform, defined by the delay parameter in the data field of the downlink management message, and is measured in seconds. It indicates how long the device should wait after disconnecting the current MQTT connection before restarting the device discovery process. The rediscovery execution status indicates whether the device has successfully received and is ready to execute the instruction; its value is a 32-bit integer, with 0 indicating success and 1 indicating failure.

[0107] In practice, when the device determines that the `type` field is 10002, it first parses the `response` and `delay` parameters in the `data` field. The `response` parameter specifies how many seconds the device should respond to the request. The device immediately constructs a response message containing the rediscovery execution status (the `status` field) and sends it to the cloud platform. After sending the response, the device disconnects the current MQTT connection. Subsequently, the device starts a timer, waiting for the duration specified by the delay time (the value of the `delay` parameter). After the wait is over, the device re-executes the device discovery process, returning to step 101. It is worth noting that after sending this instruction, the cloud platform temporarily retains the token of the device's current connection session, without immediately deleting it, to facilitate reconnection.

[0108] The third specific implementation method is step 203: when the message type field is a device upgrade request, perform the upgrade operation according to the upgrade file path and file verification information carried in the downlink management message, and send a response message containing the upgrade status to the cloud platform.

[0109] The core technical features of this step are the upgrade file path and file verification information. In the `data` field of the downlink management message, the upgrade file path is specified by the `file_path` parameter, which is an absolute path string pointing to the upgrade file. The file verification information is specified by the `md5` parameter, which is the MD5 hash value of the upgrade file. In addition, the `data` field also includes required parameters such as `file_flag` (upgrade file flag, used to distinguish upgrade types such as OEM, image, etc.), `model` (model name), and `device_type` (model code) to ensure the accuracy of the upgrade operation.

[0110] In practice, when the device determines that the `type` field is 10003, it initiates the upgrade process. The device first sends a response message to the cloud platform, where the upgrade status (`status`) in the `data` field is set to 2, indicating "Upgrading in progress." Subsequently, the device parses the `data` field to obtain the upgrade file path and file verification information. The device downloads the upgrade file according to the path. After downloading, the device calculates the MD5 value of the file and compares it with the MD5 value carried in the message. If the verification fails, the device terminates the upgrade and sends a "failed" response to the cloud. If the verification succeeds, the device begins the upgrade operation. After the upgrade is complete, the device reconnects to the cloud platform and sends a final response message containing either an upgrade status of "success" (`status` is 0) or "failure" (`status` is 1).

[0111] The fourth specific implementation is step 204: When the message type field is to start an SSH traversal request, an SSH traversal connection is established based on the proxy server information and port mapping information carried in the downlink management message, and a response message containing the SSH traversal enabled status is sent to the cloud platform.

[0112] The technical features of this step include proxy server information and port mapping information. This information is provided in the data field of the downlink management message. Proxy server information includes its IP address (server_ip) and port (server_port). Port mapping information defines the port mapping relationship for the tunneling connection, including the remote port on the proxy server (remote_port) and the port listened to by the device's local SSH service (local_port).

[0113] In practice, when the device determines the `type` field to be 10004, it parses the `data` field to obtain proxy server information and port mapping information. The device then starts an SSH reverse tunnel client. This client connects to the specified `server_ip` and `server_port`, requesting the proxy server to listen on the specified `remote_port`. Once an external connection accesses the proxy server's remote port, the proxy server forwards all traffic to the IoT device, which then forwards it to its `local_port`. In this way, an SSH tunneling connection is successfully established. After the connection is established, the device constructs and sends a response message to the cloud platform containing the SSH tunneling status (a `status` field value of 0 indicates success, and 1 indicates failure).

[0114] The fifth specific implementation is step 205: when the message type field is a device offline request, perform the MQTT connection disconnection operation and send a response message containing the offline status to the cloud platform.

[0115] In practice, when the device determines that the type field is 10005, it parses the mac and sn parameters in the data field for verification. Then, the device constructs a response message whose data field contains the offline status (a status value of 0 indicates successful command reception). The device sends this response message to the cloud platform. After sending, the device immediately disconnects the MQTT connection.

[0116] The sixth specific implementation is step 206: when the message type field is a device restart request, perform a restart operation and send a response message containing the restart status to the cloud platform.

[0117] In practice, when the device determines that the `type` field is 10006, it parses the `mac` and `sn` parameters from the `data` field. The device then immediately constructs a response message, where the `data` field contains the reboot status (a `status` value of 0 indicates an imminent reboot). The device sends this response message to the cloud platform. After sending, the device calls an interface provided by its operating system to perform the reboot operation.

[0118] In one possible implementation, refer to Figure 3 , Figure 3 This is the third flowchart of the IoT device management method based on the MQTT protocol provided by the present invention, which also includes the following steps:

[0119] Step 301: After establishing an encrypted connection, send an online request message containing basic device information to the cloud platform, and receive an online response message containing initial configuration parameters from the cloud platform.

[0120] Step 302: According to the keep-alive period in the initial configuration parameters, periodically send device keep-alive request messages to the cloud platform so that the cloud platform can confirm the online status of the IoT device.

[0121] Step 303: Periodically report real-time device status information to the cloud platform.

[0122] The method of this invention can also be implemented on the IoT device side, including several uplink communication steps performed after an encrypted connection is established. These steps enable the device to proactively interact with the cloud platform to complete registration, maintain online status, and report its own status.

[0123] The first implementation of uplink communication is step 301: After establishing an encrypted connection, send an online request message containing basic device information to the cloud platform, and receive an online response message containing initial configuration parameters from the cloud platform.

[0124] In this step, the basic device information is a set of data describing the attributes of the IoT device itself. Specifically, it includes the device's MAC address (mac), serial number (sn), model name (model), model code (device_type), and software version (version). The initial configuration parameters are a set of parameters issued to the device by the cloud platform to regulate its subsequent behavior. Specifically, it includes the keepalive interval (keepalive_interval), maximum keepalive attempts (keepalive_max), country code (country_code), and time zone-related addition and subtraction rules and values.

[0125] In practice, after successfully establishing an MQTT connection, the IoT device immediately constructs a go-live request message. This message is a JSON formatted message with its type field set to 20002. The device fills its basic device information into the data field of this message. Subsequently, the device publishes this go-live request message to a pre-defined topic, such as Cloud.Public. Upon receiving this message, the cloud platform verifies the token and license information. After successful verification, the platform generates a set of initial configuration parameters for the device, places them in the data field of a go-live response message, and then sends this response message to the device. The device receives and parses the response message, storing the obtained initial configuration parameters for later use.

[0126] The second implementation method for uplink communication is step 302: according to the keep-alive period in the initial configuration parameters, periodically send device keep-alive request messages to the cloud platform so that the cloud platform can confirm the online status of the IoT device.

[0127] In this step, the keepalive period is a time interval measured in seconds, at which the device needs to send keepalive information. This value is precisely the keepalive_interval that the device obtains from the initial configuration parameters in step 301. Another feature is the device keepalive request message, which is a message that the device sends periodically to prove that it is online.

[0128] In practice, after completing online initialization, the device starts a timer based on the acquired keep-alive period. Each time the timer expires, the device constructs a keep-alive request message. The `type` field of this message is set to 20001. Its `data` field contains information such as the device's MAC address, serial number (SN), and device model, as well as the current keep-alive period and the maximum number of keep-alive failures. The device sends this message to the cloud platform. Upon receiving the message, the cloud platform updates the device's last online time record to confirm the IoT device's online status. If the cloud detects that the keep-alive request interval sent by the device does not match the agreed-upon interval, or that the timestamp in the message differs significantly from the server's local time, it can determine that the device is malfunctioning and take appropriate measures, such as sending a clock synchronization request.

[0129] The third implementation method for uplink communication is step 303: periodically report the real-time status information of the device to the cloud platform unilaterally.

[0130] In this step, the device's real-time status information is a set of data describing the device's current performance load. Specifically, it is an object called status, which contains the percentage of CPU utilization (cpu), memory utilization (mem), and storage utilization (storage).

[0131] In practice, an independent scheduled task runs within the IoT device. This task periodically collects local performance data, specifically the current utilization rates of CPU, memory, and storage. After collection, the device constructs a reporting message with its `type` field set to 20003. The device then fills the message's `data` field with its MAC address, serial number, software version, and a `status` object containing real-time device status information. Subsequently, the device unilaterally reports this message to the cloud platform. This unilateral reporting means that after sending the message, the device neither expects nor waits for any response from the cloud platform. Upon receiving this information, the cloud platform stores it in its database for subsequent display, analysis, and alerting.

[0132] Through the steps described above, the cloud platform can continuously and in real time acquire performance metrics for all devices it manages. Maintenance personnel can then visually monitor the health status of each device through the platform's graphical interface.

[0133] In one possible implementation, refer to Figure 4 , Figure 4 This is the fourth flowchart of the IoT device management method based on the MQTT protocol provided by the present invention. The method is also applied to a cloud platform and includes the following steps:

[0134] Step 401: Receive a device discovery request sent by an IoT device, carrying the device's unique identifier.

[0135] Step 402: Verify the IoT device based on the device's unique identifier, and generate authorization credentials and MQTT server connection information for MQTT connection after successful verification.

[0136] Step 403: Send the authorization credentials and MQTT server connection information to the IoT device so that the IoT device can establish an encrypted connection with the MQTT server and perform identity authentication.

[0137] Step 404: After the IoT device establishes an encrypted connection with the MQTT server using authorization credentials, a downlink management message is sent to the IoT device. The downlink management message is in a predefined JSON format, which contains a message type field for defining behavioral operations and authorization credentials for session verification.

[0138] The method of the present invention can also be applied to cloud platforms, which include the step of interacting with Internet of Things devices to achieve device management.

[0139] The first step for the cloud platform is step 401: receiving device discovery requests carrying unique device identifiers from IoT devices. In an IoT system, the cloud platform, acting as the management center, passively waits for and processes access requests from a massive number of unknown devices. This step marks the starting point for the platform's response to device access intentions. Specifically, an HTTPS service interface on the cloud platform listens for HTTP GET requests from devices. The platform extracts information such as the device's serial number and MAC address from the URI parameters of this request, thus completing the reception of the device discovery request. This step enables the platform to detect new devices attempting to access the network and obtain a unique device identifier to identify those devices.

[0140] Next, the cloud platform executes step 402: verifying the IoT device based on its unique identifier, and generating an authorization credential and MQTT server connection information upon successful verification. This step is the core of the platform's access control and resource allocation, designed to ensure that only legitimate devices are accepted. In practice, the platform queries the device's authorization status in its internal database based on its unique identifier, such as checking the validity of its license. After successful verification, the platform generates a time-sensitive, unique token as the authorization credential, and selects a suitable MQTT server for the device according to a load balancing strategy or preset rules, combining this information into MQTT server connection information containing the domain name and TCP port. This step ensures platform security through the verification mechanism and achieves effective management of access resources by dynamically generating connection information.

[0141] Subsequently, the cloud platform executes step 403: sending the authorization credentials and MQTT server connection information to the IoT device, enabling the IoT device to establish an encrypted connection with the MQTT server and perform identity authentication. After completing verification and information generation, the platform needs to provide feedback to the device to guide its next step. In practice, the platform sends the authorization credentials and MQTT server connection information generated in the previous step as the response body of an HTTPS request to the IoT device. Upon receiving this information, the IoT device obtains all the credentials and path guidance required to access the MQTT network. This step completes the guidance from the discovery phase to the connection phase, providing the necessary conditions for establishing a secure communication link.

[0142] After the device completes the connection, the cloud platform executes step 404: After the IoT device establishes an encrypted connection with the MQTT server using authorization credentials, it sends a downlink management message to the IoT device. The downlink management message is in a predefined JSON format, containing a message type field for defining behavioral operations and authorization credentials for session verification. This step is fundamental for the cloud platform to proactively manage and control the device. It defines the standard way the platform issues commands to the device.

[0143] In practice, the platform first confirms that the IoT device has successfully established an encrypted connection with the MQTT server using authorization credentials. When operation on the device is required, the platform constructs a downlink management message. This message is a predefined JSON format string. This string contains a message type field (type) defining the action and an authorization credential (token) for session verification. The platform then sends this downlink management message to the IoT device via the MQTT protocol's publish mechanism.

[0144] This step establishes a secure command channel from the cloud to the device. Using a predefined JSON format and including a message type field allows for flexible expansion of the types of management commands. Simultaneously, the message includes authorization credentials for session verification, adding an application-layer security check to each downlink command, ensuring the platform can flexibly, accurately, and securely issue various management commands to specific devices.

[0145] In one possible implementation, refer to Figure 5 , Figure 5 This is the fifth flowchart of the IoT device management method based on the MQTT protocol provided by the present invention. In step 404, sending a downlink management message to the IoT device specifically includes the following steps:

[0146] Step 501: When it is necessary to synchronize the clock of an IoT device, send a downlink management message with the message type field set to clock synchronization request, and receive a response message from the IoT device containing the clock synchronization status.

[0147] Step 502: When IoT devices need to be rediscovered, send a downlink management message with the message type field set to device rediscovery request, and receive a response message from the IoT device containing the rediscovery execution status.

[0148] Step 503: When an IoT device needs to be upgraded, send a downlink management message with the message type field set to device upgrade request, and receive a response message from the IoT device containing the upgrade status; the downlink management message also carries the upgrade file path and file verification information.

[0149] Step 504: When it is necessary to start SSH tunneling for IoT devices, send a downlink management message with the message type field set to "Start SSH tunneling request" and receive a response message from the IoT device containing the SSH tunneling enabled status; the downlink management message also carries proxy server information and port mapping information.

[0150] Step 505: When it is necessary to notify the IoT device to go offline, send a downlink management message with the message type field set to device offline request, and receive a response message from the IoT device containing the offline status.

[0151] Step 506: When it is necessary to restart the IoT device, send a downlink management message with the message type field set to device restart request, and receive a response message from the IoT device containing the restart status.

[0152] It is understood that, corresponding to steps 201 to 206 above, in the implementation of the cloud platform described above, the specific implementation of sending downlink management messages to IoT devices in step 404 can include the following various situations, each corresponding to different management needs.

[0153] The first specific implementation is step 501: When it is necessary to synchronize the clock of an IoT device, a downlink management message with a clock synchronization request in the message type field is sent, and a response message containing the clock synchronization status sent by the IoT device is received. To ensure the uniformity of system time, the cloud platform will proactively initiate this operation. The platform constructs a downlink management message with a type field of 10001, whose data field carries one or more NTP server addresses. The platform sends this message to the device, then waits for and receives the response message from the device containing the clock synchronization status, thus completing a closed-loop time calibration operation.

[0154] The second specific implementation is step 502: When IoT devices need to be rediscovered, a downlink management message with a message type field indicating a device rediscovery request is sent, and a response message containing the rediscovery execution status is received from the IoT device. This operation is used for platform load balancing or device migration. The platform constructs a downlink management message with a type field of 10002, and its data field can specify the delayed reconnection time after the device disconnects. After sending this message, the platform receives a response message from the device containing the rediscovery execution status to confirm that the instruction has been received by the device.

[0155] The third specific implementation is step 503: When an IoT device needs to be upgraded, a downlink management message with a message type field indicating a device upgrade request is sent, and a response message containing the upgrade status is received from the IoT device; the downlink management message also carries the upgrade file path and file verification information. This operation is used for remote firmware or software updates of the device. The platform constructs a downlink management message with a type field of 10003, whose data field carries the upgrade file path and file verification information such as MD5. After sending this message, the platform receives response messages from the device in stages, containing the upgrade status (e.g., "Upgrading", "Success", or "Failure"), to monitor the entire upgrade process.

[0156] The fourth specific implementation is step 504: When it is necessary to initiate SSH traversal for an IoT device, a downlink management message with the message type field set to "Initiate SSH Traversal Request" is sent, and a response message containing the SSH traversal enabling status is received from the IoT device; the downlink management message also carries proxy server information and port mapping information. This operation is used for remote device debugging. The platform constructs a downlink management message with a type field of 10004, whose data field carries proxy server information and port mapping information. After sending this message, the platform receives a response message from the device containing the SSH traversal enabling status to confirm that the remote debugging channel has been established.

[0157] The fifth specific implementation is step 505: When it is necessary to notify the IoT device to go offline, a downlink management message with the message type field set to "Device Offline Request" is sent, and a response message containing the offline status is received from the IoT device. This operation is used for controllable offline management of the device. The platform constructs a downlink management message with the type field set to 10005 and sends it to the designated device. Subsequently, the platform receives a response message containing the offline status returned by the device before disconnection to confirm that the device is normally offline.

[0158] The sixth specific implementation method is step 506: When it is necessary to restart the IoT device, a downlink management message with the message type field set to device restart request is sent, and a response message containing the restart status is received from the IoT device. This operation is a basic remote maintenance method. The platform constructs a downlink management message with the type field set to 10006 and sends it. The platform will then receive a response message containing the restart status returned by the device before performing the restart, thereby confirming that the restart command has been successfully delivered.

[0159] In one possible implementation, refer to Figure 6 , Figure 6 This is the sixth flowchart of the IoT device management method based on the MQTT protocol provided by the present invention, which also includes the following steps:

[0160] Step 601: Receive the online request message containing basic device information sent by the IoT device after establishing an encrypted connection, and respond to it with an online response message containing initial configuration parameters.

[0161] Step 602: Receive device keep-alive request messages sent periodically by the IoT device according to the keep-alive period in the initial configuration parameters, and confirm the online status of the IoT device based on the device keep-alive request messages.

[0162] Step 603: Receive real-time device status information reported unilaterally by IoT devices at regular intervals.

[0163] Similarly, the method of the present invention also includes the following implementation on the cloud platform side, for processing communications initiated by IoT devices to achieve device registration and status monitoring.

[0164] The first implementation is step 601: Receiving an online request message containing basic device information sent by the IoT device after establishing an encrypted connection, and responding with an online response message containing initial configuration parameters. This step completes the formal registration of the device. Specifically, the cloud platform receives an online request message with a type field of 20002. The platform parses the message to obtain the basic device information contained therein, such as MAC address, serial number, and software version. After successful verification, the platform generates initial configuration parameters, such as the keep-alive interval and time zone information. Finally, the platform responds with an online response message carrying these generated parameters to guide the device's subsequent behavior.

[0165] The second implementation is step 602: receiving device keep-alive request messages periodically sent by the IoT device according to the keep-alive period in the initial configuration parameters, and confirming the online status of the IoT device based on the device keep-alive request messages. This step is used to maintain the application-layer heartbeat of the device. Specifically, the cloud platform periodically receives device keep-alive request messages from the IoT device. The sending frequency of this message is determined by the keep-alive period issued by the platform in the previous step. After receiving the message, the platform updates the last online timestamp of the device in the database to confirm the online status of the IoT device. This allows for the timely detection of devices that have lost connection due to application anomalies.

[0166] The third implementation method is step 603: receiving real-time device status information reported unilaterally by IoT devices at regular intervals. This step is used to collect device performance data for monitoring. Specifically, the cloud platform receives messages reported unilaterally by IoT devices at regular intervals. The message's type field is 20003, and its data field contains real-time device status information, such as CPU utilization, memory utilization, and storage utilization. After receiving this message, the platform stores it in the database for subsequent analysis and display, without needing to respond to the message. This achieves refined monitoring of device health status.

[0167] Reference Figure 7 , Figure 7 This is one of the structural diagrams of an IoT device management system based on the MQTT protocol provided by the present invention, applied to IoT devices. The system includes:

[0168] The device sending module is used to send a device discovery request carrying the device's unique identifier to the cloud platform.

[0169] The device receiving module is used to receive the authorization credential and MQTT server connection information sent by the cloud platform; the authorization credential and the MQTT server connection information are generated by the cloud platform based on the device's unique identifier;

[0170] The device processing module is used to establish an encrypted connection with the MQTT server based on the MQTT server connection information, and to use the authorization credential for identity authentication during the connection.

[0171] The device receiving module is also used to receive and parse downlink management messages sent by the cloud platform. The downlink management messages are in a predefined JSON format and contain a message type field for defining behavioral operations and the authorization credentials for session verification.

[0172] The device processing module is also used to verify the authorization credential in the downlink management message, and after the verification is successful, to perform the corresponding management operation according to the message type field.

[0173] Reference Figure 8 , Figure 8 This is the second structural diagram of the IoT device management system based on the MQTT protocol provided by this invention, applied to a cloud platform. The system includes:

[0174] The cloud receiving module is used to receive device discovery requests carrying unique device identifiers sent by IoT devices.

[0175] The cloud processing module is used to verify the IoT device based on the device's unique identifier, and generate authorization credentials and MQTT server connection information for MQTT connection after successful verification.

[0176] The cloud sending module is used to send the authorization credential and the MQTT server connection information to the IoT device, so that the IoT device can establish an encrypted connection with the MQTT server and perform identity authentication;

[0177] The cloud sending module is also used to send a downlink management message to the IoT device after the IoT device establishes an encrypted connection with the MQTT server using the authorization credential. The downlink management message is in a predefined JSON format and contains a message type field for defining behavioral operations and the authorization credential for session verification.

[0178] It should be noted that the IoT device management system based on the MQTT protocol provided by the present invention can execute the IoT device management method based on the MQTT protocol of any of the above embodiments during specific operation, which will not be elaborated in this embodiment.

[0179] This application also discloses an electronic device. (See reference...) Figure 9 , Figure 9 This is a schematic diagram of the structure of the electronic device provided by the present invention. The electronic device 900 may include: at least one processor 901, at least one network interface 904, a user interface 903, a memory 905, and at least one communication bus 902.

[0180] The communication bus 902 is used to enable communication between these components.

[0181] The user interface 903 may include a display screen and a camera. Optionally, the user interface 903 may also include a standard wired interface and a wireless interface.

[0182] The network interface 904 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0183] The processor 901 may include one or more processing cores. The processor 901 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 905, and by calling data stored in the memory 905. Optionally, the processor 901 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 901 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 901 and may be implemented as a separate chip.

[0184] The memory 905 may include random access memory (RAM) or read-only memory. Optionally, the memory 905 may include a non-transitory computer-readable storage medium. The memory 905 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 905 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 905 may also be at least one storage device located remotely from the aforementioned processor 901. (Refer to...) Figure 9 The memory 905, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and an application program.

[0185] exist Figure 9In the illustrated electronic device 900, the user interface 903 is mainly used to provide an input interface for the user and to acquire user input data; while the processor 901 can be used to call an application stored in the memory 905. When executed by one or more processors 901, the electronic device 900 performs one or more methods as described in the above embodiments. It should be noted that, for the foregoing method embodiments, for the sake of simplicity, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0186] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0187] In the various embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

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

[0189] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0190] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0191] Finally, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer is able to execute the energy consumption prediction method based on the energy consumption model provided in the above embodiments.

[0192] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will readily conceive of by those skilled in the art upon consideration of the specification and the disclosure of practical truths.

[0193] This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for managing Internet of Things devices based on an MQTT protocol, characterized in that, The application is applied to an Internet of Things device, and comprises the following steps: sending a device discovery request carrying a device unique identifier to a cloud platform; receiving authorization credentials and MQTT server connection information sent by the cloud platform, wherein the authorization credentials and the MQTT server connection information are generated by the cloud platform according to the device unique identifier; establishing an encrypted connection with the MQTT server according to the MQTT server connection information, and using the authorization credentials for identity authentication when the connection is established; receiving and parsing a downlink management message sent by the cloud platform, wherein the downlink management message is in a predefined JSON format, and comprises a message type field for defining behavior operation and the authorization credentials for session verification; verifying the authorization credentials in the downlink management message, and executing a corresponding management operation according to the message type field after the verification is passed.

2. The IoT device management method based on the MQTT protocol implementation according to claim 1, characterized in that, The step of executing a corresponding management operation according to the message type field comprises the following steps: when the message type field is a clock synchronization request, performing clock synchronization according to NTP server information carried in the downlink management message, and sending a response message comprising a clock synchronization state to the cloud platform; when the message type field is a device rediscovery request, disconnecting the current MQTT connection, and re-executing a device discovery process according to a delay time carried in the downlink management message, and sending a response message comprising a rediscovery execution state to the cloud platform; when the message type field is a device upgrade request, performing an upgrade operation according to an upgrade file path and file verification information carried in the downlink management message, and sending a response message comprising an upgrade state to the cloud platform; when the message type field is a start SSH penetration request, establishing an SSH penetration connection according to proxy server information and port mapping information carried in the downlink management message, and sending a response message comprising an SSH penetration opening state to the cloud platform; when the message type field is a device offline request, performing a disconnection operation of the MQTT connection, and sending a response message comprising an offline state to the cloud platform; when the message type field is a device restart request, performing a restart operation, and sending a response message comprising a restart state to the cloud platform. 3.The method for managing Internet of Things devices based on MQTT protocol implementation according to claim 1, characterized in that, The application further comprises the following steps: after the encrypted connection is established, sending an online request message comprising device basic information to the cloud platform, and receiving an online response message comprising initial configuration parameters sent by the cloud platform in response; sending a device keep-alive request message to the cloud platform at a regular time according to a keep-alive period in the initial configuration parameters, so that the cloud platform confirms the online state of the Internet of Things device; regularly reporting device real-time state information to the cloud platform unilaterally.

4. An Internet of Things device management method implemented based on an MQTT protocol, characterized by, The application is applied to a cloud platform, and comprises the following steps: receiving a device discovery request carrying a device unique identifier sent by an Internet of Things device; verifying the Internet of Things device according to the device unique identifier, and generating authorization credentials and MQTT server connection information for MQTT connection after the verification is passed; sending the authorization credential and the MQTT server connection information to the IoT device to enable the IoT device to establish an encrypted connection with the MQTT server and to perform identity authentication; sending a downlink management message to the IoT device after the IoT device establishes the encrypted connection with the MQTT server using the authorization credential, the downlink management message being in a predefined JSON format and containing a message type field for defining behavior operation and the authorization credential for session verification.

5. The IoT device management method based on the MQTT protocol implementation according to claim 4, characterized in that, The sending of the downlink management message to the IoT device comprises: when it is necessary to synchronize the clock of the IoT device, sending a downlink management message with the message type field being clock synchronization request, and receiving a response message containing clock synchronization status sent by the IoT device; when it is necessary to re-discover the IoT device, sending a downlink management message with the message type field being device re-discovery request, and receiving a response message containing re-discovery execution status sent by the IoT device; when it is necessary to upgrade the IoT device, sending a downlink management message with the message type field being device upgrade request, and receiving a response message containing upgrade status sent by the IoT device; the downlink management message further carries upgrade file path and file verification information; when it is necessary to start SSH penetration of the IoT device, sending a downlink management message with the message type field being start SSH penetration request, and receiving a response message containing SSH penetration opening status sent by the IoT device; the downlink management message further carries proxy server information and port mapping information; when it is necessary to notify the IoT device to go offline, sending a downlink management message with the message type field being device offline request, and receiving a response message containing offline status sent by the IoT device; when it is necessary to restart the IoT device, sending a downlink management message with the message type field being device restart request, and receiving a response message containing restart status sent by the IoT device.

6. The IoT device management method based on the MQTT protocol implementation according to claim 4, characterized in that, Further comprising: receiving an online request message containing device basic information sent by the IoT device after the establishment of the encrypted connection, and responding to it with an online response message containing initial configuration parameters; receiving a device keep-alive request message sent by the IoT device according to the keep-alive period in the initial configuration parameters, and confirming the online state of the IoT device according to the device keep-alive request message; receiving device real-time state information reported by the IoT device on a regular basis.

7. An Internet of Things device management system implemented based on an MQTT protocol, characterized by, Applied to an IoT device, comprising: a device sending module for sending a device discovery request carrying a device unique identifier to a cloud platform a device receiving module for receiving an authorization credential and MQTT server connection information sent by the cloud platform; the authorization credential and the MQTT server connection information are generated by the cloud platform according to the device unique identifier; a device processing module for establishing an encrypted connection with the MQTT server according to the MQTT server connection information, and performing identity authentication using the authorization credential when connected. The device receiving module is further configured to receive and parse a downlink management message sent by the cloud platform, the downlink management message being in a predefined JSON format, containing a message type field for defining behavior operation and the authorization credential for session verification; The device processing module is further configured to verify the authorization credential in the downlink management message, and after verification, perform a corresponding management operation according to the message type field.

8. An Internet of Things device management system implemented based on an MQTT protocol, characterized by, The application is applied to a cloud platform, comprising: A cloud receiving module is configured to receive a device discovery request sent by an Internet of Things device, the device discovery request carrying a device unique identifier; A cloud processing module is configured to verify the Internet of Things device according to the device unique identifier, and generate an authorization credential and MQTT server connection information for MQTT connection after verification; A cloud sending module is configured to send the authorization credential and the MQTT server connection information to the Internet of Things device, so that the Internet of Things device establishes an encrypted connection with the MQTT server and performs identity authentication; The cloud sending module is further configured to send a downlink management message to the Internet of Things device after the Internet of Things device establishes an encrypted connection with the MQTT server using the authorization credential, the downlink management message being in a predefined JSON format, containing a message type field for defining behavior operation and the authorization credential for session verification.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and running on the processor, characterized in that, The processor executes the computer program to implement the Internet of Things device management method based on the MQTT protocol as claimed in any one of claims 1 to 3, or implement the Internet of Things device management method based on the MQTT protocol as claimed in any one of claims 4 to 6.

10. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the Internet of Things device management method based on the MQTT protocol as claimed in any one of claims 1 to 3, or implement the Internet of Things device management method based on the MQTT protocol as claimed in any one of claims 4 to 6.

Images