It's a wrap!

Mon, 23 Mar 2015 18:30:00 +0000

In the last couple of weeks, we have been working hard on watr.li. Today marks the deadline for the Eclipse Open IoT Challenge 2015, so we’d like to take the opportunity to summarize our work and experience so far.

In this wrap-up post, we do not only want to present the fruits of our labour, but also go into what we’ve learned, which mistakes we made, and which future steps we’d like to take with watr.li.

Presenting watr.li

We’ve created a short video on the problem we’re trying to solve, presenting the solution we’ve implemented both from the user- and the technical perspective. We hope you will enjoy it!

Technologies used

For watr.li we’ve relied on homogenous hardware, Open Source technology as well as Open Standards, the most important of which we summarize in this section.

Open source software and open standards

CoAP: To encode our data and its context, we used
CoAP. On the display nodes, we have integrated Eclipse Californium into our web server to be able to parse, handle and send CoAP requests. Our plant nodes run the RIOT port of microcoap. During both CoAP development processes, we relied on the Eclipse Copper plugin for reference and testing.
If you’d like to learn more about CoAP, check out our non RFC-writers guide to CoAP. For details on our implementations, see the posts on connecting Californium to the Play framework and building a small microcoap server for RIOT.
RPL: To connect all nodes of the Internet of plants, we
chose to use RPL as our routing protocol. RPL was made for environments in which all traffic is directed towards one central, strong node. Our display node fulfills this role, so RPL was a great fit for watr.li’s current configuration.
IEEE 802.15.4: forms the MAC and PHY layer of our plant nodes. This
standard was designed specifically for embedded devices: Its hardware is cheap to produce, energy efficient and features very small packets– with a frame size of 128 bytes, only 81 bytes of payload are left to the upper layers. For comparison: the size of a minimal IPv6 header alone is 40 bytes.
6LoWPAN: To adapt our IPv6 packets to the the restrictions of
our IEEE802.15.4 transceiver, we used a 6LoWPAN adaption layer.
RIOT: All plant nodes run RIOT, an
embedded Operating System designed for the Internet of Things. RIOT comes with POSIX compliance, full C language support, IEEE 802.15.4. support, a network stack that features RPL and 6LoWPAN and ports of two different CoAP implementations: microcoap and libcoap.

Hardware

Plant node: The plant nodes consist of an
Atmel SAM R21 connected to a DFROBOT SEN0114 humidity sensor, with an optional USB/UART converter for debugging.
Display Node: Our display node is a
Raspberry Pi equipped with a R-IDGE 6LoWPAN USB Border Router which lets us receive IEEE 802.15.4 packets and transform their 6LoWPAN packets into regular IPv6 packets.

What we’ve learned

Building watr.li has been a great learning experience. We’ve fell on our noses a couple of times, but emerged with a stronger knowledge about the technologies we’ve used. In the following, we will summarize the experiences we made as well as good and bad decisions (in hindsight).

The plant node side of life

Picking a CoAP implementation turned out to be a bit trickier than we thought: It seems that the general assumption is that IoT devices are so constrained that they cannot issue requests on their own, but must be asked for their data by other, stronger nodes. This is why the creation of a CoAP server is often more trivial than the creation of a client. libcoap, RIOTs original CoAP implementation, does appear to support clients, but its only documentation are >1000 mostly uncommented lines of code. So Martine Lenders kindly added a port of microcoap to RIOT. Microcoap is more minimalistic and easier to use, but it lacks the ability to create and send requests without having previously received a request from another CoAP client. We needed this functionality to register our plant nodes at the display node, though, so why we built our own microcoap extension to do this.

Additionally, RIOT is currently going through some major network stack refactoring, and we’ve come to learn why. Unfortunately, the current IPv6 Neighbor Discovery doesn’t always work as expected, which can lead to inconsistencies in the communication between plant node and display node, because Linux refuses to believe the plant nodes are its neighbors if it doesn’t have confirmation from the Neighbor Cache. The refactoring seems to be progressing rapidly, though, and we’re looking forward to updating our application!

On the dashboard side

Choosing Eclipse Californium as the CoAP client/server turned out to be a good decision. While the developer-oriented documentation is not as extensive as one would wish, the example applications are numerous and the overall code architecture seems well-thought-out.

Choosing the Play framework on the other hand turned out to be more trouble than it was worth. While the WebSocket integration is good and almost effortless, many simple tasks that have to be performed in a web application were comparatively time intensive. Some examples:

Integrating database access through Slick, which is recommended by the Typesafe stack, was difficult due to missing/badly written documentation.
Generating URLs from a template does not seem to be trivially possible, thus we had to hard-code all of them.
File upload and general form submission are two separate operations, making image upload in a form complicated.

For future work on watr.li we will definitely evaluate other ways to implement the web frontend. Last but not least, no standard RPL implementation for Linux currently exists, which is why we used the implementation from Rosand Tech, who also manufacture the R-Idge 6LoWPAN router we used. Since the implementation was a little dated, we had to adjust it to the current version of the Linux kernel.

Future work

Now that we’ve figured out how to put together the building blocks of the Internet of Plants, we have a great platform to further experiment with. We’ve come up with ideas for future extensions and improvements for watr.li, and we’d like to share them with you.

Battery life experience

During the development process, our plant nodes have been powered by cable or spare battery packs made for smartphones we had lying around. Our next step will be to connect them to li-ion batteries which are smaller in size (and energy capacity) and experiment with their lifetime.

Custom plant node cases

Up until now, our prototype plant nodes have been lying around close to their plant’s pots. This is not feasible in the long term, as it is ugly, dangerous for the electronics involved, and annoying to move and clean. Designing a case which holds the battery and the SAM R21 board safely above the soil and lets us plug the sensor firmly into the ground would be a major improvement. One way to create such a case could be with the help of a 3D printer. In case you happen to have one and have experience in creating such cases for electronics, please don’t hesitate to get in touch! ;)

Extended sensing

Apart from water, plants also have other needs. We’re planning to extend our plant nodes’ abilities to sense a multitude of other environment variables, such as oxygen, carbon dioxide, temperature or light.

Plant-to-plant coordination

In our current network, plant nodes only communicate with the display node, forming a tree-like topology with the display node at its root, acting as a so-called “sink node”. This is perfectly common for many IoT environments. In fact, the Routing Protocol for Low power and Lossy Networks (RPL), which watr.li currently uses to establish connections throughout the network, is optimized for exactly this scenario.

However, the IoT is not just about conversations between things and humans. Machine to machine (or rather, thing to thing) communication is a central aspect of the IoT, and we believe it should be part of the IoP, too. In the future of watr.li, we want to enable plants to talk amongst each other, forming a mesh- rather than a tree topology. This could enable plants to coordinate their findings amongst each other, report new or more detailed data, and even provide instructions on how to change the IoP ecosystem. Suppose, for example, all plant nodes are equipped with a light sensor. In case of under- or overexposure, the plants could coordinate amongst themselves who should switch places, and provide their humans with the resulting instructions.

Employing a true mesh network could also save energy, since not all communication has to go through the Display Node. This adaption may require us to switch routing protocols, but since RIOT offers alternatives to RPL such as AODVv2 and OLSRv2 (in progress), that should be feasible.

Plant-to-thing coordination

Since we’re ultimately talking about the Internet of Things, plants should be able to talk to other kinds of things, too. Some example applications for this could be: instructing blinds to move when there’s too much or too little light, regulating room temperature or humidity, or cooperating with automatic watering systems during holiday season.

However, since home wireless automation over IEEE 802.15.4 is a comparatively new field with lots of incompatible, proprietary solutions, this vision may be a bit out of scope.

That’s all (for now), folks!

We’ve had a lot of fun building watr.li and will continue to use and enhance it, for the good of the plants in our offices. What do you think? Which crucial feature would you like to see in watr.li? What are the things we could’ve done better, or differently?

Sensing the humidity of a plant's soil

Mon, 23 Mar 2015 00:00:00 +0000

One of the last pieces of the watr.li puzzle was to measure the humidity of a plant’s soil with one of our monitoring nodes. How we connected our humidity sensor to the SAM R21 and sampled its values is the topic of this post.

The humidity sensor basically consists of two electrodes which should pass a current. These are tucked into the soil whose humidity we want to measure. The soil becomes more electrically conductive the more humid it is, increasing the current flow. On the sensor, a common collector circuit then translates the change in current flow to a change in voltage at its output, which is the sensor’s output pin.

We sample this value using the “analog to digital converter” (ADC) on the SAM R21 board. The ADC is used in an operation mode that compares the input signal to a reference voltage and then quantizes the signal. The maximum sampled value is reached when the input has the same magnitude as the reference voltage, 3.3V for our scenario. Ignoring small voltage drops caused by the transistor circuit, the sensor should roughly reach this maximum value when submerged in water. We used the ADC with a sampling width of 12-bit, leading to a maximum value of 2^12-1 = 4095.

Calibrating the ADC

Ideally, the correlation between sampled voltage and value is as shown in the figure below, i.e. the “Gain” is 1 and the “Offset” is 0.

In our case, however the value never dropped below a certain minimum and the maximum value of 4095 (i.e. 3.3V) was never reached, even when the sensor was submerged in water. This is a common issue with cheap ADC components, which is why they include hardware capabilites to compensate these inaccuracies. This compensation has to be calibrated, though.

