The CoAP protocol is an IoT protocol that supports communication between constrained devices operating in constrained networks. Therefore, the CoAP protocol is designed to be very lightweight and uses the UDP protocol for data transmission, making it well-suited for constrained network environments.
CoAP operates in a manner similar to HTTP, allowing operations on abstract resources on devices within an M2M network of constrained devices. This enables simple and efficient synchronization and asynchronous information exchange between constrained devices.
However, if a constrained network needs to communicate with an external network, CoAP does not adapt well. Additionally, since CoAP was primarily designed with the M2M network model in mind, it lacks support for resource handling centers (the CoAP-based LwM2M protocol introduces concepts such as resource registration and resource services for this purpose).
Fortunately, these issues can be effectively resolved using the EMQX message server. This article will introduce how to use EMQX to connect to the CoAP protocol and enable communication between CoAP protocol devices and external networks.
Connecting CoAP Protocol Devices with EMQX
For CoAP devices that need to communicate with external networks, using EMQX as a message middleware allows for the convenient implementation of the following functionalities:
-
Authenticate devices and reject data from untrusted devices
-
Manage resource permissions, allowing different devices to have different read/write permissions for a specific resource
-
Act as an information transmission center between different network CoAP devices
-
Serve as middleware for other applications, such as CoAP management applications, data analysis applications, and access middleware between CoAP devices and networks
EMQX provides two different methods for accessing CoAP, covering most CoAP business scenarios, and the integration is straightforward, with no need to modify the CoAP protocol itself.
The cost of integrating existing CoAP devices and applications with EMQX is also minimal.
URL Model
EMQX accesses CoAP through URL path and queryString, and the URL model needs to be organized according to the following rules:
coap connection_type://Host:Port/mode/TopicName?c=clientId&u=username&p=passwordWhere coap connection_type can be:
-
coap: uses standard UDP for transmission
-
coaps: enables secure transport layer; details on enabling coaps (including unidirectional and bidirectional authentication) can be found in the encryption communication configuration
The mode currently includes: MQTT and PubSub, with specific differences detailed in the following sections.
The TopicName: In EMQX, the Topic serves as the resource identifier in CoAP; each Topic represents a resource object, and Topics can be any UTF8 string allowing multiple levels, such as coap/, coap/test/queryString.
The fields c, u, and p in the URL are mandatory:
-
c represents the client ID, which can be any string; theoretically, each client ID should be unique
-
u and p represent the username and password, which need to be pre-configured in EMQ X’s authentication module
MQTT Mode
The MQTT mode escapes the CoAP Method according to MQTT standards and only supports simple Pub/Sub behavior; the escape mapping is as follows:
| Method | Token | MQTT |
| GET | 0 | Subscribe |
| GET | 1 | Unsubscribe |
| GET | – | Illegal operation |
| PUT | – | Publish |
| POST | – | Illegal operation |
| DELETE | – | Illegal operation |
This mode is suitable for the following scenarios:
-
Only need to use EMQX for message, instruction, or other real-time information transmission
-
If long-term use of the Observe function is required, it should be in a dedicated network or intranet; this is important because UDP is connectionless, so a UDP link generated on the public network cannot be maintained for long, which may cause Observe to fail to receive data normally
-
If on the public network, Observe can only be used as a result listening mechanism for PUT operations; for example, if a CoAP device needs to send instructions or data to other devices via EMQX and process subsequent operations based on returned data, it can:
-
Use the PUT method to send instructions to a Topic
-
Use Observe to listen to that Topic
-
Process according to the data returned by EMQX; due to the maintenance time of UDP links on the public network, it is safe to keep Observe time within 30 seconds, and within 15 seconds is sufficiently safe
PubSub Mode
The PubSub mode is relatively more complex than the MQTT mode but aligns better with the concept of