7  CoAP Methods and Multicast

coap
methods

7.1 Start With the Device Menu

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 the physics guide

Phoebe’s Why

This chapter’s own CON/NON calculator treats the CR2032 as a fixed 2430 J tank that current drains at a steady rate – a reasonable first pass. A real coin cell is not a tank; it is a chemical cell whose open-circuit voltage only shows up fully when almost no current is flowing. The moment a 20 mA transmit pulse asks for real current, some of that voltage is lost inside the cell itself, across its own internal resistance, before it ever reaches the radio. That internal resistance is not fixed either – it climbs as the cell ages and as it gets cold, so the same 20 mA pulse that barely dents a fresh cell at room temperature can pull a well-used cell’s terminal voltage down far enough to brown the radio out while the datasheet capacity is still mostly unused.

The Derivation

Nominal energy from charge and voltage:

\[E = Q_{Ah} \times V_{oc}\]

Real terminal voltage under load (Thevenin battery model):

\[V_{load} = V_{oc} - I R_{int}\]

Energy actually delivered per message at the pulse current \(I\) over transmit time \(t\):

\[E_{msg} = I \times V_{load} \times t\]

Worked Numbers: This Chapter’s CR2032 Calculator

  • Chapter’s own model: \(V_{oc} = 3.00\) V, \(I_{tx} = 20.0\) mA, capacity \(2430\) J \(= 675\) mWh (\(= 225\) mAh \(\times 3.00\) V, a standard catalog CR2032 rating)
  • Fresh cell (catalog-typical \(R_{int} \approx 15.0\ \Omega\) near the start of discharge): \(V_{load} = 3.00 - 0.0200\times15.0 = 2.70\) V – 10.0% below the calculator’s nominal 3.00 V, so its energy-per-message figure overstates delivered energy by that same 10.0%
  • Aged or cold cell (catalog-typical \(R_{int}\) rising toward \(\approx 100\ \Omega\) near end of discharge or at low temperature): \(V_{load} = 3.00 - 0.0200\times100 = 1.00\) V – below the roughly 2.0 V minimum operating voltage many 3.3 V-class radio ICs specify, so the transmit pulse can brown the radio out while most of the nominal 675 mWh is still chemically present
  • Self-discharge / shelf-life ceiling: at the calculator’s own default 1000 NON messages/day (45-byte payload, \(8.64\times10^{-5}\) J/message), the message-energy math alone predicts \(2430/(8.64\times10^{-5}\times1000) = 28{,}100\) days \(\approx 77.1\) years of battery life – but CR2032 datasheets commonly cap useful shelf life at about 10 years regardless of load, from self-discharge and internal passivation. The real ceiling on this “message budget” is never the radio energy; it is the cell’s own shelf life, roughly 7.7x shorter than the naive message-energy calculation implies
Chapter Roadmap

This chapter moves from verbs to deployment choices:

  1. First map GET, POST, PUT, and DELETE to sensor resources.
  2. Then test those methods in Python and ESP32 examples.
  3. Next compare CoAP, MQTT, and HTTP with the byte and battery calculators.
  4. Finally add multicast, discovery, Observe, and CON/NON evidence.

Checkpoint callouts pause the tour; Deep-dive sections and calculation audits are optional support on a first pass.

7.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
Key Concepts
  • CoAP: Constrained Application Protocol — REST-style request/response protocol using UDP instead of TCP
  • Confirmable Message (CON): Requires ACK from recipient — provides reliable delivery over UDP at the cost of one roundtrip
  • Non-confirmable Message (NON): Fire-and-forget UDP datagram — lowest latency, no delivery guarantee
  • Observe Option: CoAP extension enabling publish/subscribe: client registers to receive notifications on resource changes
  • Block-wise Transfer: Fragmentation mechanism for transferring payloads larger than a single CoAP datagram
  • Token: Client-generated value matching responses to requests — enables concurrent request/response pairing
  • DTLS: Datagram TLS — CoAP’s security layer providing encryption and authentication over UDP

7.3 In 60 Seconds

CoAP supports four REST methods mirroring HTTP: GET (retrieve), POST (create), PUT (update/create), and DELETE (remove), with GET, PUT, and DELETE being idempotent. Beyond basic REST, CoAP adds multicast support for group operations (e.g., turning off all lights), resource discovery via /.well-known/core, and the Observe extension that enables server-push notifications – reducing energy consumption by up to 99% compared to polling.

For Beginners: What is CoAP?

Think about how you communicate with friends. You might send a long email with lots of details, or you might send a quick text message with just the essential information. Both get the message across, but text messages are faster and use less data especially important when you have limited battery or a slow connection.

CoAP is like the text message version of web communication for IoT devices. Regular websites use HTTP, which is like sending detailed emails with lots of extra information in headers and metadata. That works great for powerful computers and smartphones with strong batteries and fast internet. But tiny sensors running on coin batteries can’t afford that luxury. CoAP strips away all the unnecessary extras and keeps just the essential parts: what you want to do, which resource you’re accessing, and the actual data.

