Getting Connected
CoAP is a lightweight, UDP-based protocol designed for constrained IoT devices. ThingsBoard acts as a CoAP server supporting both regular request-response and the CoAP Observe option for push-style subscriptions.
Connection Parameters
Section titled “Connection Parameters”| Parameter | Value |
|---|---|
| Host | Your ThingsBoard hostname or IP |
| Port | 5683 (plain CoAP) · 5684 (CoAP over DTLS) |
| Protocol | CoAP / CoAP over DTLS |
| URL scheme | coap:// · coaps:// |
Command-Line Tools
Section titled “Command-Line Tools”Examples in this section use coap-client (from the libcoap package), which supports query parameters and DTLS. Install it on Ubuntu:
sudo apt install libcoap2-binFor DTLS examples, coap-client-openssl is required — a build of coap-client with OpenSSL support. See the Californium cf-client or build from source.
Credential Types
Section titled “Credential Types”CoAP supports two credential types. Configure them per device under Manage credentials — see Devices.
| Type | URL | Authentication |
|---|---|---|
| Access Token | coap(s)://HOST/api/v1/$ACCESS_TOKEN/{resource} | Token in the URL path |
| X.509 Certificate | coaps://HOST/api/v1/{resource} | Mutual DTLS — no token in URL |
Access Token
Section titled “Access Token”Include the device access token as a path segment in the URL. Copy it from Entities → Devices → [device] → Copy Access Token.
Plain CoAP (port 5683):
coap-client -v 6 -m POST -t "application/json" -e '{"temperature":25}' "coap://$THINGSBOARD_HOST:5683/api/v1/$ACCESS_TOKEN/telemetry"CoAP over DTLS — One-way TLS (port 5684):
The client verifies the server certificate using a CA root certificate. Download ca-root.pem from the Entities → Devices → [device] → Check connectivity → CoAP .
coap-client-openssl -v 6 -m POST -R ca-root.pem -t "application/json" -e '{"temperature":25}' "coaps://$THINGSBOARD_HOST/api/v1/$ACCESS_TOKEN/telemetry"X.509 Certificate
Section titled “X.509 Certificate”Mutual DTLS authentication — both client and server verify each other’s certificates. No token is included in the URL.
-
Generate a self-signed EC private key and certificate:
Terminal window openssl ecparam -out key.pem -name secp256r1 -genkeyopenssl req -new -key key.pem -x509 -nodes -days 365 -out cert.pem -
Go to Entities → Devices → [device] → Manage credentials, select X.509 Certificate, and paste the contents of
cert.pem. -
Connect using the certificate and key:
Terminal window coap-client-openssl -v 6 -c cert.pem -j key.pem -m POST -t "application/json" -e '{"temperature":25}' "coaps://$THINGSBOARD_HOST/api/v1/telemetry"
CoAP over DTLS — Server configuration
Section titled “CoAP over DTLS — Server configuration”To enable DTLS on the ThingsBoard server, set these environment variables:
COAP_DTLS_ENABLED=trueCOAP_DTLS_CREDENTIALS_TYPE=PEMCOAP_DTLS_PEM_CERT=server.pemCOAP_DTLS_PEM_KEY=server_key.pemCOAP_DTLS_PEM_KEY_PASSWORD=secretAdditional DTLS settings:
| Variable | Default | Description |
|---|---|---|
COAP_DTLS_BIND_ADDRESS | 0.0.0.0 | Bind address for the secure CoAP server |
COAP_DTLS_BIND_PORT | 5684 | Bind port for the secure CoAP server |
TB_COAP_X509_DTLS_SESSION_INACTIVITY_TIMEOUT | 86400000 | DTLS session inactivity timeout in ms (default: 1 day) |
TB_COAP_X509_DTLS_SESSION_REPORT_TIMEOUT | 1800000 | Frequency of inactive session cleanup in ms (default: 30 min) |
CoAP Transport Configuration
Section titled “CoAP Transport Configuration”When you set the transport type to CoAP in a device profile, additional settings become available under Transport configuration. These settings apply to all devices using the profile.
CoAP device type
Section titled “CoAP device type”| Type | Description |
|---|---|
| Default | Standard CoAP device. Supports JSON and Protobuf payloads. |
| Efento NB-IoT | Built-in support for Efento NB-IoT sensors. ThingsBoard automatically parses Efento’s proprietary Protobuf format for measurements, device info, and configuration. See Efento NB-IoT sensors and ThingsBoard for setup details. |
Payload format (Default type)
Section titled “Payload format (Default type)”When using the Default device type, choose the serialization format for CoAP messages:
| Format | Description |
|---|---|
| JSON | Default. Devices send plain JSON payloads as shown in the telemetry, attributes, and RPC examples. |
| Protobuf | Devices send binary Protocol Buffers messages. You define .proto schemas per profile for telemetry, attributes, RPC request, and RPC response — identical to the MQTT transport Protobuf configuration. |
Power Saving Mode
Section titled “Power Saving Mode”NB-IoT devices typically operate in low-power modes where they are not always reachable. The power saving mode setting tells ThingsBoard how long the device is available after it wakes up, so the platform can queue and deliver commands (RPC, shared attribute updates) within the reachability window.
| Mode | Parameters | Description |
|---|---|---|
| PSM (Power Saving Mode) | PSM Activity Timer, Time unit | The device wakes up periodically to send data, then enters deep sleep. ThingsBoard delivers queued commands during the activity window defined by the PSM Activity Timer. |
| DRX (Discontinuous Reception) | (none) | The device uses standard sleep cycles and is reachable frequently. No additional configuration needed. |
| eDRX (Extended Discontinuous Reception) | eDRX cycle, Time unit, Paging Transmission Window, Time unit | The device has longer sleep cycles than DRX. ThingsBoard uses the eDRX cycle and Paging Transmission Window to determine when the device is reachable. |
PSM parameters:
| Parameter | Description |
|---|---|
| PSM Activity Timer | Duration the device stays awake after sending data. ThingsBoard must deliver commands within this window. |
| Time unit | Seconds, Minutes, or Hours |
eDRX parameters:
| Parameter | Description |
|---|---|
| eDRX cycle | Total duration of one eDRX cycle (sleep + wake). |
| Paging Transmission Window | Duration within each eDRX cycle when the device listens for downlink messages. |
| Time unit | Seconds, Minutes, or Hours (configurable per parameter) |
Response Codes
Section titled “Response Codes”| Code | Meaning |
|---|---|
2.01 OK | Client’s request has been successfully |
4.00 Bad Request | Invalid URL, parameters, or payload |
4.01 Unauthorized | Invalid or missing access token |
4.04 Not Found | Requested resource does not exist |
4.05 Method Not Allowed | URL doesn’t support this request method |