Unfortunately, it is currently not possible to calibrate the ADC without modifying the RIOT source tree, so that is what we will have to do. The relevant settings are stored in the boards/samd21-xpro/include/periph_conf file. The values we will need to tweak are SAMPLE_0_V_OFFSET (the offset) and SAMPLE_REF_V (the gain). Do determine these values we will need to run the ADC test application, as explained in the upcoming section.

Additionally, the ADC conflicts with the default STDOUT device (UART_0) on the SAM R21 board, which is piped through the EDBG USB port. To be able to see the debug output from the RIOT application nonetheless, we have to change the output to UART_1. Since UART_1 does not have a USB interface, we’ll needed an additional USB/UART converter, which had to be connected as illustrated below:

This switch to a nonstandard output device means RIOTs make term doesn’t listen on the right device anymore. This is why, instead of using make term, you’ll have to start pyterm like this:

<path to your RIOT directory>/tools/pyterm/pyterm -p "/dev/ttyUSB0"

Running the test application

The test application can be found on GitHub. In any directory, first clone the Watr.li RIOT fork and check out the “watrli” branch and then get the adc_test node from the Watr.li nodes repository:

git clone https://github.com/watr-li/RIOT.git &&
    cd RIOT &&
    git checkout watrli &&
    cd .. &&
    https://github.com/watr-li/nodes.git &&
    cd nodes/adc_test &&
    BOARD=samr21-xpro make

Setting up the offset correction

In this test we will identify the offset, i.e. the minimum value the ADC can return with our setup. For this, SAMPLE_REF_V needs to be initialized with 0 and ADC_0_CORRECTION_EN has to be disabled, i.e. set to 0 too. Connect a GND pin to the ADC pin PA06 and a the 3.3V (the reference voltage) to the PA04 pin. Now run the test. The application will print values larger than 0. We’ll call this value “offset_value”. This is the value to set for SAMPLE_0_V_OFFSET.

Setting up the gain correction

This time we try to discover the maximum value the ADC measures when the reference voltage is supplied. For this test SAMPLE_0_V_OFFSET needs to be set as described above and SAMPLE_REF_V has to be set to 2048. Connect the 3.3V pin to the ADC pin PA06 and run the test and to the PA04 pin. The application should print values smaller than 4095. We’ll call this value the “measured_value”.

Calculating the gain

The general equation for the ADC hardware correction abilities is:

expected_value = (measured_value - offset_value) * gain_value

Substituting the known values and solving the equation for gain_value we get:

gain_value = (expected_value) / (measured_value - offset_value)

In my case, I measured the following values:

For the expected_value we’ll use 4095 since that is the maximum value the ADC can return with 12-bit resolution.
offset_value = 90
measured_value = 3700

The gain value thus becomes

gain_value = (4095) / (3700 - 90) ≈ 1.13

To set the microcontroller to the correct 12-bit gain value, we will need a truncated binary fixed-point representation (this site lets you convert back and forth between the formats):

1.13₁₀ = 1.0010000101000111101...₂
1.13₁₀ ≈ 1.00100001010₂ (truncated)

We then remove the decimal point in the truncated binary representation and convert the resulting binary number back to the decimal system:

100100001010₂ = 2314₁₀

This resulting value is the one that we want to set the SAMPLE_REF_V parameter in our periph_conf to.

SAMPLE_0_V_OFFSET = 90
SAMPLE_REF_V = 2314

Final setup

After calibrating the ADC, we can finally connect the sensor! As the sensor, we’ve used a SEN0114 Moisture Sensor from dfrobot, which is connected to the board as follows:

Now that everything is set up and connected, we can finally get some humidity values by running the ADC test application once more!

Note: When using the sensor in your plant pot, you should not set the soil under continuous voltage as this might damage the plant. Also you should not measure more often than “a couple of times” in an hour.

Serving CoAP on RIOT

Tue, 17 Mar 2015 00:00:00 +0000

Note: A previous version of this post linked to a now deprecated microcoap example
application for RIOT. The old version also contained instructions for using marz, which is now deprecated as well. You can find the old version of this post here.

In a previous post, we explained how the Constrained Application Protocol (CoAP) enables us to exchange data between nodes in the Internet of Plants using a request/reply cycle similar to that of HTTP.
To do this, we need both of our node types– plant nodes and display nodes– to be able to send, process and answer CoAP requests.

This post explains how to implement a simple CoAP server on our plant nodes, which run RIOT, using RIOTs microcoap package.

Since no special modifications to the code are needed to get it to run on RIOT, this guide may also be useful to you if you’re looking to run microcoap on Linux or your Arduino.

We’ll also show you how to test your microcoap server with Copper.

Implementing a small microcoap server

This section will walk you through the implementation of a very small microcoap server. In the end, you’ll have a server which is able to answer GET requests to /riot/board, and (hopefully :) ) the knowledge how to extend this server at will. This guide is based on the code of this example application. It might be useful to keep an eye on it as a reference.
Let’s go through the code file by file.

The Makefile

Note: this part is only relevant if you use RIOT.

Even though the RIOT wiki has a more in-depth explanation of RIOT Makefiles, there is one thing that you shouldn’t overlook:
Each RIOT Makefile specifies the board the application should be built for using the BOARD parameter. In the example Makefile, you’ll find the following line:

BOARD ?= native

This means that your application will be built as a native applications. the application and the RIOT instance it is running on will run inside a thread on your Linux OS, which is great for testing and debugging. Once you’re ready to flash your code to your actual board, substitute native with the name of your board (in our case samr21-xpro) and flash it.

Please note that microcoap currently doesn’t have a nice API to create requests on its own (i.e. without being triggered by a client). It can be done, though, but that’s for another blog post.

endpoints.c

As explained in our previous post, a CoAP server answers requests which are directed at the resource of a certain endpoint (namely, the IP address of our server). Our server will thus have to define the resources which can be requested, and how to handle these requests.

Probably a bit confusingly named, microcoap handles this with the help of an array of type endpoints.
This array should not contain information about any endpoints (i.e. IP and port pairs), but information about your resources.
You will have to create a const coap_endpoint_t endpoints[] and fill it to match your desired endpoints and how they should be handled. Let’s look at this step by step.

In microcoap_server/coap.c, you will find that the example application has created an array of coap_endpoint_t called endpoints:

const coap_endpoint_t endpoints[] =
{
    { COAP_METHOD_GET,  handle_get_well_known_core,
      &path_well_known_core, "ct=40" },
    { COAP_METHOD_GET,  handle_get_riot_board,
      &path_riot_board,    "ct=0"  },
    /* marks the end of the endpoints array: */
    { (coap_method_t)0, NULL, NULL, NULL }
};

For simplicity’s sake, we’ll only be looking at the second entry from now on.

Now, if we look at the coap.h file of the microcoap code, we can see that a coap_endpoint_t is defined as follows:

typedef struct
{
    coap_method_t method;              /* (i.e. POST, PUT or GET) */
    coap_endpoint_func handler;         /* callback function which
                                         * handles this type of
                                         * endpoint (and calls
                                         * coap_make_response()
                                         * at some point) */
    const coap_endpoint_path_t *path; /* path towards a resource
                                         * (i.e. foo/bar/) */
    const char *core_attr;             /* the 'ct' attribute,
                                         * as defined in RFC7252,
                                         * section 7.2.1.:
                                         * "The Content-Format code
                                         * "ct" attribute provides
                                         * a hint about the
                                         * Content-Formats this
                                         * resource returns."
                                         * (Section 12.3. lists
                                         * possible ct values.) */
} coap_endpoint_t;

This helps us understand the entries of our endpoints[].

COAP_METHOD_GET specifies that this entry describes how to handle a GET request.
handle_get_response is the function which should be called in case a suitable request has been received.
&path is a pointer towards the path that specifies the resource which is handled by this entry. path is defined as

static const coap_endpoint_path_t path_riot_board = { 2, { "riot", "board" } };

a few lines up, so we know that this entry handles a path which contains two segments, namely /riot/board.

microcoap supports a maximum segment number of two out of the box. If you need more, you’ll have to adjust MAX_SEGMENTS in coap.h.

"ct=0" Specifies the Content-Format, which is a hint on how to interpret the payload of the packet (if any). In this case, the content format is 0, which stands for text/plain
A list of possible Content-Format types can be found in section 12.3 of the CoAP RFC.

If our CoAP server receives a request which matches this definition, i.e. a GET request to /riot/board/ with the Content-Format set to 0=text/plain, the handle_get_riot_board() function will be called, which handles the processing of this request and the creation of a response, if necessary. Let’s look at this function in detail:

static int handle_get_riot_board(coap_rw_buffer_t *scratch,
        const coap_packet_t *inpkt, coap_packet_t *outpkt,
        uint8_t id_hi, uint8_t id_lo)
{
    const char *riot_name = RIOT_BOARD;
    int len = strlen(RIOT_BOARD);

    memcpy(response, riot_name, len);

    return coap_make_response(scratch, outpkt,
                             (const uint8_t *)response, len,
                              id_hi, id_lo, &inpkt->tok,
                              COAP_RSPCODE_CONTENT,
                              COAP_CONTENTTYPE_TEXT_PLAIN);
}

Whenever a callback function that is defined in an coap_endpoint_t is called, it is provided with parameters. Let’s look at the ones that may be important to you.

const coap_packet_t *inpkt Is a pointer to the packet which caused this callback to be called. This way, your callback function can examine its content and determine how it should react.
coap_packet_t *outpkt Is a pointer to the buffer into which a response packet can be written.
uint8_t id_hi and uint8_t id_lo Are, when put together, the CoAP Message ID. These Message IDs are used to detect duplicate packets or to match Acknowledgement packets to the requests that triggered them.

