CoAP · Study deck

CoAP Methods and Multicast

Picture a caretaker using a small panel to read a tank level and change an alarm limit.

Broker Bex is your guide for this deck.

methods

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

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 CoAP Observe enables server-push notifications and can reduce repeated polling traffic when resource changes are infrequent; calculate energy separately for the device and network.

Major section

Start With the Device Menu

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.
The panels show a tank reading and a change to its alarm limit.
They show why a repeated request must keep the same meaning.

Major section

Start With the Device Menu (continued)

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.
If many devices receive the same request, prove that the result stays bounded and that replies do not swamp the link.

Major section

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.

Major section

For Beginners: What is CoAP?

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.
That works great for powerful computers and smartphones with strong batteries and fast internet.

Major section

For Beginners: What is CoAP? (continued)

Regular websites use HTTP, which is like sending detailed emails with lots of extra information in headers and metadata.

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.

Major section

Key Insights

The simulator comparisons become a protocol choice only after interaction pattern and device constraints are considered together.

The branches describe fit, not a universal winner.
Having chosen an interaction model, the next question is what that choice costs on the wire.

Protocol selection decision tree for choosing CoAP, MQTT, or HTTP from interaction pattern and device constraints.

Major section

Critical Battery Life Insights

NON vs CON Performance: Read these points as one illustrative byte-count comparison: NON sends 45 bytes and: CON plus ACK sends 57 bytes, a 12-byte increase in this example.

Radio energy also depends on the receive window, retries, and sleep schedule.
NON messages skip acknowledgment; this example sends 45 bytes versus 57 bytes for CON plus ACK (12/57 = 21% fewer bytes).
Battery-life change depends on the full device energy budget.

Major section

Multicast Support

Once a single exchange is clear, scale the same resource model to a group.

Multicast helps discovery without changing what GET means.
Unicast increases request count and sequential time with every device; multicast holds the outbound request count at one but still receives one response per participating endpoint.
That distinction explains why discovery benefits from multicast while state-changing commands still need per-device authorization, outcome tracking, and retry decisions.

Major section

Learning Points

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.

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.
Service versioning support.

CoAP resource link format field breakdown for a temperature sensor advertisement.

Major section

Learning Points (continued)

Standard Endpoint - /.well-known/core is CoAP convention (RFC 6690).

Example Resource Advertisement: Resource discovery is useful only if a client can interpret an advertisement rather than merely find a URI.
Those attributes let discovery feed a compatible client action, which is why the application examples below can find capabilities without hard-coded endpoint catalogs.
Resource discovery can shorten integration work when it replaces manually maintained endpoint lists.

Major section

Protocol Comparison

This is a transmit-only comparison. Sleep current, computation, retries, and battery behavior must be measured before predicting deployment life.

Total message overhead directly affects both bandwidth and battery life.
With CR2032 battery (675 mWh = 2,430 J): CoAP enables 7.7 years vs HTTP's 0.8 years.
The printed years describe transmit charge only.
Sleep current and computation add separate energy costs.

CoAP versus HTTP overhead for a 5-byte temperature reading, comparing total on-wire bytes, daily radio energy, and TX-only CR2032 battery life.

Deck summary

Key takeaways

A read must not alter the device.

A protocol is a shared set of rules for exchanging messages.
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$ .
You might send a long email with lots of details, or you might send a quick text message with just the essential information.
Regular websites use HTTP, which is like sending detailed emails with lots of extra information in headers and metadata.

Retrieval practice

Recall check 1 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q1Which of the following CoAP method properties is correct?

APOST is idempotent whenever two requests carry the same payload.

BGET, PUT, and DELETE are idempotent; POST generally is not.

CDELETE is non-idempotent because the URI may be gone afterward.

DCoAP PUT differs from HTTP PUT by being non-idempotent.

Show answer

Answer: B GET is safe and idempotent; PUT and DELETE have idempotent method semantics.

Retrieval practice

