Keywords

1 Introduction

According to recent reports in the field of the Internet of Things (IoT) (e.g. [1]), there will be 25 billion connected things by 2021. These estimations call for smart solutions that provide means to connect, manage and control these devices efficiently. IoT can be envisioned as a dynamic network with self-configuring capabilities, in which devices (that are called as things) can interact and communicate among themselves and with the environment by exchanging sensor data. Such systems can be utilized in many application areas, thus they may have very different properties.

Smart farming is also a rapidly growing area within smart systems, that need to respond to great challenges of the near future. By 2050, it is expected that global population will grow to 9.6 billion as the United Nations Food and Agriculture Organisation predicts. A recent Beecham Research report [2] also states that food production have to respond to this growth to increase it with 70% till 2050. This report also states that agriculture is responsible for a fifth of greenhouse gas emissions and for 70% of the world’s fresh water usage, which strives for a reform. IoT supported by cloud services has the potential to implement the required changes [3].

Plant phenotyping [4] also evolves rapidly and provides high throughput approaches for monitoring the growth, physiological parameters, and stress responses of plants with high spatial and temporal resolution. Recent advances use the combination of various remote sensing methods that can exploit IoT and cloud technologies. In the past typical plant phenotyping platforms used very expensive instrumentation to monitor several hundreds, even few thousands of plants. Although these large infrastructures are very powerful, they have high cost ranging to a few mEUR per platform, which limits their widespread, everyday use. Due to recent ICT developments we can apply novel sensor and IoT technologies to provide a promising alternative, called affordable phenotyping. Our research goals also point to this direction, and in this paper we propose a low cost plant phenotyping platform for small sized plants, which enables the remote monitoring of plant growth in a standard greenhouse environment. In an earlier work we introduced the first prototype of our IoLT Smart Pot [28]. In this work we discuss its extension for leaf area calculations, and present a detailed evaluation of it.

The main contributions of this paper are the design and implementation of the IoLT Smart Pot Gateway for managing smart pot clusters by monitoring their environmental parameters. This IoT-Cloud platform is capable of collecting, storing and visualizing sensor data, as well as performing leaf area calculations with image processing to allow plant growth tracking. We also evaluate the proposed solution with scalable simulations, and exemplify real world utilization.

The remainder of this paper is as follows: Sect. 2 introduces related approaches for smart farming and plant monitoring, and Sect. 3 highlights our research aims and discusses the proposed smart pot solution. Section 4 presents a detailed evaluation of our gateway framework by means of simulation, and Sect. 5 shows real world utilization. Finally, we conclude the paper in Sect. 6.

2 Related Work

Smart system design and development have started to flourish. Smart farming is also getting very popular, there are many commercial solutions and products in household areas.

Concerning indoor plant monitoring, many tools are available for monitoring temperature, humidity, light, water level and salt content of the plant soil, and are able to communicate with nearby devices. Some advanced systems are capable of automatic watering or provide notifications or even remote control through mobile applications. Table 1 shows a comparison of the available solutions, and we briefly introduce them in the following.

Table 1. Comparison of commercial smart pot solutions.

PlantRay [8] is a really basic smart pot, it has a soil moisture sensor, and it changes color and beeps if watering is required. The battery may last for a year. AeroGarden [9] has many different size products, able to hold from two to 24 plants. They have LED lights, but only the bigger ones have automatic LED control. The most advanced one can be connected with Amazon Echo.

Xiaomi Flora [5] has an indicator board for providing information coming from the sensors, and it has a dedicated application for remote controlling the management of the pot. It is able to monitor the moisture and salt content of the soil. GAIAA [7] is a solution from sPlant, which is able to manage four plants at a time. It also has a remote app control, and provides automatic watering, light supplement, and WiFi communication with a cloud server. Tregren [11] produces 3 different size products, they can handle 3, 6 or even 12 plants. The watering and the light control are automatic, usually it can be leaved alone for 21 days. The SmartPot [15] is just a prototype, but it has temperature, humidity, light, soil moisture sensors and a water pump. It can be controlled by a mobile application. The Parrot pot [6] includes a self-watering system and four built-in sensors. Unfortunately, its production has been suspended. Click & Grow [12] has two similar products, they only differ in size. The smaller one is for three plants, the bigger one can handle 9 plants. CitySens [13] is a vertical pot system with auto-watering and variable pot numbers with an option to communicate with a mobile application via wifi. LeGrow [14] creates modules for a smart pot system. Currently they sell lamp, humidifier, power and pot modules. Odyseed [10] is a smart pot solution that uses time schedules for automatic irrigation and lighting.

