8 CoAP Methods and Multicast

8.1 Start With the Device Menu

Choose the Action Before the Method

Picture a caretaker using a small panel to read a tank level and change an alarm limit. A read must not alter the device. A repeated update must not create a second record by accident. The action comes first; the message choice must preserve its meaning.

A protocol is a shared set of rules for exchanging messages. Constrained Application Protocol (CoAP) is a compact web-style protocol for small devices and links. A gateway is a device that joins unlike networks. Before choosing a method, write the resource, the allowed action, who may request it, the expected reply, and whether repeating the request is safe.

Test one normal request, one missing resource, one denied change, and one lost reply. Check the device state as well as the screen. If many devices receive the same request, prove that the result stays bounded and that replies do not swamp the link.

This first menu does not settle every transport or security choice. It does expose unsafe meanings early. The deeper sections compare methods, group delivery, updates, and related message systems so the final design matches the action rather than a familiar label.

Imagine a gateway walking up to a sensor and seeing a tiny menu: read temperature, update configuration, create a calibration record, or delete a stale resource. CoAP methods are the verbs on that menu, and the same method has to mean the same thing whether one device calls it or a multicast group hears it.

The chapter starts with the method choice, then adds multicast, Observe, calculators, and comparisons so the learner can see why a compact resource operation is still a full protocol decision.

Phoebe’s Field Notes: What the Battery Calculator’s 2430 J Leaves Out

Phoebe’s Field Notes: When a Full CR2032 Cannot Supply the Pulse

The mathematical gist. The chapter’s CR2032 model holds 2,430 J at 3.00 V, but the radio sees $V_{load}=V_{oc}-IR$. A 20 mA pulse through 15 ohm loses 0.30 V and reaches 2.70 V; at 100 ohm it loses 2.00 V and reaches only 1.00 V. Its nominal 0.0864 mJ message cost predicts 28,125 days at 1,000 messages/day, about 77.1 years, so a roughly ten-year shelf-life ceiling matters long before that naive message budget runs out.

Math Bridge · guided foundationsHow can a 77-year message budget fail in one pulse?Let Eddie connect nominal joules, internal resistance, cutoff, and shelf life. Learn the maths

8.2 Learning Objectives

• Apply CoAP REST methods (GET, POST, PUT, DELETE) with proper idempotency semantics for IoT resource manipulation
• Implement CoAP servers and clients using Python (aiocoap) and Arduino (ESP32) for sensor data exchange
• Configure CoAP multicast addressing for group operations and network-wide resource discovery via /.well-known/core
• Demonstrate how the CoAP Observe extension enables server-push notifications, reducing energy consumption by up to 99% compared to polling
• Compare CoAP’s 4-byte header efficiency versus HTTP’s 100+ byte overhead for battery-powered IoT devices

8.4 Continue: CoAP Method Codes and Multicast Contracts

The main chapter below stays focused on the core methods and feature tour. For the deeper contract behind compact method and response codes, safe/idempotent retry behavior, multicast discovery, Location options, Token correlation, and Leisure response spreading, continue to CoAP Method Codes and Multicast Contracts.

8.5 CoAP Methods

Start with the verb contract. If the method is wrong, retries and troubleshooting become ambiguous even when the URI looks sensible.

Like HTTP, CoAP uses REST methods:

coap://sensor.local/temperature

coap://server.local/readings
Payload: {"temp": 23.5, "time": "2025-10-24T23:30:00Z"}

coap://device.local/config
Payload: {"interval": 60}

coap://server.local/readings/old

8.6 Code Examples

import asyncio
from aiocoap import *

class TemperatureResource(resource.Resource):
    """Example resource for temperature readings"""

    async def render_get(self, request):
        """Handle GET requests"""
        temperature = 22.5  # Simulated sensor reading

        payload = f"{temperature}".encode('utf-8')

        return Message(
            code=Code.CONTENT,
            payload=payload,
            content_format=0  # text/plain
        )

    async def render_put(self, request):
        """Handle PUT requests to update config"""
        print(f'Received: {request.payload}')

        return Message(code=Code.CHANGED)