Recall check 2 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q2A developer is implementing a CoAP server for a smart thermostat. The thermostat should allow reading current temperature, updating the target temperature, and resetting to factory defaults. The developer writes: PUT /temperature to read values, POST /target to update settings, and GET /reset to perform factory reset. What's wrong with this design?

ANothing is wrong - these are all valid CoAP methods being used correctly

BShould use GET /temperature to read, PUT /target to update, and POST /reset for factory reset

CShould use OBSERVE /temperature to read continuously, DELETE /target to update, and PUT /reset for factory reset

DCoAP methods are interchangeable - only the URI path matters for determining the operation

Show answer

Answer: B GET retrieves data without side effects (reading temperature).

Retrieval practice

Recall check 3 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q3Complete the CoAP PUT request to update a resource:

Arequest = Message(code=PUT, uri='coap://device.local/led')

Brequest = Message(code=POST, uri='coap://device.local/led')

Crequest = Request(method='PUT', url='coap://device.local/led')

Drequest = coap.put('coap://device.local/led')

Show answer

Answer: A CoAP uses code=PUT for resource updates (like HTTP PUT).

Retrieval practice

Recall check 4 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q4A facility manager has 200 CoAP sensors from three manufacturers on the same link-local multicast scope. Each supports CoRE resource discovery, and identity enrollment is handled separately. The installer wants to discover their resource addresses without manually entering each IP. Which feature fits?

ACoAP Observe - sensors automatically register with the management system

BDTLS authentication - sensors authenticate themselves to the management system

CBlock-wise transfer - sensors send their configuration in blocks during setup

DResource discovery at /.well-known/core using a multicast query

Show answer

Answer: D A NON multicast GET to the link-local CoAP group at /.well-known/core can discover responses from reachable devices that implement CoRE Link Format. The client must handle missing or delayed responses, and discovery does not replace identity enrollment.

Retrieval practice

Recall check 5 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q5What group request avoids an acknowledgement from every CoAP multicast recipient?

AScoped Group Address

BEligible Servers Evaluate

CLeisurely Unicast Replies

DNON Multicast GET

Show answer

Answer: D A Non-confirmable group request avoids requiring every recipient to send a message-layer acknowledgement.

Retrieval practice

Recall check 6 of 6

Broker Bex says: answer from memory, then check your reasoning.

Q6An IoT architect is designing a smart parking system. Sensors report infrequent car-presence changes and need individually addressable maintenance resources. There is no broker, and the device design requires short datagram exchanges without TCP connection setup or a persistent session. Five-year battery life remains a target to verify. Which listed protocol best fits?

AMQTT QoS 1 for a brokered stream despite addressable maintenance need.

BCoAP for sparse device updates and individually addressable resources.

CHTTP REST for each constrained sensor despite heavier request overhead.

DWebSocket for a persistent stream despite infrequent car-state changes.

Show answer

Answer: B CoAP provides compact resource-oriented exchanges over UDP without a broker, fitting the stated datagram design and addressable maintenance resources.

Print reference

Answers 1 of 2

Answer key.

B · GET is safe and idempotent; PUT and DELETE have idempotent method semantics.
B · GET retrieves data without side effects (reading temperature).
A · CoAP uses code=PUT for resource updates (like HTTP PUT).
D · A NON multicast GET to the link-local CoAP group at /.well-known/core can discover responses from reachable devices that implement CoRE Link Format. The client must handle missing or delayed responses, and discovery does not replace identity enrollment.

With the answer frame visible, connect the six checks. G-E-T reads; P-U-T sets a value; P-O-S-T can invoke reset. Discover resources before onboarding devices. Choose a protocol from the interaction, then measure its energy cost. One group request may produce many separate replies, so inspect each device’s result.

Print reference

Answers 2 of 2

Answer key.

D · A Non-confirmable group request avoids requiring every recipient to send a message-layer acknowledgement.
B · CoAP provides compact resource-oriented exchanges over UDP without a broker, fitting the stated datagram design and addressable maintenance resources.