Internet of Things gateway device communication method and system based on MQTT

Abstract

The invention relates to the field of Internet of Things communication technology and gateway equipment, in particular to an Internet of Things gateway equipment communication method and system based on MQTT, and the method comprises the following steps: constructing a communication channel of an equipment layer, a unified equipment management platform and an application layer based on an MQTT protocol, the unified equipment management platform communicates with the equipment of the equipment layer and the application of the application layer by using a preset API (Application Program Interface) which is based on semantic consistency of attributes, telemetering and instructions; the equipment layer or the application layer sends a message to the application layer or the equipment layer through a preset API (Application Program Interface), the equipment layer or the application layer firstly sends MQTT PUBLISH to the unified equipment management platform, and after the unified equipment management platform receives the MQTT PUBLISH, the unified equipment management platform forwards the message to the application layer or the equipment layer according to the theme of the message. Through the method and the system, the functions of access, data reporting, reverse control and the like of the Internet of Things gateway equipment are realized, and standardized concepts and interfaces are provided for upper-layer application development and gateway equipment access.

Description

Technical Field

[0001] The present invention relates to the field of Internet of Things communication technology, the field of Internet of Things gateway equipment, and in particular to an MQTT-based Internet of Things gateway equipment communication method and system. Background Art

[0002] MQTT (Message Queuing Telemetry Transport) is a lightweight publish / subscribe messaging protocol designed for low-bandwidth, unreliable or high-latency communication environments, such as the Internet of Things (IoT) scenario. The MQTT protocol occupies an important position in IoT communications due to its simplicity, ease of implementation, support for QoS (Quality of Service), and small message size.

[0003] Relying on the rapid expansion of the concept of the Internet of Things, IoT gateway devices have also been widely used in various fields, such as power monitoring gateways deployed on power overhead lines, environmental monitoring gateways deployed in the wild, high-speed monitoring gateways deployed on high-speed gantries, etc. When developing vertical industry platforms for gateways in different industries, there is an urgent need for a universal IoT gateway communication method and system to provide basic support for these industry application platforms, such as shielding the underlying communication details, providing a unified device communication interface, and accelerating the development of the application layer.

[0004] The existing interaction methods between vertical platforms and devices in the IoT industry have their own semantic concepts and communication methods due to different industry fields, showing two characteristics: fragmented communication methods and repeated development work. For example, when we apply the IoT gateway to the power industry, we need to develop a set of communication methods and systems unique to the power industry when we need to develop a power platform. When we apply the gateway to another vertical industry field, the same work has to be done again. This situation has caused duplication of work, which is obviously inefficient. At the same time, because the communication semantic concepts are not unified, it also creates obstacles for application layer development and device layer development. Summary of the invention

[0005] The present invention proposes an IoT gateway device communication method and system based on MQTT, establishes three concepts of attributes, telemetry, and instructions, unifies the semantics of application layer development and device layer development; secondly, provides standardized interfaces based on the three concepts for the application layer and the device layer. This solves the problem of fragmentation of communication methods and duplication of development work for IoT gateways applied to different vertical industry fields.

[0006] In order to achieve the above objectives, the following technical solutions are proposed:

[0007] A method for communicating with an IoT gateway device based on MQTT, comprising the following steps:

[0008] Based on the MQTT protocol, a communication channel is constructed between the device layer, the unified device management platform and the application layer. The unified device management platform uses a preset API with consistent semantics based on attributes, telemetry and instructions to communicate with devices at the device layer and applications at the application layer.

[0009] The device layer or application layer sends a message to the application layer or device layer through a preset API. The device layer or application layer first sends an MQTT PUBLISH to the unified device management platform. After the unified device management platform receives the MQTT PUBLISH, the unified device management platform forwards the message to the application layer or device layer according to the subject of the message.

[0010] Preferably, the preset API includes MQTTAPI, KafkaAPI and RESTfulAPI;

[0011] The telemetry includes key-value pairs with timestamps;

[0012] The instructions include server instructions and client instructions. The server instructions allow an application to send a request to a device, and the client instructions allow a device to send a request to an application.

[0013] Preferably, the attributes include server attributes, shared attributes and client attributes.

[0014] The server attributes can only be read and written by the server program or user, and are not visible to the device;