There are some other interesting products, like Lua [16] the flowerpot with 15 different animated emotions. The emotions representing the status of the plant based on the moisture, light and temperature sensors. The Vincross [18] company has an AI robot called HEXA, and it can move the plant to get enough sunshine. The TOKQI [17] smart pot can detect if the user pets the plant and starts playing music. It is a decorative item with RGB lighting and it can be used as a regular bluetooth speaker too.

For professional usage, there are only very few commercially available platforms for affordable phenotyping (e.g. PhenoBox [19]).

Concerning generic IoT gateways, Kang et al. [20] introduced the main types and features of IoT gateways in a detailed study, which presents the state-of-the-art and research directions in this field. This solution is also too generic for our needs.

Focusing on the development of a smart farming environment, Dagar et al. [21] proposed a model of a simple smart farming architecture of IoT sensors capable of collecting information on environmental data and sending them to a server using wireless connection. There are also generic solutions to monitor agriculture applications using IoT systems, such as the Kaa IoT Platform [22]. It is a commercial product that is able to perform sensor-based field and remote crop monitoring. It also has an open source version called the Kaa Community Edition. Such generic toolkits are quite complex and heavy-weight, so they are not well suited to specific needs.

In contrast to these solutions, our approach aims to provide a low-cost solution using the latest IoT and Cloud techniques to enable a robust and scalable solution to be used for groups of plants with user friendly management.

3 The Design of a Smart Pot for the IoLT Project

The Internet of Living Things (IoLT) project was started in 2017 with the aims to integrate IoT technological research with applied biological research, and to develop IoT applications for three target fields: complex plant phenotyping, actigraphy for psychosocial treatments, and Lab-on-a-chip systems for microfluidic diagnostics. IoLT is also forming a Network of Excellence of researchers of corresponding disciplines working at the University of Szeged and the Biological Research Centre of the Hungarian Academy of Sciences. An opensource IoLT platform is under development to enable the execution of applications on cheap, low capacity IoT devices providing easy to use programming interfaces based on Javascript.

Fig. 1.
figure 1

IoLT Smart Pot prototype (left), and one pot of the cluster (right).

Fig. 2.
figure 2

The architecture of the IoLT Smart Pot Gateway as shown in [28].

In the research field of plant phenotyping we planned to design and develop a scalable, low-cost automation system called IoLT Smart Pot using IoT and cloud technologies, to monitor the effect of various stress factors of plants (drought, nutrition, salt, heavy metals, etc.), as well as behavior of various mutant lines. For the first prototype depicted in Fig. 1, the biologists designed a hardware for hosting 12 small sized plant pots (for Arabidopsis plants) organized in a 4 \(\times \) 3 matrix. To monitor plant growth an RGB camera and a LED-based illumination system for additional lighting are installed above the plant cluster. The relevant environmental parameters are light intensity, air and leaf temperature, relative air and soil humidity, which are monitored by sensors placed above and into the pots. To govern the monitoring processes, a Raspberry Pi board is placed beside the cluster. The monitored sensor data is stored locally on the board, and accessible through a wired connection on the same network. The initial configuration for performing periodical monitoring was set to 5 min concerning the sensor readings, and 1 h to take pictures of the cluster of pots.

3.1 Implementation of the IoLT Smart Pot Gateway

