2 months of watr.li: presentation, conclusion and outlook.
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.
Setting up the sensor with the SAM R21
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.
Building a small microcoap server tested with Copper
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.
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.
And they have Raspberries for dinner!
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 non RFC-writers guide to CoAP
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.
R-Idge 6LoWPAN router meets the Rasperry Pi
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.
Setting up a RIOT development environment
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.
An operating system choice for low-power embedded devices
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.
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).