Back to field notes

Irrigation verification

How to Verify a Missed OpenSprinkler Irrigation Event

A practical evidence checklist for separating a pending event, a missed event, a short runtime, and a controller-program mismatch.

Core Cannabis · Product field notePublished 2026-09-16

Start with the authoritative schedule

Record the schedule date, room, mapped station, start time, and expected runtime. This is the reference used to judge the controller log. A screenshot of a weekly program without its date and station mapping is not enough.

Check whether the event is still in the future. A 10:00 event with an eight-minute runtime remains pending until its expected completion window has passed. Labeling it missed at 10:02 creates false alarms and can lead to duplicate recovery.

  • Exact schedule date
  • Expected station
  • Expected start time
  • Expected duration

Separate stored program from execution log

The Programs screen shows what the controller intends to run. The Logs screen shows station activity that actually occurred. Both matter, but they are not interchangeable.

If the program is missing, investigate deployment or persistence. If the program exists but no matching log appears after the event window, investigate controller execution, pump state, master-station behavior, or device availability.

  • Program absent: deployment problem
  • Program present and log absent: execution problem
  • Log shorter than expected: short-run problem
  • Log longer than expected: overrun problem

Compare every station in the group

A grouped program can appear to have run while only part of the room received the full duration. Compare each mapped station separately. Station 1 completing does not prove Stations 2 through 8 completed.

Sequential and parallel station settings can also change how the log appears. Verification should use the controller's actual station timestamps and durations rather than assuming every zone ran together.

  • One expected row per station
  • Duration tolerance applied consistently
  • No unmapped active stations
  • No duplicate station events

Calculate recovery from confirmed missing volume

Once the missing events are known, calculate their volume from the same approved schedule that created the expected runtimes. Do not substitute a generic long watering or replay the entire day.

Protect future scheduled events from duplication. A recovery window should begin only after pending production events complete, preserve the daily cutoff, and remain a temporary one-day action rather than replacing the recurring schedule.

  • Recover confirmed misses only
  • Keep the normal recurring schedule unchanged
  • Respect cutoff and overlap constraints
  • Verify recovery in logs

Keep the evidence together

A useful incident record links the expected schedule, deployment acknowledgement, persistence read-back, controller log, recovery decision, and final verification. That record makes the next investigation faster and exposes repeated failures that a single connection badge cannot show.

The operational goal is not merely to clear an action-needed label. It is to know what water was expected, what the controller stored, what actually ran, and what was deliberately recovered.

  • Expected
  • Stored
  • Executed
  • Recovered
  • Verified

See the operating workflow

Follow room inputs through P1/P2/P3 schedule generation and operator review without connecting a controller.

Open the interactive demo