The architecture of our initially proposed IoLT Smart Pot Gateway [28] can be seen in Fig. 2. It has a modular setup, it consists of three microservices, and its source code can be found on GitHub [27]. The microservices are realized by Docker containers [25], which are composed together to form the gateway application deployable to a virtual machine (VM) of a cloud provider. Special monitoring scripts are used to track and log the resource utilization of the containers for performance measurements. The users can access the gateway through a web interface provided by a Node.js portal application. It can be used to group and manage pots and users with projects created by administrators. Projects need to have start and finish dates, associated users and a short description. Pots can also be registered by them and linked to projects. In this way, registered and connected smart pots can send sensor data to them, which can be visualized in the portal. A sample view of such a portal web interface can be seen in Fig. 3. It displays a project named Real BRC Smartpot test (1 week) managing a smart pot registered as BRC_Smartpot_1. The chart depicts values (y axis) of seven sensor types with timestamps (X axis) for a week of utilization. On the chart interface a user can tick or untick certain sensors, and change the time interval below the chart using a sliding bar. Once a setup is done, the depicted sensor datasets can be downloaded (in CSV format) by clicking on the “Download” button.

Fig. 3.
figure 3

Historical sensor data visualization in the IoLT Smart Pot Gateway as shown in [28].

Fig. 4.
figure 4

Real and segmented pictures of the Smart Pot cluster taken at 2019.01.01.

The Node.js portal application is built upon two other microservices. In the middle of the architecture in Fig. 2 we can find the Mosquitto MQTT Broker service, which is built on the open-source Mosquitto tool [23] to store the received sensor values of the pots using a MongoDB [24] database. The monitored seven sensor types of a pot are described by a JSON document (see later in Fig. 9), which should be regularly updated and sent in a message by an MQTT client of a smart pot to the MQTT broker running in this service. The sensor readings on the Raspberry Pi board are performed by a python script using an MQTT client package configured with a pot identifier, sensor value sampling frequencies and picture taking frequencies. The third microservice on the bottom is called the Apache Web Server, which is responsible to save the pictures of the plants of the pots. The python scripts of the boards use SFTP file transfers to send the pictures stored by this service.

3.2 A Solutions for Monitoring and Analyzing Plant Growth over Time

After the initial version of the gateway portal was released, the biologists started to use it for monitoring Arabidopsis plants. As mentioned in the previous section, the gateway stores regularly updated sensor values, and periodically taken pictures of the smart pot cluster. The portal can be used to query, visualize and download a set of sensor values for a certain period, and the created pictures.

Besides viewing these monitored results, the biologists had to perform post-processing tasks of the monitored data by downloading them from the gateway portal. One of these tasks is to calculate the growth speed of the plants, which is generally performed by calculating the projected leaf area visible on the taken pictures, and filing them to a time series document, later depicting them in diagrams. Such a task had to be done manually, taking valuable time from the researchers.

By responding to their need, we extended the gateway with a new functionality. After a new picture is uploaded to the gateway, a python script is triggered to perform the segmentation of the picture. The segmented pictures are also stored in the gateway server in a subfolder to allow verification from the researchers. After segmentation the projected leaf area is calculated for all 12 plants visible on the segmented picture (also with image-processing algorithms in a python script), then saved to the database of the gateway in the format shown in Fig. 5 (in cm2).

Fig. 5.
figure 5

Projected leaf area values to be stored in the database of the gateway.

Fig. 6.
figure 6

The gateway screen for querying detailed leaf area values.

Fig. 7.
figure 7

Selection of a pot from the cluster.

Fig. 8.
figure 8

Detailed leaf area values over time for a pot.

In order to access the results, a researcher should log in to the portal web interface of the gateway, and select a registered project with a time interval, as shown in Fig. 6. For the next step, one can select one of the plants (represented with a slot id) of the smart pot cluster associated to the given project (as depicted by Fig. 7). Finally, as Fig. 8 shows, we can see the chart of the calculated values that represent a time course of the projected leaf area of the selected plant in a pot of the cluster. The curve nicely reveals a cirkadian oscillation pattern due to periodic leaf movement (flattening in the dark and erection in the light period).

4 Evaluation of the Smart Pot Gateway

In order to evaluate our proposed solution, we instantiated an IoLT Smart Pot Gateway service in the MTA Cloud [26] with a small VM flavor with a single virtual CPU core and two GB memory. The MTA Cloud is an OpenStack-based, national community cloud financed by the Hungarian Academy of Sciences for providing cloud infrastructure services for scientists from the academy.

