How to Verify a Missed OpenSprinkler Irrigation Event

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.

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.

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.

When a station group is still running at the next program's scheduled start, the controller may queue that group's next run. Compare the actual start against the previous run's end in the same group before calling the later event missed. A late start with the full expected duration is different from a missed watering.

If several station logs end at the same second, inspect the controller and automation audit for a stop-all action. That pattern can indicate an interrupted program even when a program was saved and some stations started. Controller logs verify valve runtime; they do not prove that the pump delivered the expected volume to each plant.

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.

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.