Content uploaded by Tim-Lucas Rabbel
Author content
All content in this area was uploaded by Tim-Lucas Rabbel on May 17, 2023
Content may be subject to copyright.
Funded by
the European Union
Technical report
Developing a hybrid sensor network
Tim-Lucas Rabbel
Eduard Buss
Marko Križmančić
May 16, 2023
WatchPlant - Technical report Developing a hybrid sensor network
Contents
1 Introduction 2
2 Devices and technologies 2
3 Methodology 4
3.1 Zigbeenode............................................ 5
3.2 Zigbee/LoRaWANnode ..................................... 5
3.3 Datasink ............................................. 6
3.4 LoRaWANcontroller....................................... 6
3.5 Putting everything together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Conclusion 7
1
WatchPlant - Technical report Developing a hybrid sensor network
Figure 1: A schematic display of the envisioned bio-hybrid sensor network in Zagreb, Croatia. Source:
Ilija Ascic/Shutterstock.com
1 Introduction
WatchPlant [1, 2] is an EU Horizon 2020 project that proposes a radically novel approach to environmen-
tal monitoring by using living plants as natural sensors. As plants react to changes in their surroundings,
their reactions can be measured and correlated to the actual conditions using the state-of-the-art methods
of machine learning and artificial intelligence (AI). The project aims to develop a sustainable, energy-
efficient bio-hybrid system that harvests energy from plants and provides a low-cost alternative to large
sensor stations for urban air pollution monitoring.
The first step in ensuring the high quality of data collected by the proposed approach is to increase
the robustness and coverage of the system by connecting multiple sensors into a network and developing
methods for efficient data sharing between them. This kind of system is commonly known as a Wireless
Sensor Network (WSN) - a type of network composed of a large number of small, low-power, and
autonomous sensor nodes that communicate wirelessly to collect and transmit data about the physical
world. The nodes in a WSN are generally equipped with various types of sensors, such as temperature,
humidity, and air pressure sensors, to monitor a range of environmental parameters. In the WatchPlant
project, we are also extending this list with specialized sensors measuring the biological parameters of
plants. A schematic display of a WSN with bio-hybrid devices mounted on trees as envisioned in the
project is shown in Fig. 1.
WSNs have become increasingly popular due to their potential for various applications. One of the
most common applications of WSNs is environmental monitoring, where sensors are used to monitor pa-
rameters such as temperature, humidity, and air quality [3]. Other applications include smart homes [4],
precision agriculture [5], healthcare [6], and industrial automation [7]. In smart homes, WSNs can be
used to monitor and control various appliances and devices, while in precision agriculture, they can be
used to monitor soil moisture and crop health. In healthcare, WSNs can be used for remote patient
monitoring and fall detection, while in industrial automation, they can be used to monitor and control
machinery and equipment.
Despite their potential, WSNs face several challenges that need to be addressed. One of the main
difficulties of WSNs is energy consumption since most sensors are battery-powered and have a limited
lifetime. Another challenge is communication reliability, as the wireless communication channel can
be affected by interference or noise. In addition, WSNs face security and privacy concerns, as the
data collected by the sensors can be sensitive and must be protected from unauthorized access (e.g., in
healthcare applications).
2 Devices and technologies
Wireless Sensor Networks use a variety of communication technologies to transmit data wirelessly. The
most commonly used communication technologies in WSNs include Zigbee, Bluetooth Low Energy (BLE),
Wi-Fi, and LoRa (Long-Range).
2
WatchPlant - Technical report Developing a hybrid sensor network
Figure 2: Pair of XBee Series 2s modules. Source: Mark Fickett, distributed under a CC BY 3.0 license.
Zigbee [8] is a low-power wireless communication protocol designed for low data rate, low power
consumption, and long battery life applications. Zigbee operates in the 2.4 GHz band and uses a
mesh networking topology to enable communication between nodes. It is based on the IEEE 802.15.4
standard, which specifies the physical layer and medium access control layer for low-rate wireless personal
area networks (LR-WPANs). Zigbee supports a maximum range of up to 100 meters and a maximum
network size of 65,536 devices. It is suitable for applications such as smart homes, industrial automation,
and building automation. Computer chips that implement Zigbee communication can easily be integrated
into smart devices or attached externally using, e.g., an XBee module (Fig. 2).
BLE [9] is another low-power wireless communication protocol that is commonly used in IoT devices
due to its low energy consumption and range. BLE operates in the 2.4 GHz band and uses a star topology
network architecture, making it suitable for point-to-point and point-to-multipoint communication. BLE
has a range of up to 30 meters and can support up to 8 devices in a network. In comparison to Zigbee,
BLE has a lower range and a smaller maximum network size, but it consumes less power, making it
suitable for applications such as smart homes, healthcare, and wearables.
LoRaWAN (Long Range Wide Area Network) [10] is a low-power, long-range wireless commu-
nication protocol designed for IoT applications. The network topology consists of low-power end devices
connected to gateways with internet access. The gateways are connected via a network server back-end
like The Things Network1(TTN) forming a star-of-stars topology and thus increasing coverage. By using
the sub-GHz spectrum, LoRaWAN can provide long-range communication capabilities of up to 10 km in
rural areas and 2-3 km in urban environments. However, it has a low data rate (typically in the range of
a few kilobits per second), making it suitable for applications such as environmental monitoring, smart
cities, agriculture, and asset tracking.
LoRa (Long Range) [11] is the physical layer technology used in LoRaWAN that provides long-
range communication capabilities with low power consumption. LoRa uses chirp spread spectrum modu-
lation, which enables robust communication with low sensitivity to noise and interference. In comparison
to other communication technologies, LoRa has a lower data rate but a longer range and lower power
consumption.
Wi-Fi is a high-speed wireless communication protocol that provides high bandwidth and range but
consumes more power than Zigbee and BLE. Wi-Fi operates in the 2.4 GHz and 5 GHz bands and uses
a star topology network architecture, making it suitable for applications such as industrial automation,
home automation, and multimedia streaming. However, its range is typically limited to less than a
hundred meters, while the increased energy consumption makes it less suitable for battery-powered
devices.
1https://www.thethingsnetwork.org/
3
WatchPlant - Technical report Developing a hybrid sensor network
Table 1: Comparison of wireless communication technologies based on range, power consumption, and
data rate. Data taken from [12, 13].
Technology Range Power Consumption Data Rate
Zigbee 100 meters Low power 20-250 kbps
BLE 10 meters Low power 125 kbps - 2 Mbps
WiFi 100 meters High power consumption Up to 600 Mbps
LoRaWAN 2-10 km (urban) Low power 0.3-50 kbps (uplink)
Table 1 summarizes various types of wireless communication technologies, their range, power con-
sumption, and theoretical data transmission rates. It is clear all technologies have their strength and
weaknesses, and, in order to build a wide-area, low-power network with good data throughput that is
required in WatchPlant, several of them need to be used together.
Figure 3: The schematic of the proposed hybrid Zigbee/LoRaWAN network. Zigbee and Zigbee/Lo-
RaWAN nodes collect measurements and send them to a sink. Zigbee/LoRaWAN nodes additionally
request acknowledgment that their messages are received. They count the number of failed transmis-
sions over a period of time and sent this number as a status message to a public LoRaWAN gateway. A
server-side application evaluates the status messages from all Zigbee/LoRaWAN nodes and can react by
sending reconfiguration messages back to the Zigbee/LoRaWAN nodes, which will then distribute the
new configuration using Zigbee broadcasts.
3 Methodology
For the first prototype of our heterogeneous sensor network, we have decided to use Zigbee and LoRaWAN.
The main differences between these technologies are communication range and bandwidth. Generally
speaking, Zigbee can transfer a lot of data fast over a short range, while LoRa can transmit less data,
but over a far longer range. The network uses the advantages of both technologies and uses Zigbee to
transmit measurement data and LoRaWAN to transmit control flow messages. During long-term net-
work deployment, we expect regular and long data messages, but only a few shorter control messages. In
a bigger network, data messages that are sent via Zigbee don’t have the range to be directly transmitted
to a data sink. Instead, Zigbee will utilize intermediary nodes as routers for multi-hop routing. This can
be problematic if intermediary nodes fail. LoRa, on the other hand, has a far higher range of multiple
kilometers. Using the LoRaWAN network, a LoRaWAN node can always directly communicate with a
LoRaWAN gateway without dependence on intermediary nodes.
The network design is displayed in Fig. 3. Zigbee nodes collect data and send it via Zigbee to the
4
WatchPlant - Technical report Developing a hybrid sensor network
sink. Zigbee/LoRaWAN nodes do the same, but they also have additional tasks. In contrast to pure
Zigbee nodes, they request an acknowledgment from the sink. They count over a fixed period of time how
many messages failed to get through and send the count to the nearest public TTN LoRaWAN gateway.
A server-side Python program evaluates the data and, if necessary, changes the network configuration.
For example, if only one of the LoRaWAN nodes reports failed messages, the Python controller can
assume that the network is damaged, but also that the damage is contained in a relatively small area,
i.e., the Zigbee/LoRaWAN node itself or a few intermediary Zigbee nodes. The majority of the network
(majority of Zigbee nodes and also the sink) is still intact. Otherwise, more Zigbee/LoRaWAN nodes
would have reported failed transmissions. As long as the majority of the network is still operating, there
is no need to react and change the configuration. The controller could also be used to send out an
email notification to the operators running the network to fix the broken nodes, but since the network
is data-centric, a few failed nodes are acceptable.
A bigger problem would be a failing data sink because the network would lose all data from all
nodes. In this case, a majority of Zigbee/LoRaWAN nodes would report failed transmissions. Now the
controller reacts and sends out a new network address to change the data flow to the backup sink. The
Zigbee/LoRaWAN nodes receive the new address as a LoRaWAN message and reconfigure their Zigbee
addresses. Then they broadcast the change to all Zigbee nodes in the network. In this way, only a small
portion of the information is lost.
Additionally, the operators can use the controller to change network settings remotely. We imple-
mented changing the measurement frequency of all nodes, but there are of course many more possibilities
depending on the sensor loadout and the requirements.
3.1 Zigbee node
The Zigbee node is the base of a sensor node. It has only Zigbee capabilities through the use of the
attached XBee module. We use STM32WB55 NUCLEO boards and USB dongles for processing the
data. For the power supply, we use a solar power manager board DFR0559 from DFRobot connected to
a 1500 mAh battery and a solar panel. These nodes are shown in Fig. 4 and the state machine of their
program is given in Fig. 7.
(a) A Zigbee node based on the NUCLEO board (b) A Zigbee node based on the NUCLEO
USB dongle
Figure 4: Two types of Zigbee nodes with optional solar panel
3.2 Zigbee/LoRaWAN node
Zigbee/LoRaWAN nodes are extensions of basic Zigbee nodes. They generally do the same task -
measuring data and sending it to the sink. In addition to their XBee modules, they also have LoRa
5
WatchPlant - Technical report Developing a hybrid sensor network
modules for LoRaWAN communication. They periodically send LoRaWAN messages over the nearest
LoRaWAN gateway to the server. The server is in this case a laptop that pulls the LoRaWAN messages
from the internet using the MQTT protocol and sends responses. For testing purposes, we used our own
LoRaWAN gateway that we registered with The Things Network, but registration of Zigbee/LoRaWAN
nodes with TTN allows us to use any connected community gateway. In this way, the whole network is
easier to deploy because it can use public infrastructure for communication. The used hardware consists
of a Heltec Wireless Stick v2.1, which includes a LoRa module, and a connected XBee. These devices
can also be powered by a battery and a solar panel. The node is displayed in Fig. 5 and its state machine
in Fig. 8.
Figure 5: A Zigbee/LoRa node based on the Heltec Wireless Stick. The black antenna to the right side
is used for LoRa/LoRaWAN communication.
3.3 Data sink
The primary sink used in the experiment was the custom-made, waterproof, autonomous data acquisition
unit called the Orange Box. The main processing unit inside the box is a Linux-based mini-computer
Rock Pi S, similar to the popular Raspberry Pi line of computers. The second sink was built out of a
Raspberry Pi 4 and an XBee module. Generally, every device that is able to interface with an XBee
can be used as a sink. However, the program of the sink uses Python and relies on a conventional file
system, so it is recommended to use mini-computers (or even desktop computers or laptops during tests
in the lab) instead of microcontrollers. The program on the sink just listens to the data and creates new
folders and files for each transmitting sensor node. The names of the files are based on the 64-bit MAC
addresses of the XBee modules.
3.4 LoRaWAN controller
Using LoRaWAN and The Things Network, the Zigbee/LoRaWAN nodes send their status messages to
the nearest TTN gateway. The controller downloads the messages from the TTN server. This requires
that the controller code is running on a device that has internet access. The controller is used for
periodically checking the network status and sending user commands.
To check the network status, it relies on received messages that notify the controller about failed
transmissions between Zigbee/LoRaWAN nodes and the sink. In our practical test, we used three
Zigbee/LoRaWAN nodes. In this scenario, the network was working under perfect conditions, so the
controller implements the following rule: "If the majority of Zigbee/LoRaWAN nodes report one or
more failed transmissions, the sink is assumed to have failed." The controller then sends a LoRaWAN
message back to the network containing an alternative sink address. This behavior assumes that the
addresses of all possible sinks are known. The controller cycles through all known link addresses if a
change is necessary. Selecting a good threshold of failed transmissions and reporting devices is a design
decision and it depends on the size and the structure of the network. In general, some messages can
6
WatchPlant - Technical report Developing a hybrid sensor network
Figure 6: Test network with 15 nodes: Two sinks (RPi on the left side, open Orange Box on the right
side), three Zigbee/LoRaWAN nodes, and 10 Zigbee nodes.
be expected to fail. The second task of the controller is to react to human input. An operator working
with the network might want to change network settings, like the measurement frequency of the sensor
nodes. This is possible over the internet using the controller, so that the network can be controlled and
monitored worldwide, as long as the operator has internet access. Depending on the task the network
should perform, a multitude of options can easily be added to the system.
3.5 Putting everything together
The code for all network components is available on Github2. In the laboratory test setup shown in
Fig. 6, we used a total of 15 devices: two sinks, three Zigbee/LoRaWAN nodes, and ten Zigbee nodes.
Failures of the sink and other nodes were simulated by disconnecting their XBee modules, effectively
disabling their communication. In our experiments, the network fulfilled the set expectations and proved
that our heterogeneous networking concept has great potential for further development and future use
in the project. Moreover, the network can be easily extended with additional types of devices. We have
developed the code for interfacing with the XBee module for the Arduino framework, Arduino through
PlatformIO, MBed OS, and Python. As long as a device can run any of these four options, it is easy to
integrate into the network.
As a next step, we plan to deploy the prototype in outdoor conditions for a longer period of time
and compare the performance of this novel wireless sensor network approach to networks with a single
communication technology.
4 Conclusion
We have developed a heterogeneous Wireless Sensor Network with a hybrid communication system
and successfully deployed the first prototype in our lab. Due to the use of two different communication
technologies, we were able to decouple the infrastructure for sending data messages and the infrastructure
for sending status and reconfiguration messages. In a more "traditional" WSN, the sink (base station)
has two responsibilities: receiving sensor data and sending out reconfiguration messages when it detects
errors. Using two infrastructures, we were able to split these responsibilities so that the LoRaWAN
controller is responsible for error detection and reconfiguration, and the sink is used only for data
collection. This reduces the bottlenecks in the network and increases overall robustness since the critical
roles are distributed to multiple devices. Furthermore, the LoRaWAN range can span over multiple
kilometers, so as long as there is a gateway close enough, the network can still be monitored and
configured even without direct access to the internet.
2https://github.com/trabbel/WP_network
7
WatchPlant - Technical report Developing a hybrid sensor network
Start
Setup, start
serial port
Start ZB timer
Timer
triggered?
Get
measurement
Send data
Received
message?
Execute command
no
yes
yes
no
Figure 7: Flowchart explaining the operation of Zigbee nodes.
8
WatchPlant - Technical report Developing a hybrid sensor network
Start
Setup, start
serial port
Join LoRaWan
network, start
LoRa timer,
counter=0
Start ZB timer
ZB Timer
triggered?
Get
measurement
Send data
Received
LoRaWAN
message?
Change own
settings
Broadcast
new settings
Received
Zigbee
message?
Message failed?
counter++
LoRa timer
triggered?
Send counter
reset counter
yes
no
yes
no
yes
no
yes
no
no
yes
Figure 8: Flowchart explaining the operation of Zigbee/LoRaWAN nodes. Blue nodes highlight Lo-
RaWAN communication, while orange nodes highlight Zigbee communication.
9
WatchPlant - Technical report Developing a hybrid sensor network
References
[1] L. García-Carmona, S. Bogdan, A. Diaz-Espejo, M. Dobielewski, H. Hamann, V. Hernandez-
Santana, A. Kernbach, S. Kernbach, A. Quijano-López, N. Roxhed, B. Salamat, and M. Wahby,
“Biohybrid Systems for Environmental Intelligence on Living Plants: WatchPlant Project,” in Proc.
of the Conf. on Information Technology for Social Good, GoodIT ’21, (New York, NY, USA),
pp. 210–215, Association for Computing Machinery, 2021.
[2] H. Hamann, S. Bogdan, A. Diaz-Espejo, L. García-Carmona, V. Hernandez-Santana, S. Kernbach,
A. Kernbach, A. Quijano-López, B. Salamat, and M. Wahby, “WatchPlant: Networked Bio-hybrid
Systems for Pollution Monitoring of Urban Areas,” in ALIFE 2021: The 2021 Conf. on Artificial
Life, MIT Press, 2021.
[3] H. M. A. Fahmy, “Wsns applications,” in Concepts, applications, experimentation and analysis of
wireless sensor networks, pp. 67–242, Springer, 2023.
[4] B. L. R. Stojkoska and K. V. Trivodaliev, “A review of internet of things for smart home: Challenges
and solutions,” Journal of cleaner production, vol. 140, pp. 1454–1464, 2017.
[5] D. Thakur, Y. Kumar, A. Kumar, and P. K. Singh, “Applicability of wireless sensor networks in
precision agriculture: A review,” Wireless Personal Communications, vol. 107, pp. 471–512, 2019.
[6] H. Alemdar and C. Ersoy, “Wireless sensor networks for healthcare: A survey,” Computer networks,
vol. 54, no. 15, pp. 2688–2710, 2010.
[7] V. C. Gungor and G. P. Hancke, “Industrial wireless sensor networks: Challenges, design principles,
and technical approaches,” IEEE Transactions on industrial electronics, vol. 56, no. 10, pp. 4258–
4265, 2009.
[8] S. C. Ergen, “Zigbee/ieee 802.15. 4 summary,” UC Berkeley, September, vol. 10, no. 17, p. 11, 2004.
[9] R. Heydon and N. Hunn, “Bluetooth low energy,” CSR Presentation, Bluetooth SIG https://www.
bluetooth. org/DocMan/handlers/DownloadDoc. ashx, 2012.
[10] LoRa Alliance, “LoRaWAN specification.” https://lora-alliance.org/resource_hub/
lorawan-specification-v1-1/, 2023. Last Accessed: 2023-05-12.
[11] D. Croce, M. Gucciardo, S. Mangione, G. Santaromita, and I. Tinnirello, “Lora technology demys-
tified: From link behavior to cell-level performance,” IEEE Transactions on Wireless Communica-
tions, vol. 19, no. 2, pp. 822–834, 2019.
[12] S. Atanasov, “An overview of wireless communication technologies used in wireless sensor networks,”
in International Scientific Conference eRA-8, pp. 11–18, 2013.
[13] X. Feng, F. Yan, and X. Liu, “Study of wireless communication technologies on internet of things
for precision agriculture,” Wireless Personal Communications, vol. 108, no. 3, pp. 1785–1802, 2019.
10