4.1 Simulations with a Python Tool

First, we performed a throughout evaluation by means of simulation. After executing some initial measurements, we found out the exact, real data value ranges for the installed sensors of the smart pot. Based on these values, we designed a simulated smart pot represented by python scripts capable of sending generated sensor data via the MQTT protocol. Figure 9 depicts a generated sample JSON file for the revealed sensor types.

Fig. 9.
figure 9

Sample JSON message of seven sensor values of a pot as shown in [28].

First, we created 250 simulated pots with scripts that sent generated sensor data to our IoLT Smart Pot Gateway service (runing at MTA Cloud) for 30 min. We divided the total experiment time-frame to the following periods:

  • in the first 10 min we applied sensor data generation frequency of 30 s (which means that each pot sent a message of 7 sensor values every 30 s);

  • in the second 10 min we applied sensor data generation frequency of 10 s;

  • in the following 5 min we applied sensor data generation frequency of 2 s;

  • and in the last 5 min we applied sensor data generation frequency of 10 s, again.

We also developed a special monitoring script for the gateway (as shown in Fig. 2) to track its resource consumption. The resource usage sampling of the script was set to 10 s. They queried CPU, memory, network and input/output (I/O) resource utilization for all containers, and we summed these values to get the total resource consumption of the composed service (running in a VM). We can see the measurement results for this initial round simulating 250 pots in Fig. 10 and Fig. 11. The x axis denotes the timestamps of resource usage monitoring, while the y axis denotes the resource usage values (in percentage or in kB or MB). We can see that there are some spikes in the resource usage percentages after the first 10 min, when we start to send more messages, and from the 20th minute the utilization has an increasing trend. Nevertheless, we have to mention that the resource using sampling is less frequent than the arrival rate of the messages, which results in an incomplete curve (the resource utilization is not tracked between the sampling intervals). The network and I/O utilization was visible only for the first 10 min, possibly due to the initialization phase of the script.

Fig. 10.
figure 10

CPU and memory usage measurement results for 250 pots.

Fig. 11.
figure 11

Network and I/O usage measurement results for 250 pots.

Next, we set the simulation parameters in a way to mimic future, real world utilization. Our proposed IoLT Smart Pot is basically a cluster of 12 pots, as shown in Fig. 1. To evaluate the scalability of our gateway solution, we performed three simulation measurements with 50, 100 and 250 clusters (composed of 600, 1200 and 3000 pots respectively). In all cases we performed the measurements for 30 min, and the simulated smart pot platform sent sensor values with the following setup:

  • in the first 10 min we applied sensor data generation frequency of 5 min (which means that each pot sent a message of 7 sensor values every 5 min: resulting 2 messages in this period per pot);

  • in the second 10 min we applied sensor data generation frequency of 1 min;

  • and in the last 10 min we applied sensor data generation frequency of 5 min, again.

In the first simulation for 50 clusters we set the sampling of resource usage (processor and memory usage) in every 10 s, while for the second and the third one (100 and 250 clusters) we set it to 2 s (to have a better resolution of resource loads).

Fig. 12.
figure 12

CPU and memory usage measurement results for 50 pot clusters.

Fig. 13.
figure 13

Network and I/O usage measurement results for 50 pot clusters.

Fig. 14.
figure 14

CPU and memory usage measurement results for 100 pot clusters.

Fig. 15.
figure 15

Network and I/O usage measurement results for 100 pot clusters.

We can see the measurement results for the first round simulating 50 clusters with 600 pots in Fig. 12 and Fig. 13 for 30 min. Here we can see that the average CPU load varies between 1 and 2%, and the memory usage fluctuates between 15 and 19%. The network and I/O utilization are slowly, but constantly growing. In this experiment we also observed that the time of an actual data processing (receiving a message and writing its contents to the database) and the time of the resource usage sampling are rarely matched. One matching example can be seen right after the 3rd minute in Fig. 12, which shows a spike with almost 14% of CPU utilization.

