Closed-loop watering

Main page: Configuration

By default Smart Irrigation runs open loop: it calculates a duration and fires an event, but it does not know whether (or how much) watering actually happened, so you reset the bucket from an automation. The closed-loop features remove that guesswork. They are all opt-in and configured in the panel under General.

Observed watering (credit the bucket automatically)

When enabled, Smart Irrigation watches each zone's linked valve/switch. Whenever it runs (a manual tap, an automation, or Smart Irrigation itself), the zone's bucket is credited from the run time and the zone's throughput (depth_mm = throughput_L_per_min x minutes / size_m2). No more manual reset.

To set it up:

1. In General, turn on Enable observed watering.
2. In Zones, set each zone's Linked valve/switch to the entity that waters that zone (a switch, valve or input_boolean).

Important: when observed watering is on it becomes the only thing crediting the bucket. Remove any reset_bucket service call from your irrigation automation, otherwise the bucket is accounted twice.

Optional: a cumulative volume meter (more precise)

For exact accounting you can also set a zone's Cumulative volume meter. The applied depth is then taken from the measured volume delivered during the run (meter_at_close - meter_at_open) instead of throughput x time.

It must be a cumulative water-meter total (state class total_increasing), not an instant flow rate. The unit is read automatically from the sensor (L, mL, m³, gal, ft³). An instant flow-rate sensor (for example L/min) will not work; if your hardware only exposes a rate, feed it through a Riemann-sum Integration helper first to get a cumulative total.

What the meter tells us about your throughput

Every irrigation duration is derived from the zone's configured throughput: the bucket says how many mm are missing, the size turns that into litres, and the throughput turns litres into minutes. A throughput copied off a datasheet rather than measured at the tap is one of the quietest ways to water twice as long as intended, or half as long, for a whole season.

A zone with a volume meter gives the answer for free, since a run knows both how many litres came out and how long the valve was open. Smart Irrigation divides one by the other, smooths the result over several runs, and raises a repair notice in Settings > Repairs when it drifts more than 25% from what you configured. Runs shorter than two minutes are ignored: filling the pipe dominates them.

It only ever tells you. The zone's throughput is never rewritten, because pressure varies, a meter can sit upstream of more than one zone, and silently changing how long valves stay open is not something to do behind your back. If the measurement looks right, copy it into the zone yourself.

Direct valve control (let Smart Irrigation run the valves)

With Let Smart Irrigation control the valve on, Smart Irrigation opens each zone's linked valve, waits the calculated duration, then closes it. No execution automation needed. The start event still fires, so external executors keep working too.

It stands on its own: the zone's Linked valve/switch can be set with direct valve control alone, without observed watering. The two answer different questions, and the difference matters when the same valve is used for other things -- filling a paddling pool, hosing the terrace. Direct valve control credits the bucket for the runs it performs, since it knows exactly what it delivered. Observed watering credits any run of that valve, which is what you want for a tap somebody opens by hand to water the same lawn, and not what you want if that valve also does something else. Leave observed watering off in that case.

• Zone sequencing: Sequential runs one zone at a time (safe for water pressure); Parallel opens all eligible zones at once. This setting also decides how long the whole run is taken to be, which is what a start trigger works back from when it has to finish at sunrise: sequential is the sum of every zone's run time, parallel is the longest of them. It therefore applies whether Smart Irrigation opens the valves itself or an automation of your own does, and it is available in the general settings either way.
• Open confirmation: before crediting, Smart Irrigation waits for the valve to report an on-state. If it never opens, the run is not credited (so the deficit stays and rolls over to the next day) and a smart_irrigation_zone_problem event is fired. A write-only valve with no readable state is given the benefit of the doubt.
• Reboot resilience: a run that is in progress when Home Assistant restarts is resumed (or closed if it already exceeded its duration) and then credited.
• One run per zone per cycle: a zone whose valve is already open is left out, and a zone watered while it waited its turn in a sequential run is not watered again when the queue reaches it. With observed watering on, that includes a valve opened outside Smart Irrigation, by hand or by another automation: running it too would close the valve under that run and count the overlap twice.
• One cycle at a time, in sequential mode: a run asked for while one is already going joins the queue instead of starting beside it, so two valves are never open at once. A zone already waiting is not queued twice, the zone being watered right now is not queued behind itself, and the zones that joined are in the same end-of-run summary. In parallel mode there is nothing to join: every zone at once is what that setting asks for.

