Purpose

The purpose of the Ring-Of-Things is to use the openwsn firmware stack and the CoAP library to implement a simple demo where a 'ringmaster' (in this case a local python client), instructs motes via CoAP packet communication to do simple actions like blink or buzz.

Powerpoint of initial design: https://docs.google.com/presentation/d/1atlBdYjgV6HwVyvTbz42K-ek7jkmLHYt7oatlnUHvk0

Design

A CoAP app must be added to the firmware, called 'rrt', to allow for the ringmaster to send and receive CoAP packets to the resource. A tutorial for adding a CoAP app is described here: Adding a CoAP app

This app needs to have several functionalities:

notify the ringmaster of a mote's availability (when it goes 'online')
ability for a mote to wait for an incoming packet from the ringmaster
checking for a message type upon reception, and knowing whether to 'blink', 'buzz', perform another simple action, or forward an action to another mote (identified via ipv6)
ability to send a CoAP packet from itself to another mote (with some data)

The ringmaster needs to:

send packets to motes via the coap library
wait on incoming packets
keep track of all motes that are in its ring (in this case with a simple queue) and send instructions in a rotation
handle error handling - motes dropping off unexpectedly, packet loss, receiving unexpected packets

Code - firmware

The firmware code is the main addition (openwsn-fw), which runs on the motes.

Here is the firmware pull request: https://github.com/openwsn-berkeley/openwsn-fw/pull/128/

File Changed	Description
bsp/boards/python/openwsnmodule_obj.h	add rrt_vars_t struct to python OpenMote struct
inc/opendefs.h	add ringmaster port constant on which to listen to and send ring master packets
openapps/SConscript	add rrt as part of the default apps to be built with SCons
openapps/openapps.c	add rrt_init(), the initialization function for rrt resource
openapps/rrt/rrt.c	add rrt resource to openapps, with the code for handling all mote actions. A GET action sends confirmation to the ringmaster, a POST action accepts payloads and determines what to do next (forward, perform action, or nothing), and a DELETE (which unregisters a mote). rrt.c also defines a function sendCoAPMsg, which sends a char to either an address or a hardcoded ringmaster address
openapps/rrt/rrt.h	define function signatures to be used outside of rrt.c, as well as the rrt_vars_t struct
openapps/rrt/rrt.py	simple python program for testing python coap library functionality - no purpose other than coap library experimentation
openstack/04-TRAN/opencoap.h	hardcoded ringmaster address added here
openstack/04-TRAN/openudp.c	add switch blocks for the ringmaster port in openudp_receive and openudp_sendDone
openstack/SConscript	add proper path for rrt folder
projects/python/SConscript.env	add proper constants to get the proper objectification

Code - ringmaster.py

Here is the repo: https://github.com/openwsn-berkeley/ringmaster

To run the client, simply execute

python ringmaster.py

This will open up communication with OpenWSN motes on default port 15000.

This script maintains a stack (array) of registered motes that have sent a discovery packet to it. It maintains a pointer which rotates through the stack.

Analysis

Here is a screenshot of wireshark whilst the ringmaster and simulator is running at some point in time

Notice some interesting packets:

packet #13 - A CoAP packet is captured from the localhost to mote bbbb::1415:92cc:0:2 (mote 2 in simulation). This is the packet that is sent when sending a GET request to the 'rt' resource of mote 2 through Firefox Copper (CoAP Interaction#CoAPdiscovery). In the context of ringmaster, this triggers the mote to be online

packet #17 - a UDP packet headed for localhost from mote 2. This packet has the simple message 'D' in its payload, representing Discovery. Notice the Source port is 5683, the default port for COAP communication, while the destination is 15000, the hardcoded port I chose for the ringmaster to listen on.

packet #22 - A CoAP PUT packet telling the mote that it has been confirmed as registered by the ringmaster

packet #28 - ringmaster tells packet 2 to perform action 'B' - in this case, blink

Here is a simple ringmaster output, as of this writing:

The output here is fairly arbitrarily, used just for demonstration purposes. First, the ringmaster is started, where it waits for incoming messages. At some point, it received a discovery message from mote 2, after which it sends a confirmation message via CoAP PUT. Then, it sends an action B to the same mote, as it now has a mote queue to work with. When the mote blinks, it notifies the ringmaster. Seeing as there is only one mote in the queue at the time, the ringmaster tells mote 2 to forward an action to another ipv6, which in this case is the same one. Only after mote 3 gets registered can we start seeing oscillation between the two motes performing actions.