Because handle_get_riot_board() handles a GET request, we want this function to answer with a response value. So we’re copying the current BOARD name into response[].
Then, we use coap_make_response() to build our packet:

The struct that the outpkt pointer points to is filled with fresh data.
The data behind response is incorporated into outpkt as payload.
id_hi and id_lo are echoed back to help our client match the response to its request.
COAP_RSPCODE_CONTENT sets the message response code to 2.05 Content.
COAP_CONTENTTYPE_TEXT_PLAIN sets the media type to text/plain.

When this is done, handle_get_riot_board() returns the response code that coap_make_response() gave us, so that main.c knows if our endeavors were successful.

As you can see, our response payload in this example is very simple. In a real application, however, this might be where you’ll read out sensor data which has been requested.

Note that microcoap will recognize the endpoints array by its name. This will not work if your array is called anything but endpoints!

microcoap_conn.c

Now, let’s see how we can use our newly-defined endpoints to handle requests.
For an in-depth explanation of the structure of a RIOT application, please see this RIOT wiki page

You’ll see that microcoap_server_loop() starts with calls to conn_udp_create() and conn_udp_recvfrom(). This is RIOT-specific code to set up and receive from a UDP connection and can be substituted with regular POSIX socket code, if that’s what you need.

The interesting part starts at line 60:

/* parse UDP packet to CoAP */
if (0 != (rc = coap_parse(&pkt, _udp_buf, n))) {
    DEBUG("Bad packet rc=%d\n", rc);
}

checks whether the packet we received is actually a valid CoAP packet.

else
{
    coap_packet_t rsppkt;
    DEBUG("content:\n");
    coap_dumpPacket(&pkt);

    /* handle CoAP request */
    coap_handle_req(&scratch_buf, &pkt, &rsppkt);
}

After the packet passes this test, it is passed to coap_handle_req(). If the method and path of the request match one of the method-path combinations we specified in endpoints[] earlier on, the coap_endpoint_func handler provided along with them (in our case, this is handle_get_riot_board) will be called automagically. The resulting response packet is written into rsppkt.

/* build reply */
size_t rsplen = sizeof(_udp_buf);
if ((rc = coap_build(_udp_buf, &rsplen, &rsppkt)) != 0) {
    DEBUG("coap_build failed rc=%d\n", rc);
}

Now, the response packet rsppkt we just built is serialized and written to buf so that we can send it. Note that we also pass a pointer to rsplen: This doesn’t just tell coap_build() the size of our buffer. When coap_build() is done, it will have written the actual CoAP packet size to rsplen. This way, we can avoid sending bogus data which fills the rest of buf by providing our send function with rsplen as the buffer size indicator:

else {
    DEBUG("Sending packet: ");
    coap_dump(_udp_buf, rsplen, true);
    DEBUG("\n");
    DEBUG("content:\n");
    coap_dumpPacket(&rsppkt);

    /* send reply via UDP */
    rc = conn_udp_sendto(_udp_buf, rsplen, NULL, 0, raddr, raddr_len,
                         AF_INET6, COAP_SERVER_PORT, rport);
    if (rc < 0) {
        DEBUG("Error sending CoAP reply via udp; %u\n", rc);
    }
}

And that’s it! We’ve now successfully received, processed and answered a CoAP request.

Testing your microcoap server

Now that our microcoap server is up and running, we’ll want to feed it requests and see if it behaves as expected. This section will guide you through the setup of a simple environment which lets you do this. (Despite the somewhat misleading terminology, this section is not about thorough, automated tests.)

Using Copper as a test client

Copper, is a Firefox plugin that turns your browser into a powerful CoAP client.

radvd: making RIOT available to Copper

If your microcoap application is running on RIOT native, there are some extra hoops to jump through before you can test it with Copper (in case you don’t use RIOT, skip this subsection).

Make sure you’ve installed the Router Advertisement Daemon (radvd).

Build the application again using make.

Enter the following into your /etc/radvd.conf (if it doesn’t exist yet, create one):

interface tap0
{
    AdvSendAdvert on;

    MinRtrAdvInterval 3;
    MaxRtrAdvInterval 10;

    AdvDefaultPreference low;

    prefix 2001:db8:1:0::/64
    {
        AdvOnLink on;
        AdvAutonomous on;
        AdvRouterAddr off;
    };
};

(you can use radvd -c to check for syntax errors)

and run

sudo radvd

Then, run the RIOT binary as usual:

make term

Note that the output listing all configured interfaces contains a globally scoped
address, which you can now use to reach the RIOT instance via Copper.

After you’ve installed the Copper plugin in your Firefox browser and successfully set up radvd, start the microcoap application:

$ make term

RIOT native interrupts/signals initialized.
LED_GREEN_OFF
LED_RED_ON
RIOT native board initialized.
RIOT native hardware initialization complete.

main(): This is RIOT! (Version: 2016.03-devel-145-g7da0d-ubuntu)
RIOT microcoap example application
Configured network interfaces:
Iface  5   HWaddr: 62:fc:3c:5e:40:df
           MTU:1500  HL:64  RTR  RTR_ADV
           Source address length: 6
           Link type: wired
           inet6 addr: ff02::1/128  scope: local [multicast]
           inet6 addr: fe80::60fc:3cff:fe5e:40df/64  scope: local
           inet6 addr: ff02::1:ff5e:40df/128  scope: local [multicast]
           inet6 addr: ff02::2/128  scope: local [multicast]
           inet6 addr: 2001:db8:1:0:e42a:1aff:feca:10ec/64  scope: global

Waiting for incoming UDP packet...

Note the address marked as “scope: global”. This is the address you’ll use to communicate with your microcoap server using Copper.

If the above doesn’t work, try manually adding a Global address to the tap0 interface:

sudo service radvd start
sudo ip address add 2001:db8:1::a/64 dev tap0
make term

Using Copper

Now, you can enter

coap://[2001:db8:1:0:e42a:1aff:feca:10ec]/riot/board

into your Firefox address bar, where you should replace 2001:db8:1:0:e42a:1aff:feca:10ec with your server’s IPv6 address (for RIOT, tis is the “scope: global” address). If you use IPv4, remove the [].

Your browser window should look similar to this:

Now you can click the big green GET button. This will send a GET request to the resource foo/bar/ of our microcoap server. Our server should reply with a 2.05 Content message containing the payload native, which Copper should display in the big grey box, similar to the “1337” in this screenshot:

When all of this works, you’re ready to go. Extend endpoints[] with your own methods and paths, create response payloads that actually make sense and build awesome stuff with your new CoAP server. Happy hacking!

Californium meets the Play Framework

Tue, 24 Feb 2015 00:00:00 +0000

On our Raspberry Pi web interface we want to display the data from all our plant nodes in “realtime”. In this post we will be introducing our technology stack that will be running on the Raspberry Pi and explain step by step how all the pieces fit and can be made to work together.

The graphic shows an abstract overview of our setup. On the bottom left we have one of our plant nodes which communicates with the Eclipse Californium Server via the CoAP protocol, both of which have been introduced here.

To develop the web interface we have chosen the Play framework because it runs inside the JVM and thus integrates well with Californium. The communication between the Californium Server and the web application is established through an Akka Actor, which is the conventional solution for asynchronous communication within Play. Lastly, the user’s browser communicates with the Play application server using HTTP as well as the WebSocket protocol for “realtime” updates. Communication between actors is highlighted in red. No protocol is mentioned because no serialization of the messages is necessary, since the subsystems operate inside the same Java Virtual Machine, thus making it possible to simply pass Java objects around.

Creating a Play application

In order to create a new Play application, Java has to be installed on your system. Please follow the guide on playframework.com on how to install the Play framework itself. After the installation you’re ready to create a new Play app. Since this article does not intend to be an introduction to the Play framework, only the necessary steps are shown here. For more details check out the framework’s getting started guide.

Note: While Play offers the option for development in Scala, this blogpost relies entirely on an implementation written in Java, in the the hope that a Java implementation reaches a wider audience. Most parts should be easily interchangeable with Scala code, however.

To create a new Play application based on the Java template, run the following in your console after installing Play:

activator new play-californium play-java

This will create a new directory play-californium in the current directory, to which we can switch and execute ./activator run. This will start a webserver at port 9000, so navigating to http://localhost:9000 should display the Play welcome message.

Note: Play automatically detects changes in the project directory after each request to the webserver, so it is not necessary to restart it after source code changes.

Adding Eclipse Californium

Now that we have a very basic Play application set up we want to add Californium as a dependency. To do this, we include the following line in the build.sbt file within the project’s root directory:

libraryDependencies += "org.eclipse.californium" % "californium-core" % "1.0.0-M3"

Note: The above statement has to be surrounded by newlines or an error will be thrown. This is a convention of the Scala Build Tool (SBT) which is used by Play.

After adding said line and re-running ./activator, the dependency should now be included in the project. If 1.0.0-M3 should not be the current release of californium-core then you will have to update the last segment of the above dependency to match the current version designation.

Starting a Californium Server

Background jobs in Play are executed through so-called “Actors”, which are lightweight concurrent entities which process messages asynchronously (docs.akka.io provides a much more detailed explanation). We will use such an actor to handle creation and graceful shutdown of our Californium CoAP server. Additionally it will handle communication between the CoAP server and the rest of the Play application.

The Californium Server Actor

Actors in Play (which uses the Akka framework) have a single abstract method void receive(Object message) that needs to be implemented and is invoked whenever the actor receives a message. The following code is shortened for better readability of the article. Please refer to GitHub for the full source:

package actors;
[...]
public class CaliforniumServerActor extends UntypedActor {
  LoggingAdapter log = Logging.getLogger(getContext().system(), this);
  CaliforniumServer server;
  [...]

There are several types of actors, but we will be working with the simplest, the UntypedActor. The server variable will hold a reference to the instantiated Californium server, which is initialized in the constructor. The implementation of said server is presented in the next section.

public CaliforniumServerActor() {
  super();
  server = CaliforniumServer.initialize(getSelf());
}

Here we pass a reference to the actor, obtained by calling getSelf and of type ActorRef, as a parameter to the Californium initialization routine. We do this so that the Californium server will be able to send messages to the Californium actor and thus to the Play application.

Now that the server is initialized, only the onReceive method remains to be implemented. This method defines which types of messages an actor can react to. The message is passed as an Object parameter, so it is possible to simply send strings as messages to the actor. It is preferable to send Java objects though, since these can be extended with additional data attributes when necessary. For example, for our server actor we will implement two messages, CoapMessageReceived and ShutdownActor. These messages are simple Java objects which store data to be transmitted in the message. The implementation for our two messages looks like this:

// app/actors/messages/CoapMessageReceived.java
package actors.messages;
public class CoapMessageReceived {
  private String message;

  public CoapMessageReceived(String message) {
    this.message = message;
  }

  public String getMessage() {
    return message;
  }
}

// app/actors/messages/ShutdownActor.java
package actors.messages;
public class ShutdownActor {}

In our onReceive method we can now check which type of message we have received using instanceof. If the received message contains actual data we can then cast it to the correct type and call the defined getter methods, like so:

public void onReceive(Object message) throws Exception {

  if(message instanceof CoapMessageReceived) {
    CoapMessageReceived msg = (CoapMessageReceived) message;
    log.info("Received a message via CoAP: {}", msg.getMessage());

  } else if(message instanceof ShutdownActor) {
    log.info("Graceful shutdown");
    server.stop();
    getSelf().tell(akka.actor.PoisonPill.getInstance(), getSelf());

  } else {
    log.info("Unhandled message: {}", message);
    unhandled(message);
  }
}

One thing to note is the ShutdownActor case. In it, we first call server.stop() to shutdown the Californium server. In the following line we send a PoisonPill message to the current actor. This is a message provided by the Akka actor framework which instructs the actor to process all messages remaining in its inbox and then shut itself down.

Starting the actor

Now that we’ve created our actor we need to initialize it when the Play application starts. This is done by defining a Global object which handles global settings and startup routines in Play. For that, we create a Global.java inside the app/global/ directory (which we have to create), adding the following content:

package global;
[...]
public class Global extends GlobalSettings {

    private static ActorRef californiumActor;

    public void onStart(Application app) {
      californiumActor = Akka.system().actorOf(
        Props.create(CaliforniumServerActor.class)
      );
    }

    public void onStop(Application app) {
      californiumActor.tell(new ShutdownActor(), null);
    }

    public static ActorRef getCaliforniumActor() {
      return californiumActor;
    }
}

In the onStart method we create an instance of our Californium Server Actor and store the reference for later access. In onStop we send it a ShutdownActor message to gracefully shutdown the Californium server as well as itself. For a more in-depth explanation of how the Play integration of Akka works please refer to the Play documentation.

Normally Play expects the Global object to reside inside the app/ directory. Unfortuntately Java does not allow access to classes in the root namespace from other packages, which we will need later in order to obtain a reference to the server actor through the getCaliforniumActor getter. To work around this limitation we have to put the Global object in the global package (any name works though) and tell Play where to find it. We do this by adding the following line to the conf/application.conf:

application.global=global.Global

Example Californium Server

For this guide we have slightly modified the official Californium Hello World Server. The following section highlights our modifications. For the full class please refer to GitHub.

Just as in the Hello World example, our server class inherits from CoapServer:

// app/californium/CaliforniumServer.java
public class CaliforniumServer extends CoapServer {
    ActorRef serverActor;
    [...]
}

Instead of a static main(String[] args) method we use a static method that initializes the server, passing a reference to our server actor from the previous section, and returning the resulting instance:

public static CaliforniumServer initialize(ActorRef serverActor) {
  CaliforniumServer server = null;
  try {
    server = new CaliforniumServer(serverActor);
    server.start();
  } catch (SocketException e) {
    logger.error("Failed to initialize server: " + e.getMessage());
  }
  return server;
}

Then comes the constructor which registers our example CoAP resource and stores the reference to the server actor so that we can later send messages to it:

public CaliforniumServer(ActorRef serverActor)
  throws SocketException {

  this.serverActor = serverActor;
  add(new HelloWorldResource());
}

Lastly we define said resource as an inner class of the CaliforniumServer. The constructor of the CoapResource takes the resource name as a parameter, which in this case is helloWorld.

In order to send messages to the resource we still need to define a handler for one of the CoAP methods (GET, POST, PUT and DELETE). We don’t use GET (as the Californium HelloWorld example does) because it cannot have a payload.

class HelloWorldResource extends CoapResource {

  public HelloWorldResource() {
    super("helloWorld");
    getAttributes().setTitle("Hello-World Resource");
  }

