Automations
Main page: Usage
Previous: Events
Next: Off-the-shelf controllers
Since this integration does not interface with your irrigation system directly, you will need to use the data it outputs to create an automation that will start and stop your irrigation system for you. This way you can use this custom integration with any irrigation system you might have, regardless of how that interfaces with Home Assistant. In order for this to work correctly, you should base your automation on the value of sensor.smart_irrigation_[zone_name] as long as you run your automation after it was updated (e.g. 11:00 PM/23:00 hours local time). If that value is above 0 it is time to irrigate. Note that the value is the run time in seconds. Also, after irrigation, you need to call the smart_irrigation.credit_watering service with how long the zone ran, so the bucket is credited with the water it received. (smart_irrigation.reset_bucket, which sets the bucket to 0, still works, but loses the deficit a run cut short by the maximum duration did not water.)
The last step in any automation is very important, since you will need to let the integration know you have finished irrigating, by calling the
smart_irrigation.credit_wateringservice
Resetting the bucket says the soil is at field capacity at that moment, so any rain collected since the last calculation is part of what that statement covers and is not counted again at the next one. Rain falling after the reset still counts as usual. This matters when it rains between the calculation and irrigation: without it the same rain would both shorten the run and fill the next bucket.
Experts say you should water deeply but infrequently to avoid overwatering and encourage deep rooting. It might be a good idea to create an automation that starts early enough to finish before sunrise (using the smart_irrigation_start_irrigation_all_zones event) and only once per week if duration is above 0 or whenever the bucket < -25 mm. Adjust to your specific needs.
The examples on this page don't use a timer - see this discussion for an example of using a timer for extra safety.
Writing your own executor rather than using a blueprint? The output contract says exactly what Smart Irrigation publishes, when it changes, and what to send back.
Blueprints we provide
A blueprint is a parameterised mould for an automation: you import it once, pick your entities from filtered dropdowns, and Home Assistant writes the automation for you.
You already have them. Smart Irrigation copies the blueprints below into your own blueprints/ folder when it starts, so they are waiting for you under Settings > Automations & scenes > Blueprints, grouped as Smart Irrigation. Nothing to download.
Existing files are never overwritten, so anything you have edited stays yours. That also means an improved blueprint does not reach you on its own: use the Import link in the table below to pull the current version, or delete your copy and restart. You can also browse the whole folder.
Pick the one that matches how your valves are actually driven:
| Blueprint | Use it when | |
|---|---|---|
standard-irrigation.yaml |
A plain switch, valve or input_boolean per zone. Turns it on for the calculated duration, then resets the bucket. Has an optional pause switch. | Import |
esphome.yaml |
An ESPHome device that takes the duration itself. | Import |
simple-scheduler.yaml |
A script rather than an automation, if you prefer to call irrigation from elsewhere. | Import |
irrigation-unlimited-adjust-time-single-zone.yaml |
Irrigation Unlimited runs your schedule and you want Smart Irrigation to set the run time of one zone through adjust_time. |
Import |
irrigation-unlimited-adjust-time-sequence.yaml |
The same for one zone inside an IU sequence. Adjusting a sequence as a whole spreads the time across its zones in proportion to their original durations, which is not what a calculated duration means, so this adjusts one zone of it and you add one automation per zone. | Import |
irrigation-unlimited-reset-bucket.yaml |
Pair with either of the two above: resets the bucket when IU reports the run finished. | Import |
weather-responsive-scheduling.yaml |
You want a seasonal multiplier applied automatically and runs skipped on cold or windy days. | Import |
valve-watchdog.yaml |
A backstop: closes a valve left open longer than a limit you set, and tells you. Worth adding whatever else you use. | Import |
rainbird.yaml |
A Rain Bird controller: starts the Rain Bird zone for the calculated run, in whole minutes. | Import |
hydrawise.yaml |
A Hunter Hydrawise controller: the same, through hydrawise.start_watering. |
Import |
rachio.yaml |
A Rachio controller: the same, through rachio.start_watering (at most 3 hours a run). |
Import |
opensprinkler.yaml |
An OpenSprinkler controller (the OpenSprinkler integration from HACS): the run in seconds, through opensprinkler.run_station. |
Import |
bhyve.yaml |
An Orbit B-hyve controller (the B-hyve integration from HACS), through bhyve.start_watering. |
Import |
With an off-the-shelf controller (Rain Bird, Hydrawise, Rachio, OpenSprinkler, B-hyve), Smart Irrigation decides how long each zone waters and the controller runs the valves. The off-the-shelf controllers page walks through the setup, which entity to pick for each brand, how to turn off the controller's own schedule, and what to do with several zones. These five have been written against each integration's documented actions but not yet confirmed on real hardware: if you have one, a word on the discussions saying it works, or what it needed, is the most useful contribution there is.
Irrigation-V5 needs no blueprint at all: it reads a numeric entity as a multiplier, so pointing its Adjustment Sensor at our zone sensor with a base watering time of 1 second gives it the calculated duration directly. See executor integration.
With Irrigation Unlimited, note that it exposes binary sensors, not switches: Smart Irrigation tells it how long to run through adjust_time and IU does the running. Do not drive the valve yourself in parallel, or the two will fight.
If you use observed watering or direct valve control (see closed loop), turn off the blueprint's option to credit the run (or do not use a blueprint that calls reset_bucket): the integration credits the bucket itself and the two would count twice.
Example 1: one valve, once per week irrigation if duration > 0 or if the bucket < - 25 mm:
This example automation runs daily and checks sensor.smart_irrigation_[zone_name]. It checks if the buckets is < -25mm (~1") or if's a monday and duration is above 0. This follows the expert recommendation mentioned above.
Example 2: one valve, potentially daily irrigation
Here is an example automation that runs when the smart_irrigation_start_irrigation_all_zones event is fired. It checks if sensor.smart_irrigation_[zone_name] is above 0 and if it is it turns on switch.irrigation_tap1, waits the number of seconds as indicated by sensor.smart_irrigation_[zone_name] and then turns off switch.irrigation_tap1. Finally, it resets the bucket by calling the smart_irrigation.reset_bucket service. If you have multiple instances you will need to adjust the event, entities and service names accordingly.
Example 3: one valve, irrigation depending on work day sensor
Here is an example automation that runs at 5 AM local time, but only on set days of the week indicated by binary_sensor.workday_sensor). As above, it checks if sensor.smart_irrigation_[zone_name] is above 0 and if it is it turns on switch.irrigation_tap1, waits the number of seconds as indicated by sensor.smart_irrigation_[zone_name] and then turns off switch.irrigation_tap1. Finally, it resets the bucket by calling the smart_irrigation.reset_bucket service.
This automation depends on the workday binary sensor which you will have to set up separately. Alternatively you could use a condition such as:
condition:
condition: time
weekday:
- mon
- thu
Example 4: two valves, irrigation depending on work day sensor
Here is an example automation that runs at 4 AM local time, but only on set days of the week indicated by binary_sensor.workday_sensor). As above, it checks if sensor.smart_irrigation_[zone_name] is above 0 and if it is it turns on switch.irrigation_tap1, waits the number of seconds as indicated by sensor.smart_irrigation_[zone_name] and then turns off switch.irrigation_tap1. Then it turns on switch.irrigation_tap2, waits the number of seconds as indicated by sensor.smart_irrigation_[zone_name] and then turns off switch.irrigation_tap2. Finally, it resets the bucket by calling the smart_irrigation.reset_bucket service.
This automation depends on the workday binary sensor which you will have to set up separately. Alternatively you could use a condition such as:
condition:
condition: time
weekday:
- mon
- thu
Example 5: Advanced multi-tap example
This example handles multiple taps for a six-zone system controlled by ESPHome. This is the automation the creator of this integration uses themselves (ignoring the expert advice above...).
Main page: Usage
Previous: Events
Next: Off-the-shelf controllers