DEV Community

Cover image for We Deployed IoT Water Sensors on a Kenyan Farm. Here's What Broke.
Stephen Musyoki
Stephen Musyoki

Posted on

We Deployed IoT Water Sensors on a Kenyan Farm. Here's What Broke.

A single cracked joint in a 200-metre irrigation line can lose 4,000 litres of water a day. On a commercial farm, that's not measured in litres. It's measured in failed harvests.

We build IoT systems for farms and small businesses across Kenya. In January this year, we started a pilot with a farm in Kitui County — six hectares of mixed crops, drip irrigation on four of them, flood irrigation on the other two. The owner had two problems he couldn't see: water disappearing from his main line at night, and a pressure drop on his western block he couldn't explain.

The brief was simple: instrument the piping, log everything, alert when something looks wrong. Nine months later, we have a working system and a much longer list of things we'd do differently. This is the honest write-up — what worked, what broke, and what we'd tell someone about to do the same.

What we actually deployed
Not everything made it through the pilot. Here's what survived, and where.

Flow meters. Two YF-S201 units on the source lines, one electromagnetic meter on the main distribution line. The electromagnetic meter was 8x the cost of the YF-S201s, and worth every shilling. The YF-S201s are turbine-based, and once sediment starts accumulating (which it did by month two), the readings drift. The electromagnetic has no moving parts and stayed accurate.

Pressure sensors. Two industrial 4–20 mA transducers, one at the pump and one at the far end of the western block. These were the most reliable hardware we deployed. Zero failures over nine months. Cost was around KES 9,000 each.

Acoustic leak sensors. We deployed two of these at suspected weak points. They worked in the sense that they detected the signature, but the interference was severe. Farm equipment, wind, birds, and even the vibration of the pump itself all produced signals in the same frequency band. We ended up disabling the alerts from these after week six.

Microcontrollers. ESP32 dev boards with LoRa modules. Three nodes in total. Two got water ingress within the first three months — the enclosures weren't sealed properly. We replaced them with IP67 boxes and silicone gaskets, and haven't had a failure since.

Gateway. A single LoRaWAN concentrator mounted on a pole near the farmhouse, powered by a small solar panel and a 12V battery. Coverage was the biggest surprise. We expected 10–15 km of range. The farm's terrain (rolling hills, dense vegetation) cut that to about 2.5 km before we lost packet delivery. That was enough for this deployment, but on a larger farm it would be the limiting factor.

Power. Each sensor node runs on a 6V solar panel and a small LiFePO4 battery. The panel is overkill for the load — the nodes draw about 40 mA on average — but the battery is the weak point. LiFePO4 degrades faster in heat than the datasheet suggests. After nine months, one battery lost about 30% of its capacity.

What worked
Three things performed better than we expected.

The differential leak detection. This is the core mechanic: compare flow at the source to flow at the field. If the source says 100 L/min and the field receives 87 L/min, you have a 13% loss somewhere between them. By week three, the system had caught a slow leak in an underground joint that the farm manager had been walking past for months. It was losing about 200 litres per hour. That alone paid for the pilot.

Theft detection. The farm shares its water source with a neighbouring property. Water was going missing at night — around 40 minutes of flow when all valves reported closed. The system caught it within a week of going live. The neighbouring farm had a manual tap on the shared line that they were opening after midnight. The farm owner was able to resolve it directly, without a legal fight, because he had the data.

The dashboard. We built a simple Grafana setup — flow over time, pressure per zone, daily water usage. The farm manager, who'd never used anything more technical than a smartphone, was reading it within a week. That was surprising. The visualisation of "your western block is using 30% more water than last week" was the actual value, not the alerts.

What broke
Honestly, most things, in some way or another.

Rodents. By month two, we'd lost one sensor cable to something that chewed through the outer sheath. By month four, two more. The cables we were using weren't armoured. We replaced all exposed runs with steel-braided cable and routed as much as possible underground in conduit. If we did it again, we'd use armoured cable from day one.

