Version: 3.0 (next)

CoAP Nodes

GET, PUT, POST and DELETE resources on constrained devices and gateways from a pipeline, with the payload decoded by the Content-Format the device declared.

Needs: A CoAP connection
Operations: CoAP GET · PUT · POST · DELETE
Payloads: text · JSON · CBOR · base64
Limits: A POST is never retried automatically

Use sensors, actuators, gateways and building controllers that speak CoAP in pipelines. Each function authored on a CoAP connection is available as a matching node in the Pipeline Designer.

For connection setup, message types, block-wise transfer and the egress guard, see the CoAP connection guide.

For the event-driven trigger, see the CoAP Observe Trigger node. It starts a pipeline on every notification of an observed resource (the Observe function, trigger.coap); its result is one notification, read as $trigger.result.value, $trigger.result.code and so on.

Configuration Quick Reference

Field	What you choose	Details
Parameters	`Connection`, `Function`, `Function Parameters`, `Timeout Override`	Select the CoAP connection, pick a function, bind parameters with expression support, and optionally override the timeout.
Settings	`Description`, `Timeout (seconds)`, `Retry on Timeout`, `Retry on Fail`, `On Error`	Node description, maximum execution time, retry behaviour and error strategy. All execution settings default to pipeline-level values.

The Response

The four nodes share one result: the response code, and the payload decoded by the Content-Format the device declared. Keys that only some responses carry are absent when the response did not carry them, never filled with a placeholder.

Key	Meaning
`result.path`	The resource path the request was sent to
`result.code`	The response code as class.detail, e.g. `2.05` or `2.04`
`result.status`	The response code's name, e.g. `Content`, `Changed`, `Created`, `Deleted`
`result.contentFormat`	The Content-Format the device declared for the payload. Present when the response carried a Content-Format option
`result.value`	The payload: text as a string, JSON and CBOR as a value, anything else (or no declared format) as base64. Present when the response carried a payload
`result.valueEncoding`	`text`, `json` or `base64`: how `result.value` represents the payload. Present when the response carried a payload
`result.bytes`	The payload's size on the wire, in bytes
`result.etag`	The ETag option, as hex. Present when the response carried one
`result.maxAge`	The Max-Age option: how many seconds the value stays fresh. Present when the response carried one
`result.location`	CoAP POST only: the path of the resource the POST created, from the Location-Path options. Present when the response carried them (a `2.01 Created`)

A payload that does not parse as its declared Content-Format fails the node; it is never returned as a best-effort value. See Content-Format: how payloads are read.

Each CoAP node delivers its data under result, and the call's facts under _metadata: the engine's _metadata.success, _metadata.functionId, _metadata.durationMs and _metadata.timestamp, and the connector's own:

Expression	Description
`$node["Name"]._metadata.protocol`	Always `coap`
`$node["Name"]._metadata.operation`	The function type: `coap.get`, `coap.put`, `coap.post` or `coap.delete`
`$node["Name"]._metadata.messageType`	`confirmable` or `nonConfirmable`, as the function sent it

CoAP GET Node

Supported Function Types:

Node	Function	Purpose	Common Use Cases
CoAP GET (`connected.coap.get`)	`coap.get`	Read a resource and return its decoded payload	Sensor readings on a schedule, gateway status documents, `/.well-known/core` discovery

Node Configuration

Parameter	Type	Required	Description
Connection	Selection	Yes	CoAP connection profile to use
Function	Selection	Yes	A `coap.get` function from the selected connection
Function Parameters	Dynamic	Varies	Auto-populated from the function's `((parameter))` placeholders (Resource Path and Query). See GET for field-level details.
Timeout Override	Number (seconds)	No	Override the default function timeout

All function parameters support expression syntax ({{ expression }}) for dynamic values from the pipeline context.

Input

The node receives the output of the previous node as input. Input data can be referenced in function parameter expressions using $input.

Output Structure

{
  "result": {
    "path": "/sensors/temp",
    "code": "2.05",
    "status": "Content",
    "contentFormat": "application/json",
    "value": { "t": 21.5 },
    "valueEncoding": "json",
    "bytes": 10,
    "etag": "a1b2",
    "maxAge": 30
  },
  "_metadata": {
    "success": true,
    "functionId": "aef374c3-aa2b-454e-aabc-5657faac5950",
    "durationMs": 12,
    "timestamp": "2026-10-20T10:14:03Z",
    "protocol": "coap",
    "operation": "coap.get",
    "messageType": "confirmable"
  }
}

