It's a wrap!

2 months of presentation, conclusion and outlook.

In the last couple of weeks, we have been working hard on 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


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 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

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.

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’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.
To adapt our IPv6 packets to the the restrictions of our IEEE802.15.4 transceiver, we used a 6LoWPAN adaption layer.
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.


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 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 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, 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 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, 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 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 What are the things we could’ve done better, or differently?