The magic is that CoAP still works like the web you know. You can GET data from a sensor, PUT a new setting to a device, or POST a command just like with regular websites. But instead of using hundreds of bytes of overhead like HTTP, CoAP uses just 4 bytes for its header. This means a temperature sensor can report readings for years on a single battery instead of months, and devices can communicate even over slow, unreliable networks where every byte matters.

Sensor Squad: The Four Magic Words

“CoAP has four magic words that do everything!” announced Max the Microcontroller. “GET means ‘tell me your value.’ PUT means ‘change your setting to this.’ POST means ‘do this action.’ And DELETE means ‘remove this thing.’”

Sammy the Sensor demonstrated: “When the dashboard sends me a GET, I reply with my temperature. When someone sends a PUT to change my sampling rate from 10 to 30 seconds, I update my setting and confirm. It’s just like asking and answering questions!”

“And multicast is the coolest feature!” added Lila the LED. “Instead of asking each sensor one by one – ‘Sammy, what’s your temperature? Bella, what’s your voltage?’ – you shout to ALL sensors at once: ‘Everyone, report your temperature!’ One message, fifty replies. Imagine how much time and energy that saves in a building with hundreds of sensors!”

Bella the Battery loved that. “One multicast GET instead of fifty individual GETs means I save 98% of my radio energy for discovery. It’s like a teacher taking attendance by saying ‘raise your hand if you’re here’ instead of calling each name individually!”

7.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.

7.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:

Method Purpose HTTP Equivalent Idempotent
GET Retrieve resource GET Yes
POST Create resource POST No
PUT Update/Create PUT Yes
DELETE Remove resource DELETE Yes

7.5.1 Examples

GET: Retrieve temperature

coap://sensor.local/temperature

POST: Add new sensor reading

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

PUT: Update configuration

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

DELETE: Remove old data

coap://server.local/readings/old

Broker BexCheckpoint: Method Semantics

You now know:

  • CoAP carries the same four REST verbs as HTTP: GET, POST, PUT, and DELETE.
  • GET, PUT, and DELETE are idempotent; POST is not, so duplicate delivery must be considered.
  • A thermostat API should read with GET, update with PUT, and reserve POST for one-time actions.

7.6 💻 Code Examples

7.6.1 Python CoAP Server

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())

Install: pip install aiocoap

7.6.2 Python CoAP Client

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())

7.6.3 Arduino ESP32 CoAP Client

#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();
}

7.7 📊 Interactive Comparison: CoAP vs MQTT vs HTTP

Key Insights

CoAP Advantages:

  • ✅ Smallest header size (4 bytes) - minimal overhead
  • ✅ Best battery life (UDP, no connection overhead)
  • ✅ RESTful design - familiar to web developers
  • ✅ Low latency - simple request/response

When CoAP Wins:

  • Resource-constrained devices (8-bit microcontrollers)
  • Battery-powered sensors (years not months)
  • Intermittent connectivity (devices sleep often)
  • Integration with web infrastructure (HTTP proxies)

When to Choose Alternatives:

  • MQTT: Publish-subscribe needed, TCP reliability required
  • HTTP: Full web stack needed, rich tooling ecosystem

The examples showed how a device speaks CoAP. The next question is what that choice costs on the wire.

7.8 💻 Interactive Tool: CoAP Message Size Calculator

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

Message Size Optimization

For small payloads (< 100 bytes), protocol overhead dominates. Try adjusting the payload size above to see how CoAP’s efficiency scales.

Recommendation: For sensors sending small readings frequently, CoAP’s low overhead translates to: - 📉 Reduced network congestion - 🔋 Longer battery life (less radio time) - ⚡ Lower latency (smaller packets = faster transmission)

7.9 🔋 Battery Life Calculator: CON vs NON Messages

Critical Battery Life Insights

NON vs CON Performance:

  • NON messages skip acknowledgment, saving approximately 21% energy per transaction (45 bytes vs 57 bytes for CON + ACK round-trip)
  • CON messages require an ACK response, adding 12 bytes of overhead and an additional receive window — increasing per-message energy by ~27% compared to NON
  • For sensors with reliable links, NON can extend battery life by years
  • Use CON only when guaranteed delivery is critical

Broker BexCheckpoint: Message Cost

You now know:

  • CoAP’s base header is 4 bytes; the HTTP comparison uses 100-200 bytes of headers plus setup.
  • For the 5-byte temperature example, the chapter’s model gives 45 bytes for CoAP and 425 bytes for HTTP.
  • CON adds a 12-byte ACK path over the NON case, so reliability has a measurable battery cost.

🎮 Interactive Simulator: CoAP-Style UDP Communication

What This Simulates: ESP32 demonstrating CoAP’s lightweight UDP request/response pattern

CoAP Communication Pattern:

CoAP UDP request/response

CoAP UDP request/response
Figure 7.1: CoAP request/response communication pattern showing lightweight UDP exchange between ESP32 client and server with minimal 4-byte header overhead.

