Responsive image

Our Develop Team

Students from the course of Ambient Intelligence in Politecnico di Torino

Eduardo Henrique Fonseca Moreira

Software Developer

Andrea Galeone

Hardware Developer

João Calado Vicente

Software Developer

Giuseppe Galati

Hardware Developer


The WWW allows you to keep your water system under control.

Stop water wasting

Reduce our water bill

Have a better chance to save our home

It is designed for big buildings such as factories and especially public places like theaters or anything managed by the public administration, where a single functionary has to do the maintenance. Through a user-friendly UI, the functionary will be able to control every single duct covered by the WWW system.

What does WWW actually do It detects if a duct in the system is broken or, by detecting the flux of water, if there is any trouble in the pipes (for example, if it is obstructed). The HUD will inform the user, after evaluating and choosing the hypothesis with the highest probability between different choices, such as a broken duct, leak, obstructed duct and so on. It will detect which pipe is malfunctioning, so that the user can find it quickly.

    Also, the WWW is modular. It means that you can install as many sensors as you need, you can use it in one area or in the whole building, and in one or more buildings, by adding sensors and control boxes linked to a single account and to the main system. These will be useful for the public administration because it must keep track of a big infrastructures under control.

    The system can act instead of the user. If the functionary is far away or even can't reach the place in which he should operate, WWW is able to fix or minimize the damages while waiting for user intervention; it closes valves to block the leaks.

Ambient Intelligence Features


Evaluate the water flux difference between 2 or more duct checkpoint, to find damaged or obstructed (total or partial) ducts; sensing the local temperature to prevent freezes


Suggest different hypothesis, evaluated by the data captured by the sensors, of the most probable damage or issue, and the best course of action to solve the problem. Evaluate average daily consumption and, if possible, try to find a way to reduce it


Close broken valves that are detected by the sensors, warm pipes with a Thermo-box


Communicate to the user the location and the type of issue, allow the user to control different areas by an HUD, if chosen, could act without waiting for the user input

AmI feature Description
Sensitive With a large amount of different sensors, it could detects water fluxes, temperature, leaks. They are autonomous, one kind is not necessary to make the others work.
Responsive The system could act quickly instead of the user, and automatically (if this mode is previously chosen by the user)
Adaptive Two ways of operating: as an assistant or in total autonomy
Transparent The user is called only when necessary
Ubiquitous A single system could manage one or more buildings, and be managed by one or more people
Intelligent Suggest different solutions evaluating the data acquired


The goal of the system is to prevent, find and contain water leaks avoiding water waste. As an intelligent system, Water Waste Watcher (WWW) is able to help the user in his daily work detecting possible leaks and damages on ducts and act on the water system to eliminate or, at least, limit the damages waiting for the user intervention.

For big buildings the difficulty on its control and management is also high becoming harder to find where and why water is being wasted. The WWW aims to contain the losses generated by damages on the water transport system. It is especially designed for buildings that need continuously maintainance and that offers difficulty to track broken ducts; That way, WWW system is meant to be used by the team responsible for the maintainance of these buildings.


  • HW Box: Set of hardware and sensors connected to the pipes.
  • Influence Area: The area where the sensors work and the hardware acts.
  • HUB: Central hardware that receives information from local hubs.
  • Local Hub: Hardware that collects information from all the different sensors.
  • Talk: Local hub interaction (sending and receiving information from local hubs).
  • Sensors: Volumetric, humidity and temperature sensor.
  • Water Leaks: Caused by broken pipes, open faucets, or malfunctioning hydraulic systems.
  • Electro-Valves: Valves that open or close ducts through an electrical impulse.


The system is created for technicians involved in the maintenance of large buildings, such as schools or hospitals.

Functional Area

ID Functional Area Description
1 User User login, registration and logout
2 Preferences Interface for setting user preferences
3 Notifications Notifications sent by the system to user devices
4 Monitoring and Sensing Receiving data from sensors and be capable to keep an area under control
5 Activation Activation of the hardware

Functional Requirements

The ID of the Functional Requirement is linked to the correspondent Functional Area of the Requirement. For example, the Functional Requirement 2.1 is the first requirement of the Functional Area number 2 (Preferences)

ID Title Description Priority
1.1 Login User login to the private area 3
1.2 Logout User logout of the private area 3
1.3 Sing-in User Registration to save preferences on the cloud 3
2.1 Measure Unit Choose the measuring unit 2
2.2 Box Name Set the name of a single operative unit 1
2.3 Wait Time For Broken Ducts Set the time that the system should wait until automatically act on broken ducts, closing the water flow 2
2.4 Wait Time For Obstructed Ducts Set the time that the system should wait until automatically act on obstructed ducts, closing the water flow 2
3.1 Leaking Notification Receive notifications about a leaking duct 1
3.2 Obstruction Notification Receive notification about an obstructed duct 2
3.4 Data Show data of wasted water 2
3.5 Acting Notification Send the user a notification and the request for autonomous activation or user intervention 1
4.1 Broken Duct Recognize a broken duct 1
4.2 Obstructed Duct Recognize an obstructed duct 2
4.3 Water Waste Evaluate the waste produced by a leak 2
4.4 Solution Checker Check for a solution for the broken or obstructed duct 1
5.1 Brake Leak Close the water flow of a leaking duct 1
5.2 Brake Obstruct Close the water flow of an obstructed duct 2

