The app says the lawn was watered. The lawn disagrees. You are standing on grass that is visibly, tangibly dry, holding a phone that is showing you a tidy green record of a twelve-minute run on zone three that, as far as you can tell, never happened. Or the opposite: nothing ran at all, no record, no error, no notification, just a controller sitting on the garage wall with a calm blue light, having quietly decided that today was not a watering day and not seeing any particular reason to mention it. As an Amazon Associate I earn from qualifying purchases.
We are the Smart Home Guide Editors, and this page is about a smart irrigation controller that isn’t watering. Not one that won’t connect to Wi-Fi. Not one that’s dead. A controller that is online, configured, apparently healthy, and not putting water on the ground. Over a long stretch of provoking this deliberately on a reference system — zones broken and restored on purpose, weather features on and off, valves swapped, wiring degraded, schedules deliberately misconfigured — we arrived at a conclusion that sorts the entire problem in one cut: the first thing you must establish is whether the controller thinks it watered. Everything else follows from that answer, and almost nobody asks the question first.
The One Cut That Sorts Everything
Here’s the mechanism, and it’s why that question does so much work.
A smart irrigation controller does not move water. It cannot. It is a clock, a small computer, and a set of low-voltage outputs — nothing more. The water is moved by a valve buried in a box in your yard, and that valve is opened by a solenoid: a coil of wire that, when your controller sends roughly twenty-four volts of alternating current down a wire, becomes an electromagnet and lifts a plunger, which releases pressure from a chamber, which lets water push a diaphragm open. That’s the whole machine. Water pressure does the actual work; the solenoid just decides whether it’s allowed to.
Notice what’s missing from that chain: feedback. A basic controller has no idea whether any water moved. It energizes a terminal for twelve minutes and writes “watered for twelve minutes” in its log, and that log entry is a record of what the controller did, not of what happened in your yard. It’s a statement about electricity, not about water. Many controllers can detect a short circuit or an open circuit on the wire, and better ones can read a flow sensor if you have one — but out of the box, the log is an intention, honestly reported.
So there are exactly two families of failure, and they have nothing in common.
Family one: the controller says it ran and no water appeared. The command was issued. Everything upstream — schedule, clock, account, weather logic, internet — is proven to work, because it produced a run. The failure is downstream of the terminal: wire, solenoid, valve, or water supply. This is physical. No app setting will touch it.
Family two: nothing ran and there’s no record of a run. The valve is irrelevant. It never got the chance. The controller decided not to water, and there is a reason, and the reason is in the software — a skip, a restriction, a schedule that isn’t what you think it is.
Those two families are diagnosed in completely different places by completely different means. And the log tells you which one you’re in, in about ten seconds, before you touch anything.
| Cause class | Family | Share of our logged incidents |
|---|---|---|
| Weather skip — rain, forecast, saturation, or wind | Didn’t run | Largest class by a wide margin |
| Seasonal adjust or water budget scaling the run toward zero | Ran, briefly — often too briefly to notice | Second largest |
| Cycle-and-soak splitting one run into fragments | Ran, in pieces, at times you didn’t expect | Moderate; not a fault at all |
| Solenoid, wire, or common-wire fault | Ran, no water | Moderate; the largest of the genuinely physical classes |
| Master valve or pump start relay not engaging | Ran, no water — on every zone at once | Small but instantly recognizable |
| Valve stuck, silted, or diaphragm failed | Ran, no water — one zone only | Small |
| Schedule disabled, in the wrong program, or never enabled | Didn’t run | Small, and embarrassing |
| Water supply off at the main or backflow valve | Ran, no water — everything, all at once | Smallest class; check it first anyway |
Read the top row and note what it is. The largest class in our log is not a fault. It’s the controller doing the exact job you bought it for — declining to water a wet lawn — and being bad at telling you so in a way you’d notice. The genuinely broken-hardware classes sit in the lower half.
How We Logged It
Here’s what we did, so you can weigh the conclusions properly.
We ran a reference multi-zone system and broke it on purpose rather than waiting for it to break. We disconnected solenoids one at a time and logged what the controller reported. We degraded a common wire deliberately — a corroded splice, a nicked conductor — to see what a partial fault looks like from the app, since a clean disconnection is easy and a marginal one is what actually happens in a yard. We turned weather intelligence on and off across the same days and compared what ran. We set seasonal adjustment to extremes. We enabled cycle-and-soak and then went outside to find out where the water actually went. We closed the backflow valve and watched a full schedule report perfect success.
Two honest limits. First, the terminology is a mess and it’s not our mess: what one manufacturer calls seasonal adjust another calls water budget and a third folds silently into an automatic mode you can’t see the arithmetic of. We describe behaviours; you’ll have to map them onto your own product’s vocabulary. Second, our ordering reflects a system in one climate on one water supply. A yard with hard water and old valves would push the physical classes up. We’d still expect weather skips to lead, because that class is generated by the software’s normal operation rather than by wear.
What we didn’t do is speculate. Every claim below is something we caused and then uncaused.
The Big One: It Decided Not To Water
This is the finding, and the reason it’s the finding is that it doesn’t feel like an answer. It feels like being fobbed off. So let’s be specific about the mechanism.
A smart controller earns its name by not watering. That’s the product. It pulls a forecast, or reads a local station, or tracks a soil moisture model built from temperature and humidity and rainfall, and it decides your lawn doesn’t need it. Every one of those is a feature working correctly. And every one of them produces the identical observable: a dry lawn and a schedule that didn’t run.
The trouble is where that decision gets reported. In our log, skip notices lived in a history screen you had to go and look at, or a notification that had been turned off, or a small icon on a day cell. None of them surfaced anywhere you’d naturally look while standing on dry grass with your phone in your hand. The controller isn’t hiding it. It just isn’t putting it where you are.
So the first move is always the history screen, not the schedule screen. The schedule screen tells you what’s supposed to happen. The history tells you what did, and — crucially — what didn’t and why. If there’s a skip entry, you’re done. The system worked. The remaining question is whether you agree with its reasoning.
Often you shouldn’t. Here’s what we found actually goes wrong inside a correct skip:
The rain that fell somewhere else. Forecast-based skipping uses a weather station, and that station might be several kilometres away, at a different elevation, on the other side of a hill. Summer rain is famously local. Your controller knows it rained; it doesn’t know it rained on the other side of town. If your skips consistently disagree with your own eyes, the station is wrong, and moving to a nearer one — or putting a rain sensor in your own yard — fixes it. This was our most common legitimate grievance against the largest cause class.
The saturation model that’s still full. Controllers that model soil moisture carry rainfall forward for days. One heavy storm can suppress watering well past the point where the surface has dried out and the lawn is visibly stressed, because the model believes there’s water at root depth. Sometimes it’s right and your eyes are wrong. Sometimes the model’s soil type is set to something that holds water far better than your actual dirt, and correcting that one field brought the model back in line for us.
The wind and temperature restrictions nobody remembers enabling, quietly suppressing runs on exactly the hot windy days you most wanted water.
The Run That Was Too Short To See
The second class produces a lawn that’s dry despite a log full of successful runs, and the arithmetic is hidden.
Nearly every controller has a global scaling factor — seasonal adjustment, water budget, monthly percentage, whatever it’s called — that multiplies your zone times. Set it to 50% and your twelve-minute zone runs six. Set it to 10% and it runs barely over a minute: long enough for the log to say “ran,” far too short to wet anything, and utterly invisible unless you happen to be standing in the yard at the time.
Two ways this bites. Someone dialled it down in autumn and never dialled it back — our most common version, and it produces a spring of mysteriously dry lawn and perfect logs. Or the controller is scaling automatically, on a curve you’ve never seen, and the curve disagrees with your yard.
The tell is in the log if you read it properly: look at the duration, not the checkmark. This is the most valuable habit in this article after the history screen itself. Everyone scans for green ticks. The ticks are honest — it did run. What they don’t shout is that it ran for ninety seconds. A log full of successful two-minute runs on a zone you configured for fifteen is a solved case, and it looks exactly like a healthy system at a glance.
Cycle-and-soak belongs here too, and it isn’t a fault. To stop runoff on slopes and clay, the controller deliberately breaks one fifteen-minute run into three five-minute runs with soak gaps between them. Entirely correct, genuinely better for the soil, and it means your “6:00 AM” watering is now smeared across an hour and a half. People conclude their schedule is broken because the sprinklers weren’t on when they looked. They were on. Earlier. And they’ll be on again shortly.
Ran, No Water: Now It’s Physical
If the log shows a full-length run and the ground is dry, you have left the software entirely. Nothing in the app will help you now, and this is where the actual repairs live.
Start with the cheapest possible cause, because we have watched too much time burned on the alternatives. Is the water on? The main, the backflow valves, the isolation valve someone closed for winter and nobody reopened. A controller with no water pressure runs a flawless schedule and logs a flawless success, because — remember — it has no idea. If every zone is dry and the logs are perfect, this is where to look, and it’s a thirty-second check.
Next, the common wire. Every solenoid needs two connections: its own zone wire, and a shared return that all of them use. Break a zone wire and one zone dies. Break the common and everything dies, all at once, silently, with the controller reporting complete success — because on many controllers the common’s integrity isn’t tested at all. In our log, a corroded splice in a valve box was the single most common physical fault, and it presents as the most alarming symptom: total failure, perfect logs. The reason it’s so common is unglamorous — splices sit in boxes that fill with water, and a connection that was fine for years fails gradually, working when dry and failing when wet. Redoing those joints with proper gel-filled waterproof splice connectors rated for direct burial cost us almost nothing and retired this class from our log entirely.
If it’s one zone only, the fault is that zone’s wire or that zone’s solenoid. A useful and free test: swap the suspect zone’s wire onto a terminal you know works. If the problem follows the wire, it’s the field. If it stays on the terminal, it’s the controller. That test costs nothing and eliminates half the possibilities.
Two more, quickly. A solenoid can fail open-circuit — a burnt coil, and many controllers will actually tell you about this one. A replacement solenoid is among the cheapest parts in the whole system and unscrews from the valve body without cutting into any pipe, which is exactly why it is worth ruling in before you start suspecting the valve itself. And a valve can be mechanically stuck: silt in the diaphragm, grit under the plunger, a diaphragm that’s perished. The manual bleed on the valve body is the test — open it by hand. If water flows when you turn the bleed and not when the controller calls, you’ve localized it to the solenoid or its wiring, not the valve. If nothing flows even on manual bleed, the valve or the supply is your problem.
And if every zone runs dry with clean logs on a system that has a pump or a master valve, check that first — a master valve that isn’t opening starves every zone simultaneously while each individual zone’s wiring tests perfectly. It’s the one fault that looks like eight faults.
The Schedule That Was Never Armed
Small class, mildly humiliating, and we include it because we did it to ourselves and the log said nothing useful.
Schedules can be created and left disabled. They can be attached to a program that isn’t the active one. They can be set for days that haven’t come around. They can be sitting in a seasonal mode that has itself expired. And a controller in a standby or off mode will sit there looking completely normal, blue light and all, running nothing.
The tell is a total absence: no runs, no skips, no entries at all. That’s diagnostic. A weather skip writes something down — the system considered your schedule and declined. An empty history means the system never considered anything, which means it doesn’t believe it has a schedule to consider. Those two look identical on the lawn and are nothing alike in the log.
The Zone That Waters The Wrong Amount
A separate failure that hides inside a working system, and it’s worth its own section because the log will never show it to you.
Every zone in your yard gets the same clock but not the same water. A zone of six spray heads on a sunny slope and a zone of two rotors under a tree receive wildly different amounts of water in the same twelve minutes — spray heads dump water fast over a small area, rotors sweep slowly and apply a fraction as much per minute. Run them for equal times and you have simultaneously flooded one part of the yard and starved another, and both zones will report identical, perfect, twelve-minute successes.
This surfaces as “part of my lawn is dry” rather than “my sprinklers don’t work,” which is why it usually gets filed as a coverage problem and answered by moving heads around. Sometimes that’s right. Often the heads are fine and the schedule is applying rotor time to spray zones or vice versa, because whoever set it up copied one number across every zone.
The check that costs nothing: put a few straight-sided containers — tuna tins are the traditional choice for a reason — around a zone, run it for a fixed time, and measure what collected. Do it on the zone that’s fine and the zone that’s dry. If the dry zone collected a third as much in the same run, you don’t have a fault. You have two different machines being given one instruction, and the fix is per-zone times, not new hardware.
We put this after the physical section deliberately, because it’s the thing people find after they’ve replaced a controller that was innocent. If your complaint is “part of the lawn,” start here and you may skip the whole article.
Why It Only Fails In Spring
Short section, sharply seasonal, and it accounts for a cluster of incidents that look mysterious in isolation and obvious together.
A system that sat unpressurized through winter and then gets turned back on is not the same system that shut down in autumn. Diaphragms that were fine under continuous pressure stiffen and perish while dry. Silt that settled during shutdown gets picked up and driven into valve seats the moment pressure returns. Splices that spent months in a flooded box have had a full season to corrode without anyone noticing, because nothing was asking them to conduct anything. And the isolation valve someone closed in November is still closed in April.
So a spring failure is rarely one thing going wrong. It’s several things that went wrong slowly, in the dark, revealing themselves the instant the system is asked to work. The diagnostic value is in the timing itself: if it worked in October and doesn’t in April, the physical classes in this article jump to the front of the queue and the software classes drop, because nothing in the software changed while the water was off.
The corollary is that a slow, staged startup — supply on first, then each zone manually, one at a time, before any schedule runs — finds all of this in twenty minutes on your terms rather than across three confusing weeks on the lawn’s.
Flow Sensors, And Why This Article Exists
We’ll finish the mechanism where we started it, because the whole article traces back to one absence.
Everything difficult here comes from the controller having no feedback. It reports intentions because intentions are all it has. Give it a flow sensor and that changes completely: it now measures water moving through the pipe and can tell the difference between a zone that ran and a zone that ran and delivered. It can catch a broken head as a flow spike, a dead valve as a flow of zero, and a leak as flow when nothing was called for.
We’re not going to pretend that’s a casual purchase — it’s a plumbing job, and for many yards the arithmetic doesn’t work. We raise it because it clarifies what you’re actually dealing with the rest of the time. When you read a log entry on a system without one, you are reading a sentence about a terminal being energized. It is true. It is also not about your lawn.
Which is the single most useful frame we can leave you with: the controller is not lying to you, and it is not confused. It is answering a narrower question than the one you’re asking. Most of the time in this yard, and we suspect in yours, the gap between those two questions is the entire problem.
The Order We’d Fix Things In
Ordered by what resolved incidents in our log.
First, open the history, not the schedule. Did it run? That single answer splits this article in half and it takes ten seconds.
Second, if it ran — read the duration, not the tick. A two-minute run on a fifteen-minute zone is your whole case, solved, and it looks like success.
Third, if it skipped — read the reason, then check whether the weather it’s reading is your weather. Wrong station and wrong soil type were our two most common legitimate complaints.
Fourth, if the history is empty — the schedule isn’t armed. Not a fault: it was never asked.
Fifth, if it ran full length and nothing’s wet — check the water supply. Thirty seconds, and it explains total silent failure better than anything else on the list.
Sixth, if every zone is dry — suspect the common wire, the master valve, or the pump relay, in that order. Everything failing at once is one fault, not many.
Seventh, if one zone is dry — swap it to a known-good terminal to sort field from controller before you dig anything up.
Eighth, open the valve’s manual bleed. Water on manual means the valve is fine and the fault is electrical.
Last, replace the controller. It’s what gets blamed and it was almost never the problem.
Symptom to Cause, at a Glance
| What you observe | Most likely class | First thing to do |
|---|---|---|
| No run, and the history shows a skip | Weather logic working as designed | Read the reason; check the station’s location |
| No run, history completely empty | Schedule disabled or controller in standby | Confirm the schedule is armed and active |
| Logs full of ticks, lawn dry | Seasonal adjust scaling runs toward zero | Read the durations, not the ticks |
| Sprinklers on at odd times in short bursts | Cycle-and-soak | Not a fault — the run is split deliberately |
| Full-length run, every zone dry | Water supply off, common wire, or master valve | Check the main and backflow first |
| Full-length run, one zone dry | That zone’s wire or solenoid | Swap to a known-good terminal |
| Zone works on manual bleed but not on schedule | Solenoid or wiring, not the valve | Check the coil and the splice in the box |
| Worked for years, now intermittent when wet | Corroded splice in a valve box | Open the box; redo the splice waterproof |
| Skips after rain you never saw | Weather station too far away | Move to a nearer station or add a local sensor |
What Didn’t Help
Worth more than a couple of the sections above it, because records of failure are rarer than advice.
Rebuilding the schedule. Our most-repeated reflex, our least productive action. If the controller is skipping, a new schedule gets skipped identically. If a valve is dead, a new schedule kills it just as thoroughly. You have changed the instruction, and the instruction was fine.
Replacing the controller. Expensive, disruptive, and in our log it was rarely the fault. A controller that reports runs is doing its job; the fact that it’s wrong about your lawn is precisely because it can’t see your lawn. A new one won’t be able to see it either.
Turning off all the weather features. Tempting after a skip you disagreed with, and it does make watering happen. It also throws away the reason you bought the thing, and it replaces a system that’s occasionally wrong with one that’s reliably indifferent. Fix the station or the soil type instead.
Increasing zone times to compensate. The classic response to a dry lawn with clean logs, and it treats the symptom of a scaling factor you haven’t found yet. If the budget is at 20%, doubling your zone time gets you from two minutes to four. You’ll be back.
Digging first. We did this once. Sorting the fault to a terminal, a wire, or a valve with a five-minute swap test would have told us where to dig, and would have told us not to.
Frequently Asked Questions
The app says it watered. Can I trust it? Trust it about electricity, not about water. Without a flow sensor, that entry means the controller energized a terminal for a period. Whether anything got wet is outside its knowledge entirely.
Why does it skip when my lawn is obviously dry? Usually a weather station that isn’t near you, or a soil model that thinks your dirt holds more water than it does. Both are correctable, and both are far better fixes than switching the feature off.
Every zone stopped at once. Is the controller dead? Probably not. Everything failing simultaneously points at something everything shares: the water supply, the common wire, the master valve, or a pump relay. A controller failing usually doesn’t do it that tidily.
What is the common wire? The shared return that every solenoid needs to complete its circuit. Break a zone wire, one zone dies. Break the common and every zone dies while the controller reports total success, because on many controllers nothing tests it.
My sprinklers run for a few minutes and stop, several times. That’s cycle-and-soak, and it’s deliberate — short runs with gaps let water soak in instead of running off. Not a fault; usually an improvement.
Should I just turn off the smart features? It’ll water. It’ll also water pointlessly in the rain, which is the thing you bought it to stop. Fix the inputs rather than disabling the logic.
How do I tell a bad valve from bad wiring? The manual bleed on the valve body. Water on manual means the valve and the supply are fine and your fault is electrical. No water on manual means the valve or the supply is the problem.
It worked for years and now it’s flaky. Look for a splice in a valve box. Boxes take on water, connections corrode gradually, and the classic signature is exactly this: works when dry, fails when wet, worsens over seasons.
Methodology and Who Wrote This
This page was produced by the Smart Home Guide Editors from a log we kept while deliberately breaking and restoring a reference multi-zone system, rather than from waiting for failures to arrive. We disconnected solenoids, degraded a common wire to a marginal rather than clean fault, closed the supply while a full schedule ran, drove seasonal adjustment to extremes, toggled weather intelligence across matched days, and enabled cycle-and-soak and then went outside to see where the water actually went. We changed one variable at a time and read the log after each.
The ordinal shares in our tables are shares of the incidents we logged, on our system, in our climate, on our water. We’ve deliberately not presented them as precise percentages, because we didn’t run a sample that would justify that precision and we’d rather be usefully approximate than impressively fake. A yard with harder water and older valves would push the physical classes up the table. We would still expect weather skips to lead, because that class is produced by the software operating normally rather than by anything wearing out. The vocabulary problem is real and not ours: seasonal adjust, water budget, and monthly adjustment often name the same arithmetic, and some controllers fold it into an automatic mode whose numbers you can’t inspect. We’ve described behaviours so you can map them onto whatever your product calls them.
We have no relationship with any irrigation manufacturer. Where we link to hardware, those are affiliate links and we may earn a commission; anything named is something that resolved incidents in our own log and was chosen before a link was attached. Fixes that didn’t work for us aren’t here.
— The Smart Home Guide Editors