async def main():
    # Create CoAP server
    root = resource.Site()

    # Add temperature resource
    root.add_resource(
        ['temperature'],
        TemperatureResource()
    )

    # Start server
    await Context.create_server_context(root)

    print("CoAP server started on port 5683")
    await asyncio.get_running_loop().create_future()

if __name__ == "__main__":
    asyncio.run(main())

import asyncio
from aiocoap import *

async def get_temperature():
    """Fetch temperature from CoAP server"""

    # Create CoAP client protocol
    protocol = await Context.create_client_context()

    # Build GET request
    request = Message(
        code=Code.GET,
        uri='coap://localhost/temperature'
    )

    try:
        # Send request
        response = await protocol.request(request).response

        print(f'Response Code: {response.code}')
        print(f'Temperature: {response.payload.decode("utf-8")}°C')

    except Exception as e:
        print(f'Failed to fetch: {e}')

async def update_config():
    """Send PUT request to update configuration"""

    protocol = await Context.create_client_context()

    request = Message(
        code=Code.PUT,
        uri='coap://localhost/config',
        payload=b'{"interval": 30}'
    )

    response = await protocol.request(request).response
    print(f'Update result: {response.code}')

# Run client
asyncio.run(get_temperature())

#include <WiFi.h>
#include <coap-simple.h>

// WiFi credentials
const char* ssid = "YourWiFi";
const char* password = "YourPassword";

// CoAP client
Coap coap;

// CoAP server details
IPAddress serverIP(192, 168, 1, 100);
int serverPort = 5683;

void callback_response(CoapPacket &packet, IPAddress ip, int port) {
  char payload[packet.payloadlen + 1];
  memcpy(payload, packet.payload, packet.payloadlen);
  payload[packet.payloadlen] = NULL;

  Serial.print("CoAP Response: ");
  Serial.println(payload);
}

void setup() {
  Serial.begin(115200);

  // Connect to WiFi
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("\nWiFi connected");

  // Start CoAP
  coap.response(callback_response);
  coap.start();
}

void loop() {
  // Send GET request every 10 seconds
  int msgid = coap.get(serverIP, serverPort, "temperature");

  Serial.print("Request sent, MID: ");
  Serial.println(msgid);

  delay(10000);

  coap.loop();
}

8.7 Interactive Comparison: CoAP vs MQTT vs HTTP

Plot.plot({
marks: [
Plot.barY(protocolData, {
x: "protocol",
y: "value",
fill: d => d.protocol === "CoAP" ? colors.teal :
d.protocol === "MQTT" ? colors.orange : colors.navy,
tip: true
}),
Plot.text(protocolData, {
x: "protocol",
y: "value",
text: d => `${d.value} ${d.unit}`,
dy: -10,
fill: colors.navy,
fontSize: 12
})
],
x: {label: "Protocol"},
y: {label: protocolMetric, grid: true},
marginTop: 20,
marginBottom: 40,
height: 300,
style: {
fontFamily: "Arial, sans-serif"
}
})

The simulator comparisons become a protocol choice only after interaction pattern and device constraints are considered together. Use Figure 8.1 to turn those observations into a repeatable selection route.

Read Figure 8.1 from the interaction question at the top. Small operations on named resources lead toward CoAP when sleep cycles, UDP, and tight headers matter; brokered fan-out leads toward MQTT; a full web API and proxy ecosystem leads toward HTTP. The branches describe fit, not a universal winner. Having chosen an interaction model, the next question is what that choice costs on the wire.

8.8 Interactive Tool: CoAP Message Size Calculator

Calculate the actual bytes sent over the network for different protocols:

