Content uploaded by Alexander Liu Cheng
Author content
All content in this area was uploaded by Alexander Liu Cheng on Aug 15, 2020
Content may be subject to copyright.
978-1-7281-3764-3/19/$31.00 ©2019 IEEE
Development of an Adaptive Rainwater-Harvesting
System for Intelligent Selective Redistribution
Alexander Liu Cheng1,2, Luis Morán Silva2, Martín Real Buenaño2, Nestor Llorca Vega2,3
1Faculty of Architecture and the Built Environment, Delft University of Technology, Delft, The Netherlands
2Facultad de Arquitectura e Ingenierías, Universidad Internacional SEK, Quito, Ecuador
3Escuela de Arquitectura, Universidad de Alcalá, Madrid, Spain
E-mail: a.liucheng@tudelft.nl, {lmmoran.mapi, cmreal.mapi, nestor.llorca.arq}@uisek.edu.ec
Abstract—This paper presents an adaptive rainwater-
harvesting (RWH) system based on a rainwater-collecting unit
that (1) ascertains baseline water-quality in its collected
rainwater via Ph- and turbidity sensors, and (2) redistributes it
to designated toilet-tanks and/or irrigation points. Each unit is
integrated with an XBee S2B antenna to enable cost-effective
and energy-efficient mesh capabilities for inter-unit
communication when two or more units conform the system.
Moreover, each unit is also an Internet-of-Things (IoT) device
that transmits water-tank levels and sensor-data to a local
supervising microcontroller (MCU) via Open Sound Control
(OSC). This MCU is, in turn, capable of communication with a
cloud-based data plotting / storing and remote-control
platform—viz., Adafruit IO—via Message Queueing Telemetry
Transport (MQTT). The interface with Adafruit IO enables a
remote administrator (a) to monitor water-tank levels and
sensor readings, and (b) to execute manual overrides in the
system—for example, any or all of the units may be shut-down
remotely. When only one unit conforms the system, its water-
tank services the toilet-tanks and/or irrigation points connected
to the unit. When two or more units conform the system, their
water-tank outputs are physically linked, enabling any unit to
contribute to the servicing of a variety of connected toilet-tanks
and/or irrigation points. In both single or multi-unit
configurations, water redistribution is impartial to any end-
point at initialization, yet over time the system identifies which
end-point(s) require(s) water with a higher frequency and
selectively prioritizes servicing to it/them to guarantee prompt
refill / supply. The present work is part of ongoing developments
of features and services that attempt to imbue the built-
environment with intelligence via Information and
Communication Technologies (ICTs).
Keywords—Internet-of-Things, Cyber-Physical Systems,
MQTT, Adaptive Architecture, Intelligent Built-Environment.
I. INTRODUCTION
Rainwater-harvesting (RWH) systems can play an
important role in providing limited alternatives to sources
dependent on conventional water treatment to meet present
water requirements [1]. Their versatile character enables them
to be implemented in a variety of application domains
including: cleaning services [2], farming and agriculture [3,
4], and—to a limited extent—healthcare [5], etc. Incidentally,
although most of its uses are non-potable, some users have
explored their potable potential—for example, 25% of
respondents in a survey conducted on members of the
American Rainwater Catchment Systems Association reported
to use rainwater for potable purposes [6].
The present paper situates RWH systems within the
intelligent built-environment discourse. The detailed RWH
system is presented as an open-ended and highly scalable
system for the intelligent selective redistribution of collected-
water (with tolerable Ph and turbidity levels) to toilet-tanks
and/or limited irrigation points based on the frequency of
requirement. The system is a Cyber-Physical System (CPS)
[7] composed of one or more rainwater-collecting units
designed as Internet-of-Things (IoT) devices capable of
communicating with one another (when consisting of two or
more units) and with a cloud service (viz., Adafruit IO [8]) via
a supervising Microcontroller Unit (MCU). Data pertaining to
water-tank levels as well as sensor-readings from each module
is streamed to said cloud service, which also enables override
interventions in the system’s local operation (see Section II
and Section III for technical details). The physical /
mechanical resolution of the system is developed to a
Technology Readiness Level (TRL) [9] of 4, while its
informational / computational resolution—which is based on
established Information and Communication Technologies
(ICTs)—is developed to a TRL of 9. The RWH system
represents a highly technological (in terms of ICTs) type of
RWH systems, one capable of open-ended scalability; and of
employing ICTs to enhance its serviceability and performance
over time. In the context of the authors’ ongoing
developments of features and services that attempt to imbue
the built-environment with intelligence, the system is
construed as a potential sub-system within a larger highly
heterogeneous ecosystem sustained by a self-healing and
meshed Wireless Sensor and Actuator Network (WSAN),
whose underlying System Architecture is presented and
detailed elsewhere by the authors [10].
The development of the system is presented in five
sections. In Section II, the Concept and its corresponding
Approach are described in detail. In Section III, the
Methodology and Implementation of two instances of a fully
functional prototype are described. In Section IV, sample
Results are presented and discussed. Finally, in Section 0, a
Conclusion including a discussion of limitations as well as
future development and application is provided.
II. CONCEPT
Figure 1. System layers: (1) collection of rainwater; (2) 1st storage tank; (3)
2nd storage tank, measurement of Ph-levels; (4) 3rd storage tank, measurement
of turbidity—if levels exceed 5 NTUs, the water is released to the main,
otherwise it is passed through (5) a ceramic filter in the 4th tank (if between
3.5 – 5 NTUs), or sent directly to the (6) 5th and general collection tank (if
<3.5 NTUs); (7) Outlet for all releases to the main water system; (8) 6th water
tank, representing a toilet-tank; (9) if the toilet-tank is full, contained water
in the 5th tank is released for irrigation.
The operation of each rainwater-collecting unit in the
RWH system consists of nine layers (see Figure 1 and Figure
4). In the first layer, rainwater is collected via a funnel—
equipped with a meshed filter to exclude visible particulates—
installed directly below designated water-draining points
(typically on the roof and/or on regions of walls immediately
below the roof). Alternatively, and instead of the funnel, a
drain-pipe connected to a protected water-catchment point
may be directly connected to the unit. The water is collected
into the storage tank of the second layer, which holds collected
water until a minimum of one liter is obtained. In the third
layer, the Ph-levels of the water are gauged, and if it is either
hazardously acidic or basic, it is immediately released to the
main water system. If, however, the Ph-levels are within 6 to
8.5, the water is passed to the storage tank of the next layer. In
the fourth layer, the water’s turbidity levels are gauged. If the
water exceeds 5 Nephelometric Turbidity Units (NTUs), it is
released to the main water system.
Figure 2. Deployment Configurations. Top-Left: a single-unit system
servicing a single tan. Top-Right: a multiple-unit system servicing a single
tank. Bottom-Left: a single-unit system servicing multiple tanks. Bottom-
Right: a multiple-unit system servicing multiple tanks. N.B.: ‘~’ symbol
indicates location of servovalve & water-flow sensor.
If, however, it is between 3.5 to 5 NTUs, the water is
passed to the fifth layer for filtering. And if turbidity levels are
below 3.5 NTUs, it is passed directly to the sixth layer,
bypassing the need for filtering. All collected water with non-
hazardous Ph- and turbidity-levels is stored in the tank of the
sixth layer, which has a maximum capacity of ten liters. A
water-sensor is attached near the rim of the water tank, which
informs all previous tanks to withhold passing water until
levels are reduced. The tank in the sixth layer itself cannot
overflow, as an outlet connected to the main water system is
installed near the rim. The seventh layer is where all the
connections to the main water system meet into a single outlet.
The eighth layer represents the toilet-tank, although it may
also represent a reserve tank additional to the toilet-tank
depending on the requirements of the user. Finally, the ninth
layer represents the irrigation outlet, which is optionally
engaged—likewise by means of servovalves—as a release
mechanism when the tanks are at full capacity.
When the system is conformed by a single unit or multiple
units servicing only one toilet-tank (see Figure 2, Top-Left and
Top-Right), no reconfiguration of parameters is required in the
unit’s program or electronics. In the case of a single-unit
system servicing multiple toilet-tanks (see Figure 2, Bottom-
Left), the outlet pipe of the ten-liter tank furcates to correspond
to and connect with each toilet-tank. Immediately past the
point of furcation, corresponding servovalves and water-flow
sensors are attached at the root of each diverging pipe. Minor
modifications to the unit’s program and addition of the
servomotors to the MCU must be undertaken to meet the
physical configuration demands. N.B.: In the present TRL-4
RAINWATER-COLLECTING UNIT
physical design, each unit is capable of servicing a maximum
of two ultra-low-flow toilet-tanks (~six liters per flush) in
situations of simultaneous flush, provided that the storage
tanks across all operation layers are full. In Figure 2, Bottom-
Left, the output of the ten-liter tank of system C’s unit
bifurcates to connect to toilet-tanks 3 and 4, with a
servovalves and water-flow sensor integrated at each
furcation. The flushing of either toilet-tanks 3 or 4 (or both) is
detected by the water-flow sensor—i.e., as the toilet-tank
empties, a pressure differential draws water from the system.
If toilet-tank 3 is to be prioritized due to a detected higher
frequency of usage, then the servovalve controlling the flow
to toilet-tank 4 is restricted (see Section 0 for the reasoning
behind such selective restriction). In the case of a multi-unit
system servicing multiple toilet-tanks (see Figure 2, Bottom-
Right), the ten-liter tank outlets of all units are linked into one
outlet in order to instantiate a single source of collected
rainwater. As in the case of a single-unit system servicing
multiple toilet-tanks, the single-source outlet furcates to
correspond to and connect with each toilet tank, where a
servovalve and a water-flow sensor is attached at the root of
each furcation. This setup also requires minor
reconfigurations to the program and electronics of each unit.
The same selective restriction by servovalves at the furcation
of pipes enables a selective prioritization of service to a given
toilet-tank.
As the RWH system is a CPS, in parallel to the above-
mentioned activities, a corresponding set of activities taking
place informationally / computationally are also taking place
in tandem correspondence. As stated briefly in the
Introduction, all sensed data and water-tank levels are
transmitted by each unit to a supervising MCU. Moreover, the
states of all servovalves and water-flow sensors (in cases of a
single-unit system or a multiple-unit system servicing
multiple toilet-tanks) is also communicated to said MCU. This
MCU first verifies if malfunctions have occurred—i.e., if the
unit or units have deviated from expected states and ranges. If
it has, the MCU shuts the system down automatically.
Regardless of malfunction, all received sensor and actuator
data across the system (i.e., across all units in the network) are
streamed to a cloud-based data plotting / storing and remote-
control platform, viz., Adafruit IO via Message Queueing
Telemetry Transport (MQTT) (see Figure 5 for sample
streamed-data plots). A remote administrator—say, the owner
or care-taker of the building—is able to view the states of all
sensors and actuators across all units in the deployed system.
He/she can also intervene with a manual override via MQTT
to the local system. For example, suppose tank 3 in Figure 2,
Bottom-Left is being selectively prioritized by the local system
due to a detected high frequency of use. In such a case, the
remote administrator could override this to prioritize tank 4 or
to reset all priority weighs to instantiate an initial state of
impartial distribution. Furthermore, the setup enables the
remote administrator to shut-down all units across a system
during a dry period. The ability to interact with the system
remotely is one of the salient characteristics of the present
system, and one that may be expanded to include non-human
control. For example, instead of a remote administrator
deciding that a period is dry, this may be objectively
determined via Dark Sky [11], which works with Adafruit IO.
III. IMPLEMENTATION
Figure 3. System breakdown: (A) rainwater downpipe; (B) water-level
switch; (C) 1st container, 1L capacity; (D) servovalve; (E) Ph sensor; (F)
water-level switch; (G) 2nd container, 0.5L; (H) manual valve, representing
flush-lever / -handle; (I) water-level switch, representing toilet tank-float; (J)
6th container, 5L, representing toilet-tank; (K) water-level switch; (L)
turbidity sensor; (M) 3rd container, 0.5L; (N) servovalve (O) servovalve; (P)
4th container, 0.5L; (Q) ceramic filter; (R) servovalve; (S) servovalve; (T)
water-level switch; (U) water-pump; (V) 5th container, 10L; water-sensor
installed to measure levels; (!) overflow-outlet; (~) outlet to the main, for
harmful Ph levels; (=) outlet to the main, for high turbidity levels; (*) intake
to toilet water-tank; (^) outlet to irrigation (when toilet water-tank is full).
The physical / electronic part of the system is built with
three ¼” tie-rods, six acrylic water-tight tanks, a ceramic
water-filter (particular to dissolved solids), a 2” funnel,
threaded hoses, and triplex wood (see Figure 3 and Figure 4).
Figure 4. System layers, photograph of one of two implemented prototypes.
N.B.: Numbered items correspond to those detailed in Figure 1.
With respect to the ICTs: each unit is integrated with an
XBee S2B antenna via a shield on its MCU to enable cost-
effective and energy-efficient mesh capabilities for inter-unit
communication when two or more units conform the system.
Each unit is designed as an IoT device that transmits water-
tank levels, Ph- and turbidity sensor-data, servovalve states,
and water-flow sensor-data to a local supervising MCU built
with a WiPy 3.0 board on a PySense shield. This local
transmission takes place via OSC. The supervising MCU, in
turn, streams gathered data every minute to Adafruit IO via
MQTT. The communication between the supervising MCU
and Adafruit IO is programmed with Adafruit IO’s API in
MicroPython.
Once one prototype was successfully built and tested, a
second instance is built in order to simulate a two-unit system
servicing two toilet-tanks (see Figure 2, Bottom-Right). To
undertake functionality tests, the toilet tanks are simulated
virtually to gauge the behavior of the prototypes in a simpler
manner. All other systems are implemented fully and
functionally using commercial and/or open-source TRL-9
ICTs. Nevertheless, since the TRL of a system is determined
by the TRL of the least-mature sub-system or component, the
present overall implementation is at TRL 4.
IV. RESULTS
Figure 5. Plotting by Adafruit IO, one-minute intervals. Top-Down: Toilet-
tank levels A&B; Prioritizing tank A (blue); Ph- and turbidity-levels, unit A.
1
2
3
4
5
6
7
8
9
The prototypes were tested in several configurations and
scenarios continuously for a period of 24 hours. During this
time, the local supervising MCU disconnected from Adafruit
IO twice due to an exceeding of streaming frequency rates for
free-accounts. This was resolved by slowing the streaming to
once every minute. During this period, negligible leakage was
observed in a number of servovalves, which was resolved via
software by reconfiguring rotation values. Also, the ceramic
filter’s rate of filtration was measured to be unacceptably slow
for a higher TRL development, and hence a new filter was
purchased. Nevertheless, the physical / electronic part of the
system performed as expected. As may be gathered by the first
and top image of Figure 5, the transmission of sensor-data
from rainwater-collecting units A and B to the supervising
MCU, and then from this latter to Adafruit IO was successful.
Also, as shown in the second image of the same Figure,
selective prioritization of toilet-tank A’s levels (plotted in
blue) was verified in a simulated synchronized flushing of
both tanks, as toilet-tank A refills more rapidly and to a higher
level than toilet-tank B. Finally, the two bottom images in
Figure 5 show successful tracking of Ph- and turbidity sensor-
values transmitted from unit A.
V. CONCLUSIONS
This paper presented an adaptive RWH system based on a
rainwater-collecting unit capable of ascertaining baseline
water-quality in its collected rainwater via Ph- and turbidity
sensors, and of redistribution it to designated toilet-tanks
and/or irrigation points. As an RWH system, it represents one
of the first IoT and CPS solutions that imbues remote control
capabilities via cloud services. Its performance was reliable
and its implementation cost-effective. The authors view the
system as an appropriate solution for low-income housing
communities, where water scarcity renders waste of potable
water untenable.
A word on the reasoning behind selective prioritization of
distribution of collected rain-water: it may be argued that such
a selective prioritization of toilet-tank refills is trivial, as
regardless of which toilet-tank is prioritized, others will still
be filled by the main water system. While this consideration
is true, the objective with selective prioritization is not an
argument for independence from the main water system, but
one for a reduction of consumption from said system. That is
to say, if toilet-tank A is actually used five times more
frequently than toilet-tank B, then allocating as much
collected rainwater to toilet-tank A does indeed represent a
reduction of consumption from the main water system. Of
course, if the difference in usage is negligible, then the
selective prioritizing of refills inherits is almost trivial.
However, when viewed in the long run, even if one toilet-tank
is flushed one time more than others, savings will accumulate
over time. Economic considerations aside, selective
prioritization reduces waste.
ACKNOWLEDGEMENTS
The authors acknowledge the assistance of Adolfo Duarte,
Daniela Duque, Jean Carlos Montero, Saskya Sangurima,
students at Facultad de Arquitectura e Ingenierías,
Universidad Internacional SEK, who contributed to the
implementation of the prototypes. Also, the authors thank
Juan Balseca, a student at Facultad de Ingeniería Eléctrica y
Electrónica, Escuela Politécnica Nacional, who assisted in
the test-run programming at initial stages but whose program
was not used in the present implementation.
REFERENCES
[1] M. V. Vargas-Parra, M. R. Rovira-Val, X. Gabarrell, and G. Villalba,
“Rainwater harvesting systems reduce detergent use,” Int J Life Cycle
Assess, vol. 24, no. 5, pp. 809–823, 2019.
[2] Sanches Fernandes, Luís F., Terêncio, Daniela P.S., Pach eco, Fernando
A.L., “Rainwater harvesting systems for low demanding applications,”
Science of The Total Environment, vol. 529, pp. 91–100, 2015.
[3] J. F. Velasco-Muñoz, J. A. Aznar-Sánchez, A. Batlles-delaFuente, and
M. D. Fidelibus, “Rainwater Harvesting for Agricultural Irrigation: An
Analysis of Global Research,” Water, vol. 11, no. 7, p. 1320, 2019.
[4] M. A. Macias-Corral and I. Sanchez-Cohen, “Rainwater harvesting for
multiple uses: A farm-scale case study,” (en), Int. J. Environ. Sci.
Technol., pp. 1–10, https://link-springer-
com.tudelft.idm.oclc.org/content/pdf/10.1007%2Fs13762-018-02200-
7.pdf.
[5] K. W. Koenig, “Rainwater harvesting: Vortex filters make cost savings
at German hospital,” Filtration + Separation, vol. 51, no. 1, pp. 36–38,
2014.
[6] R. B. Thomas, M. J. Kirisits, D. J. Lye, and K. A. Kinney, “Rainwater
harvesting in the United States: A survey of common system
practices,” Journal of Cleaner Production, vol. 75, pp. 166–173, 2014.
[7] S. Ochoa, G. Fortino, and G. Di Fatta, “Cyber-physical systems,
internet of things and big data,” Future Generation Computer Systems,
vol. 75, pp. 82–84, https://www-sciencedirect-
com.tudelft.idm.oclc.org/science/article/pii/S0167739X17311196/pdf
ft?md5=67689f695d26ac87b30f1765c457e09f&pid=1-s2.0-
S0167739X17311196-main.pdf, 2017.
[8] Adafruit®, Adafruit IO. [Online] Available: https://io.adafruit.com/.
Accessed on: Aug. 14 2019.
[9] European Association of Research and Technology Organisations
(EARTO), The TRL Scale as a Research & Innovation Policy TOOL:
EARTO Recommendations. [Online] Available:
http://www.earto.eu/fileadmin/content/03_Publications/The_TRL_Sc
ale_as_a_R_I_Policy_Tool_-_EARTO_Recommendations_-
_Final.pdf. Accessed on: Jan. 07 2015.
[10] H. Bier, A. Liu Cheng, S. Mostafavi, A. Anton, and S. Bodea, “Robotic
Building as Integration of Design-to-Robotic-Production and -
Operation,” in Springer Series in Adaptive Environments, vol. 1,
Robotic Building, H. Bier, Ed., 1st ed.: Springer International
Publishing AG, 2018.
[11] The Dark Sky Company, LLC., About Us. [Online] Available:
https://darksky.net/about.
