*3.1. Nodes*

Two basic wireless nodes have been envisaged, each one equipped with Semtech SX1272 LoRa Radio: "Greenhouse Node" and "Plant Node". A single "Greenhouse Node" is needed for a greenhouse. Instead, every plant to be monitored will feature a "Plant Node".

Both node types share the same structure (Figure 2a), i.e., (1) low power, ARM-based STM32L152RE microcontroller hosted in a NUCLEO\_L152RE board, (2) chirp spread spectrum SX1272 LoRa Radio, and (3) sensor shield.

The sensor shield of the Greenhouse Node (Figure 2b) provides the connections to (1) a Si7021, a common and widely used RH and temperature sensor, (2) a Photoresistor for light detection, and (3) a 4.8 V battery.

The Plant Node is dedicated to measuring the fundamental parameters of the soil, i.e., soil water content and soil temperature, and to soil watering. Its dedicated shield (Figure 2c) hosts a BD6212HFP H-bridge used for driving a bistable solenoid valve and a power feed interconnection to turn the sensors on and off. Moreover, it is connected to (1) a TMP36 or an LM35 temperature sensor, (2) a "Capacitive Soil Moisture Sensor v1.2" for measuring water content, (3) a bistable solenoid valve, and (4) a 4.8 V battery. Finally, it includesa1MΩ shunt resistor useful to correct a fabrication defect of the batch of sensor we received.

**Figure 2.** (**a**) Plant and Greenhouse node electronics and their actuator and sensors. (1) Semtech SX1272 LoRa Radio, (2) L152RE low power microcontroller, (3) Sensor/Actuator Interface Shield; (**b**) from left to right for the Greenhouse Node: Si7021 and Photoresistor. (**c**) from left to right for the Plant Node: "Capacitive Soil Moisture Sensor v1.2", TMP36 or LM35 temperature sensor, and bistable solenoid valve.

It is worth giving some details here on the design choices of this Plant Node. The use of an H-bridge and a bistable valve greatly helps in minimizing power consumption, as the valve will drain current only during switching. Power supply for temperature and water content sensors was delivered through the GPIOs of the microcontroller to feed the sensors only when a measurement must be accomplished. In fact, the maximum allowed current delivered by the GPIOs of the STM32L152RE microcontroller is more than enough for the low power sensors we adopted. However, it must be pointed out the present version of the system is designed to provide maximum flexibility and is not conceived for power optimization. For example, the STM NUCLEO boards still include the ST-LINK/V2-1 programming and debugging tool, whose power consumption is way larger than that of the main STM32L152RE microcontroller.

Several plant nodes have been manufactured (Figure 3). After some design steps, the present version of the Plant Node is composed of (*i*) a waterproof junction box (including all electrical and electronic components) connected with (*ii*) a 3D printed PET-G shell which protects the soil sensor and the temperature sensor.

**Figure 3.** The final version of the Plant Node.

Regarding the soil water content sensor, most papers presented in the literature either measure the capacitance of the soil, which, of course, depends on the water content, or adopt high frequency (around 100 MHz) AC measurements to characterize the dielectric constant of the soil [58]. Other papers describing low-cost IoT nodes adopt fork-like metallic sensors that, when used with a DC bias, mainly characterize the ionic content of the soil by measuring the electrical resistance between the two arms of the fork. AC could also be used with fork-like sensors to limit electrolysis and consequent metal electrode etching/degradation and DC ion currents in the soil. Examples can be found in GardenBot literature [60] or [27] and references therein.

For this prototype of the system, we use the commercial, blade-shaped, "Capacitive Soil Moisture Sensor v1.2" (also dubbed SKU: SEN0193 in its version 1.0 by DFROBOT [61]) for sensing water content in the soil. This sensor is undoubtedly the least expensive water content sensor in the market and was also exploited in other scientific papers (see for example [32,33]) and well-documented internet projects [62]. In [32] the authors found that this sensor did not perform acceptably in predicting soil moisture content in a laboratory soil mixture prepared by mixing organic-rich soil and vermiculite, while it can estimate soil water in gardening soil in the so-called "field capacity" range. In [33] the author linearly correlates the voltage provided by the sensor reading to the gravimetric moisture approximations, providing an effective relationship between the reading from the capacitive sensor and the water content in the soil. This calibration procedure demonstrated that low-cost capacitive-type soil moisture sensors are capable of predicting the water content in soils to a high degree of accuracy, with little required outside of the device itself, which is in direct contrast to the time it takes to traditionally measure the water content in soils.