[0015] The shared attributes can be read and written by the server program or user, and are read-only by the device;

[0016] The client attributes can be reported or queried by the device, but can only be read by the server program or user.

[0017] Preferably, the communication process of the device reporting the client attributes specifically includes the following steps:

[0018] After receiving the MQTT CONNACK from the unified device management platform, the device-side program publishes attribute data in JSON format to the MQTT topic;

[0019] The unified device management platform forwards the client attributes to the application through the Kafka API, and the application receives the client attributes reported by the device.

[0020] Preferably, the communication process of the device querying the shared attribute or the client attribute specifically includes the following steps:

[0021] S41: After receiving the MQTT CONNACK, the device program sends an MQTT SUBSCRIBE and receives the query response by subscribing to the MQTT topic;

[0022] S42: The device program sends a query request to the MQTT topic;

[0023] S43: The device-side program receives the MQTT PUBLISH of the MQTT topic and the query response pushed by the unified device management platform.

[0024] Preferably, the communication process of the device reporting the telemetry data specifically includes the following steps:

[0025] S51: The device program receives MQTT CONNACK;

[0026] S52: The device-side program sends an MQTT PUBLISH to send telemetry data to the MQTT topic; the unified device management platform forwards the telemetry data to the application through the Kafka API, and the application receives the telemetry data reported by the device.

[0027] Preferably, the communication process of the application sending the server instruction specifically includes the following steps:

[0028] S61: The device program receives MQTT CONNACK;

[0029] S62: The device program sends an MQTT SUBSCRIBE and receives server instructions by subscribing to the MQTT topic;

[0030] S63: The application initiates a command call through the unified device management platform RESTful interface;

[0031] S64: The device-side program receives a command request pushed by the unified device management platform;

[0032] S65: The device program sends an MQTT PUBLISH and sends a command response to the MQTT topic;

[0033] S66: The unified device management platform forwards the instruction response to the application through the Kafka API, and the application receives the instruction response.

[0034] Preferably, the communication process of the device sending the client instruction specifically includes the following steps:

[0035] S71: After receiving MQTT CONNACK, the device program sends MQTT SUBSCRIBE to subscribe to the MQTT topic;

[0036] S72: The device-side program sends a client instruction to the subject;

[0037] S73: The unified device management platform forwards the client command request to the application through the Kafka API;

[0038] S74: The application processes the client command and replies to the client command response through the Kafka API;

[0039] S75: The unified device management platform forwards the client command response, and the device-side program receives the client command response pushed by the unified device management platform.

[0040] Preferably, the process starts with the application starting and subscribing to KafkaAPI, the device-side program starts and sends MQTT CONNECT to connect to the unified device management platform; the unified device management platform calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections.

[0041] Based on the same concept, an MQTT-based IoT device communication system is also proposed, including an application layer, a unified device management platform and a device layer. The application layer includes power applications, environmental applications and high-speed applications for processing various application tasks.

[0042] The unified device management platform includes API Gateway, device services, data services, MongoDB, Kafka and MQTT broker, which are used to provide the application layer with semantically consistent RESTful API and Kafka API based on attributes, telemetry and instructions, and provide the device layer with semantically consistent MQTT API based on attributes, telemetry and instructions;

[0043] The equipment layer includes a power monitoring gateway, an environmental monitoring gateway and a high-speed monitoring gateway, which are used to monitor the environmental status in real time;

[0044] The device layer or application layer sends a message to the application layer or device layer through a preset API. The device layer or application layer first sends an MQTT PUBLISH to the unified device management platform. After the unified device management platform receives the MQTT PUBLISH, the unified device management platform forwards the message to the application layer or device layer according to the subject of the message.

[0045] Compared with the prior art, the present invention has the following beneficial effects:

[0046] The present invention provides semantically consistent APIs based on attributes, telemetry, and instructions to applications and devices in the north and south respectively through the Unified Device Management Platform (UMPD). It provides RESTful and Kafka APIs to applications and MQTT APIs to devices. It realizes the access, data reporting, and reverse control of IoT gateway devices, and provides standardized concepts and interfaces for upper-layer application development and gateway device access. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is an architecture diagram of an MQTT-based IoT gateway device communication method in Example 1;

[0048] Figure 2 is a diagram illustrating the visibility of attributes on the server side in Example 1;

[0049] Figure 3 is a diagram illustrating the visibility of shared attributes in Example 1;

[0050] Figure 4 is a diagram illustrating the visibility of client attributes in Example 1;

[0051] Figure 5 This is a diagram illustrating the one-way server instruction in Example 1;

[0052] Figure 6 is a diagram illustrating the bidirectional server instructions in Example 1;

[0053] Figure 7 This is a diagram illustrating the client instructions in Example 1. DETAILED DESCRIPTION

[0054] The present invention is further described in detail below in conjunction with test examples and specific implementation methods. However, this should not be understood as the scope of the above subject matter of the present invention being limited to the following embodiments, and all technologies realized based on the content of the present invention belong to the scope of the present invention.

[0055] Example 1

[0056] A communication method for IoT gateway devices based on MQTT, such as Figure 1 As shown, the following steps are included:

[0057] Based on the MQTT protocol, a communication channel is constructed between the device layer, the unified device management platform and the application layer. The unified device management platform uses a preset API with consistent semantics based on attributes, telemetry and instructions to communicate with devices at the device layer and applications at the application layer.

[0058] The device layer or application layer sends a message to the application layer or device layer through a preset API. The device layer or application layer first sends an MQTT PUBLISH to the unified device management platform. After the unified device management platform receives the MQTT PUBLISH, the unified device management platform forwards the message to the application layer or device layer according to the subject of the message.

[0059] The communication method of the present invention refers to a method in which a device communicates with the system of the present invention based on the three concepts of attributes, telemetry, and instructions based on the MQTT protocol. The following is an explanation of these three concepts.

[0060] In different IoT verticals, although the specific businesses are different, there are always common communication models between devices and platforms. For these common communication models, we have extracted three concepts: attributes, telemetry, and instructions. The following is an explanation of these common communication models.

[0061] Communication model 1: Devices always have some property data belonging to them, which need to be interacted between the platform and the device. These property data may come from the device itself and need to be reported to the platform, such as the device's firmware version number; they may come from the user's assignment to the device, such as the user setting a device to belong to group 1, or the platform's assignment to the device, such as whether the device is currently online; it is also possible that the property is jointly maintained by the platform and the device, such as the current on / off status of a smart light.

[0062] In terms of the frequency of changes, these attribute data usually remain basically unchanged, such as the model of the device, or change at a lower frequency, such as whether the device is online.

[0063] From the perspective of time, we basically only care about the current values ​​of these property data, not their historical values. From the perspective of read and write permissions, some property data can only be read and written by users or platforms, and are not visible to devices, such as which group the device belongs to and whether the device is online; some can be read and written by users, platforms, and devices, such as the switch status of smart lights, which may be changed by users operating the APP or by the device due to physical switch operations; some can only be read and written by devices and cannot be changed by users and platforms, such as the firmware version number of the device. We abstract this property data belonging to the device into attributes, and divide it into three types according to the above sources and read and write permissions: server attributes, shared attributes, and client attributes.

[0064] Communication model 2: Devices always have some data points that need to be continuously sent to the platform. These data points are usually large in quantity, such as the speed of industrial equipment collected once a second. In terms of collection frequency, they are usually high. In terms of time dimension, people are usually more concerned with historical data over a period of time and draw certain conclusions by analyzing historical data. We call data points with strong time attributes of devices telemetry.

[0065] Communication model three: The platform always needs to send some commands to the device for the device to execute, and vice versa. For example, when the platform needs to upgrade the device, it needs to send a command containing the upgrade information to the device; when the device needs to calibrate its local time, it needs to send a command to the platform to request time calibration information. We call this kind of command an instruction. The command sent by the platform (user) to the device is called a server instruction, and the command sent by the device to the platform is called a client instruction.

[0066] For server-side commands, they are divided into one-way server-side commands (no device response required) and two-way server-side commands (device response required) according to whether the device needs to reply. According to the timeliness of the commands, they are divided into persistent commands (the validity period of the commands can be very long) and non-persistent commands (the validity period of the commands is very short).

[0067] The following are the definitions of properties, telemetry, and commands:

[0068] Attribute: An attribute is a property of a device and its value. It is a key-value pair. The key is the name of the attribute, the type is a string, and the value is the value of the attribute. The type can be a string, integer, floating point number, Boolean value, or JSON. The source may be reported by the device or set by the server. The system only records the current value of the attribute, not its historical value.

[0069] There are three types of attributes: server attributes, shared attributes, and client attributes.

[0070] Server attributes: Attributes generated by the server or set by the user. Server attributes can only be read and written by the server program or user, and are not visible to the device. Figure 2 shown.

[0071] As a specific embodiment:

[0072] 1. Some data generated when the device goes online or offline: whether the device is online, the last active time of the device, the last connected time of the device, and the last disconnected time of the device can be stored in the server properties of the device.

[0073] 2. A certain type of device on a certain business platform does not report longitude and latitude location information, but I want to allow users to manually specify the longitude and latitude of the device on the business platform so that I can view the location of all devices on a map. Then the longitude and latitude specified by the user can be stored in the server attributes of the device.

[0074] Shared attributes: attributes shared by the server and the device. The server program or user can read and write, while the device can only read. Figure 3 shown.

[0075] As a specific embodiment:

[0076] 1. Device configuration: for example, device log record level; maximum time for device video storage; device alarm threshold.

[0077] 2. Control devices: For example, the application can turn on the light remotely by setting the open property to true (the device subscribes to the relevant topic and can receive property notifications in real time).

[0078] Client attributes: Attributes reported by the device. Server programs or users can only read, but devices can report or query. Figure 4 shown.

[0079] Use Cases:

[0080] 1. Report the inherent properties of the device: firmware version number, software version number, whether there is a 5G module, whether there is a WIFI module, etc.

[0081] 2. Report the status or configuration of the device: the switch status of the light, whether a certain functional module of the device is enabled, the current log recording level of the device, the maximum time the device currently saves the video, the current alarm threshold of the device, etc.

[0082] Telemetry: Telemetry refers to data points of a device that change very frequently. Telemetry is a key-value pair with a timestamp. The key is the name of the data point, the type is a string, and the value is the value of the data point, which can be a string, integer, floating point number, Boolean, or JSON. The system stores all data points reported by the device.

[0083] As a specific embodiment:

[0084] 1. Data values ​​collected by sensors: for example, air quality data, wind speed and direction collected by environmental monitoring sensors.

[0085] 2. The device’s own monitoring data: for example, CPU usage, memory usage, etc.

[0086] Commands: The system allows you to send commands, either from the application to the device or from the device to the application. There are two types of commands, server commands and client commands.

[0087] Server commands: Server commands allow applications to send requests to the device.

[0088] Server instructions are divided into two types: one-way server instructions and two-way server instructions.

[0089] One-way server command: One-way means that the application does not care about the result of executing this command. UDMP will reply to the application after sending the command to the device. Figure 5 shown.

[0090] As a specific embodiment:

[0091] 1. To turn the light on or off, you only need to send the command and the device will execute it. There is no need for the device to reply with a result that the light has been turned on or off.

[0092] 2. To restart, you only need to send the command and the device will execute it. There is no need for the device to reply with a result that it has restarted.

[0093] Bidirectional server command: Bidirectional means that the application cares about the result of this command. UDMP will wait for the device to reply after sending the command to the device, and then reply to the application after receiving the result. This process is synchronous unless it times out. Figure 6 shown.

[0094] As a specific embodiment:

[0095] 1. For example, an industrial device has a built-in self-check logic. The application sends instructions to the device to self-check. In this case, you are naturally concerned about the self-check results.

[0096] There is another concept of server-side instructions, which is persistence. This means that when an application initiates a server-side instruction, it can use a parameter to specify whether the instruction is persistent.

[0097] Non-persistent commands: Non-persistent commands are not stored in the database. After the application initiates a command request, it either gets an empty result immediately (one-way), or gets a result returned from the device after a certain period of time (two-way), or times out and fails. After that, there is no record of the command.

[0098] Persistent server instructions: Persistent instructions will be stored in the database and have their own life cycle (created, sent, successful, failed, etc.). The relevant data of the instruction can be checked by id at any time later.

[0099] As a specific embodiment:

[0100] 1. For example, the user-defined interaction mode is that the operation on the device does not need to display the result immediately, but the result can be viewed on another page called "Operation Record". In this case, persistent instructions can be used.

[0101] 2. For example, the user has made a synchronization button on the page (the device re-reports its attribute data). This button can only be clicked when the device is online. Clicking the button will start to spin until a response is received from the device. In this case, non-persistent instructions can be used.

[0102] Client commands: Client commands allow applications to send requests to devices. Figure 7 shown.

[0103] As a specific embodiment:

[0104] 1. The device reports the status of the OTA upgrade task.

[0105] 2. The device sends a computing task to the server to calculate the result.

[0106] The system described in the present invention refers to a platform system that supports the above communication method. The system is called Unified Device Management Platform, or UDMP for short.

[0107] UDMP mainly consists of the following components:

[0108] 1. API Gateway: exposes RESTful API and KafkaPub / SubAPI for applications to use. Applications call these APIs to communicate with devices based on attributes, telemetry, and instructions.

[0109] 2. Device services: manage basic device information, such as serial number and authentication information.

[0110] 3. Data service: manages the device's attributes, telemetry, and command information, and is responsible for uplink and downlink data routing. For example, it provides an interface for querying device telemetry data. For example, it routes the application's light-on command to a certain smart light. It routes the client attributes reported by the device to the application.

[0111] 4.MongoDB: Database, stores all data, including device data, authentication data, attribute data, telemetry data, and command data.

[0112] 5. Kafka: core messaging middleware. First, it is responsible for providing interaction channels for various components within the system, such as device services, data services, and MQTT Broker; second, it provides an API based on the subscription push model so that applications can receive real-time data.

[0113] 6.MQTT broker: The core service component responsible for establishing a connection with the device based on the MQTT protocol, providing the device with the MQTT API based on attributes, telemetry, and instructions, parsing MQTT protocol data, maintaining MQTT connections, and pushing various MQTT events of the device to Kafka, such as connection events, sending client attribute events, reporting telemetry data events, etc., for device service and data service processing.

[0114] UDMP provides semantically consistent APIs based on attributes, telemetry, and instructions to applications and devices in the north and south directions, respectively. It provides RESTful and Kafka APIs for applications and MQTT APIs for devices.

[0115] UDMP provides northbound applications with RESTful and Kafka APIs that are unified with device-side concepts. Application developers no longer need to focus on the heterogeneity of underlying communications between different types of devices. Instead, they only need to use unified concepts based on attributes, telemetry, and instructions to interact with devices. This greatly simplifies application layer development and reduces the difficulty of application layer development.

[0116] The following is the communication process of the device reporting client attributes based on the present invention:

[0117] S101. The application starts and subscribes to the Kafka API.

[0118] S102. The device-side program starts and sends MQTT CONNECT to connect to UDMP.

[0119] S103.UDMP calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections. UDMP supports two mainstream authentication methods, such as authentication based on client certificates and authentication based on MQTT username & password. The former is more secure, but more expensive. The latter is slightly less secure, but less expensive.

[0120] S104. The device-side program receives MQTT CONNACK.

[0121] S105. The device program sends an MQTT PUBLISH to publish attribute data in JSON format to the MQTT topic udmp / v1 / devices / $sn / attributes / write. For example, {"attribute1":"value1","attribute2":42}.

[0122] The MQTT topic is a multi-level structure, udmp / v1 / devices / $sn / attributes / write. The front udmp / v1 / devices is a fixed prefix, indicating that the API is the MQTT interface for device version v1 provided by udmp. $sn represents the device serial number, which is the unique device identifier. attributes represents properties. write represents the device reporting properties.

[0123] S106.UDMP forwards client properties to the application through KafkaAPI.

[0124] S107. The application receives the client attributes reported by the device.

[0125] The following is a communication process for a device to query shared attributes or client attributes based on the present invention:

[0126] S101. The application starts and subscribes to the Kafka API.

[0127] S102. The device-side program starts and sends MQTT CONNECT to connect to UDMP.

[0128] S103. UDMP calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections.

[0129] S104. The device-side program receives MQTT CONNACK.

