City wide water leakage monitoring

Adelaide city, a city with very limited water resources, has an issue with burst pipes

Similar projects worth following
Adelaide city, a city with limited access to water has a problem with burst water mains pipes, not just leaking valuable water but also disrupting roads and access to homes. Our project is designed to address this by laying out many cheap sensors around the water pipe network to detect water leaks through moisture sending and smart meter monitoring.

Problem being addressed:

Adelaide is a city with limited access to water, and water wastage is an issue. In recent months there have been several water mains bursting, not only wasting a valuable resource but also disrupting roads and infrastructure.


Sensors can be placed over the whole water network, or strategically in places where known issues are occurring. Sensor data can then feed information to cloud data storage for further evaluation.

Connecting these sensors to the cloud creates a connectivity issue that needs to be solved and there are two possibilities, polling bluetooth devices or the device polling the cloud. What needs to be considered is how the data is to be collected, whether it is from cars travelling around or fed into an existing network, this document seeks to address both issues.

Our solution would be a hybrid of the following types of sensors:

Scan and collect:

This would involve using connected devices to passively collect data from the sensor modules spread around the monitoring network. This could be achieved with a variety of low power protocols, for example Bluetooth Low Energy (BLE). BLE data can be collected by specific devices, multi function devices and smartphones.

This also opens the option of allowing the general public to gather data with an App on their mobile phones and be appropriately compensated. Compensation could also be directed in other ways, such as to charity. Data collection for charity could also be gamified, encouraging data collectors to transmit data from local sensors and in turn regularly emailing the person collecting data with information about what change their donation has contributed to.

Fixed infrastructure:

This solution is the lowest power usage and takes advantage of pre-existing wireless infrastructure to actively upload sensor data. This needs minimal interaction, aside from maintenance.


  • Collecting preemptive data in this way removes the need to disrupt customer supply outside of regular maintenance.
  • Additional sensors can be added at customer.


  • Environmental damage from destroyed or lost devices.
  • Additional maintenance and tracking of sensors.

User experience

We would analyse the data in house (eg. via IBM Bluemix), combining pattern recognition and weather data to create regular reports as well as instant alerts. This could be done with a priority map and instant alerts via email or SMS; as per customer requirments.

App users may be asked for a bitcoin address or payment destination, and the app would run in the background collecting data and uploading that data to our servers.


There are a few options for deployment:

  • Dig a hole
  • Use a small post hole digger to remove a layer of dirt and drop the sensor in the hole before covering it back up
  • In drains
  • Water meter
  • With new water pipe installations
  • Mounted on the bottom of an exposed water main


Iot device: Power consumption (possible energy harvesting options for battery life), transmitter options (BLE & WiFi), prototyping, design for use in public spaces (max radiated power, tamper proof, environmental protection, replaceability)

Acquisition device: motivation for people to use app


  • Gas leakage sensors
  • Other water providers
  • Mining
  • Water usage monitoring
  • Farm sensors

  • Data Collection Compensation and Monetisation

    Paul Schulz04/27/2016 at 04:18 0 comments

    (In the following, 'bitcoin' has been used as the payment process used in this implementation. This should be understood as being generic, as any block-chain based transaction system would be suitable. Bitcoin itself may prove to be problematic due to the transaction fees which need to be included.)

    A funding mechanism is required which promotes a self sustaining business model. A suitable model would:

    • Reflect the true costs of running the business
    • Provide effective and efficient remuneration
    • Support the ongoing development of the IoT ecosystem
    • Allow effective community involvement

    The suggested business model may also be disruptive, new and novel.

    A micropayment system for sensor data based on Bitcoin is proposed. When data is transmitted from sensors a bitcoin address is associated with the data. Bitcoin is paid to this address once data is received expected sensor time of life, recovery and recycling costs.

    By attaching micropayments to sensor network operation there is an incentive for the operator to keep up with sensor maintenance.

    Sensors are registered with data consumers to supply data at a particular bitcoin rate.

    Data Consumers

    • Receive data and pay bitcoin.
    • Collect sensor data and pay bitcoin to associated account as data is received.

    Data Brokers / Gateways

    • Acts as data consumer, and paying bitcoin to data sources.
    • Sell data to other data consumers

    Data Producer/Sensor data

    • As data points are measured/produced by a sensor, they are associated with a Bitcoin address, which is transmitted along with the data to the network.
    • Data may be stored for later transmission, when opportunistic networking is used.
    • Bitcoin addresses can be allocated per sensor or to a group of sensors. (Individual sensor bitcoin addresses would be preferred.)
    • The amount of bitcoin charged per data-point is determined by the cost of the sensor, May strip and reissue bitcoin address for data consumers.
    • Can aggregate data and create value added data collections.

    Deployment of the sensor data requires an upfront investment in equipment, infrastructure, (some) R&D and deployment. Funds also need to be allocated to recovery and recycling. This investment can be recouped over a particular period, determined by the sensors (battery life) in the network.

    Additional sensor network deployments by other organisations can be incorporated into the aggregated data and also made available via Bitcoin payments.

    The sensor network can be monitored via bitcoin transactions.

  • We won!

    Marcus Berg04/24/2016 at 09:49 0 comments

    We won the Adelaide IoT Hackathon! We are really excited to continue to develop this idea over the next few months and to have a chance at the bigger prize in the Hackaday Challenge 2016. Expect a lot more from us!

  • Adelaide IoT Hackathon

    Marcus Berg04/24/2016 at 09:47 0 comments

    During the Hackathon we: developed out idea, considered many alternatives, refine the idea (see details) and test the infrastructure.

    We were able to get a TI SensorTag to connect via a smartphone to IBM Bluemix, and then have the data analysed and provide two levels of warning.

    We also shown that we can communicate with the TI SensorTag at a distance of 15m in the open air to a smartphone.

View all 3 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates