IoT & Embedded

Soil Moisture Driven Irrigation Controller

An irrigation controller that waters based on measured soil moisture and forecast rainfall rather than a timer, with a documented measurement of water saved. The engineering that matters is what happens when the network, the sensor or the power fails.

Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

1 semester, 2 students

Deliverables

5 to ship

3 optional extras

Suggested stack

ESP32C++MQTTNode.jsInfluxDBReact
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • Sensor node measuring soil moisture at two depths plus temperature, battery powered with measured runtime
  • Irrigation decision logic using moisture thresholds and a rainfall forecast, running on the device
  • Valve control with hard safety limits on maximum continuous and daily runtime
  • Dashboard showing moisture history, irrigation events and water used
  • A controlled comparison against timer based irrigation over at least 4 weeks, with water use reported

If you have time left

  • Sensor calibration against gravimetric soil sampling
  • Multiple zones with independent thresholds
  • Solar power with a charge controller and measured autonomy

The problem

Most irrigation runs on a timer, which waters during rain and continues through a wet week. Moisture sensors are inexpensive and the control logic is not complicated, so the gap is mostly one of integration.

What you build

A battery powered sensor and control node, decision logic that runs locally, a dashboard, and a measured comparison against a timer.

The design principle that makes it real engineering

The device must work when the network does not. If irrigation depends on a server, a lost connection means either no water or a valve stuck open, and both are serious. Keep the decision logic on the device, treat the forecast as an optional input, and fail into a safe timer based mode.

The safety requirement

Hard limits on valve runtime, enforced in firmware, independent of any logic above. A software bug that leaves a valve open overnight is the failure that matters here, and a maximum runtime that cannot be overridden is the defence.

The result to lead with

Water used per unit of plant health, measured over four weeks against a timer controlled plot. That measurement is the contribution; the hardware is how you obtained it. Start the deployment early enough to collect it.

Scope warning

Two zones at most. Depth of measurement beats breadth of coverage.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Get guidance
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.

Follow along

New writing, resources and project ideas land here first.