Key	Meaning
`result.path`	The resource path read
`result.code`	`2.05` (Content) for a successful read
`result.status`	`Content`
`result.contentFormat`	The declared Content-Format, when there was one
`result.value`	The decoded payload, when there was one
`result.valueEncoding`	`text`, `json` or `base64`
`result.bytes`	The payload's size, in bytes
`result.etag`	The ETag, as hex, when the response carried one
`result.maxAge`	Seconds the value stays fresh, when the response carried Max-Age

Read a JSON field with $node["Read Sensor"].result.value.t. When the device may answer in more than one Content-Format, branch on $node["Read Sensor"].result.valueEncoding first.

CoAP PUT Node

Supported Function Types:

Node	Function	Purpose	Common Use Cases
CoAP PUT (`connected.coap.put`)	`coap.put`	Replace a resource's state with the payload	Actuator set-points, dimmer levels, configuration documents

PUT is idempotent: sending the same PUT twice leaves the resource in the same state, so the node's retry settings may send it again after a transient failure.

Node Configuration

Parameter	Type	Required	Description
Connection	Selection	Yes	CoAP connection profile to use
Function	Selection	Yes	A `coap.put` function from the selected connection
Function Parameters	Dynamic	Varies	Auto-populated from the function's `((parameter))` placeholders (Resource Path, Query, Payload). See PUT for field-level details.
Timeout Override	Number (seconds)	No	Override the default function timeout

All function parameters support expression syntax ({{ expression }}) for dynamic values from the pipeline context.

Input

The node receives the output of the previous node as input.

A realtime device write

The PUT acts on the device now or not at all: it is never buffered for later delivery, and a run started by a late (replayed) value refuses it unless the node allows late input.

Output Structure

{
  "result": {
    "path": "/lights/1/level",
    "code": "2.04",
    "status": "Changed",
    "bytes": 0
  }
}

Key	Meaning
`result.path`	The resource path written
`result.code`	`2.04` (Changed), or `2.01` (Created) when the PUT created the resource
`result.status`	`Changed` or `Created`
`result.bytes`	The response payload's size; usually `0`
`result.contentFormat`, `result.value`, `result.valueEncoding`	Present only when the device answered with a payload; a response to a PUT seldom has one
`result.etag`, `result.maxAge`	Present only when the response carried those options

CoAP POST Node

Supported Function Types:

Node	Function	Purpose	Common Use Cases
CoAP POST (`connected.coap.post`)	`coap.post`	Send a payload for the resource to process	Start a pump cycle, acknowledge an alarm, create a schedule entry

Node Configuration

Parameter	Type	Required	Description
Connection	Selection	Yes	CoAP connection profile to use
Function	Selection	Yes	A `coap.post` function from the selected connection
Function Parameters	Dynamic	Varies	Auto-populated from the function's `((parameter))` placeholders (Resource Path, Query, Payload). See POST for field-level details.
Timeout Override	Number (seconds)	No	Override the default function timeout

All function parameters support expression syntax ({{ expression }}) for dynamic values from the pipeline context.

Input

The node receives the output of the previous node as input.

A POST is never sent twice automatically

POST is not idempotent. If it fails after it may have reached the device (no response before the timeout, a lost connection, an undecodable response), the node fails with coap.post command outcome unknown and is not retried, even with Retry on Fail, Retry on Timeout or a ForEach retry configured: sending it again could run the action again. Check the device before running it again. A POST the device refused (4.xx) fails with the device refused the coap.post command and is not retried either.

A POST is also never buffered for later delivery, and a run started by a late (replayed) value refuses it unless the node allows late input.

Output Structure

{
  "result": {
    "path": "/schedules",
    "code": "2.01",
    "status": "Created",
    "bytes": 0,
    "location": "/schedules/7"
  }
}

Key	Meaning
`result.path`	The resource path posted to
`result.code`	`2.01` (Created), `2.04` (Changed) or another `2.xx`
`result.status`	The code's name, e.g. `Created`
`result.bytes`	The response payload's size, in bytes
`result.location`	The path of the resource the POST created, from the Location-Path options; present on a `2.01 Created` that names it
`result.contentFormat`, `result.value`, `result.valueEncoding`	Present when the device answered with a payload, e.g. an action's result
`result.etag`, `result.maxAge`	Present only when the response carried those options

Delete what a POST created with a CoAP DELETE whose Resource Path is $node["Create Entry"].result.location.

Safety First

Always validate values in a Condition node before acting on equipment. A POST can start a pump or a motor immediately.

CoAP DELETE Node

Supported Function Types:

Node	Function	Purpose	Common Use Cases
CoAP DELETE (`connected.coap.delete`)	`coap.delete`	Delete a resource	Remove a schedule entry, clear a stored alarm

DELETE is idempotent: deleting a resource twice leaves it deleted. A device may answer the second DELETE with 2.02 Deleted or with 4.04 Not Found; a 4.04 fails the node as the device's refusal.

Node Configuration

Parameter	Type	Required	Description
Connection	Selection	Yes	CoAP connection profile to use
Function	Selection	Yes	A `coap.delete` function from the selected connection
Function Parameters	Dynamic	Varies	Auto-populated from the function's `((parameter))` placeholders (Resource Path and Query). See DELETE for field-level details.
Timeout Override	Number (seconds)	No	Override the default function timeout

All function parameters support expression syntax ({{ expression }}) for dynamic values from the pipeline context.

Input

The node receives the output of the previous node as input.

Output Structure

{
  "result": {
    "path": "/schedules/7",
    "code": "2.02",
    "status": "Deleted",
    "bytes": 0
  }
}

Key	Meaning
`result.path`	The resource path deleted
`result.code`	`2.02` (Deleted)
`result.status`	`Deleted`
`result.bytes`	The response payload's size; usually `0`
`result.contentFormat`, `result.value`, `result.valueEncoding`	Present only when the device answered with a payload
`result.etag`, `result.maxAge`	Present only when the response carried those options

Errors

A response that is not 2.xx fails the node; the error names the operation, the path and the code, e.g. coap.get /sensors/x: server answered 4.04 NotFound.

Error	Meaning	Retried by the node settings?
`server answered 4.xx …` (`4.00`, `4.04`, `4.05`, `4.15`, …)	The device refused the request; it did not act	No: the result is permanent
`server answered 4.08 …` / `4.29 …` / `5.xx …`	A block was lost, the device is busy, or it failed	Yes (never for a POST)
`response payload: payload declared … is not valid …`	The response does not parse as its declared Content-Format	Yes (never for a POST)
`… command outcome unknown …`	A POST failed after it may have reached the device	Never, whatever the retry settings: check the device
`the device refused the coap.post command …`	The device answered a POST with `4.xx`	No
A timeout	No response before the timeout; the device may have acted	Yes (never for a POST)
`not connected to CoAP server …`	The connection is down	Yes
`write refused: the value that started this run was late …`	A PUT, POST or DELETE in a run started by a late value	No: allow late input on the node if the pipeline must act on replayed data

Settings Tab

All CoAP node types share the same Settings tab:

Setting	Type	Default	Description
Description	Text	-	Optional description displayed on the node
Timeout (seconds)	Number	Pipeline default	Maximum time the node may run before timing out
Retry on Timeout	Toggle	Pipeline default	Automatically retry the node if it times out
Retry on Fail	Toggle	Pipeline default	Automatically retry the node if it fails
On Error	Selection	Pipeline default	Error strategy: Pipeline Default (the pipeline's Error Handling setting), Stop Pipeline or Continue Execution

When left at their defaults, these settings inherit from the pipeline-level execution configuration. The retry settings never re-send a CoAP POST, and do not retry a request the device refused (see Errors).

Test before wiring

Use the Test button in the function form (on the connection page) to run every CoAP function against the live device before wiring it into a pipeline. It is the fastest way to catch a wrong path, a resource that does not allow the method (4.05), or a Content-Format the device does not accept (4.15).

Configuration Quick Reference​

The Response​

CoAP GET Node​

Node Configuration​

Input​

Output Structure​

CoAP PUT Node​

Node Configuration​

Input​

Output Structure​

CoAP POST Node​

Node Configuration​

Input​

Output Structure​

CoAP DELETE Node​

Node Configuration​

Input​

Output Structure​

Errors​

Settings Tab​

Configuration Quick Reference

The Response

CoAP GET Node

Node Configuration

Input

Output Structure

CoAP PUT Node

Node Configuration

Input

Output Structure

CoAP POST Node

Node Configuration

Input

Output Structure

CoAP DELETE Node

Node Configuration

Input

Output Structure

Errors

Settings Tab