Data Matters

The known schedule

Node 1 meters an irrigation controller running a six-valve program that starts at 11:00 PM. The valve cadence is fixed: 15, 15, 15, 10, 10, 15 minutes for V1 through V6, which is 15/15/15/10/10/15 = 80 minutes end to end. Nothing exotic; a controller anyone could program.

What the per-minute data adds is proof that the program actually runs the way it is written, night after night, without drift. It is metronomic. Every watering night the cycle starts at 22:57, ends at 00:17, runs a contiguous 80 minutes, and lands somewhere between 2,302 and 2,332 gallons. That is a spread of just 30 gallons, about 1.3%, across 7/1, 7/4, 7/6, and 7/8.

A controller can tell you what it was told to do. Only a meter can tell you what actually flowed through the pipe. Here they agree to within a rounding error, which is exactly what you want to see.

Per-valve fingerprints

From the flow data alone, each valve has a stable signature: a characteristic volume and an average flow rate. Because the program is so steady, those signatures become a fingerprint you can compare night over night. Below is 7/6 against 7/8, valve by valve, for the 23:00 program.

Every valve lands within 0.3 to 3.0% night to night (+1.3% overall), well inside the normal noise of pulse timing and line pressure. The per-valve shape is unchanged: V5 is the biggest drinker at roughly 36 gpm, V3 the smallest at roughly 21 gpm, exactly as the night before.

That stability is the health-monitoring value. No valve shows the drop you would expect from a clog or a partial close. None shows the jump you would expect from a broken head or a stuck-open valve. A changed fingerprint, a zone that suddenly runs 40% higher or a third of its usual volume, is an early warning you would otherwise get only when someone noticed a soggy lawn or a spiked bill weeks later.

The discovery: volunteer irrigation events

The valves were the reassuring part. The data also surfaced something nobody scheduled. Pulling a multi-night range and grouping each night into cycles (dropping the zero-gallon idle blocks) produced this log for the eight nights:

The 23:00 program is the same rock-steady 80-minute run every watering night. The earlier cycles are the story: they are the two copper bars in the chart at the top of this page. They are recurring but irregular: 7/1 started at 22:00 and ran 38 minutes for 801 gallons; 7/8 started at 21:27 and ran 69 minutes for 1,613 gallons. Different start times, different durations, and roughly double the volume the second time. That variability is the exact opposite of the metronomic scheduled program, which is what makes them stand out.

On 7/8 the early run also carried its own tells. It terminated abruptly, with V6 getting only about 5 of its usual 15 minutes, and its later valves ran at noticeably lower pressure: roughly 21 gpm on V4 and V5, versus roughly 32 and 36 gpm for those same valves in the 23:00 cycle. That is consistent with a hand-started run, and possibly with a supply or pressure interaction when two cycles fire close together on the same line.

The arithmetic is the point. That single early cycle on 7/8 added 1,613 gallons. Node 1 used 3,944 gallons that night against 2,302 on a normal night: about +71% in one evening, from one unscheduled run.

We call these volunteer irrigation events, in the sense of a volunteer plant: nobody planted it, it showed up anyway. The explanations are worth laying out even-handedly. It could be someone manually starting the controller to give a dry patch of greenspace extra water; a forgotten supplemental or soak program still enabled from earlier in the season; or tampering with the controller. The point is not to accuse anyone. The point is that without per-minute metering, roughly 2,400 extra gallons in a single week would sit invisible inside a monthly utility bill, indistinguishable from ordinary use.

A second story: a leak, and proof it is gone

The Node 1 story above is about finding water nobody scheduled. This one is about the opposite problem: water that leaked away quietly, was fixed, and then had to be proven fixed. It comes from Node 4, on a different controller in the same neighborhood.

Node 4 waters four valves. Each one is meant to run 15 minutes, one after the other, starting at 10:00 PM. Four nights a week: Sunday, Tuesday, Thursday, Saturday. Simple.

What the leak looked like

Look at the copper line, the one from before the repair. For the first 30 minutes it behaves. Valve 1 runs near 18 gallons per minute, valve 2 near 16.5. Then at minute 30 it jumps to about 22.5 and simply stays there for the next half hour, dead flat, right through the handover from valve 3 to valve 4.