How to Use:

  1. Click ▶️ Start Simulation
  2. Watch Serial Monitor show UDP request/response cycle
  3. Observe message types (CON, NON, ACK)
  4. See CoAP-style resource addressing
  5. Monitor round-trip times (RTT)

💡 Learning Points

What You’ll Observe:

  1. UDP Transport - Connectionless, lightweight communication
  2. 4-Byte Headers - Minimal overhead compared to HTTP
  3. Request/Response - RESTful pattern like HTTP GET
  4. Message IDs - Tracking requests and responses
  5. No Handshake - Direct communication without TCP overhead

CoAP Message Structure (Simplified):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T |  TKL  |      Code     |          Message ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ver = Version (2 bits)
T   = Type (CON, NON, ACK, RST)
TKL = Token Length
Code = Method (GET) or Response (2.05 Content)

Real-World Applications:

  1. Smart Home - Light bulbs responding to GET/PUT requests
  2. Industrial IoT - Sensors publishing data via RESTful interface
  3. Building Automation - HVAC systems with RESTful control
  4. Energy Management - Smart meters with resource discovery
  5. Wearables - Health sensors with minimal power consumption

Experiments to Try:

  1. Change Request Frequency - Modify delay() to see network load
  2. Add More Resources - Simulate /humidity, /pressure endpoints
  3. Implement Observe - Add subscription pattern (like MQTT subscribe)
  4. Calculate Overhead - Compare 4-byte CoAP vs HTTP headers
  5. Test Reliability - Implement CON (confirmable) message handling

CoAP vs HTTP Power Consumption:

HTTP Request:  ~500 bytes (headers + TCP)
CoAP Request:  ~20 bytes (4-byte header + minimal payload)
Power Savings: ~96% less data transmitted

7.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:

7.10.1 IPv4 Multicast

224.0.1.187

7.10.2 IPv6 Multicast

FF0X::FD

Use cases:

  • Discover devices on network
  • Broadcast commands to group
  • Query multiple sensors simultaneously

Example:

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

Sends GET request to all devices in multicast group.

7.10.3 📊 Multicast Efficiency Calculator

Broker BexCheckpoint: Discovery and Observe

You now know:

  • Multicast can send one discovery request instead of contacting 50 sensors one by one.
  • Polling 50 sensors every 5 seconds creates 600 request cycles per minute even when values stay stable.
  • Observe fixes the polling problem by registering once and sending updates only when the resource changes.

7.11 CoAP Features

Key Features
  1. Reduced Overhead: 4-byte header vs 100+ bytes in HTTP
  2. URI Support: Resource addressing like HTTP
  3. Content-Type: Supports JSON, XML, CBOR, etc.
  4. Resource Discovery: Automatic service discovery (/.well-known/core)
  5. Observe Pattern: Subscribe to resources, receive push notifications
  6. Simple Caching: Based on maximum message age
  7. Block-wise Transfer: For large payloads
  8. Security: DTLS encryption

7.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. Click ▶️ 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

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:

CoAP resource link format

CoAP resource link format
Figure 7.2: CoAP resource link format showing the structure of a resource advertisement with path, resource type, interface description, observability, and content type attributes.

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:

7.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.

7.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

Bar chart comparing CoAP and HTTP total message sizes and energy consumption for a small sensor reading, illustrating CoAP's efficiency advantage for battery-powered IoT devices
Figure 7.3: CoAP versus HTTP comparison for a temperature reading showing significantly lower bandwidth and energy usage for CoAP due to its 4-byte header versus HTTP’s verbose header format

7.12.1.1 Putting Numbers to It

Tip

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.

Broker BexCheckpoint: Protocol Selection

You now know:

  • CoAP keeps REST-style GET, POST, PUT, and DELETE while avoiding TCP setup.
  • In the chapter model, 1,000 daily readings produce 0.86 J/day for CoAP and 8.16 J/day for HTTP radio transmission.
  • The isolated protocol-overhead model yields 7.7 years versus 0.8 years of TX-only battery life before other loads are counted.

7.12.2 CoAP vs MQTT

Feature CoAP MQTT
Pattern Request/Response Publish/Subscribe
Transport UDP TCP
Discovery Built-in External
QoS Via message type 3 levels (0,1,2)
Broker Optional Required
Best For RESTful IoT Event-driven IoT
Protocol selection tree
Figure 7.4: IoT Protocol Selection Decision Tree: CoAP, MQTT, or HTTP
🏷️ Label the Diagram

7.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.

Interaction Prefer Reason
Periodic temperature or humidity reading NON The next reading replaces the missing one, so avoiding ACK traffic usually matters more than perfect delivery
User-initiated configuration PUT CON The user or controller needs acknowledgement that the new state was accepted
Door unlock, alarm, valve close, or safety threshold alert CON Silent loss creates a safety or security failure
High-frequency heartbeat NON, with application-level missing-heartbeat detection Missing one heartbeat is tolerable; several missing heartbeats become the signal
Firmware block transfer CON Every block must arrive or be retried to reconstruct the payload

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.

7.14 See Also

7.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.

7.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.