Hello World is great and all. But this is where my project sort of kinda explodes into a huge complex mess that's yet to be organsied.

My next project goal was to control a RGB LED from my phone or desktop.

• Add a RGB LED resoruce with information about how to send data to it
• Allow the App to identify the resource's schema and present a UI the easily control the resource.

Simple enough, right?

CoAP. What are they, we just don't know

I've mentioned CoAP as being the protocol of choice. but haven't explained what it is or what it provides. Simply put, Constrained Application Protocol (or CoAP [RFC7252]) is a constrained-resource friendly protocol that takes concepts from HTTP and applies it to an unreliable transport (like UDP).

• It provides the well known GET, PUT, POST and DELETE methods.
• Has response codes (2xx, 4xx, 5xx).
• Supports simple message reliability options
• Allows resources to be observed
• And (my favourite part) uses a /.well-known/core URI to allow anyone else on the network easily discover it's resources and additional meta data.

I like the discovery aspect to CoAP as it means you don't need to configure the ip address of the device (actually, anything at all about it). As clients will send out a multicast "GET /.well-known/core" request on the local network, then all CoAP server devices will eventually respond (with in a short random period) with a a list of their resources, and attached meta data.

To go into a bit more detail:

1. A CoAP Client (App, or another device) sends a "Non-Confirmable GET /.well-known/core" request to 224.0.1.187 on port 5683
   1. Non-Confirmable means "You are not required to reply with a acknowledgement" otherwise, the network immediately becomes a mess of "Yup I got it"...
   2. 224.0.1.187 is a special IP address used for multicast messages specifically for CoAP
2. A CoAP Server (a device with resources) is subscribed to the multicast address 224.0.1.187 and waits for messages that were sent to it.
3. When the server receives a message that was sent to multicast. it waits a Leisure period before responding to the client directly (unicast) with another Non-Conformable message
   1. A Leisure period is by default 5 seconds. but can be any random period. however, Section 8.2 of RFC7252 has more specifics on what this period should be.
   2. Unicast means that the server sends the message to the client's ip address directly, and not through the multicast address.
4. The client then receives a response and processes it like any other message.

What's so special about /.well-known/core?

/.well-known/core is a special resource that is easy to parse and human readable. An example looks like

;ct="0,50";rt="temperature";if="sensor",;anchor="/sensors/temp";rel="describedby"

A little confusing at first. but breaking it down shows

1. </sensors/temp>;ct="0,50";rt="temperature";if="sensor" -> that there is one resource at /sensors/temp
   1. ct="0,50" -> that can be read in human readable "text/plain" or in "application/json"
   2. rt="temperature" -> the resource uses a temperature Resource Type
   3. if="sensor" -> the resource interfaces like any other sensor (GET, PUT, POST, DELETE)
   2. <http://exaample.com/schemas/temp>;;anchor="/sensors/temp";rel="describedby" -> Not a resource, but a link to an external site that contains information
   1. anchor="/sensors/temp" this resource is metadata for /sensor/temp
   2. rel="describedby" This resource describes how to interface with /sensor/temp

I wont go into much more detail as it's all specified in RFC75252 and RFC6690

However, this allows an app to see what a device has to offer and any information needed to interact with the resources on a device.

Putting it all together

I created a LED resource on my device at /leds. The Lobaro-CoAP library is nice in that it automatically adds an entry to /.well-known/corefor you. Then added a colour picker to my Xamain.Forms app (again this was no easy feat, I ended up building a custom control for Windows which took a lot of trial and error 😱). Finally, I added some busniness logic to show the color picker on a resource when it reconised the resource type reported by the devie.

The result is very similar to my previous tweet (Sorry, I don't have video of my latest code in action... as it's not currently in action...)

https://twitter.com/NZSmartie/status/844921602995204096 <- Video in action on twitter