On the first cool morning of the season, a farm operator stands at the controller cabinet with the installation manual open in one hand and a printed copy of the local watering notice in the other, about to type a schedule into a panel that has been running the same program since midsummer. What he has to decide is not which weather feed sounds smarter. A smart sprinkler setup should be judged on two things you can actually locate in a manual: a documented way to accommodate watering restrictions, and, on a soil moisture controller, a preset threshold the unit holds. Weather-data marketing is easy to print on a box. Those two capabilities are what keep a seasonal schedule tied to changed rules and changed water need.
The scope is landscape irrigation. The controller material behind this walkthrough covers US EPA WaterSense weather-based irrigation controllers and soil moisture–based controllers (SMSs), which act on a moisture threshold instead of a clock. None of it establishes a crop-farm water budget, a yield effect, or a savings number for a production field. Two items also sit outside that material: electrical compatibility between a new controller and the existing system, and any farm-level savings claim. Both stay as questions for the supplier.
Day One Checks the Controller's Capabilities
Day one is a documentation pass, not a wiring pass. Keep the controller separate from the sprinkler hardware it drives, because they are sold and specified separately. A weather-based controller adjusts schedules using local weather data and landscape conditions to tailor the amount, frequency, and timing of watering. A soil moisture controller works from a different input: it acts on the moisture state rather than a weather forecast, and it decides against a preset threshold. The manual for the model in your hands is the only place that tells you which behavior you bought and how to reach it.
The WaterSense label earns its place through certification, not through promise. A labeled SMS has to be able to consistently prevent or allow irrigation at a preset threshold, and labeled products are independently certified against the EPA's criteria for efficiency and performance. Read that as a statement about tested capability under listed criteria, not a rating of how much water your operation will save.
Three checks come before anything is rewired, and each is a paper exercise. Find the feature that accommodates watering restrictions and note its exact name and location in the manual. Find how the threshold is set and how the unit displays whether it is holding or allowing irrigation. Then put the electrical question to the supplier or installer: ask them to confirm the controller's electrical requirements against the existing system's, since that comparison is not covered by anything here.
Set a Seasonal Baseline First
The classic failure is not a broken controller. It is a schedule set once at the height of the growing season and never revisited: irrigation programs are commonly written for peak demand, and the person who wrote it often does not come back when the weather turns or plant needs shift. A controller that adjusts from weather data can correct for that drift, but only relative to the baseline you gave it. Build the baseline from the site's current season and the conditions you can document — plant type, exposure, soil, which zones are actually planted — rather than from a neighbor's program.
Resist turning any example into a rule. Run times that circulate as minutes per zone come from somebody else's soil, slope, head spacing, and pressure; copying one into your panel installs a baseline you cannot defend and makes every later adjustment inherit the error. What you want on day one is a defensible starting schedule plus a written reason it looks the way it does, so a change you notice in week three can be credited to the controller's adjustment instead of a guess you forgot you made.
First Week Verify Weather-Based Adjustments
Keep a dated log through the first week. Each day, record the weather input the controller is designed to use, the schedule the panel presents, and whether the amount, frequency, or timing of watering changed. That last column is the one people skip, and it is the only one that answers the question you actually have: is this unit responding to conditions, or running a table? A clock-based controller is the original set-and-forget device: you program it at peak season and it keeps that promise through a cool spell and a downpour alike.
Read the log honestly in both directions. A day with no change is not proof the controller failed, because conditions may simply not have crossed whatever the unit responds to. A day with a change is not proof of savings; it shows adjustment and nothing more. You are checking a mechanism, not an outcome. And confirm the unit is actually in its weather-based mode, since one left on a fixed program presents a perfectly stable schedule that looks like discipline and reveals nothing.
If the interface does not show why a change happened, that is a documentation request, not permission to improvise. Ask the manufacturer how the unit indicates that it has adjusted and where that status appears. Improvised diagnostics tend to leave the controller in a state you cannot reconstruct, and you lose the baseline you were comparing against.
Add Watering Restrictions as a Capability
WaterSense treats the ability to accommodate watering restrictions as a supplemental capability, one of the additional features meant to support greater long-term water savings. That is a capability statement, and reading more into it is the most common setup error in this whole exercise. The restriction menu is a feature, not a rulebook: nothing in it tells you which days or hours your water authority allows, and a unit running contentedly through a prohibited window is not evidence of compliance.
The sequence that holds up: get the current rule from the authority that issues it, record the source and the date you pulled it, and enter only what the manual documents as a restriction setting. When the written rule and the menu do not map cleanly — a weekly limit against a menu built around odd and even addresses, say — the written rule stays the controlling document and the menu is what has to be reconciled. Ask the supplier which setting represents the rule and get the answer in writing. Then compare the schedule the panel presents against the rule you recorded, not against your memory of last year's notice.
First Month Confirm Threshold Behavior
By the end of the first month, a soil moisture controller should be verifiable on its own terms. A WaterSense-labeled SMS has to be able to consistently prevent or allow irrigation at a preset threshold. That gives you two things to find at the panel: the threshold value the controller acts on, and the status indication that shows which side of it the current reading sits on.
Confirm the threshold mode is active, then use the manufacturer's documented method to read the status. What you should not do is substitute your own judgment for the threshold. Entering a moisture number you guessed, or overriding the sensor input, puts the unit outside the behavior the label covers and leaves you with a system that looks instrumented while it behaves manually. If the unit does not expose its status anywhere you can see, that belongs in a support ticket, not in a workaround.
Three Months Later Review Seasonal Fit
Three months out, the question changes from whether the controller works to whether the setup still fits the season. Do the review with three artifacts in front of you: the restriction note with its source and date, the current mode and threshold setting shown on the panel, and what the site actually looks like — ponding, runoff, dry corners, a zone that never needed the water it received.
Adjust only inside documented settings, and change one thing at a time. If the local rule changed since you recorded it, pull the current version and re-date the note before touching the restriction menu, because a stale citation is worse than no citation: it looks like a check. If the season shifted and the baseline no longer describes the site, rebuild the baseline instead of nudging the threshold to compensate. Everything here stays at the level of irrigation behavior on the landscape — ponding and dry corners are the feedback, not a yield verdict.
Run the Setup as One Workflow
Run end to end, the sequence is a chain of records rather than a chain of button presses. The controller model and its type get written down first, because everything after depends on which manual you are reading. The label claim, the restriction-accommodation feature, and the threshold method get confirmed on paper. The local rule gets pulled from its issuing authority and dated. The baseline gets written before it gets entered. Then the unit goes into the mode the manual documents, the first week gets logged daily, and the threshold status gets read by the end of the first month.
Those records are what separate a setting problem from a hardware problem from a rule change in midsummer. Neither electrical compatibility with the existing system nor a farm-level savings figure comes out of any of this material, so both stay with the supplier: one as a compatibility question, the other as something no EPA landscape-controller document will answer for a production field.
One objection tends to survive all of this: the controller reads the weather, so why keep checking a restriction menu and a threshold at all? Because the weather feed and the restriction notice answer different questions, and only the manual tells you where each one lives on the panel. Before the next seasonal change, open the manual at those two pages again rather than re-reading the box, and keep the written rule in front of you while you compare it with what the panel shows.