  public void handlePUT(CoapExchange exchange) {
    serverActor.tell(
      new CoapMessageReceived(exchange.getRequestText()), null);
    exchange.respond(ResponseCode.CHANGED);
  }
}

In the handlePUT method we notify the server actor that a message has been received through a CoapMessageReceived instance containing the message’s paylod. The second parameter of tell is the sending actor. Since we’re not in an actor context and do not need to receive a response from the actor, we can simply pass null. Lastly we respond with the CHANGED response code which indicates that the request was successful but did not result in the creation of a new resource.

Testing locally

Now let’s test what we’ve built. In the Play project’s root directory, launch ./activator run (if it isn’t still running) and navigate to http://localhost:9000. This will initialize the Californium server and the actors, thus allowing us to receive CoAP messages.

To test that functionality we’ll be using Eclipse Copper, a Firefox plugin that adds coap:// URI support. After installing Copper and the server, we should be able to navigate to coap://localhost:5683/ and see the following screen:

We can see that Copper used the CoAP resouce discovery mechanism to list all the available resources that our server provides, which is just helloWorld. We can can proceed by clicking on that resource, entering something in the “Outgoing” textfield in the center of the screen and then click on the PUT icon at the top (we use the PUT method because that is how we have defined our resource handler). The expected result is that whatever you’ve entered into the “Outgoing” field now pops up in the console where you’ve started the Play application:

[INFO] [02/20/2015 17:12:08] [...] Received CoAP message: 'Success!'

Deploying the application to the Raspberry Pi

The last step we’ll have to take is to get our application deployed to Raspberry. This is relatively simple if you’ve set it up according to our previous post, “”, because Java comes pre-installed on recent releases of Raspbian.

To prepare our deployment we run ./activator stage. This will bundle the application inside the target/universal/stage directory relative to the project’s root. All we have to do then is rsync said directory to the Raspberry and run the application by changing into the stage directory on the Raspberry and running:

JAVA_OPTS="-Xmx64M -Xms16M -XX:PermSize=24M -XX:MaxPermSize=64M" \
    ./bin/play-californium

Note: If you’re deploying to a device that has e.g. Java 7 installed, but you built the application with Java 8, running it on the target will fail. To circumvent this, add the following to your build.sbt if necessary: javacOptions ++= Seq("-source", "1.7", "-target", "1.7"). This sets the Java compiler’s target version to Java 7.

This starts the Play application, which might take quite a while to spin up since the Raspberry isn’t the fastest of devices. The JAVA_OPTS that we’re passing limits the amount of memory the JVM uses. If Play has started successfully, it will display the following messags:

[info] play - Listening for HTTP on /0.0.0.0:9000

After that you should be able to test the Californium Server inside Play just as you’ve done locally, by entering the IP of your Raspberry into Firefox with the coap:// protocol prefix.

An upcoming post will explain how to forward the CoAP messages to the user’s browser through WebSockets and how to process CoAP messages and update a web interface in “realtime” based on the received data.

Sending small packets

Wed, 18 Feb 2015 00:00:00 +0000

In order to transfer data in the Internet of Plants, nodes need to know the type of interaction and its exact target: Did my neighbor just ask me for a specific information, or did they send unsolicited information? If so, which resource is this query or information about? Et cetera et cetera.

We could have defined our own way of communicating this information. We could have specified a suitable JSON-based interface of some sort or put the data into protocol buffers and prayed that they wouldn’t exceed the 81 bytes of payload the teeny-tiny MTU of IEEE 802.15.4 leaves us. We probably would have entered a world of pain.

Luckily, there is a better way of doing this: the Constrained Application Protocol (CoAP). It operates on the Application Layer and was designed to be a lightweight complement to HTTP. Because of this coupling, CoAP requests can be translated to HTTP requests and a subset of HTTP requests can be translated to CoAP. This is great for nodes that act as border routers (like our display node) and translate between IoT environments and the “big” internet.

Endpoints and Resources

All entities participating in the CoAP protocol are called “endpoints”. For our use case, these participants are the client and the server.

Note: Other participants include intermediaries such as proxies which are not discussed here.

Each endpoint is uniquely identified by a the triplet (IP, Port, Transport Layer Security), the latter two being optional, defaulting to 5683 and None respectively. Every type of information a CoAP endpoint has to offer is called a resource. These resources are identified by a Unique Resource Identifier (URI), which resembles (but is completely unrelated to) a filesystem path. With endpoint information included, a CoAP URI might look something like this:

coap://[fe80::c2ff:febc:139c]:1234/foo/bar

The IPv6 address and port identify the endpoint that provides the foo resource. bar is a sub-resource of foo.

Note: Literal IPv6 address in a URI have to be enclosed in [...] according to RFC 2732.

Request methods

When interacting with a CoAP resource, one of four “request methods” must be specified. The request method identifies the intent with which a resource is being accessed and each method has some inherent properties:

Note: A CoAP request is idempotent if you can invoke a request multiple times with the same effect. A request is safe if it does not change any state on the server.

Method	Semantics	Safe	Idempotent	Payload	Return Codes
GET	Retrieve the current state of a resource identified by the accessed URI.	✓	✓	𝗫	2.03 Valid, 2.05 Content
POST	A generic indicator for the recipient that the enclosed message should be processed, usually resulting in the creation of a new resource or the update of the target resource.	𝗫	𝗫	✓	2.01 Created, 2.02 Deleted, 2.04 Changed
PUT	Indicates that the target resource should be created or updated.	𝗫	✓	✓	2.01 Created, 2.04 Changed
DELETE	Requests that the target resource should be deleted.	𝗫	✓	𝗫	2.02 Deleted

Example

Let’s say we have a CoAP client C and a CoAP server S. Suppose node C wanted to know about the humidity status of the plant node S is watching over. S has the IP fe80::42 and runs a CoAP server which is listening on port 1234.

To retrieve the desired information, C may send the following request (request parameters are specified in Parameter: Value format in this example):

GET coap://[fe80::42]:1234/plant/humidity
Accept: 0

The Accept option indicates the desired response format. The value 0 stands for text/plain within the CoAP Content-Formats Registry (see RFC7252 12.3.).

S then answers with a 2.05 Content response, which is similar to HTTP’s 200 OK, and the requested value the response’s payload.

Implementations

Some implementations of the CoAP protocol can be found at coap.technology. For watr.li, we chose to use Californium to handle all things CoAP on our Display nodes, since it provides a nicely architected high-level abstraction over the CoAP protocol, which is exactly what we desired for our relatively powerful display node running a Raspberry Pi (in comparison to the SAM R21 based plant nodes). Since Californium runs inside of the JVM it also integrates nicely with the Play framework which we chose to implement our web interface.

On our plant nodes, we had the choice between microcoap and libcoap, as RIOT features both as an external package. libcoap is a more monolithic effort which not only sets the CoAP headers and payload in place, but also takes care of dispatching them. microcoap, on the other hand, gives the user a blob of data which they can then dispatch however they see fit. This decreases complexity and removes the need for additional socket-handling threads. This is why we chose to use microcoap on our plant nodes.

In our next series of posts, we will explain how to create, send and answer CoAP requests with both microcoap and Californium, so keep an eye out for updates!

Header image by Flickr user ДьюФрейм. Released under CC BY-ND 2.0.

Setting up the Border Router

Fri, 13 Feb 2015 00:00:00 +0000

Providing our office flowers with intelligent equipment to measure humidity and giving them the ability to form a network over IEEE 802.15.4 is all well and good. Unfortunately, this only creates a network amongst office flowers, which is separated from the internet.

To provide a connection between this network and the Internet, thus enabling Humans™ to know that they should water the plants, we need to setup a border router to evolve the network of plants to the Internet of Plants. This post explains how to prepare the border router components, for which we have chosen the Rasperry Pi with 6LoWPAN capabilities provided by the R-Idge USB router.

Installing Raspbian on the Raspberry Pi

First we need to download a recent version of Raspbian, a Linux distribution specifically made for the Raspberry Pi. This image will be flashed onto an SD Card to serve as the operating system. For this post we used Rasbian Debian Wheezy, version December 2014, which can be downloaded here. After the download finishes we follow the comprehensive guide on how to flash the image to the SD Card published by elinux.org, which covers Windows, OS X and Linux users.

Now we insert the freshly flashed SD Card into our RasPi, connect a monitor, plug in a keyboard and connect the RasPi to with the Internet using a good old ethernet cable.

When booting the Raspberry Pi, you will be presented with an initial configuration screen for basic setup of the operating system similar to the above. This screen includes the “Expand Filesystem” option which gives you read-write access to the entire SD card from within Raspbian. This one should be definitely selected. For a more detailed explanation on all options please check out elinux.org. After finishing the setup procedure, restarting and logging in, we are finally presented with (or similar):

Linux raspberrypi 3.12.35+ #730 PREEMPT Fri Dec 19 18:31:24 GMT 2014 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Jan 26 10:13:52 2015
pi@raspberrypi ~ $

Note: if you’ve chosen the graphical user interface, open a terminal (i.e. click the “black monitor” icon) to proceed. Of course this only works if you plugged in a mouse or similar. If not, you can hit CTRL+ESC to navigate through the Menu and choose Accessoirees > Terminal with the arrow keys and hit enter, which also opens a new terminal window.

To finish the initial installation, we do an update of Raspbian to get the most recent versions of the installed packages. To do this, we run in a terminal:

sudo apt-get update &&
    sudo apt-get upgrade &&
    sudo apt-get dist-upgrade

Warning: Running a dist-upgrade is a potentially destructive operation, so it is NOT recommended if you don’t have a dedicated installation of Raspian for this excercise.

The first line fetches all information for packages and available updates.
The second line updates the currently installed packages.
The third line installs new and updated packages, including kernel updates.

Now we have an up-to-date foundation of Raspbian to start setting up a border router!

Preparing the Internet of Plants

After the initial installation of Raspbian we need to configure it further to enable the Raspberry Pi to act as a border router. The first thing to be done is to enable IPv6. In the initial configuration of Raspbian only IPv4 handling is activated. We can check this by entering lsmod | grep ipv6 in a terminal. When IPv6 support is not activated, this command returns with no output. To load the IPv6 kernel module we enter sudo modprobe ipv6, which should return with no output if the loading succeeded. Entering lsmod | grep ipv6 again will present us with:

ipv6                  316254  20

indicating that the module is loaded. To load the module automatically at boot time we enter

:bash:
echo ipv6 | sudo tee -a /etc/modules

which appends ipv6 as last line to /etc/modules. The next time we boot, the ipv6 module will be loaded automatically.

Operating the R-Idge USB router

To provide connectivity to other IEEE 802.15.4 devices we use the R-Idge 6LoWPAN USB router. After the USB stick is plugged in, it should create a new available network interface called usb0. We can check this entering ifconfig usb0 which will provide us with information on the interface:

usb0      Link encap:Ethernet  HWaddr 02:12:4b:e4:0a:83
inet6 addr: fe80::12:4bff:fee4:a83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B)  TX bytes:2018 (1.9 KiB)

Note: if you are presented with (or similar):

pi@raspberrypi ~ $ ifconfig usb0
usb0: error fetching interface information: Device not found

the interface has probably received a different name from the operating system. You can list all available and active interfaces by entering ifconfig.

To verify if any of shown network interface is our R-Idge USB router, we enter dmesg -T | tail | grep RNDIS.
We will be presented with the following output:

[Mon Jan 26 12:39:27 2015] rndis_host 1-1.3.4:1.0 usb0: register 'rndis_host' at usb-bcm2708_usb-1.3.4, RNDIS device, 02:12:4b:e4:0a:83

We can then compare the shown hardware address (at the far end of the shown line) with the HWaddr presented in the first line of the entered ifconfig command. If the addresses match everything is fine and we can move on to configure our R-Idge 6LoWPAN USB router.

Configuring the R-Idge 6LoWPAN router

To configure the router, we need to use the provided Configuration program from Rosand Technologies. Unfortunately the provided binary/installation packages are not compiled for being used on the Raspbian, so we need to build them from source. For the build we need to install the tools required to build the source by entering

sudo apt-get install bison flex wget

After bison and flex are installed we can proceed to build the configuration program:

wget http://rosand-tech.com/downloads/cfgtool-1.00.tar.gz &&
    tar -xvzf cfgtool-1.00.tar.gz &&
    cd cfgtool-1.00 &&
    ./configure &&
    make

After the build finishes, we create a new directory for the compiled binary (mkdir ../cfgtool-bin), and copy the relevant files there by entering

cp cfgtool ../cfgtool-bin/ &&
    cp cftool.conf ../cfgtool-bin/

Now we change the directory to cd ../cfgtool-bin and configure our R-Idge USB router. To have a look in the current setup of the R-Idge USB router, we enter

./cfgtool -p ridge \
          -c serial \
          -C ./cfgtool.conf \
          -U channel:r: \
          -U power:r: \
          -U panid:r: \
          -U prefix:r:

This will present us with the following (or similar):

channel = 21
power = 21
panid = 0x3e9
prefix = 3

The most interesting values here are the channel and the panid. These values must both be the same for all communication participants, i.e. the R-Idge router and any node in the network. To change these values we set the according parameters to write (exchange :r: with :w: in the command above) and provide an appropriate value, e.g we set channel to 22 and the panid to 0x123:

./cfgtool -p ridge \
          -c serial \
          -C ./cfgtool.conf \
          -U channel:w:22: \
          -U panid:w:0x123:

Which should result in the following output:

