Reference · built on requestConnectorIndustrial & building protocols

CoAP

Resources on constrained devices through CoAP GET, observe, and block-wise transfer over UDP, DTLS, or TCP.

About

The Constrained Application Protocol is defined by the IETF in RFC 7252 as a specialized web transfer protocol for constrained nodes and constrained, low-power, lossy networks. It carries GET, POST, PUT, and DELETE requests with a four-byte header over UDP, using Confirmable and Non-confirmable message types, a token that matches responses to requests, and response codes such as 2.05 Content and 4.04 Not Found. RFC 7641 adds the Observe option so a server pushes notifications after a single GET. RFC 7959 splits large payloads into blocks. RFC 8323 carries CoAP over TCP, TLS, and WebSockets where UDP is blocked.

Through Fibric, a CoAP client reads and observes the resources you name and hands each notification to an operator. A PUT or POST is proposed for your approval and sent once.

This is a reference listing. It documents what Fibric would read from CoAP and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Resource representations returned by GET, with the Content-Format, ETag, and Max-Age options
  • Notifications from observed resources (RFC 7641): further 2.05 Content responses, each carrying a 24-bit sequence number in the Observe option
  • The list of hosted resources from GET /.well-known/core in CoRE Link Format (RFC 6690), with rt, if, and sz attributes
  • Large representations assembled from Block2 responses of 16 to 1024 bytes per block (RFC 7959), with Size2 as the server's size estimate
  • Responses to multicast requests sent to the All CoAP Nodes addresses 224.0.1.187 and FF0X::FD
  • Connection capabilities from the CSM signaling message on CoAP over TCP, and Ping and Pong liveness (RFC 8323)

Proposed actions

  • Target capability: propose a PUT to update a resource, or a POST to create one, with a large body sent in Block1 pieces
  • Target capability: propose a DELETE of a resource
  • Target capability: propose registering or deregistering an observation, sending a GET with the Observe option set to 0 or 1

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Watch cold-room sensors without polling

    The client observes each temperature resource. Notifications arrive as the value changes. The operator compares them against the limit and proposes the notice before the excursion is logged.

    With Cold Room Watch, Cold Chain Excursion

  • Find devices that went quiet

    A resource whose Max-Age has passed without a notification, or a Confirmable request that exhausts its retransmissions, is listed by device and last-seen time for a person.

    With Sensor Health, Data Freshness

  • Set a device parameter once

    The operator proposes a PUT with the new value. You approve. The client sends it as a Confirmable request and records the 2.04 Changed response as the receipt.

    With Setpoint Drift

  • Roll a key before it lapses

    Certificate-mode devices carry X.509 certificates that expire. The operator lists devices by certificate end date and proposes the provisioning order.

    With Secret Rotation, Certificate Expiry

Requirements

  • UDP reach to each device on port 5683, or 5684 for coaps; where a network blocks UDP, CoAP over TCP or WebSockets under RFC 8323
  • Keying material provisioned per device: pre-shared keys with node lists, raw public keys with out-of-band identities, or certificates with root trust anchors
  • Devices that implement Observe (RFC 7641) if you want notifications rather than polling
  • A resource list, from /.well-known/core or from the device's documentation
Authentication
DTLS in one of the four RFC 7252 modes, NoSec, PreSharedKey, RawPublicKey (mandatory to implement), or Certificate with X.509 and root trust anchors, and TLS under the coaps+tcp scheme over TCP.

Limits

  • RFC 7252 wants a message to fit one IP packet: upper bounds of 1152 bytes for the message and 1024 bytes for the payload
  • Non-confirmable notifications can be lost; only Confirmable messages are retransmitted, with ACK_TIMEOUT 2 seconds and MAX_RETRANSMIT 4 by default
  • NoSec mode sends packets in the clear, and IPsec or link-layer security is outside the protocol
  • An observer is dropped when a client answers a notification with Reset, and Max-Age bounds how stale an observed value may be

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request CoAP ↗

Questions and answers

Which transports does CoAP use?
UDP by default on port 5683, and DTLS on 5684 (coaps). RFC 8323 adds TCP (coap+tcp, 5683), TLS (coaps+tcp, 5684), and WebSockets (coap+ws on 80, coaps+ws on 443) for networks that do not forward UDP.
How does observe differ from polling?
A client sends one GET with the Observe option set to 0. The server adds it to the resource's observer list and sends a notification each time the state changes, as Confirmable or Non-confirmable messages, with Max-Age stating how stale a value may be.
How large can a CoAP payload be?
RFC 7252 suggests 1024 bytes of payload so a message fits one IP packet. RFC 7959 block-wise transfer moves larger representations in Block1 (request) or Block2 (response) pieces of 16 to 1024 bytes, avoiding IP fragmentation.
Ask about CoAP

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.