Water ingress. Two ESP32 nodes failed at the enclosure seal. Even with an IP65-rated box, the combination of daily temperature cycling and irrigation spray found a way in. Our fix: IP67 boxes, silicone gaskets, and a small desiccant pack inside each. No failures since.

Connectivity. We originally tried NB-IoT on one node. Safaricom's coverage at the farm was listed as "good" but the actual data throughput was unreliable — the modem would connect, send a few packets, then drop. We switched to LoRaWAN for everything and didn't look back. LoRa's low bandwidth is fine for this application.

The software ate a weekend. Our first version of the rules engine flagged a leak every time flow dropped below a threshold. That happened at every valve close and every pump shutdown. We got 300+ alerts in a day before we shut it off and rewrote the logic. Lesson: baseline first, then alert on deviation, not absolute values.

The client didn't trust the alerts at first. This was the most important failure, and the one we underestimated. The farm manager ignored the first two leak alerts because they'd been preceded by false positives from the flawed rules engine. We had to rebuild trust before he'd act on any alert. If we did it again, we'd train the system on real data for two weeks before enabling any notifications.What it cost
For a six-hectare farm with two zones and one main line:

Flow meters (3): KES 42,000

Pressure sensors (2): KES 18,000

Acoustic sensors (2): KES 45,000 — we would not deploy these again on this farm

Microcontrollers and LoRa (3 nodes): KES 21,000

Gateway + antenna + solar: KES 38,000

Solar panels + batteries (3 nodes): KES 32,000

Enclosures, cabling, waterproofing: KES 24,000

Installation labour: KES 40,000

Total hardware + install: approximately KES 260,000.

Ongoing cost is the platform: we self-host on the same infrastructure we use for other clients, so marginal cost is low. If you used a managed service like Datacake or Ubidots, expect KES 3,000–8,000 per month.

Payback estimate: the leaks and theft we detected were costing roughly KES 8,000–12,000 per month in water and pumping. So the deployment pays back in about 24 months. Not spectacular. But the data also let the farm owner make better decisions about irrigation scheduling, which is harder to quantify but probably worth more than the direct savings.

What we'd do differently
Four things.

Use armoured cable from day one. The savings from using standard cable were wiped out by the cost of replacements and labour.

Skip acoustic sensors. They didn't earn their place. Differential flow catches leaks well enough. If we need to pinpoint location, we'd rather spend the money on more flow meters to narrow the segment.

Run a two-week calibration period before any alerts go live. Not just for accuracy, but to build trust with the operator. If the system cries wolf in week one, nobody trusts it in week four.

Involve the operator from the design phase, not the handover. The farm manager had insights we didn't — where the ground was softest, which pipes had been repaired before, when the neighbouring farm was likely to draw water. We could have designed around those if we'd asked earlier.

What this changes for our next deployment
We're doing a second deployment in November. Same budget range, but with:

Armoured cabling throughout

IP67 enclosures with desiccant

LoRa only, no NB-IoT experiments

A two-week calibration phase before alerts go live

One less sensor type, three more flow meters

The technology works. The failures were almost all environmental or operational, not sensor or software issues. That's a good sign — those are the failure modes you can plan for.

If you're considering this
Three things to know before you start:

The sensors are the cheap part. They're maybe 40% of the cost. The rest is enclosures, cabling, installation, and the time to make the system work reliably in the field.

The first deployment always has failures. Budget for a replacement cycle within the first six months. Expect some sensors to fail. Expect one or two to be destroyed by something you didn't anticipate.

The dashboard matters more than the alerts. Alerts catch acute problems (leaks, theft). The dashboard changes behaviour — it shows patterns, costs, and opportunities that a single alert can't.

We build IoT and cloud systems for agriculture, logistics, and industrial clients across Kenya. If you're considering something similar, we can scope a pilot in a week. You can find us at Pasbest Ventures.

Top comments (0)