cfgtool: 1 bytes of channel written
cfgtool: verifying channel memory:
cfgtool: reading on-chip channel data:
cfgtool: verifying ...
cfgtool: 1 bytes of channel verified
cfgtool: 2 bytes of panid written
cfgtool: verifying panid memory:
cfgtool: reading on-chip panid data:
cfgtool: verifying ...
cfgtool: 2 bytes of panid verified

Reading the configuration again (as done above) reveals that the new values are set:

channel = 22
power = 21
panid = 0x123
prefix = 3

Note: These values are examples. You need to make sure that whatever you set in the configuration tool for the R-Idge router matches the parameters that you set in your RIOT application and/or other hardware which might want to communicate with the border router.

Next steps

This concludes the basic setup of the R-Idge router on the Raspberry Pi. Now that we have both the SAM R21 and the Rasperry Pi set up, the next step is to establish communication between both devices, which will be the topic of an upcoming post. So stay tuned :smile:

The Atmel SAM R21

Mon, 09 Feb 2015 00:00:00 +0000

For the internet of plants, we have decided to use the Atmel SAM R21, a Cortex M0 based platform with an on-board IEEE 802.15.4 wireless module, to monitor our green friends. This post explains the general process of setting up a development environment for RIOT applications on Ubuntu 14.10, taking into account the peculiarities of the SAM R21 board.

Package requirements

The following packages are needed to build the necessary tools and the RIOT application:

General: git, pkg-config, autoconf, libtool, unzip
OpenOCD: libudev-dev, libusb-1.0-0-dev

They can be installed through apt by running

sudo apt-get install git pkg-config autoconf \
    libudev-dev libusb-1.0-0-dev libtool unzip \
    valgrind

In addition it is recommendable to update Ubuntu to the latest version after installing, by invoking

sudo apt-get update &&
    sudo apt-get dist-upgrade

Warning: Running a dist-upgrade is a potentially destructive operation, so it is NOT recommended if you don’t have a dedicated installation of Ubuntu 14.10 for this excercise.

Building OpenOCD

The Open On-Chip-Debugger (OpenOCD) is used by the RIOT build system for flashing the application onto the board and to debug it. The current release (v0.8.0) of OpenOCD, however, does not contain configuration files for the SAM R21 board, so it has to be built from source. OpenOCD also requires hidapi, which is not available as a package on Ubuntu 14.10. The following script will clone, build and install hidapi if all goes well:

TMP=$(mktemp) &&
    rm -r $TMP &&
    mkdir -p $TMP &&
    cd $TMP &&
    git clone http://github.com/signal11/hidapi.git &&
    cd hidapi &&
    ./bootstrap &&
    ./configure &&
    make &&
    sudo make install &&
    sudo ln -s /usr/local/lib/libhidapi-hidraw.so.0 \
        /usr/lib/libhidapi-hidraw.so.0

Now that all requirements are installed, OpenOCD can be built:

TMP=$(mktemp) &&
    rm -r $TMP &&
    mkdir -p $TMP &&
    cd $TMP &&
    git clone https://github.com/watr-li/OpenOCD.git openocd &&
    cd openocd &&
    ./bootstrap &&
    ./configure --enable-maintainer-mode \
                --enable-cmsis-dap \
                --enable-hidapi-libusb &&
    make &&
    sudo make install

Installing the toolchain

The 64-bit version of the “GNU Tools for ARM Embedded Processors” toolchain (as recommended in the RIOT wiki) can be installed via apt using the following script.

sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi &&
    sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded &&
    sudo apt-get update &&
    sudo apt-get install gcc-arm-none-eabi=4.9.3.2015q1-0utopic14

Note: A warning could be displayed that there are conflicting package names with the Debian apt repositories. That warning is already taken into consideration here and you can safely proceed by pressing enter.

Building a RIOT example application

Now that all the requirements are set up, a RIOT-based application can be built. Cloning RIOT (via github.com/RIOT), switching to the directory of the example hello world application and building it is performed by the following script:

git clone https://github.com/RIOT-OS/RIOT.git &&
    cd RIOT/examples/hello-world &&
    export BOARD=samr21-xpro &&
    make

The only non-standard line here is the definition of the BOARD environment variable which tells the RIOT build system which hardware we are targeting.

Preparations for flashing

In order to be able to flash the application onto the board without root privileges, a couple of additional customizations are necessary. First we need to add our user do the dialout group by running the following command:

sudo usermod --append --groups dialout <our username>

This is required in order to capture the output from the board’s serial console, which is mounted as /dev/ttyACM[0-9]+ and belongs to the dialout group by default.

Note: You need to re-login after adding the user to the group.

Secondly we need to instruct udev, the device manager, to allow access to the kernel devices created by the hidapi. We do this by creating a new file 99-hidraw-permissions.rules in the /etc/udev/rules.d directory with the following content:

KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0664", GROUP="plugdev"

Note: After adding the udev permission you have to re-connect the board for the changes to take effect.

Flashing and running the application

The next step is to get the application onto the board, run it and see the output it produces. The RIOT build system is already configured to do all of this for the SAMR board, under the assumption that OpenOCD is installed. For this we need two separate terminals: one where the command to flash the board is invoked and the other where the output from the board is displayed.

Setting up the output terminal

In this terminal we start a pyterm instance, a serial port terminal emulator written in Python, listening to the output of the board:

export BOARD=samr21-xpro &&
    make term

This should result in the following being printed, after which pyterm waits for output from the board:

INFO # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.

Running the flash command

Now we can switch to the other terminal window in which we will invoke the commands to flash the application onto the board:

export BOARD=samr21-xpro &&
    make flash

The CMSIS-DAP interface for flashing and debugging is quite slow (should be around 2KiB/s). So when flashing, you might need to wait a little longer. You can also apply an OpenOCD patch that increases flashing speed by 50-100%.

make flash flashes and subsequently resets the board, causing the application to run. For our hello world example it should result in the following output being shown in the terminal window in which make term was executed:

INFO # kernel_init(): This is RIOT! (Version: 2014.12-285-gfe295)
INFO # kernel_init(): jumping into first task...
INFO # Hello World!
INFO # You are running RIOT on a(n) samr21-xpro board.
INFO # This board features a(n) samd21 MCU.

Bonus: RIOT native mode

In addition to running the application directly on the target hardware, RIOT also features a target called native, which runs the application inside the host operating system. This is especially useful when flashing the devices is comparatively slow, as is the case for the SAM R21 board.

If you want to use native mode, the only thing required is a 32-bit version of libc installed on the system:

sudo apt-get install libc6-dev-i386

After installing this dependency you can then return to the directory of the example hello world application and invoke

export BOARD=native &&
    make &&
    make term

For native mode, the build system creates a 32-bit binary in the bin/native directory. The only thing make term then has to do is running that binary. You should see the same output as when running the application on the board, except for the board’s name and the MCU.

That’s all, folks!

Now that the development environment for RIOT has been set up and applications can be flashed onto the board, you’re ready to develop your first RIOT-based IoT application!

For more information about RIOT on the SAM R21, please visit the wiki page for the board in the RIOT repository. If you have any questions on the setup procedure or if anything is not working quite right, please leave a comment!

This article is based on a great post by David Karibe on setting up an open-source development toolchain for the Freescale FRDM-KL25Z board.

Starting a RIOT in the Internet of Plants

Thu, 05 Feb 2015 00:00:00 +0000

Battery powered embedded devices such as our plant nodes lack the hardware resources to support common operating systems such as Linux or Windows. In addition, they have very different requirements: our plant nodes do not need a snappy graphical user interface or have to be able to host hundreds of applications simultaenously. What they do need is an operating system that is energy and memory efficient and features low-power wireless connectivity based on open standards.

Operating Systems such as Contiki, TinyOS or RIOT are designed to operate in the challenging environment of interconnected embedded devices, differing mainly in kernel architecture and the programming models that are employed for application development. This article explains our motivation for choosing RIOT over its alternatives.

Why we chose RIOT.

RIOT is an actively maintained Open Source project with a growing, friendly community. It features a network stack based on open standards, namely 6LoWPAN and IEEE 802.15.4. The latter offers an energy-efficient physical and MAC layer while the former adapts conventional IPv6 to IEEE 802.15.4’s constraints in terms of packet size through fragmentation and header compression (among other techniques). And since RIOT is a microkernel OS, we can specifically include only the features we need, shaving valuable bytes off of our memory footprint.

Event-based operating systems such as Contiki or TinyOS have adopted a programming model that differs from conventional C applications and only support a subset of the C language (Contiki) or provide a C dialect (TinyOS) for application development. RIOT, in contrast, offers a “traditional” threading and scheduling scheme, POSIX-compliance as well as C and (currently partial) C++ language support. This means that if you’re familiar with standard C, you won’t have to adapt to new coding paradigms to write applications for RIOT and can dive right in. It also makes it possible to port existing code, which was originally written for “traditional”, commodity operating systems, to RIOT with just a few patches, allowing for the inclusion of existing external libraries (provided there are no license clashes).

RIOT’s “native mode” makes it possible to run RIOT applications on a POSIX-compliant operating system such as Linux or OS X for testing and debugging. It is even possible to run multiple instances of RIOT applications on the same host, with communication between them enabled through virtual network devices (i.e. tun/tap). This enables a much faster feedback loop when developing and testing applications, but can prove tricky if constraints of the target hardware are not taken into account when developing primarily in native mode.

Summing up, RIOT has so far proven to be a great foundation for the development of our plant nodes and we hope to be able to contribute to RIOT’s progress with our efforts on watr.li. Since development on RIOT is an ongoing effort, some development aspects are still a little rough around the edges. A lot of work is still ahead of us, but we are confident that the growing number of awesome contributors will continue making RIOT a successful open-source option for IoT operating systems.