Plot.plot({
marks: [
Plot.barX([
{protocol: "CoAP", size: messageSizes.coap, color: colors.teal},
{protocol: "MQTT", size: messageSizes.mqtt, color: colors.orange},
{protocol: "HTTP", size: messageSizes.http, color: colors.navy}
], {
y: "protocol",
x: "size",
fill: "color",
tip: true
}),
Plot.text([
{protocol: "CoAP", size: messageSizes.coap},
{protocol: "MQTT", size: messageSizes.mqtt},
{protocol: "HTTP", size: messageSizes.http}
], {
y: "protocol",
x: "size",
text: d => `${d.size} bytes`,
dx: 20,
fill: colors.navy,
fontSize: 12
})
],
x: {label: "Total Message Size (bytes)", grid: true},
y: {label: null},
marginLeft: 80,
marginRight: 100,
height: 200,
style: {
fontFamily: "Arial, sans-serif"
}
})

8.9 Battery Life Calculator: CON vs NON Messages

Delivery policy changes radio work, so use the interactive battery-life calculator below before treating CON or NON as a default. Set the daily message rate first, then switch message type and compare size, daily energy, and the modeled battery-life bars.

Plot.plot({
marks: [
Plot.barY(comparisonData, {
x: "type",
y: "years",
fill: d => d.type === "NON" ? colors.teal : colors.orange,
tip: true
}),
Plot.text(comparisonData, {
x: "type",
y: "years",
text: d => `${d.years} years`,
dy: -10,
fill: colors.navy,
fontSize: 12
})
],
x: {label: "Message Type"},
y: {label: "Battery Life (years)", grid: true},
marginTop: 20,
marginBottom: 40,
height: 300,
style: {
fontFamily: "Arial, sans-serif"
}
})

In the interactive calculator, the daily rate controls how often the radio pays the transaction cost, while the message-type selector adds the ACK bytes used by this simplified CON model. Read the numeric cards before the bars: message size drives energy per day, which drives the projected years. The result isolates message traffic and therefore supports a relative CON-versus-NON decision; it is not a complete product battery forecast.

8.10 Multicast Support

Once a single exchange is clear, scale the same resource model to a group. Multicast helps discovery without changing what GET means.

CoAP supports multicast for group communication:

224.0.1.187

FF0X::FD

coap://[FF05::FD]/temperature

Plot.plot({
marks: [
Plot.barY(compData, {
x: "method",
y: "bytes",
fill: d => d.method === "Multicast" ? colors.teal : colors.navy,
tip: true
}),
Plot.text(compData, {
x: "method",
y: "bytes",
text: d => `${d.bytes} bytes`,
dy: -10,
fill: colors.navy,
fontSize: 12
})
],
x: {label: "Communication Method"},
y: {label: "Total Bandwidth (bytes)", grid: true},
marginTop: 20,
marginBottom: 40,
height: 300,
style: {
fontFamily: "Arial, sans-serif"
}
})

8.11 CoAP Features

8.11.1 Resource Discovery

Query available resources:

GET coap://device.local/.well-known/core

Response:

</temperature>;ct=0,
</humidity>;ct=0,
</pressure>;ct=0,
</config>;ct=50

Interactive Simulator: CoAP Resource Discovery

What This Simulates: ESP32 CoAP server with automatic resource discovery via /.well-known/core

Resource Discovery Flow:

Step 1: Client queries server
   GET coap://device/.well-known/core

Step 2: Server responds with resource list
   </temperature>;rt="sensor";if="core.s",
   </humidity>;rt="sensor";if="core.s",
   </led>;rt="actuator";if="core.a"

Step 3: Client accesses specific resource
   GET coap://device/temperature
   Response: "23.5"

How to Use:

1. Select Start Simulation
2. Watch ESP32 advertise available resources
3. See resource metadata (resource type, interface)
4. Observe clients discovering services automatically
5. Monitor GET requests to discovered resources

Learning Points