Safety: if Home Assistant goes down for a long time during a run, the physical valve stays open and keeps watering, because Home Assistant is no longer there to close it. Give your valve a hardware failsafe (a maximum runtime on the device itself). Smart Irrigation also caps the credited time at the zone's maximum duration.

Cycle and soak, and the pause between zones

Two settings on the advanced panel, both off by default, for an installation that is already tuned.

Water in several passes splits a run into shorter passes with a pause between them. Clay and compacted soil have an infiltration rate: past it the water runs off or puddles, and the zone is billed for water the roots never see. Three passes of five minutes with fifteen minutes of soaking deliver the same water as one run of fifteen minutes, and the soil keeps more of it. Guidance: sand takes water as fast as you can give it, so leave this at one pass; loam rarely needs more than two; clay and slopes are what it is for.

The plan is fixed when the run starts, and a run too short to split is left alone (no pass shorter than a minute). Each pass is credited as it closes, so a restart in the middle of a run never credits water twice and never leaves a valve open.

Pause between zones waits between two zones of a sequential run, for the line pressure to recover or for a slow valve to finish closing before the next one opens.

Both lengthen the run without adding water to it, and a start trigger that has to finish at sunrise works back from the whole thing, soaking and pauses included: three zones of half an hour in three passes with fifteen minutes of soaking occupy two and a half hours, not an hour and a half. Watch that against the hour you want to be finished by. When an executor of your own opens the valves instead, neither setting applies and the run length is the watering alone.

Events for your own automations

Direct valve control fires events you can use to notify or react, so you do not need one automation per zone:

• smart_irrigation_irrigation_started when a run begins. Data: sequencing (sequential/parallel) and zones, a list of {zone_id, zone, seconds} about to be watered.
• smart_irrigation_irrigation_finished when the whole run is done. Data: zones, a list of {zone_id, zone, seconds, volume_l, bucket} that ran (volume delivered and the new bucket level), and problems, a list of {zone_id, zone, reason} for zones whose valve did not open.
• smart_irrigation_zone_problem the moment a valve fails to open. Data: zone_id, zone, entity_id, reason.

Example: a single end-of-watering report for all zones.

alias: Watering report
triggers:
  - trigger: event
    event_type: smart_irrigation_irrigation_finished
actions:
  - variables:
      zones: "{{ trigger.event.data.zones }}"
      problems: "{{ trigger.event.data.problems }}"
  - action: notify.mobile_app_your_phone
    data:
      title: "{{ '🚨' if problems | count > 0 else '🌱' }} Watering finished"
      message: >-
        {% set l = namespace(t=[]) %}
        {% for z in zones %}
          {% set l.t = l.t + [z.zone ~ ": " ~ (z.seconds / 60) | round(1) ~ " min, " ~ z.volume_l ~ " L"] %}
        {% endfor %}
        {% for p in problems %}
          {% set l.t = l.t + ["WARNING " ~ p.zone ~ ": " ~ p.reason] %}
        {% endfor %}
        {{ l.t | join("\n") }}
mode: single

If you previously had one automation per zone that opened the valve and called reset_bucket, remove them once direct valve control is on: Smart Irrigation now opens the valves and credits the bucket itself, so the old automations would double up. Keep only report/notification automations like the one above.

The legacy smart_irrigation_start_irrigation_all_zones event still fires too (it carries the trigger identity), for setups that drive watering from their own automation or an external executor instead of direct valve control.

When does it run? The active start trigger

Irrigation starts on a single active trigger, chosen in General under the start triggers. The triggers you define are the pool of options; only the selected one starts watering, so a run happens once per day.

The default, Default (sunrise minus total watering duration), times the run so it finishes right at sunrise. Add custom triggers (sunset, solar azimuth, offsets) below and pick one as the active trigger if you prefer.

Main page: Configuration