Being that the water content sensor is the hearth of our plant nodes and since a detailed data sheet is not available for the sensors, an accurate study of the sensor electronics was initially accomplished to ge<sup>t</sup> acquainted with the operation of the sensors [8]. A low dropout 3.3 V voltage regulator (omitted in a very recent version–v1.2 and v2.0–of this sensor) feeds a TL555I CMOS timer (Figure 4) which generates a trapezoidal waveform in astable mode running at about 1.5 MHz. The trapezoidal shape is because the operating frequency of the timer is pushed beyond the physical limit for the TL555I device, specified in the datasheet as guaranteed for 1.2 MHz in astable mode. On the other hand, the non-steep rising and falling edges of the waveform help in minimizing the electromagnetic interference possibly generated by the sensor and would be beneficial in the case of "CE" or "FCC" compliance certification.

**Figure 4.** A detailed view of the printed circuit board component section with the electrical schematic of the "Capacitive Soil Moisture Sensor v1.2". The reported resistance values are taken from the component labels while the capacitance values were measured using an HP4275A LCR meter. Cprobe is the variable capacitance of the coplanar capacitor printed on the circuit board. Due to a missing grounding line of the printed circuit board [8], in our measurements, a 1 M Ω shunt resistor has been directly connected to the Sensor/Actuator Interface Shield.

The trapezoidal waveforms of nine sensors (S1, S2, S5, S6, S7, S9, S10, S13, and S14) were initially characterized to assess their uniformity. We discarded sensor S1 since its

measured frequency *f* and duty cycle DC (1.22 MHz and 37.12% respectively) were very far from the average operating frequency and duty cycle of the other eight sensors (1.53 MHz and 34.48%, with sample standard deviations of 1% and 2.2%, respectively) [8], as reported in Table 1.



After this initial screening of the available samples of Capacitive Soil Moisture Sensor v1.2, we are confident that the measurement results of a single sensor chosen among other homogeneous samples represent the expected behavior of the whole family "S2, S5, S6, S7, S9, S10, S13, and S14".

The TL555I timer supplies a passive circuit shown in Figure 4, composed of a first stage where the coplanar capacitor of the sensor Cprobe is low-pass connected with a 10 k Ω resistor. Then a peak detector provides the analog output signal that we acquire through the ADC of the microcontroller. Regarding sensor settling time, in [33] it was asserted this sensor should settle in 1–5 min, depending on the saturation level of the soil and how well the wet soil was mixed. We accomplished measurements with the Capacitive Soil Moisture Sensor v1.2 immersed in tap water and found that the output voltage could take up to one hour to reach the regime value. This could be due to a non-complete waterproofing of the sensor materials that likely incorporate water molecules. Therefore, the behavior of the Capacitive Soil Moisture Sensor v1.2 after initial watering could not be completely reproducible.

We underline that other more documented and reliable but also more expensive bladeshaped moisture sensors have been commercialized. Examples are the dielectric capacitance sensors ECH2O probe (Decagon Devices, Inc. Pullman, WA USA, now discontinued [63,64]) and the PROBE sensor [65], then modified to SMT100 ring-oscillator sensor (Truebner GmbH, Neustadt, Germany [66]) operating at approximately 150 MHz in water and 340 MHz in air.

A worst-case estimation of the overall cost of our plant node is roughly USD 60, where the most impacting figures are the microcontroller board and the LoRa shield.

#### 3.1.1. Soil Volumetric Water Content Fitting Equations

