This project is a remote monitoring system developed for the Water Wall of the Blue Diversion Autarky Project, developed at EAWAG.
Insufficiently treated reused water can transmit diseases[1]. It is necessary to ensure that the treated water is microbially safe at all times[2]. To monitor the microbial water quality in the clean water tank, to ensure sufficently high microbial water quality, currently, the operator must perform biweekly, onsite water sampling[3]. This is time-consuming, cost-inefficient and limits the possibility of performing high-quality field tests.
This RMS (Remote Monitoring System) project aims to tackle this challenge by providing a real-time, online microbial water quality prediction system. This RMS communicates problems to operators (in order to fix the problem) as well as to users (to make sure they are made aware in case the water is unsafe).
This RMS is an implementation of the machine learning model developed at EAWAG[4]. Currently, the only input parameter is the ORP reading. Decision making of water being safe or unsafe is based on a cut-off value found from the trained model. In practice, this value may be set by the operator, according to their needs.
If you need guidance or assistance, please feel free to contact me at cedricormond@gmail.com.
If you are using the project directly from the github, please make sure you do not push any modifications, and only use the release (rel) branch for using the RMS.
This project was developped using VSCode and the platformIO extension.
This branch is organised in 2 folders:
- final_project
- misc
This folder contains the source code for the project. If you want to build and upload the platformIO project to your prototype, you will need to navigate your way to this branch and follow the instructions provided in Section 2.3.
This folder contains aditional files useful for the project.
This section details the step to take to start using the device.
To use the RMS:
- clone this repo, and make
sure you are on the
relbranch (git checkout rel). You may alternatively download the .zip file from the DOI link provided at the top (recommended) - in the terminal, navigate your way to the final_project folder
(
cd yourPath/RMS/final_project) - in the terminal, type
code .. (You will need to have installed and downloaded VSCode beforehand. Make sure you have the platformIO IDE added to your VSCode) - assemble the hardware from Section 3 as shown in figure Figure 1
- configure settings as described in section Section 2.3.1.1
- build the project in VSCode
- upload the platformIO project to the board. Once uploaded, the device will automatically start
If the device is used for the first time, make sure the device is connected to a PC. This will help debugging potential wrong settings.
The first automatic run will create a RMS_V1.CFG file, with default, hard-coded settings. Once the device has run at least once, you can safely disconnect all power supply, remove the SD card, and easily tune the configuration settings.
Alternatively, you can easily upload the RMS_V1.CFG file to the SD card before the first run. RMS_V1.CFG can be found in the “misc” folder.
The parameters that may be tuned during the configuration are the following.
logitThreshold : (mv) any ORP reading above this value will translate into a safe waterquality. The appropriate setting may be found from running the code in[4].
uraPressDuration : (ms) how long the user should press the button for an alarm to be raised. In case an SMS has already been sent less then uraSMSInterval, only a water monitoring will occur, but no SMS will be spamming the user.
hbTargetHour : (hour, 24) at what time should a heartbeat be sent to the operator.
hbIntervalHour : (hour) at what frequency should the heartbeat be sent, starting from the hbTargetHour. Ensure this value is less or equal to 24. For example, consider hbTargetHour = 9 and hbIntervalHour = 6. A heartbeat will be sent to the operator at 9:00, 15:00, 21:00, 03:00. Please note that the exact time at which a heartbeat is sent is the closest time to the aforementioned full hour, plus a maximum of s/u/fwqSleepPeriod. Indeed the heartbeat SMS is sent after the device woke up for a watermonitoring function.
swqSleepPeriod : (s) how much time should elapse between two water monitoring events, from the water quality being safe.
uwqSleepPeriod : (s) how much time should elapse between two water monitoring events, from the water quality being unsafe.
fwqSleepPeriod : (s) how much time should elapse between two water monitoring events, from having received a faulty ORP reading.
uraSMSInterval : (s) how much time should elapse, before a new SMS can be sent to the operator, informing them that the user raised an alarm. This is to prevent spamming the operator with notifications in case the user uses too often the button press.
wmSMSInterval : (s) how much time should elapse, before a new SMS can be sent to the operator, updating them on the waterquality status, after an unsafe or faulty reading was first detected. This is to prevent spamming the operator with notification in the case of unsafe water quality or faulty reading.
sendSMS : (boolean) sets whether the SMS should be sent to the operator or not.
remoteNumberLength : (integer) holds the length of the operator phone number.
remoteNumber : (string) holds the operator phone number. Make sure to include the country code: for example “0041798837769” for a Swiss number.
When the RMS is started, in case of problems during initialisations, LEDs provide some feedback.
One or two LEDs are on, to indicate what region is affected, while another LED will blink to differentiate between the possible causes for the issue. The table below provides a guide to debug potential problems.
| Region | Exact problem | On LED | Blinking LED |
|---|---|---|---|
| Battery | Battery not conected | Orange | Red |
| Battery | Low battery energy level | Orange | Yellow |
| SD Card | Failed to initialise | Green | Red |
| SD Card | Failed to create a valid filename | Green | Yellow |
| SMS | Inappropriate phone number | Yellow | Red |
| RTC | Failed to initialise internal RTC using external RTC | Green + orange | Red |
| RTC | Failed to set-up heartbeat | Green + orange | Yellow |
| Unknow | Unknown error | Red | Blue |
The following components were used for the prototype. For ease of reproducibility, links to the used suppliers are provided. The final cost of the hardware amounts to just under CHF 390, including the sensor.
In case this project is carried forward, or reused, below are some directions to take, to try and improve the project further.
If the RMS is off the grid power, and has been running on the battery
for some time, the battery voltage will drop. We have set a
batteryEmptyVoltage at 3.5V. If the voltage drops below 3.5V +
0.05x3.5V, the device enters a
criticalEL
state, and must go to deepSleep, so as to consume as little as power
possible, while informing the user that the device is not running.
However, if the grid power eventually turns back on, we want the device to be able to power back up. For this to occur, just before going to sleep, an interrupt from the PMIC is attached to the arduino. That way, if the PMIC detects a stable power supply, it may interrupt the Arduino, thus waking it up. This is another reason why we send the device to deep sleep, and not completely off.
Because of the amount of time it takes to deplete the battery, thorough test could not be performed.
What remains to be tested, is whether the device can effectively carry on its usual routine after the device has woken up from a deep sleep.
Also, we want to know what happens when the battery voltage gets too low. Will the circuit disconnect?
Currently, a lot of variables are being stored inside the
rmsrmsClass
class object instance. Some of which are updated during the setup phase
with values from the configuration struct
ConfigurationStruct
cfg. These values where either read from the SD card, or set from the
default settings. This is the case for
- SWQ sleep duration
- UWQ sleep duration
- FWQ sleep duration
The code may be modified so that it uses the values in the struct
ConfigurationStruct
cfg instead of that from the
rmsClass
rms. This would allow to make the
rmsClass
object lighter and easier to read.
Nonetheless, if one wants to include more sensors, the following steps
should be included to the function FSM_implementMLDecision
-
Using the code, accessible from the paper[4]
- Extract the standardization parameters (mean + SD) from the training dataset
- Extract the PCA components from the training dataset
- Extract the β and α0, …, αn parameters from the model
-
Extract the most conservative threshold probability, based on target values set (LRTMS2, or LogICC)
-
Standardize the input parameters, using the input parameter from the trained model
-
PCA the input parameters, using the input parameter from the trained model
-
Pass the transformed input parameters, into the probability function
-
Compute the probability
-
Compare the probability with the probability limit found from training
Currently, the RMS ID is hardcoded inside the source code, as a RMS_ID
macro inside the ‘Constant.h’ file.
This RMS_IDis the first item to appear on any SMS sent to the
operator. That way, they may identify what RMS and thus Water Wall has
issues.
An alternative to this method may require to set the RMS_ID as part of the ‘RMS_V1.CFG’ file on the SD card. Some minor, easily implementable changes to the source code would be required for this.
1. Howe, K. J., Hand, D. W., Crittenden, J. C., Trussell, R. R., & Tchobanoglous, G. (2012). Principles of water treatment [Book]. John Wiley & Sons.
2. Organization, W. H. (2016). Quantitative microbial risk assessment: Application for water safety management [Journal Article].
3. Sutherland, C., Reynaert, E., Dhlamini, S., Magwaza, F., Lienert, J., Riechmann, M. E., Buthelezi, S., Khumalo, D., Morgenroth, E., & Udert, K. M. (2021). Socio-technical analysis of a sanitation innovation in a peri-urban household in durban, south africa [Journal Article]. Science of the Total Environment, 755, 143284.
4. Reynaert, E., Steiner, P., Yu, Q., D’Olif, L., Joller, N., Schneider, M. Y., & Morgenroth, E. (2023). Predicting microbial water quality in on-site water reuse systems with online sensors [Journal Article]. Water Research, 240, 120075. https://www.sciencedirect.com/science/article/pii/S0043135423005110?via%3Dihub