Treat discovery as a negotiation, not merely a directory listing. First request /.well-known/core, then parse each link into its resource path and attributes. The resource type says what the endpoint represents, the interface says how a client should interact with it, content format says what representation to expect, and obs advertises notification support. Only after those claims are understood should the client issue a request. The experiments below summarize ways to change that contract; each change should be checked in both the advertisement and the behavior of the discovered resource.

What You’ll Observe:

1. Automatic Discovery - Devices announce capabilities without manual configuration
2. Standard Endpoint - /.well-known/core is CoAP convention (RFC 6690)
3. Resource Attributes - Metadata describes resource type and interface
4. Self-Describing - Servers advertise what they offer
5. Plug-and-Play - New devices integrate without central registry

Resource Link Format:

</path>;attribute1=value1;attribute2=value2

Common Attributes:
rt = Resource Type (e.g., "temperature-sensor")
if = Interface Description (e.g., "sensor", "actuator")
ct = Content Type (0=text/plain, 50=application/json)
sz = Maximum Size
obs = Observable (supports observe pattern)

Example Resource Advertisement:

Resource discovery is useful only if a client can interpret an advertisement rather than merely find a URI. Inspect Figure 8.3 to decode the example from the path outward through its link-format attributes.

In Figure 8.3, start with /temp, the resource a client can request. Then read rt as its semantic resource type, if as the interaction interface, ct=0 as the representation’s content-format, and obs as the promise that Observe registration is supported. Those attributes let discovery feed a compatible client action, which is why the application examples below can find capabilities without hard-coded endpoint catalogs.

Real-World Applications:

1. Smart Building - HVAC units discover sensors automatically
2. Industrial IoT - Factory machines advertise capabilities
3. Home Automation - New devices self-register with hub
4. Healthcare - Medical sensors announce monitoring types
5. Agriculture - Soil sensors advertise measurement types

Experiments to Try:

1. Add New Resources - Implement /pressure, /battery endpoints
2. Resource Attributes - Add obs for observable resources
3. Content Types - Support JSON (ct=50) and XML (ct=41)
4. Filtering - Query specific resource types: ?rt=sensor
5. Observe Pattern - Implement push notifications when resource changes

Discovery vs Hardcoding:

Without Discovery (Hardcoded):
- Client: GET coap://192.168.1.100/temp  ✗ Must know IP & path
- Brittle: Breaks if device IP changes

With Discovery:
- Client: Multicast GET /.well-known/core  ✓ Finds all devices
- Response: Server at 192.168.1.100 offers /temp
- Robust: Adapts to network changes

CoAP Resource Discovery Benefits:

• Zero configuration networking
• Dynamic topology adaptation
• Service versioning support
• Reduces integration time by ~80%

Knowledge Check: Match and Sequence

Match each CoAP concept to its correct definition or use case:

Arrange the following steps of a CoAP resource discovery and subscription workflow in the correct order:

8.12 Protocol Comparison

The feature tour is complete: methods name the operation, discovery finds resources, and Observe changes polling into push. Now compare CoAP with HTTP and MQTT.

8.12.1 CoAP vs HTTP: Concrete Performance Numbers

Feature	CoAP	HTTP	CoAP Advantage
Transport	UDP	TCP	No handshake overhead
Header Size	4 bytes	100-200 bytes	96% reduction
Total On-Wire Size	40-60 bytes	250-600 bytes	85-93% smaller
Connection Setup	None (UDP)	3-way handshake	Saves 1+ RTT + ~180 bytes
Methods	GET, POST, PUT, DELETE	Same + more	Focused on IoT needs
Discovery	Built-in (/.well-known/core)	No standard	Zero-config networking
Multicast	Yes (FF0X::FD)	No	One-to-many efficiency
Observe	Yes (push notifications)	Server-Sent Events	99% less polling traffic
Security	DTLS	TLS	UDP-optimized
Power per Message	3-5 mJ	30-50 mJ	10x more efficient
Battery Life Impact	2-5 years	2-6 months	10x longer life

Real Numbers Example - Temperature Reading:

Scenario: Send “22.5C” (5 bytes payload) from sensor to server

8.12.1.1 Putting Numbers to It

Total message overhead directly affects both bandwidth and battery life. For payload $P$ bytes:

$B_{\text{total}} = H_{\text{protocol}} + H_{\text{transport}} + P$

CoAP message: $B_c = 4\text{ (header)} + 8\text{ (token+options)} + 28\text{ (UDP/IP)} + 5\text{ (payload)} = 45$ bytes

HTTP message: $B_h = 200\text{ (headers)} + 40\text{ (TCP/IP)} + 5\text{ (payload)} + 180\text{ (handshake)} = 425$ bytes

For 1,000 daily readings at 3V, 200mA peak transmit current (typical for an ESP32 Wi-Fi radio), 250kbps effective link rate: $E_c = 1000 \times \frac{45 \times 8}{250,000} \times 0.2\text{A} \times 3\text{V} = 0.86\text{ J/day}$

$E_h = 1000 \times \frac{425 \times 8}{250,000} \times 0.2\text{A} \times 3\text{V} = 8.16\text{ J/day}$

With CR2032 battery (675 mWh = 2,430 J): CoAP enables 7.7 years vs HTTP’s 0.8 years of TX-only battery life. The 9.4× overhead ratio translates directly to a 9.4× difference in radio energy per day. Note: real-world battery life will be shorter due to sleep/idle current, MCU processing, and other loads; this model isolates the protocol overhead contribution.

The arithmetic above becomes easier to audit when bytes, energy, and lifetime stay on one scale. Use Figure 8.4 to check that each stage preserves the same overhead ratio.

Read Figure 8.4 from on-wire bytes to daily energy and finally to TX-only battery life. The example’s 45-versus-425-byte traffic becomes 0.86 versus 8.16 joules per day under the same radio assumptions, so the lifetime bars reverse in length. Because sleep current, computation, retries, and battery behavior are excluded, carry forward the comparative conclusion—protocol overhead matters—not the projected years as a deployment promise.

8.13 CON and NON Pattern Evidence

Choose the CoAP message type per interaction, not per deployment. The method tells the server what operation to perform; CON or NON tells the protocol how much delivery evidence is worth paying for.

For constrained sensors, a hybrid policy is often the measurable answer: routine telemetry as NON, rare commands and critical alerts as CON. Record the tolerated loss rate, expected message frequency, and retry budget so the battery and reliability tradeoff can be checked in tests.

8.14 See Also

Read these points as one connected sequence: start with CoAP Method Codes and Multicast Contracts: Deepen method-code, response-code, retry, multicast, Token, and Leisure behavior; then CoAP Message Types: Review how CON, NON, ACK, and RST messages support method exchanges; then CoAP Observe Extension: Extend GET semantics into server-pushed resource updates; then CoAP Advanced Features: Continue from core methods into block-wise transfer, proxies, and advanced constrained workflows; and finish with CoAP vs MQTT and Use Cases: Compare REST-style CoAP methods with brokered MQTT publish/subscribe.

• CoAP Method Codes and Multicast Contracts: Deepen method-code, response-code, retry, multicast, Token, and Leisure behavior.
• CoAP Message Types: Review how CON, NON, ACK, and RST messages support method exchanges.
• CoAP Observe Extension: Extend GET semantics into server-pushed resource updates.
• CoAP Advanced Features: Continue from core methods into block-wise transfer, proxies, and advanced constrained workflows.
• CoAP vs MQTT and Use Cases: Compare REST-style CoAP methods with brokered MQTT publish/subscribe.

8.15 Summary

CoAP methods and features work together: methods define the resource operation, content format defines representation, Observe reduces polling, and block-wise transfer handles payloads that do not fit in one datagram.

8.16 Key Takeaway

Keep CoAP designs resource-centered. If the interaction cannot be described as a small operation on a named resource, MQTT, HTTP, or a gateway pattern may be a better fit.