That flatness is the giveaway. Every valve waters a different patch of ground with a different number of sprinkler heads, so every valve should have its own flow rate. Two valves in a row reading exactly the same number means the meter was no longer really measuring the valves. It was measuring a break. The leak had become the biggest opening in the pipe, so it set the flow rate no matter which valve was switched on.

The repair happened on 23 July. The blue line is what the same program looks like now. The flat block is gone, and valve 3 and valve 4 have separated into two clearly different rates, which is exactly what healthy valves are supposed to do.

About 165 gallons of that nightly saving is the leak itself, roughly 660 gallons a week, or 2,800 gallons a month. The rest comes from a shorter valve 3 run, which is the next story below. Note also that valves 1 and 2 barely moved. That is how the data pointed at which end of the system to dig up: the problem lived on the side of the line that valves 3 and 4 share.

Proving there is no leak now

Fixing a leak is one thing. Knowing that no new one has started is another, and it is the harder question, because a leak that is just beginning does not announce itself. So we ran four checks on the 13 clean nights from 2 to 23 August.

• Is any valve using more water than it used to? No. Each valve holds its flow rate to within about a quarter of a gallon per minute night after night, and none of the four is trending up.
• Is any valve using more water relative to the others? This one matters, because on a hot dry week the whole neighborhood's water pressure sags and every valve drops together, which can hide a small leak. Comparing each valve against valve 1 cancels that out. Valve 2 sits at 0.904 of valve 1, valve 3 at 1.006, valve 4 at 0.870, and those ratios move by about one part in a hundred. Flat.
• Is water moving when everything is supposed to be off? No. There is a small residue of water between runs, but it does not grow with time: gaps of 23 hours carry about 14.7 gallons and gaps of 47 hours carry about 9.9. A dripping valve would do the opposite, since twice the waiting would mean twice the water. This is just the tail of the previous run arriving late.
• Is any valve's flow climbing during its own run? No. That is what a crack widening under pressure looks like. All four valves are flat from their first minute to their last.

Every test has a limit, and it is worth stating this one plainly. Night-to-night wobble on this meter is about 0.22 gallons per minute, so a leak has to be bigger than roughly half a gallon per minute before it can be told apart from ordinary noise. That is about 7 gallons a night, or 220 gallons a month. Node 4 is clean down to that level. Below it, no honest answer is available yet, and more nights of data is the only thing that lowers the floor.

Two things that are not leaks

The same look at the data turned up two oddities. Neither is a leak, and both are worth knowing.

Valve 3 is running about 11 minutes, not 15. It started doing that on the exact night of the repair and has done it every night since. It costs about 73 gallons a night against the written schedule. Either the crew shortened that station while they had the controller open, or valve 3 is shutting itself off early. Only someone standing at the controller can say which, and that is the useful kind of question for data to hand back to a person.

Monday 24 August, 6:19 PM: 787 gallons. Node 4 has no Monday program at all. It ran flat at about 17.6 gallons per minute for 45 straight minutes with no valve changes in it, which means one valve, open, alone. That is either somebody running a station by hand or a valve that stuck open and then reseated. This is the same volunteer pattern the Node 1 story describes, showing up on a second controller.

Why data matters

The value of continuous metering is not only confirming what you scheduled. It is discovering what you did not. And the two halves reinforce each other: it is precisely because the scheduled program is so stable, 30 gallons of spread across four nights, that the anomalies pop out at all. A steady baseline is what turns an extra 1,613 gallons from noise into a signal.

None of this took special effort. It took one Node quietly metering a controller, a month of readings flowing through the Gateway into the database, and a few straightforward queries. The hardware sat on a wall and did its job; the data did the rest.

You can run this analysis yourself. The queries behind every table on this page are packaged in AnalyzeNodeData.qbquery, a free, commented MySQL toolkit on the Downloads page. Point it at your own phoa_water database, set the @ date variables at the top of each section, and run: it classifies your nodes as sub-minute (GIF2006B) or hourly (GIF2014W-OSE) from the data alone, produces the daily-usage and cycle logs above, and, on sub-minute meters, detects individual valve transitions from the utility meter alone, the analysis this page was built with.

If you want that kind of visibility on your own irrigation or utility water, the next step is putting a Node on the meter. See Installation for what a real field deployment looks like.

Installation, the next step