Non-Functional Requirements

ID Description Area
1 The system must be easy to use so that the user might be able to do the tasks with less than 4 steps Usability
2 The system must run on a computer with access to the internet Connectivity
3 The system should store all the information in a database Data Integrity
4 The system should be developed using the Python3 programming language Implementation
5 The system should be up and running without errors for more than 95% of the time for every user Reliability
6 The system should have Electro-Valves, Thermo Boxes, Flux and Proximity sensors as part of its hardware components Implementation
7 The system must be able to provide notifications to the user within 5 seconds of an occurrence, and if any action is possible, execute it Efficiency
8 The user terminal must be able to interact with the physical system Interoperability
9 The web-application should run on any of the given browsers: Google Chrome, Firefox, Internet Explorer, Edge, Safari and Opera Portability

System Architecture

The image below represents the system architecture:

A "Box", located on the facility's ducts, is composed by flux sensors and it is meant to detect the flux amount variations in the area of influence. Those sensors interact with a "Local Hub" that can act by theirselves, activating the local electro-valves (Actuators) to regulate the water flux. The "Local Hub" is also responsible to provide the data gathered of different ducts to the "Main Hub" that will show all these informations on the application running on the "PC" to the "User". This application is a web-app accessible to the users in charge of the maintenance of the building.

Architecture Image

Hardware Architecture

Hardware Components

Number Name Description
1 Flow Sensors (Box) Pixnor G34 External Thread Flow Sensor
2 Local Hub Arduino UNO R3
3 USB Cable USB 2.0 Cable Type A/B
4 Main Hub Client's Server
5 PC User's personal computer

All the items present on the Hardware Architecture are Off-the-Shelf components (OTS). Meaning that there were not necessity of building any hardware specific for this project. Only the assemble of the listed components.
Each component is used to achieve a specific Requirement (more details at the Functional Requirements section) and at the end of each description these requirements are presented.

Flow Sensors

Used to measure water flow in the water system's ducts. Composed by a rotor that detects the amount of water flowing by evaluating the number of RPM's (Rounds per minute). These sensors are distributed in the client's ducts after an evaluation of the WWW team to decide the sensors' positions. These sensors are directly connected with the functional requirements 4.1 and 4.2. These sensors had to be bought by the team and will be refund by the Ambient Intelligence Team later

Local Hub

This local computational node collects data from different sensors located on the influence area through an analog input. Than, this microcontroller will send the data collected to the server. In the prototype, two flux sensors are connected to a single Local Hub (Arduino) by a wire connecting directly the sensors to the Hub. To cover the entire water system of big buildings more than one Local Hub should be necessary as its number of ports are limited. On the prototype, there won't be electro-valves that make the automatic closure of the duct, but on the ideal project there would be these valves actived directly by some Local Hubs if configured so

USB Cable

On the prototype there will be used a USB Cable to make the connection between the Local Hub and the Main Hub (server). On a bigger project, there would be used a Wi-Fi port to make that communication

Main Hub

This server receives the data of Local Hubs (in the prototype situation, only one) and also hosts the web-application accessible by the user. The application uses the data provided to show the user the information about the water system. The Main Hub is also responsible to send the decisions made by the user back to the Actuators that would act on the water system to prevent damages. However, in the protype these actuators are not present because the Ambient Intelligence Team decided not to provide them and if the team decided to buy, they wouldn't arrive on time for the presentation


It is compulsory to have access to the internet in order to access the web-application available at the Server (Main Hub). This PC could be even a mobile phone, given that the application can be accessed by any browser. In the prototype the Main Hub and PC are represented by the same computer.

Software Architecture

Software Components

Number Name
1 Web Application
2 Flask Library
3 Bootstrap Library
4 SQLite Library
5 Arduino API
6 Arduino Software

Web Application

Developed in the Python language using the Flask framework

Hosted on the Main Hub, displays the information of the entire system (Functional Requirements ) and allows the user to take the desired decisions (Functional Requirements )

Can be run in any browser, including mobile phones (Non-Functional Requirement )

Flask Library

Responsible for the web framework. GET and POST requests.

Bootstrap Library

Makes the website responsible and enhance desing

SQLite Library

In charge of the communication with the database. As well as the DML (Data Modeling Language) to create and persist the data.

Arduino API

Library used to accomplish the communication between the Arduino and the web application

Arduino Software

Runs on separate Arduino boards (Local Hubs) across the system. The software calls specific functions according to the main hub input.

This software allows the Arduino to process and send the collected data to the main hub and also act accordingly to the received data from the main hub.

Network Architecture

In the prototype developed, the network required to the project involve:

  • An analog input between the Flow Sensors and the Arduino with the use of Jumper Wires
  • The use of a USB Cable to connect the Arduino (Local Hub) to the Server (Main Hub)

On a bigger project the network required would be:

  • A Wi-Fi conection between the Flow Sensors and the Arduino
  • Another dedicated Wi-Fi connection to connect the Arduino (Local Hub) to the Server (Main Hub)

The network architecure on a bigger project were brought just for curiosity, as the requested one is for the demo project

Open Issues

Design of user interface

How to identify a single HW unit without a gps system

How to distribute the sensors along the water system

How to inform broken ducts to the user

What mecanism can help us on the acting of broken ducts