Last but not least it is worth mentioning that Snappy Ubuntu Core is collaborating with RIOT, which will come in handy when delivering RIOT-based applications to more homogeneous networks which include nodes with increased computing power and energy resources, for which Snappy may prove to be a better fit.

In the interest of full disclosure: All four watr.li contributors use RIOT on a more or less regular basis, either at work and/or for university projects. We are all active RIOT contributors.

Workshop Prepration

Thu, 29 Jan 2015 00:00:00 +0000

For the workshop we will assume that you are familiar with the basics of the following:

Using a linux terminal
The C programming language

However, first and foremost, we’re here to learn and help each other. You don’t have to know everything in order to be able to participate. If you’re unsure about anything, or feel that you’d like some help, please do not hesitate to ask the RIOT team. We know that it may be a lot to grasp at once, and we’re happy to answer all questions, no matter how trivial they may seem.

Development environment

RIOT requires you to install and compile some dependencies. We’ve prepared a VMware Virtual Machine which is all set up and ready to go. We will distribute said virtual machine via USB sticks at the beginning of the workshop. To use it, you will need to have VMware installed on your system. Trials are available at vmware.com.

In case you prefer to set everyting up yourself, you can follow this guide up until (but not including) the section “Building a RIOT example application”.

RIOT does have experimental Windows support. If you’d prefer to use Windows as your host system, you can consult this guide, but it doesn’t cover how to flash an application. However, a word of warning: you probably know much more about your Windows machine than we do, and we might not be able to help you in case you run into trouble.

We are looking forward to seeing you at the workshop! If there are any preliminary questions about the workshop, feel free to ping us on Twitter or drop us an email to xoxo@watr.li.

Workshop Guide

Thu, 29 Jan 2015 00:00:00 +0000

Grenoble RIOT Workshop Guide

For the workshop we will assume that you are familiar with the basics of the following:

Using a linux terminal
The C programming language

Development environment

In case you prefer to set everyting up yourself, you can follow this guide up until (but not including) the section “Building a RIOT example application”.

Tip: SSH & sshfs for your VM

While our VM has a GUI, this can be annoyingly slow. Alternatively, you can use sshfs to mount your VM’s home directory as if it were a regular directory on your host system:

sshfs riot@ip.of.your.vm:/home/riot some_directory/

(get your VM’s IP by launching the Terminal application and entering ifconfig eth0)

You can then ssh onto your VM and run all make, flash etc commands from your host system’s terminal:

ssh riot@ip.of.your.vm:/home/riot

Getting started with RIOT

Now that you’re well-prepared, let’s get you started! The goal of this section is to show you how to build and flash a RIOT application.

Building a RIOT app

Checking out the RIOT repository work like follows. We’ve used a fork of the main RIOT repository to work around a memory issue on the SAM R21 that has not yet been merged to the RIOT master.

git clone https://github.com/watr-li/RIOT.git &&
    cd RIOT &&
    git checkout workshop &&
    cd ..

Now that we have checked out the RIOT repository, we can fetch some example applications:

git clone https://github.com/watr-li/applications.git &&
cd applications &&
git checkout master

Now we’re inside the applications/ folder and we can try to build our first application, the chat:

cd chat &&
    make all

Running it in native mode

You can run and test an application on your own computer with the native mode. The network is emulated through tun/tap devices which are connected through a tapbridge. This bridge has to be created beforehand:

RIOT/cpu/native/tapsetup.sh create

Now you can start your RIOT application in native mode:

make term

In a new terminal, start another RIOT, this time listening on tap1:

PORT=tap1 make term

(Note that make term only works if you’ve previously built your application. For non-native mode it will try to open up a serial connection to the hardware.)

Type help to see all commands available in the RIOT shell.
Use the say command in one RIOT shell to send a string to the other RIOT instance. If it arrives, you’re ready to go!

Flashing it to the SAMR21

Attach your SAM R21 board via microUSB. You’ll need two terminals for this: one for flashing and one to view the debug output.

Setting up the output terminal

In this terminal we start a pyterm instance, a serial port terminal emulator written in Python, listening to the output of the board:

export BOARD=samr21-xpro &&
    make term

This should result in the following being printed, after which pyterm waits for output from the board:

INFO # Connect to serial port /dev/ttyACM0
Welcome to pyterm!
Type '/exit' to exit.

Running the flash command

Now we can switch to the other terminal window in which we will invoke the commands to flash the application onto the board:

export BOARD=samr21-xpro &&
    make flash

The CMSIS-DAP interface for flashing and debugging is quite slow (should be around 3-5KiB/s). So when flashing, you might need to wait a little longer. You can also apply an OpenOCD patch that increases flashing speed by 50-100%.

make flash flashes and subsequently resets the board, causing the application to run. For our hello world example it should result in the same output you’ve already seen in the native version of the application.

You can play around with the application, send messages to the other workshop participants over UDP and see if their messages arrive on your board!

Adding your own code

Now that you’re familiar with RIOT, it’s time to add your own code. At the end of this tutorial, you’ll have built a distributed chat application which lets you communicate with the other workshop participants. All chat messages will be sent over CoAP, and the resource the CoAP messages are targeting determines the chat channel you’re in.

`nick`: add your own shell command

Goal: Create a shell command nick <nickname> which lets you set your nickname.

RIOT has a shell implementation which can be extended with your own commands. To do this, you’ll have to extend the shell_commands[] array with your own shell_command_t, which is defined as follows:

/**
 * @brief           A single command in the list of the supported commands.
 * @details         The list of commands is NULL terminated,
 *                  i.e. the last element must be ``{ NULL, NULL, NULL }``.
 */
typedef struct shell_command_t {
    const char *name; /**< Name of the function */
    const char *desc; /**< Description to print in the "help" command. */
    shell_command_handler_t handler; /**< The callback function. */
} shell_command_t;

For your first step towards chatting with RIOT, write a function that lets you set your nickname. Then, add a shell_command_t which lets you call this function from your RIOT shell with the command nick <nickname>.

Re-build your application with make (in native mode) and try your new shell command by executing the binary with:

make term

`say`: send chat messages

Goal: Create a shell command say <message> which sends a chat message. The message should be in the payload of a CoAP PUT request directed at the resource chat/default/. The message should be prepended with your nick.

Now that you can set your nick name, let’s send some chat messages!
Again, we’ll need to add a say <message> command to the shell.
Each message should be wrapped into a CoAP PUT request. CoAP requests are– just like HTTP requests– directed at a resource. The default resource for our messages is chat/default/.

In microcoap, resources are represented by the following struct:

typedef struct
{
    int count;
    const char *elems[MAX_SEGMENTS];
} coap_endpoint_path_t;

Each element of coap_endpoint_path_t.elems should be one segment of the path, like so:

coap_endpoint_path_t chat_path = {2, {"chat", "default"}};

The payload of the PUT request is our chat message. In order to make it identifiable, make sure to prepend it with your nickname, like so:

"my_nick: hello"

Once you’ve created your payload, you can use int coap_ext_build_PUT(uint8_t *buf, size_t *buflen, char *payload, coap_endpoint_path_t *path) to build your put request. Now, you can use chat_udp_send() to send the content of buf.

(For the sake of simplicity, all messages are sent to the link-local all nodes multicast address by chat_udp_send())

If you want to send messages wich contain spaces, the shell will recognize each word as a single argument, so you can have different values for argc and argv. Bonus points for concatenating them!

Receive messages

The base application contains a chat_udp_server_loop() which receives plain UDP mssages. However, our chat messages aren’t plain text anymore, they’re CoAP packets now. So instead of just printing the contents of buffer_main, you’ll need to handle these packets properly. We’ll be doing this with microcoap too.

For a more detailed explanation of microcoap servers, please visit this page.

First, you’ll need to specify an endpoint which specifies for which combinations of request method and resource path a certain callback function should be called. Endpoints are defined as follows:

typedef struct
{
	coap_method_t method;
	coap_endpoint_func handler;
	const coap_endpoint_path_t *path;
	const char *core_attr;
} coap_endpoint_t;

All endpoints need to be stored in an array which must be called endpoints and end with a NULL’ed script. It should look something like this:

const coap_endpoint_t endpoints[] =
{
	{COAP_METHOD_GET, handle_get_response, &path, "ct=0"},
	{(coap_method_t)0, NULL, NULL, NULL} /* marks the end of
    	                                  * the endpoints array */
};

But keep in mind that we’re expecting to handle a PUT request! ;)
Now you can implement the callback function handling the CoAP packet (which is called handle_get_response in the above).
After doing that, you’ll need to teach chat_udp_server_loop how to understand CoAP messages:

if (0 != (rc = coap_parse(&pkt, buf, n)))
    printf("Bad packet rc=%d\n", rc);

checks whether the packet we received is actually a valid CoAP packet.

