Test: CoAP (the web, shrunk for sensors)
CoAP: The Web, Shrunk for Sensors
Why CoAP? The web, shrunk for sensors
MQTT puts a broker in the middle. CoAP (the Constrained Application Protocol) takes the other road: every node is a small web server. Node 1 offers resources such as /temp and /humidity, the fan controller offers /fan, and a client asks for them with the web’s methods (GET, PUT, POST, DELETE). Answers come back with codes you know from HTTP, packed into one byte: 2.05 Content for 200 OK, 4.04 Not Found. It all runs over UDP, so there is no connection to set up or keep alive, and the access point in the middle just forwards datagrams. The price is that a client must know each node’s address, and each node must be reachable. Send some requests from the phone.
Challenge: Switch the fan on with a PUT, then read /fan back with a GET to check it.
Requests: the web’s methods
GET reads a resource, PUT replaces it, POST creates or triggers, DELETE removes. The URI names the node and the resource.
Responses: HTTP’s codes in one byte
Class.detail: 2.xx success, 4.xx the client’s mistake, 5.xx the server’s. 2.05 Content is HTTP’s 200, 4.04 is 404.
What the phone received, newest first
Nothing yet.
The phone sends a request (CON)
Last request
-
Answer
-
Every node runs its own server, and the phone needs each one’s address: here they are fixed IPv4 addresses on the greenhouse Wi-Fi. Nothing stands in the middle that could keep a value for later, which is why a reading is always the node’s current one.
Message log, newest first
Nothing on the wire yet.
© 2026 Derek Molloy, Dublin City University. All rights reserved.
Spot an error, omission, or have a suggestion?
Submit an errata report here.