For the second round we doubled the number of clusters to 100, and performed the simulation only for 5 min with detailed resource usage sampling of 2 s. We can see the measurement results for this round simulating 100 clusters with 1200 pots. In Fig. 14 we can see that the results reveal a periodic resource usage fluctuation denoting the data processing activities. For the network and I/O utilization shown in Fig. 15 we can still see a constant grow.

Finally, for the largest experiment we further increased the number of pot clusters to 250 arriving to a total number of 3000 simulated pots. For this third round, we performed the simulation for 30 min, again, with the same periods as defined for the first round (of 50 clusters). We can see the measurement results in Fig. 16 and Fig. 17. If we take a look at the middle 10 min period we can see the periodic resource usage spikes for CPU and memory, as in the previous round. And we can also observe the utilization growth in network and I/O data transfers.

To summarize our investigations, Table 2 compares the average and maximum resource utilization values measured during the experiments. We can see that by increasing the number of pots to be managed by the gateway service, the utilization also increases. As expected, the CPU utilization was the highest in the third round for managing 3000 pots at the same time with almost 40%. The memory utilization is also the highest in this case with almost 25%. Table 3 shows a detailed comparison for the longest experiments denoting the different phases of the measurements. This table highlights that the CPU utilization generally reaches its maximum in the first phase, then it generally drops, while memory utilization shows a quite balanced load all over the three phases. Finally, we can state that these results prove that we can easily serve numerous phenotyping projects monitoring up to thousands of pots with a single gateway instance in a Cloud.

Fig. 16.
figure 16

CPU and memory usage measurement results for 250 pot clusters.

Fig. 17.
figure 17

Network and I/O usage measurement results for 250 pot clusters.

Table 2. Comparison of the four evaluation rounds.
Table 3. Comparison of the 30 min. evaluation rounds.
Fig. 18.
figure 18

Data visualization of a real world measurement in the IoLT Smart Pot Gateway.

Fig. 19.
figure 19

Sensor data of a day in the IoLT Smart Pot Gateway.

5 Real World Measurements

We have seen in the previous section that our gateway service is scalable enough to manage a few thousands of pots in a single cloud VM. To exemplify real world utilization, we connected the gateway to the IoLT Smart Pot prototype. It is able to hold 12 Arabidopsis plants in small pots organized to a cluster (as shown in Fig. 1). We configured the python scripts of a Raspberry Pi board placed beside the pot cluster to perform sensor readings periodically, and send the environmental values to the IoT-Cloud gateway service. The wiring of the smart pot cluster formed a single IoT device with a camera and 7 sensors (attached to some of the 12 pots).

We performed the monitoring of the growth of Arabidopsis plants under standard greenhouse conditions for several periods, taking up around 2–3 months in total. RGB image taking was performed every hour, and the sensor sampling frequency was set to 5 min (to generate a JSON message). Figure 18 depicts a query at the gateway portal resulting in a chart of the sensor and leaf area values for over a month of monitoring. As we can see from the chart, the smart pot was disconnected for a certain period after around 20 days). If we zoom in by using the bar below the chart, we can view detailed results. Figure 19 shows the sensor values of a day of utilization of the smart pot cluster.

6 Conclusions

Smart farming approaches are meant to revolutionize agriculture to improve productivity and reduce waste by exploiting the latest ICT technologies and trends. Affordable phenotyping has the goal to provide low cost and easily scalable solutions to create greenhouses of the future.

In this paper we aimed to contribute to this field by proposing the IoLT Smart Pot Platform and Gateway that can be used to manage smart pot clusters by monitoring environmental parameters. This solution is capable of collecting, storing and visualizing sensor data, as well as performing leaf area calculations with image processing to allow plant growth analysis. We also evaluated the proposed solution with scalable simulations, and exemplified real world utilization in standard greenhouse conditions.

In our future work we plan to redesign the smart pot with a solar cell system to enable portable installations and remote monitoring at outdoor location.

Software availability

Its source code of the proposed cloud gateway is open and available at the following website: https://github.com/sed-inf-u-szeged/IoLT-Smart-Pot-Gateway