else
{
    size_t rsplen = sizeof(buf);
    coap_packet_t rsppkt;
    printf("content:\n");
    coap_dumpPacket(&pkt);
    coap_handle_req(&scratch_buf, &pkt, &rsppkt);

And that’s it! We’ve now successfully received and processed a CoAP request.

`join`: change channels

Goal: Create join <channel name> command that changes the second segment of our resource path. Send chat messages to resources other than chat/default

Many chat applications have topic-specific channels. Our chat application can do this too: Up until now, we’ve all been sending our messages to chat/default/. But when we change the resource to, say, chat/IoT/, we can create a new channel on the fly (to discuss all things IoT, for example).

The Internet of Plants: turning your collective black thumb green

Fri, 16 Jan 2015 17:05:58 +0000

Keeping plants alive in an office without regular hours is hard: Either everybody thinks their colleagues have already watered the plants or multiple people water the same plant, resulting in either drought or overhydration. This can be solved with technology: If each plants’ humidity status is displayed publicly, co-workers can take matters into their own hands without fear of interfering with an absent colleagues’ plant-watering scheme.

This blog documents our journey towards the realization of such a system, dubbed the Internet of Plants (IoP).

How does it work, exactly?

To the end user, the IoP consists of two different entities: one sensor node per plant, which is plugged into its flower pot, and a web interface, which is maintained by the so-called display node. The IoP is self-configuring. That means the user won’t have to re-flash their nodes when they change plants, or register each new plant with the IoP. Whenever a new plant is detected in the IoP, the web interface will show a new, blank spot for this plant. Now, the humidity needs and a picture of the plant can be added by the user, and that’s it.
A plant has three statuses: happy, okay or thirsty. Whenenver a member of the IoP feels thirsty, it will send a tweet and/or E-Mail. After it has been watered, it will tweet and/or E-Mail again to prevent overhydration. Additionally, the status of all plants can be checked through the web interface. This way, users can see that they should water an “okay” plant before a long weekend even though it did not cry for help yet.

Protocol stack

Hard- and Software

Plant nodes

For the plant nodes, we chose to use the Atmel SAM R21 boards equipped with a DFROBOT SEN0114 humidity sensor because it is robust against oxidation caused by moist soil and said to be suitable for plant-monitoring.
All plant nodes run RIOT, an embedded Operating System designed for the Internet of Things, featuring a network stack running 6LoWPAN over IEEE 802.15.4. Plant nodes will have an application which registers them with the IoP, reads their humidity sensor and reports back to the display node using CoAP.
The SAM R21 board is somewhat costly, so it might not be ideal for others that don’t happen to have some lying around. However, the beauty of RIOT is that the base code can be re-used: As long as there is a RIOT port for the board you want to use, all it takes is one changed line in the Makefile to deploy the IoP code on it.

Display node

The display node is a Raspberry Pi. It manages all plants, collects their humidity statuses and posts changes to the web interface. To accomplish this, it serves as a web server and runs Californuim. All CoAP messages received through Californium are handled and passed to the server if need be.
The display node also functions as the border router, connecting our Internet of Plants to the “big” internet. To do this, it is equipped with both an Ethernet connection to the internet and a R-IDGE 6LoWPAN USB Router for communication with the plant nodes.

Code

All of our code can be found on github.

Impressum

Thu, 01 Jan 2015 00:00:00 +0000

If you’re wondering what this is: German law requires you to provide all of the following information as the owner of a Website. It’s the future!

Impressum

Angaben gemäß § 5 TMG:

Lucas Jenß
Am Genesungsheim 2
21527 Kollow, Kurheim

Kontakt

E-Mail: public [at] x3ro [dot] de

Verantwortlich für den Inhalt nach § 55 Abs. 2 RStV:

Lucas Jenß
Am Genesungsheim 2
21527 Kollow, Kurheim

Haftungsausschluss (Disclaimer)

Haftung für Inhalte

Als Diensteanbieter sind wir gemäß § 7 Abs.1 TMG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 TMG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.

Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden von entsprechenden Rechtsverletzungen werden wir diese Inhalte umgehend entfernen.

Haftung für Links

Unser Angebot enthält Links zu externen Webseiten Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar.

Eine permanente inhaltliche Kontrolle der verlinkten Seiten ist jedoch ohne konkrete Anhaltspunkte einer Rechtsverletzung nicht zumutbar. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Links umgehend entfernen.

Urheberrecht

Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. Downloads und Kopien dieser Seite sind nur für den privaten, nicht kommerziellen Gebrauch gestattet.

Soweit die Inhalte auf dieser Seite nicht vom Betreiber erstellt wurden, werden die Urheberrechte Dritter beachtet. Insbesondere werden Inhalte Dritter als solche gekennzeichnet. Sollten Sie trotzdem auf eine Urheberrechtsverletzung aufmerksam werden, bitten wir um einen entsprechenden Hinweis. Bei Bekanntwerden von Rechtsverletzungen werden wir derartige Inhalte umgehend entfernen.

Datenschutz

Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. Wir behandeln Ihre personenbezogenen Daten vertraulich und entsprechend der gesetzlichen Datenschutzvorschriften sowie dieser Datenschutzerklärung.

Die Nutzung unserer Webseite ist in der Regel ohne Angabe personenbezogener Daten möglich. Soweit auf unseren Seiten personenbezogene Daten (beispielsweise Name, Anschrift oder E-Mail-Adressen) erhoben werden, erfolgt dies, soweit möglich, stets auf freiwilliger Basis. Diese Daten werden ohne Ihre ausdrückliche Zustimmung nicht an Dritte weitergegeben.

Wir weisen darauf hin, dass die Datenübertragung im Internet (z.B. bei der Kommunikation per E-Mail) Sicherheitslücken aufweisen kann. Ein lückenloser Schutz der Daten vor dem Zugriff durch Dritte ist nicht möglich.

Server-Log-Files

Der Provider der Seiten erhebt und speichert automatisch Informationen in so genannten Server-Log Files, die Ihr Browser automatisch an uns übermittelt. Dies sind:

Browsertyp/ Browserversion
verwendetes Betriebssystem
Referrer URL
Hostname des zugreifenden Rechners
Uhrzeit der Serveranfrage

Diese Daten sind nicht bestimmten Personen zuordenbar. Eine Zusammenführung dieser Daten mit anderen Datenquellen wird nicht vorgenommen. Wir behalten uns vor, diese Daten nachträglich zu prüfen, wenn uns konkrete Anhaltspunkte für eine rechtswidrige Nutzung bekannt werden.

Einbindung von Diensten und Inhalten Dritter

Es kann vorkommen, dass innerhalb dieses Onlineangebotes Inhalte Dritter, wie zum Beispiel Videos von YouTube, Kartenmaterial von Google-Maps, RSS-Feeds oder Grafiken von anderen Webseiten eingebunden werden. Dies setzt immer voraus, dass die Anbieter dieser Inhalte (nachfolgend bezeichnet als "Dritt-Anbieter") die IP-Adresse der Nutzer wahr nehmen. Denn ohne die IP-Adresse, könnten sie die Inhalte nicht an den Browser des jeweiligen Nutzers senden. Die IP-Adresse ist damit für die Darstellung dieser Inhalte erforderlich. Wir bemühen uns nur solche Inhalte zu verwenden, deren jeweilige Anbieter die IP-Adresse lediglich zur Auslieferung der Inhalte verwenden. Jedoch haben wir keinen Einfluss darauf, falls die Dritt-Anbieter die IP-Adresse z.B. für statistische Zwecke speichern. Soweit dies uns bekannt ist, klären wir die Nutzer darüber auf.

Auskunft, Löschung, Sperrung

Sie haben jederzeit das Recht auf unentgeltliche Auskunft über Ihre gespeicherten personenbezogenen Daten, deren Herkunft und Empfänger und den Zweck der Datenverarbeitung sowie ein Recht auf Berichtigung, Sperrung oder Löschung dieser Daten. Hierzu sowie zu weiteren Fragen zum Thema personenbezogene Daten können Sie sich jederzeit an die oben genannte E-Mail Adresse wenden.

It's a wrap!

Presenting watr.li

Technologies used

Open source software and open standards

Hardware

What we’ve learned

The plant node side of life

On the dashboard side

Future work

Battery life experience

Custom plant node cases

Extended sensing

Plant-to-plant coordination

Plant-to-thing coordination

That’s all (for now), folks!

Sensing the humidity of a plant's soil

Calibrating the ADC

Running the test application

Setting up the offset correction

Setting up the gain correction

Calculating the gain

Final setup

Serving CoAP on RIOT

Implementing a small microcoap server

The Makefile

endpoints.c

microcoap_conn.c

Testing your microcoap server

Using Copper as a test client

radvd: making RIOT available to Copper

Using Copper

Californium meets the Play Framework

Creating a Play application

Adding Eclipse Californium

Starting a Californium Server

The Californium Server Actor

Starting the actor

Example Californium Server

Testing locally

Deploying the application to the Raspberry Pi

Sending small packets

Endpoints and Resources

Request methods

Example

Implementations

Setting up the Border Router

Installing Raspbian on the Raspberry Pi

Preparing the Internet of Plants

Operating the R-Idge USB router

Configuring the R-Idge 6LoWPAN router

Next steps

The Atmel SAM R21

Package requirements

Building OpenOCD

Installing the toolchain

Building a RIOT example application

Preparations for flashing

Flashing and running the application

Setting up the output terminal

Running the flash command

Bonus: RIOT native mode

That’s all, folks!

Starting a RIOT in the Internet of Plants

Why we chose RIOT.

Workshop Prepration

Development environment

Workshop Guide

Grenoble RIOT Workshop Guide

Development environment

Tip: SSH & sshfs for your VM

Getting started with RIOT

Building a RIOT app

Running it in native mode

Flashing it to the SAMR21

Setting up the output terminal

Running the flash command

Adding your own code

nick: add your own shell command

say: send chat messages

Receive messages

`nick`: add your own shell command

`say`: send chat messages

`join`: change channels