[0130] S105. The device program sends an MQTT SUBSCRIBE and subscribes to the MQTT topic udmp / v1 / devices / $sn / attributes / response / +.

[0131] S106. The device program sends an MQTT PUBLISH and sends a query request to the MQTT topic udmp / v1 / devices / $sn / attributes / request / $request_id: {"clientKeys":["attribute1","attribute2"],"sharedKeys":["shared1","shared2"]}. The $sn in the topic is the device serial number, which is the unique identifier of the device. $request_id is the number of this request. When the device replies with the result, it needs to associate this number so that the request and response are associated. In the request body JSON data, the value of the clientKeys field indicates which client attributes the device wants to query. The value of the sharedKeys field indicates which shared attributes the device wants to query.

[0132] S107. The device-side program receives the MQTT PUBLISH and receives the query response pushed by UDMP: {"client":{"attribute1":"value1","attribute2":true},"shared":{"shared1":{"x":false,"y":32},"shared2":1.2}}.

[0133] In the response data, the client field represents the values ​​of the queried client attributes, where the value of attribute1 is the string value1 and the value of attribute2 is the Boolean value true. The shared field represents the values ​​of the queried shared attributes, where the value of shared1 is JSON{"x":false,"y":32},"shared2":1.2} and the value of shared2 is the floating point number 1.2.

[0134] The following is the communication process for the device to report telemetry data based on the present invention:

[0135] S101. The application starts and subscribes to the Kafka API.

[0136] S102. The device-side program starts and sends MQTT CONNECT to connect to UDMP.

[0137] S103. UDMP calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections.

[0138] S104. The device-side program receives MQTT CONNACK.

[0139] S105. The device program sends an MQTT PUBLISH to send telemetry data to the MQTT topic udmp / v1 / devices / $sn / telemetry / write: Data format 1 (without timestamp, the occurrence time of the telemetry data uses the time when the server receives the data): {"stringKey":"value1","booleanKey":true,"doubleKey":42.3,"longKey":73,"jsonKey":{"someNumber":42,"someArray":[1,2,3],"someNestedObject":{"key":"value"}}}, this data format indicates that the device reports 5 telemetry data. The key of the first telemetry data is stringKey, and the value is the string value1; the key of the second telemetry data is booleanKey, and the value is the Boolean value true; the key of the third telemetry data is doubleKey, and the value is the floating point number 42.3; the key of the fourth telemetry data is longKey, and the value is the integer 73; the key of the fourth telemetry data is jsonKey, and the value is JSON{"someNumber":42,"someArray":[1,2,3],"someNestedObject":{"key":"value"}}. The time when the data arrives at the platform is used as the occurrence time of the telemetry data. Data format 2 (carrying timestamp, the occurrence time of telemetry data uses the carried timestamp): {"ts":1451649600512,"values":{"stringKey":"value1","booleanKey":true,"doubleKey":42.3,"longKey":73,"jsonKey":{"someNumber":42,"someArray":[1,2,3],"someNeste dObject":{"key":"value"}}}}. This data format is different from format 1 in that it has an additional ts field, which represents the occurrence time of telemetry data; and all telemetry data is placed in the values ​​field. The rest is the same as format 1, and 5 telemetry data are reported.

[0140] S106.UDMP forwards telemetry data to the application through KafkaAPI.

[0141] S107. The application receives the telemetry data reported by the device.

[0142] The following is the communication process of sending server instructions by an application based on the present invention:

[0143] S101. The application starts and subscribes to the Kafka API.

[0144] S102. The device-side program starts and sends MQTT CONNECT to connect to UDMP.

[0145] S103. UDMP calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections.

[0146] S104. The device-side program receives MQTT CONNACK.

[0147] S105. The device program sends an MQTT SUBSCRIBE and subscribes to the MQTT topic udmp / v1 / devices / $sn / rpc / server / request / +. The MQTT topic is a multi-level structure, udmp / v1 / devices / $sn / rpc / server / request / +. The front udmp / v1 / devices is a fixed prefix, which means that the API is the MQTT interface for version v1 of the device provided by udmp. $sn represents the device serial number, which is the unique identity of the device. rpc represents the command. server represents the server command. request represents the server requesting the device. + represents a wildcard subscription, matching different request IDs, which means subscribing to all requests sent to me by the server.

