More CoAP musings…

Last week I implemented a simple version of CoAP protocol at work, going by the main specification:

CoAP seems to be similar to how a web browser works with a web server: GET some content, POST something back.

A CoAP server could report back the status of various sensors, and they would be given names similar to a web page. Instead of featching a web page using HTTP protocol like:

…you would use the COAP protocol to reference some resource:


You can GET, PUT, POST or DELETE, which I am told mimics things web developers are familiar with. Instead of passing around huge HTML text packets using TCP, CoAP sends a very tiny and compact bit of binary data using the smaller and faster UDP protocol.

CoAP is only a few years old, so many items that I needed to implement were not part of the main specification. I had to consult a second RFC document to learn about the “Observe” option:

Observe is a mechanism that allows being notified when a resource changes. For instance, if you were monitoring a motion sensor, you might GET the /motionsensor resource, and specify the Observe option. CoAP should respond with the status of the motion sensor, and any time the status changes, send a message with the update.


I was able to quickly put together a simple version that could receive and respond to CoAP messages — at least the ones that we’d be needing. However, there are still many features of CoAP I have yet to tackle.

One such features is outgoing confirmable messages. The challenge with those is that all the important information has to be retained somewhere so it can be re-transmitted if the receiver doesn’t receive :)

When I first began researching CoAP, I found several CoAP implementations for memory constrained devices like Arduino. Now that I know more about the protocol, I thought I’d revisit them and see how they approached things like Confirmable messages and Observe.

It turns out, many of the features I have been kludging together are just not supported at all by the simple CoAP implementations.

Here is one called microcoap:

With a few small changes, I was able to compile it up for a Windows PC using the GCC compiler. It easily allows creating a new endpoint function that is called when the CoAP message is received, with all important information parsed out and presented as elements in a C structure. All one needs to do is deal with the payload (passed along as a pointer to it, and the length) and generate a response packet.

It does not handle Observe or Confirmable messages, but it does have enough framework to quickly parse incoming CoAP messages, run some code, and send back a response. Like many I have looked at, this version also seems to be geared just for listening and responding. If you have a need for CoAP on that level, it’s a good place to start.

Once I get my work project done, I expect to attempt a similar project, just for fun, that will run on an Arduino with 2K of RAM.  (microcoap has 8K of buffers set aside on startup!)

More to come, maybe.

3 thoughts on “More CoAP musings…

    1. Allen Huffman Post author

      I have been waiting for someone to port the Commodore BASIC programs for FTP, IRC chat and Telnet to the CoCo (for ZiModem ESP firmware). They’d need an assembly to read/write the bitbanger, but the rest of the code looked pretty simple.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.