Water content measurements were previously accomplished in silica sandy soil with the Capacitive Soil Moisture Sensor v1.2 in conditions such that the dry unit weight *γdry* = *Ws*/*V* (*Ws* = dry soil weight, *V* = total volume of the soil) could be assumed as a constant [8]. It was demonstrated that this condition guarantees a monotonically decreasing *V*s output voltage as a function of gravimetric water content (GWC), which was approximated using a 2nd order polynomial or an exponential function. In this paper, we will deal with volumetric water content (VWC) instead of GWC. However, the two parameters are proportional to each other for a given soil where the dry unit weight is constant. In the remainder of this paper, we will use the following exponential fitting equation between the output voltage *Vs* of the Capacitive Soil Moisture Sensor v1.2 and the VWC: 

$$V\_s = A \exp\left(-\frac{\text{VWC}}{B}\right) + \text{C},\tag{1}$$

$$\text{VWC} = B \ln \left( \frac{A}{V\_s - \mathcal{C}} \right) \tag{2}$$

being *A*, *B*, and *C* suitable constants. Other fitting equations were also adopted in the literature for the same sensor. In [32] a 3rd order polynomial function VWC = *f*(*Vs*) was implemented. In [33] the following equation was used:

$$\text{VWC} = \frac{P}{V\_s} - Q \tag{3}$$

being *P* = 2.48 V and *Q* = 0.72 for a soil composed of dried coconut coir. In the remainder of this paper, we will mainly deal with fitting Equations (2) and (3).

#### 3.1.2. Embedded Software Implementation of Nodes

The C++ code exploits ARM Mbed OS libraries. Mbed OS is an open-source Real-Time Operating System (RTOS) for the creation and deployment of IoT devices based on ARM processors. The code structure is outlined in Figure 5 for the case of the Plant Node.

**Figure 5.** Embedded software implementation for the Plant Node.

The heart of the firmware is the *main.cpp* file. The header of main.cpp includes Mbed libraries (e.g., **EventQueue.h**) and LoRaWAN ™ libraries. In particular, **LoRaWANInterface.h** encompasses the prototypes of the member functions managing the upper level of the LoRaWAN ™ protocol stack, **lorawan\_data\_structures.h** includes LoRaWAN parameters, e.g., network and application key, datarate, duty cycle, antenna gain, buffer size, and SNR while **lora\_radio\_helper.h** regards the physical layer and selects the type of shield adopted in our system. The functions of **main.cpp** dedicated to the Plant Node are listed in the lower part of Figure 5. Among them, we cite the **lora\_event\_handler()** which manages the state machine of the LoRa events, the measuring functions for water content (**measure\_SoilWC()**) and temperature (**measure\_Temp()**), and the LoRa send and **send\_message()** and **receive\_message()** functions. The receive function also handles the bistable irrigation solenoid valve. In the case of the Greenhouse Node, the actual measuring functions regard ambient RH, temperature, and the ambient luminous flux.

Every node transmits a packet conforming to the structure defined in Figure 6. Depending on the node type (plant or greenhouse node), it will include different values. For example, the Plant Node features node type = 1 and transmits soil water content and temperature, while the greenhouse node is characterized by node type = 0 and transmits ambient RH, temperature, and light intensity.


**Figure 6.** Packet structure.

#### *3.2. The Things Network and Connection to the LoRaWAN™ Gateway*

Routing and processing procedures of the LoRaWAN ™ network are managed by The Things Network (TTN), acting as an active crossroad between the gateway and the application. For our application, we extensively use the TTN, a network server whose aim is building a global, worldwide open LoRaWAN ™ network. They provide a set of open tools and a global, open network to build an IoT application at low cost, featuring maximum security and ready to scale. A secure and collaborative Internet of Things network is built through robust end-to-end encryption, spanning many countries around the globe. A network server does the complicated part in creating a LoRaWAN ™ network (handling duplicate packets from multiple gateways, shunting data to servers, handling joins, etc.).

As shown in Figure 1, in the network architecture The Things Network is located between the LoRa concentrator/gateway and the applications. TTN is composed of three main structures: Router, Brokers, and Handler. The Router is in charge of managing the gateway's status and of planning transmissions. Each Router is associated with one or more Brokers. The assignment of Brokers is to map a device to an application, to forward uplink messages to the proper application, and to forward downlink messages to the correct Router-Gateway path. A Handler is responsible for treating the data of different Applications. To do so, it deals with a Broker where it registers devices and applications. The Handler is also in charge of encrypting and decrypting data.

In our system, the Uplink connection to TTN is carried out by the Radio SW of the gateway (Figure 1) that publishes the node sensor data on a specific uplink topic of the TTN MQTT broker using an internet connection.

Then, through the well-known flow-based programming tool Node-RED [67] running on the Gateway, a specific device is allowed to communicate with the database installed in the virtual machine, as sketched in Figure 1.

The Node-RED flow is composed of two sub-flows, an uplink, and a downlink flow, respectively (Figure 7a).

The uplink sub-flow, after subscribing to the same uplink topic of the TTN broker, is in charge of:


Moreover, in the second Node-RED sub-flow the application is allowed to transmit downlinks to TTN (i.e., to the device) when the bistable solenoid valve must be actuated. This is accomplished by publishing on a specific downlink topic of the TTN broker using the internet again. In the NodeRED flow, the first "TCP in" node is ready to receive messages on a given unassigned TCP port, then a "Reply" JavaScript function returns an object which contains the ID of the target node and the payload, i.e., the message sent by the server. The last light blue node is a TTN Downlink Node which publishes these data on the TTN broker.

 **Figure 7.** (**a**) The Node-RED flow running in the Raspberry of the Gateway. (**b**) The 8-channel iC880a /Concentrator, with interconnection backplane and Raspberry PI3, is mounted in a plastic box.

Our LoRaWAN™ Gateway is composed of a Raspberry Pi, an iC880a concentrator able to receive packets of different end devices simultaneously sent with different spreading factors on up to 8 different channels in parallel, and an interconnecting backplane (Figure 7b). The embedded software of the Gateway is proprietary and supplied by TTN. The gateway receives LoRa packets from nodes and forwards them to The Things Network [59] through the MQTT protocol thanks to a wideband network, typically WiFi or Ethernet build. On the other hand, it is well known that for data transmission, MQTT could rely on the TCP protocol but a variant, MQTT-SN, is used over other transports such as UDP (or even Bluetooth). However, TTN does not specify which transport protocol is exploited in its Raspberry Pi firmware.

*3.3. The Virtual Machine in the Cloud, Database Application, and Graphical User Interface*

At the application level, we installed a Linux virtual machine (Figure 8) that includes:


The database is divided into two units: (i) node data section and (ii) web application user data section (e.g., username and password). The node data section is further composed of two tables: the first one identifies the node and the second one the sensor with its data. Finally, the webserver fetches data in the database using PHP and shows them on a web page. CanvasJS is used for the Graphical User Interface (GUI). CanvasJS is described as a JavaScript Charting Library for High Performance and ease of use. It is built using the Canvas element and it can render thousands of data points in a matter of milliseconds. CanvasJS is also interactive and can be updated dynamically. Examples of the GUI, operating both from a PC and a smartphone, can be found in the following sections.

The information contained in the database of our virtual machine could represent a starting point for decision-making processes supporting smart monitoring in the frame of PA. A possible implementation could be to develop and enhance the PHP code, used until now to retrieve information from the database, adding a new section where data are analyzed by a dedicated algorithm. The decisions made by the algorithm could be directly sent to the nodes through TTN and the gateways. As an alternative, the watering decision could be directly issued by an application running on the mobile device of the greenhouse manager.

A plant node was placed in a pot hosting a daisy plant, while a greenhouse node was acquiring data in the ambient. Figure 9 includes three plots of our JavaScript GUI showing the soil water content recorded by the Plant Node together with the ambient relative humidity and temperature recorded by the greenhouse node in the same room where the plant pot was located.

**Figure 9.** Simultaneous acquisition of ambient temperature and ambient relative humidity (RH) of the greenhouse node and soil water content of a single plant node, shown on the display of a portable device.
