Rooftop Water Tank Level and Pump Controller with Dry-Run Protection

The problem with rooftop tanks and burnt-out pumps

In many cities, including most of Pakistan, homes and small hostels store water in a roof tank filled by an electric pump from an underground tank or a municipal line. Someone has to remember to switch the pump on, and then remember to switch it off. When they forget, the tank overflows and wastes water on the roof. When the supply side runs dry, the pump keeps spinning with nothing to move, overheats and burns out. A motor rewind or replacement is a real cost for a household, and for a hostel or apartment block the pain is people with no water in the morning.

Float switches are the usual fix, but they stick, the cable wears through, and they tell you nothing about how much water you have or whether the pump actually delivered any. Load-shedding makes it worse: power comes back at random times and nobody is home to manage the pump.

What already exists and the gap

• Tuya-based Wi-Fi level controllers sold on Amazon and local marketplaces combine an ultrasonic sensor with relay outputs, one for level and one for dry-run protection, controlled from the Smart Life app.
• Luubom-style wireless controllers use long-range radio between tank and pump, with a solar-powered sensor.
• Local electronic float controllers with probe rods are sold cheaply in hardware markets, with no app at all.

The gap is not the idea of a level controller. It is that cheap cloud-app products stop being useful when the vendor cloud or the home Wi-Fi goes down, rarely explain their dry-run logic, and give no history. Many only detect dry run from a probe in the source tank, not from what the motor is actually doing. A controller that runs its safety logic locally, measures motor current, and keeps an honest usage history is still missing at a student-buildable price.

What you build

Two small ESP32 nodes and a backend.

• Tank node on the roof: a waterproof ultrasonic sensor pointed down at the water, reading level every few seconds, converting it to litres from the tank shape the owner enters.
• Pump node near the motor: drives a properly rated contactor, reads motor current with a clamp or hall sensor, and decides when to run.
• Backend and dashboard: an MQTT broker, a small service that stores readings, and a phone-friendly dashboard with live level, pump state, history and alerts.

Main flows: the tank drops below the low threshold, the pump node starts the motor, watches current and level, and stops at the high threshold. If current is abnormally low (running dry) or the level does not rise within a set window, it stops the pump, raises an alarm and waits before retrying.

The technically interesting part

The hard part is making safety decisions locally with noisy signals. Ultrasonic sensors in a tank see ripples, condensation and echoes from the tank walls, so you need filtering (median of N readings, rejecting impossible jumps) without making the controller slow to react. Dry-run detection needs a small state machine: a start-up current spike, a normal running band, and a low-current band that means the impeller is spinning in air. You also need to handle power returning mid-cycle without starting and stopping the motor repeatedly. Show your evaluators the state diagram, the tests for each transition, and the logs of the device staying correct while the server is offline.

How to evaluate it

• Level accuracy against a measuring tape at five fill levels, reported as mean error in centimetres.
• Dry-run detection time: close the supply valve on purpose (safely, for a few seconds) and measure how long the controller takes to stop the motor. Repeat at least ten times.
• Offline behaviour: disconnect Wi-Fi for a day and confirm that the tank still fills correctly and events sync when it reconnects.
• A two-week field trial on a real tank with counts of overflows and manual interventions before and after.

Suggested plan

1. Weeks 1 to 3: sensor bench tests in a bucket, filtering, and tank volume maths.
2. Weeks 4 to 6: pump node with current sensing on a small test motor, dry-run state machine and tests.
3. Weeks 7 to 9: MQTT, backend, dashboard and settings sync.
4. Weeks 10 to 12: enclosure, safe mains wiring with a qualified electrician checking it, and installation.
5. Weeks 13 to 15: field trial, measurements and report.

Path to a product

The first customer is a hostel owner or apartment block caretaker who loses water or motors every month. Sell the kit as a one-time hardware price with installation, and a small yearly fee for history and alerts. Plumbers and electricians are the natural channel: give them an installer discount. Scale by adding multi-tank support for housing societies, where one dashboard covers many buildings.

Scope warning

Do not build your own cloud IoT platform, a custom PCB in semester one, or a solar-powered sensor unless the basic system already works. Do not wire mains voltage without supervision. Do not try to support every tank shape; rectangular and cylindrical cover most cases.

Learn what you need on Sefism

• Programming roadmap : the C and C++ basics you need for reliable firmware and state machines.
• Backend cheat sheet : a quick reference for the small service that stores readings and sends alerts.
• Nand to Tetris : builds the hardware intuition that makes microcontroller work less mysterious.
• GoogleTest Primer : unit test your dry-run state machine on your laptop before it touches a motor.
• Which final year project helps you get a job? : how to present a hardware project so employers value it.

Get help with this idea

This is a good first IoT project because the safety logic is small enough to get right and test properly. If you want a second opinion on scope, hardware choices or how to set up the evaluation before you commit, bring your plan and your bill of materials and we will pressure-test it together. New here? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session