[0148] S106. The application calls the UDMP RESTful interface to initiate a command call.

[0149] S107. The device program receives the MQTT PUBLISH and the instruction request pushed by UDMP: {"method":"checkSelf","params":{"level":1}}. The method and params fields are fixed, and the value of the method and the content of the params are defined by negotiation between the application and the device.

[0150] S108. The device program sends an MQTT PUBLISH and sends a command response to the MQTT topic udmp / v1 / devices / $sn / rpc / server / response / $request_id: {"code":200,"message":"","data":{}}. The code, message, and data fields are fixed, and their specific values ​​are defined by negotiation between the application and the device.

[0151] S109.UDMP forwards the command response to the application through the Kafka API.

[0152] S110. The application receives a command response.

[0153] The following is a communication process for a device to send a client instruction based on the present invention:

[0154] S101. The application starts and subscribes to the Kafka API.

[0155] S102. The device-side program starts and sends MQTT CONNECT to connect to UDMP.

[0156] S103. UDMP calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections.

[0157] S104. The device-side program receives MQTT CONNACK.

[0158] S105. The device program sends an MQTT SUBSCRIBE and subscribes to the MQTT topic udmp / v1 / devices / $sn / rpc / client / response / +.

[0159] S106. The device program sends an MQTT PUBLISH and sends the client command to the topic udmp / v1 / devices / $sn / rpc / client / request / $request_id: {"method":"getServerTime","params":{"timeZone":"UTC"}}. The method and params fields in the payload are fixed, and the value of the method and the content of the params are defined by negotiation between the device and the application.

[0160] S107.UDMP forwards the client command request to the application through KafkaAPI.

[0161] S108. The application processes the client instruction and replies to the client instruction response through the Kafka API.

[0162] S109. UDMP forwards the client instruction response.

[0163] S110. The device program receives the MQTT PUBLISH and receives the client command response pushed by UDMP: {"code":200,"message":"","data":{}}. The code, message, and data fields are fixed, and their specific values ​​are defined by negotiation between the application and the device.

[0164] The method and system described in the present invention solve the fragmentation problem of IoT gateway devices facing multiple industry fields and multiple device types, and reduce the workload of developing IoT overall applications or solutions by 30%.

[0165] By utilizing the characteristics of the MQTT protocol, information transmission between devices and device self-organizing networks are realized, thereby improving the reliability and efficiency of the IoT system. This method and system are particularly suitable for application scenarios that require remote monitoring and control, such as industrial IoT data acquisition and monitoring systems. By implementing communication between devices through the MQTT protocol, the "information island" problem existing in traditional enterprises is solved, the equipment maintenance efficiency is improved, the cost is reduced, and the need for real-time perception of the equipment's operating status is realized.

[0166] The present invention applies the gateway to related vertical industry fields, such as environmental monitoring, power monitoring, high-speed monitoring, etc., when the industry field platform needs to be developed, and provides a general communication method and system that is independent of the device system and device model. Through this method and system, the functions of access, data reporting and reverse control of the Internet of Things gateway device are realized, providing standardized concepts and interfaces for upper-layer application development and gateway device access.

[0167] Finally, it should be noted that the embodiments described in detail above are only the best practices of the invention and cannot be used to limit the scope of rights of the invention. Equivalent replacement of the technical solutions recorded in the aforementioned embodiments does not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the invention, and they should all be included in the scope of the claims and description of the invention.

Claims

1. A method for communication of Internet of Things gateway devices based on MQTT, characterized in that: The following steps are involved: Based on the MQTT protocol, a communication channel is constructed between the device layer, the unified device management platform and the application layer. The unified device management platform uses a preset API with consistent semantics based on attributes, telemetry and instructions to communicate with devices at the device layer and applications at the application layer. The device layer or application layer sends a message to the application layer or device layer through a preset API. The device layer or application layer first sends an MQTT PUBLISH to the unified device management platform. After the unified device management platform receives the MQTT PUBLISH, the unified device management platform forwards the message to the application layer or device layer according to the subject of the message.

2. The MQTT-based IoT gateway device communication method according to claim 1, characterized in that: The preset APIs include MQTT API, Kafka API and RESTful API; The telemetry includes key-value pairs with timestamps; The instructions include server instructions and client instructions. The server instructions allow an application to send a request to a device, and the client instructions allow a device to send a request to an application.

3. The MQTT-based IoT gateway device communication method according to claim 1, characterized in that: The attributes include server attributes, shared attributes and client attributes. The server attributes are read and written by the server program or user, and are not visible to the device; The shared attributes are read and written by the server program or user, and are read-only by the device; The client attributes are reported or queried by the device and are read-only by the server program or user.

4. The MQTT-based IoT gateway device communication method according to claim 3, characterized in that: The communication process of the device reporting the client attributes specifically includes the following steps: After receiving the MQTT CONNACK from the unified device management platform, the device-side program publishes attribute data in JSON format to the MQTT topic; The unified device management platform forwards the client attributes to the application through the Kafka API, and the application receives the client attributes reported by the device.

5. The MQTT-based Internet of Things gateway device communication method according to claim 3, characterized in that: The communication process of the device querying the shared attribute or the client attribute specifically includes the following steps: S51: After receiving the MQTT CONNACK, the device program sends an MQTT SUBSCRIBE and receives the query response by subscribing to the MQTT topic; S52: The device program sends a query request to the MQTT topic; S53: The device-side program receives the MQTT PUBLISH of the MQTT topic and the query response pushed by the unified device management platform.

6. The MQTT-based Internet of Things gateway device communication method according to claim 3, characterized in that: The communication process of the device reporting the telemetry data specifically includes the following steps: S61: The device program receives MQTT CONNACK; S62: The device-side program sends an MQTT PUBLISH to send telemetry data to the MQTT topic; the unified device management platform forwards the telemetry data to the application through the Kafka API, and the application receives the telemetry data reported by the device.

7. The MQTT-based Internet of Things gateway device communication method according to claim 2, characterized in that: The communication process of the application sending the server instruction specifically includes the following steps: S71: The device program receives MQTT CONNACK; S72: The device program sends an MQTT SUBSCRIBE and receives server instructions by subscribing to the MQTT topic; S73: The application initiates a command call through the unified device management platform RESTful interface; S74: The device-side program receives the instruction request pushed by the unified device management platform; S75: The device program sends an MQTT PUBLISH and sends a command response to the MQTT topic; S76: The unified device management platform forwards the command response to the application through the Kafka API, and the application receives the command response.

8. The MQTT-based Internet of Things gateway device communication method according to claim 2, characterized in that: The communication process of the device sending the client instruction specifically includes the following steps: S81: After receiving MQTT CONNACK, the device program sends MQTT SUBSCRIBE to subscribe to the MQTT topic; S82: The device-side program sends a client instruction to the subject; S83: The unified device management platform forwards the client command request to the application through the Kafka API; S84: The application processes the client command and replies to the client command response through the Kafka API; S85: The unified device management platform forwards the client command response, and the device-side program receives the client command response pushed by the unified device management platform.

9. A method for communicating with an Internet of Things gateway device based on MQTT as claimed in any one of claims 4 to 8, characterized in that: The process starts with the application starting and subscribing to the Kafka API, and the device-side program starts and sends MQTT CONNECT to connect to the unified device management platform; the unified device management platform calls the application authentication information to authenticate the device identity, rejects illegal connections, and accepts legal connections.

10. An MQTT-based IoT device communication system, characterized in that: It includes an application layer, a unified device management platform and a device layer, wherein the application layer includes power applications, environmental applications and high-speed applications for processing various application tasks; The unified device management platform includes API Gateway, device services, data services, MongoDB, Kafka and MQTT broker, which are used to provide the application layer with semantically consistent RESTful API and Kafka API based on attributes, telemetry and instructions, and provide the device layer with semantically consistent MQTT API based on attributes, telemetry and instructions; The equipment layer includes a power monitoring gateway, an environmental monitoring gateway and a high-speed monitoring gateway, which are used to monitor the environmental status in real time; The device layer or application layer sends a message to the application layer or device layer through a preset API. The device layer or application layer first sends an MQTT PUBLISH to the unified device management platform. After the unified device management platform receives the MQTT PUBLISH, the unified device management platform forwards the message to the application layer or device layer according to the subject of the message.

Images