Irrigation from soil and weather, not a calendar

Three facts decide every run

How wet the soil is now. A capacitive probe in the root zone reports volumetric water content as a percentage. The number is only meaningful once you have seen the zone saturated and seen it wilt, so each probe carries two calibration marks, field capacity and the point where the grass stops looking happy. The controller waters when a zone drops halfway between them, and stops when it reads field capacity.

How much water fell. A tipping‑bucket or haptic rain gauge on the roof gives the last 24 hours in inches. A quarter inch of rain is a full run for most turf, so that is the skip threshold.

How much water will leave tomorrow. Reference evapotranspiration (ET₀) is the depth of water a well‑watered reference crop loses to sun, wind and dry air. Forecast services publish it per day in inches. Multiply by a crop coefficient (about 0.8 for cool‑season turf) and you have tomorrow's demand before the sun is up.

The products that expose those facts locally

• Ecowitt WH51 soil probes. Up to eight report through a GW1100 or GW2000 gateway, and the gateway can be told to post every reading to any HTTP endpoint on your network on a timer. The controller is that endpoint. No cloud account is involved.
• WeatherFlow Tempest. The hub broadcasts every observation on the local network over UDP: rain, wind, solar radiation, temperature and humidity. The controller listens; it never has to ask.
• Forecast ET₀. Open‑Meteo returns daily et0_fao_evapotranspiration for your coordinates without an API key. The National Weather Service API gives the probability and amount of rain. Both are read once a day and cached, so an outage costs a forecast, not a run.

The products that do the watering

• OpenSprinkler, including the OSPi. Open firmware with a documented HTTP API: start a station for a number of seconds, stop everything, read what is running. The OSPi is a Raspberry Pi HAT, so the same Pi that runs Opichy can drive the valves directly.
• Rain Bird controllers with the LNK2 WiFi module. The module answers on the local network. The community pyrainbird library documents the request format, and the controller uses the same calls.
• Plain 24 VAC valves. Rain Bird, Hunter or Orbit solenoids on a relay HAT and a 24 VAC transformer. This is the most hardware‑defined option, and the only one where a master valve and a pulse flow meter are entirely yours.
• Rachio 3, Orbit B‑hyve, Hunter Hydrawise. Cloud tier. Rachio has a documented REST API and webhooks; the others are reverse‑engineered. Opichy can use them with the cloud layer turned on, and says so, rather than pretending they are local.

The rules, in the order they are checked

skip all zones   if rain_24h ≥ 0.25 in
skip all zones   if forecast_rain_24h ≥ 0.25 in at ≥ 60 %
skip all zones   if wind ≥ 10 mph            // spray drifts onto the driveway
skip zone        if soil ≥ field_capacity − 5 %
run zone         for demand ÷ precipitation_rate, split into two cycles on slopes
window           04:00 to sunrise            // least evaporation, least wind
fault            if flow < 70 % or > 130 % of the zone's known gal/min

The flow rule is the one people skip and later wish they had not. A pulse meter on a GPIO input turns a stuck valve or a broken head into a fault within a minute, and the controller closes the master valve. Without it, the first sign is the water bill.

What this looks like in the capability model

A valve is a Switch with a declared maximum on‑time; the controller refuses a run longer than that whatever the automation asks. A probe provides SoilMoisture with an age; a reading older than an hour becomes Uncertain and the zone is skipped rather than guessed. The weather station provides Rainfall and WindSpeed as measured values; the forecast provides ET₀ as a value whose quality is explicitly a forecast, never a measurement. The same distinctions the model draws in a factory keep a lawn from being watered on a hunch.