Events

Main page: Usage
Previous: Services
Next: Automations

After installation, the following events are available:

Event	Description
smart_irrigation_start_irrigation_all_zones	Fired when an irrigation start trigger is reached, or, with the full controller, when a schedule of the main program is due (trigger_type is then program). Listen to it to start your irrigation. See automations for examples.
smart_irrigation_irrigation_skipped	Fired when a start trigger is reached and the day is a skip day, so nothing is watered. Data: the trigger's identity, plus reason and checks, the same detail the Home page shows. The reason is the skip condition that held the day back: postponed, rain_sensor, freeze, wind, precipitation, days_between or soil_moisture. With the full controller, a trigger reached while the main program is off or suspended fires it with the reason main_program_disabled or main_program_suspended (and no checks). A trigger reached while Smart Irrigation is switched off fires it with the reason irrigation_off (and no checks).

Direct valve control fires three more, described in closed-loop irrigation. The full controller adds its own, with the data of each described there: program_started, program_finished, valve_on, valve_off, valve_out_of_sync and supply_problem. These three are also fired:

Event	Description
smart_irrigation_zone_unwatered	A zone has been dry for more than 3 days and no program will water it; fired once per zone, together with a repair notice. Data: zone_id, zone, days, deficit_mm. See the dry zone notice.
smart_irrigation_weather_stale	A temperature, humidity, dew point, wind speed or pressure source of a sensor group has not reported for 6 hours; fired once per silence. Data: mapping_id, mapping, fields (the fields that just went silent) and since (the time of the last report).
smart_irrigation_weather_recovered	Fields that were silent report again, or the outage stops being watched. Data: mapping_id, mapping, fields, and reason when it is not a recovery: unloaded (the integration was reloaded, disabled or removed) or unwatched (no automatic zone uses the group any more).

Only zone_unwatered needs the full controller; weather_stale and weather_recovered do not.

Knowing a run was skipped

A skipped day used to be the absence of an event, and nothing can listen for something that does not happen. That is why the skip now fires its own event:

automation:
  - alias: "Tell me when irrigation was skipped"
    trigger:
      - platform: event
        event_type: smart_irrigation_irrigation_skipped
    action:
      - service: notify.persistent_notification
        data:
          message: "No irrigation today: "

The Home page answers the same question without an automation: it shows whether the next start would be skipped and why, and what the last real decision was.

When does it fire?

The event fires when the active start trigger is reached. You can define several triggers, but only the one selected as active starts the watering, so the run happens once per day. The Start triggers card on the General page has the choice:

• A trigger you defined. A solar event (sunrise, sunset or solar azimuth), optionally shifted by an offset, or a fixed clock time. A fixed time suits irrigation that has to be done by a certain hour whatever the season, rather than following the sun.
• Default. Used whenever Default is selected, even if you have defined triggers. It starts early enough before sunrise that watering finishes at sunrise: sunrise minus the planned length of the run. That length is how long the run really takes, so with zones in parallel it is the longest zone rather than the sum, and the soak and pauses between zones are counted when Smart Irrigation opens the valves itself.
• None. Nothing starts the watering, whatever the weather. The durations are still calculated. It is the way to keep Smart Irrigation from starting a run.

With account for duration on, a trigger works back from its moment so watering finishes then; with it off, watering starts then. That applies to a fixed time as well: set 06:30 with it on and an hour-long run starts at 05:30.

The skip conditions still apply: on a skip day no start event is fired, and the skipped event above is fired instead.

Event data

The event carries the identity of the trigger that fired, so a single automation can react differently per trigger:

field	meaning
trigger_name	the name you gave the trigger
trigger_type	sunrise, sunset, solar_azimuth or time. With the full controller, a start or a skip decided for a program's schedule (the main program's included) has program, and carries program_id and schedule_id too
at	for a time trigger, the clock time it is set to
offset_minutes	the configured offset, in minutes
account_for_duration	whether timing is shifted so watering finishes at the target moment

Example: filter on trigger_name to react to a specific trigger.

trigger:
  - platform: event
    event_type: smart_irrigation_start_irrigation_all_zones
    event_data:
      trigger_name: "Morning"

Main page: Usage
Previous: Services
Next: Automations