1 Watr.li – Developing a showcase application for the RIOT operating system Lucas Jenß [email protected] Lotte Steenbrink [email protected] F 1 INTRODUCTION relatable, and a table full of flowers and hardware can help spark the curiosity of passers by. The Internet of Things (IoT) is a promising The remainder of this paper is structured as follows. paradigm capable of changing the way we in- An outline of the use case for the system presented teract with the world– and the way it interacts in this paper is given in Section 2. Section 3 explores with us. It describes the vision of small sensors the literature pertaining to the use case, followed and computers embedded into everyday objects, by an introduction of the main open standards which autonomously communicate with each other, used (Section 4). The system concept, beginning the Internet, and their surroundings. Since those at the hardware layer and working its way to the embedded devices are typically very constrained application layer, is presented in Section 5. This is in memory as well as computation and energy followed by a description of the implementation of capacities, operating systems powering them must the aforementioned concept (Section 6) as well as be lightweight, energy-efficient and possess a small the issues found and insights gained during that memory footprint. RIOT [1], an Operating System phase (Section 7). Finally, the community building (OS) for the Internet of Things, was designed with aspects of the project are outlined in Section 8, these criteria in mind. And while the development concluding the paper with an outlook and future on the operating system is thriving, it is lacking on work in Section 9. the application side. All existing demo applications focus on technical details, which are often hard to 2 TOWARDS THE INTERNET OF PLANTS communicate and less eye-catching for the broader public. Additionally, experiences with operating a Keeping plants alive in an office without regular network of RIOT nodes in a long-term, real world hours is hard. Either everybody thinks their col- scenario are sparse. leagues have already watered the plants or mul- To patch these gaps, this paper presents a RIOT- tiple people water the same plant, resulting in based plant monitoring application which can be either drought or overhydration. This can be solved shown at fairs, used in workshops, extended and with technology: If each plant humidity status is referenced for new projects. Using IoT hardware displayed publicly, co-workers can take matters and sensors, the wellbeing of plants can be moni- into their own hands without fear of interfering tored and communicated to the user through a web with an absent colleagues’ plant-watering scheme. interface. This is challenging in terms of network- Over the course of this paper, such a system, ing, used standards, heterogeneity of hardware and dubbed “Watr.li” (pronounced “waterli”) will be covers a broad array of RIOT features. The diverse introduced. nature of the setup also shows domain experts how To the end user, Watr.li consists of two different RIOT integrates with other IoT technologies such as entities: one wireless sensor node per plant, which IEEE 802.15.4, 6LoWPAN, and CoAP. Additionally, is plugged into its flower pot, and a web interface it makes RIOTs capabilities approachable and visi- which displays the status of monitored plants. Be- ble to observers of varying technical knowledge. To cause Watr.li should make life easier for the user, it many people, the problem of keeping plants alive is should require minimal installation effort and thus 2 be self-configuring. This means the user will not 4 TECHNOLOGIES have to re-program their nodes when they change plants, or register each new plant with the Watr.li The difference between Watr.li and existing solu- network. Whenever a new plant is detected by tions presented in Section 3 is that Watr.li relies Watr.li, the web interface will show a new, blank exclusively on Open Standards and Open Source spot for this plant. Now, the humidity needs and a software to achieve its goals. The main technolo- picture of the plant can be added by the user. gies that were employed in the Watr.li project are introduced in this section. A plant has three statuses: happy, okay or thirsty. Whenever a member of the Watr.li network feels IEEE 802.15.4 The IEEE 802.15.4 standard specifies thirsty, it will send a tweet and/or E-Mail. After it the physical (PHY) and media access control has been watered, it will tweet and/or E-Mail again (MAC) layers for low-rate wireless communi- to prevent overhydration. Additionally, the status of cation in personal area networks [7]. It was all plants can be checked through the web interface. specifically designed for embedded devices: its This way, users can see that they should water an hardware is cheap to produce, energy efficient “okay” plant before a long weekend even though and uses small packets – with a frame size of its humidity status has not dropped to thirsty yet. 128 bytes, only 81 bytes of payload are left to the upper layers. For comparison: the size of a IPv6 base header alone is 40 bytes. 3 RELATED WORK 6LoWPAN To adapt all IPv6 packets to the re- strictions of an IEEE802.15.4 transceiver, a Over the course of less than ten years, availability 6LoWPAN [8] adaption layer was used. This of hardware targeted at Wireless Sensor Network adaption is achieved through compression (WSN) has increased while costs have decreased of IP headers down to 3 bytes and packet significantly. This has increased the range of op- (de)fragmentation, if necessary. portunities for WSN, with plant monitoring being but one of the many opportunities. In large-scale RPL The Routing Protocol for Low Power and agricultural irrigation, water usage is reduced on Lossy Networks (RPL) [9] is specifically de- the basis of sensor data, which is collected and signed for networks in which all traffic is di- transmitted with the help of WSN [2, 3]. Large- rected towards one central, strong node, the scale pastures can be monitored in order to improve root node. RPL achieves this by generating a irrigation schemes with the use of a low-cost Tmote Destination Oriented Directed Acyclic Graph Sky based system, as presented by [4]. (DODAG) topology which originates at the But with decreasing cost, applications in a smart root node. Routes to the root node are then es- home context are also becoming economically vi- tablished via parent node, i.e. each node sends able. For example, a WSN based system for gar- its data to a parent which is located closer to den watering built with TinyOS on TelosB motes the root node in the tree topology. The data is (ZigBee compliant) has been built and evaluated, then forwarded recursively until the root node including plans to add remote control capabilities is reached [10]. in future work [5].This system is able to sense plant humidity through a moisture sensor and directly CoAP The Constrained Application Protocol control the irrigation of each plant using an electro- (CoAP) [11] is an application layer transfer valve. A more recent example is the commercial protocol designed to meet the requirements product “Parrot Flower Power” [6] which does not of highly resource-constrained devices and allow for automatic irrigation of the plants but pro- machine-to-machine (M2M) scenarios such as vides customers with a light-, humidity-, fertilizer- those encountered in Low-power and Lossy and moisture sensor. Based on this data transmitted Networks (LLN) [12]. Its messages can also to a corresponding smartphone app via Bluetooth, be statelessly translated to HTTP requests, the user can accurately determine whether a plant thus allowing for a proxy between an LLN should be watered, fertilizied or moved to another and the Internet. This is done to facilitate the position based on temperature and light readings. integration of constrained nodes into Internet. 3 5 SYSTEM CONCEPT was used as an external transceiver. This compo- nent is capable of receiving IEEE 802.15.4 transmis- This section describes the underlying concept of sions and transforming the contained 6LoWPAN the Watr.li system, which is comprised of two main packets into regular IPv6 packets, thus acting as a components: several Plant Nodes (PNs) and a single gateway between the IEEE 802.15.4 network and the Display Node (DN). Every monitored plant has its RasPi. own PN which measures the soil humidity and transmits it wirelessly to the DN. If the DN is not directly reachable from the PN (i.e. it is not a one- 5.2 Operating Systems hop neighbor), the PN will use intermediary PNs to send its data towards the DN. The DN then stores The tasks of the DN are processing PN information, and evaluates the received sensor data, making it hosting a web server to display PN data to the user, available for display to the user or further prop- and working as a border gateway between IEEE agation into the Internet, for example to Twitter. 802.15.4 and an Ethernet connection to the Internet. Figure 1 illustrates a possible Watr.li setup. Since the DN is connected to a stable power source it is not required to be especially energy-efficient. The remainder of this section will detail the differ- Linux was chosen as the most suitable operating ent layers of the Watr.li concept, beginning at the system for these tasks for two main reasons. First, it hardware level and working its way up to the User is well supported on the chosen hardware platform, Interface (UI) concept.