Irrigation Unlimited Integration

Hello,
I am new to Home Assistant and have installed and run irrigation unlimited.
I would need some input on the configuration.
I have a system with 6 zones and currently I use all 6 zones as a schedule 30 minutes before sunrise.
Now I would like to diversify the schedules as follows:
Zone 1 and 6 always 30’ before sunrise on alternate days
Zone 2,3,4,5 always 30’ before sunrise every day 2 times a day.
Could you help me with the configuration?

Thanks

The best thing you can do at this stage is to read the very comprehensive documentation.

Is there a way to repeat a sequence with a delay between the sequence instead of a delay between the zones?

I have new grass in the back yard and I would like to water all zones there back to back and repeat that sequence every 4 hours.

Add a dummy zone to the end of the sequence.

Thanks. I will try that.

FYI: Here’s an issue I ran into using a history_stats sensors when watering spans a day.

I’m trying to track daily water usage by tracking how long each valve is on. But, at times I’m getting very high usage number that don’t match the physical water meter. I tracked down why.

I created history_stats sensors like this to track total time on during each day:

- platform: history_stats
  name: History Sprinkler 26
  entity_id: switch.sprinkler_controller_3_2
  unique_id: sprinkler_26
  state: "on"
  type: time
  start: "{{ now().replace(hour=0).replace(minute=0).replace(second=0) }}"
  end: "{{ now() }}"

As it turned out, that sprinkler valve turned off at midnight, but the history stats sensor kept on adding up the time, even though the entity had turned off. (Sounds like a bug in the HA history_stats code?)

Below, you can see the valve (switch.sprinkler_controller_3_2) turned on at 23:45:05 and off at 2024-06-13 00:00:00.

Immediately after that you can see that the sensor.history_sprinkler_26 was reset to zero because of the time span on the sensor’s configuration (above).

But, the history stats sensor (sensor.history_sprinkler_26) just kept on adding on time as if the valve was still on.

sqlite> select state_id,m.entity_id, state, DATETIME(last_updated_ts, 'unixepoch', 'localtime') as last_updated, DATETIME(last_reported_ts, 'unixepoch', 'localtime') as last_reported from states s join states_meta m on s.metadata_id = m.metadata_id where (m.entity_id = 'sensor.history_sprinkler_26' or m.entity_id = 'switch.sprinkler_controller_3_2') and state_id >= 19563057 order by last_updated,1 limit 100;
state_id  entity_id                        state                last_updated         last_reported
--------  -------------------------------  -------------------  -------------------  -------------------
19563057  switch.sprinkler_controller_3_2  on                   2024-06-12 23:45:05  2024-06-12 23:45:05
19563112  sensor.history_sprinkler_26      0.00533106499248081  2024-06-12 23:45:24  2024-06-12 23:45:24
19563113  switch.sprinkler_controller_3_2  unavailable          2024-06-12 23:45:24  2024-06-12 23:45:24
19563125  sensor.history_sprinkler_26      0.00516385416189829  2024-06-12 23:45:27  2024-06-12 23:45:27
19563126  switch.sprinkler_controller_3_2  on                   2024-06-12 23:45:27  2024-06-13 00:00:00
19563240  sensor.history_sprinkler_26      0.021830520828565    2024-06-12 23:46:27  2024-06-12 23:46:27
19563350  sensor.history_sprinkler_26      0.0384971874952316   2024-06-12 23:47:27  2024-06-12 23:47:27
19563456  sensor.history_sprinkler_26      0.0554416319396761   2024-06-12 23:48:28  2024-06-12 23:48:28
19563559  sensor.history_sprinkler_26      0.0721082986063427   2024-06-12 23:49:28  2024-06-12 23:49:28
19563655  sensor.history_sprinkler_26      0.0887749652730094   2024-06-12 23:50:28  2024-06-12 23:50:28
19563760  sensor.history_sprinkler_26      0.105441631939676    2024-06-12 23:51:28  2024-06-12 23:51:28
19563859  sensor.history_sprinkler_26      0.122108298606343    2024-06-12 23:52:28  2024-06-12 23:52:28
19563961  sensor.history_sprinkler_26      0.138774965273009    2024-06-12 23:53:28  2024-06-12 23:53:28
19564062  sensor.history_sprinkler_26      0.155441631939676    2024-06-12 23:54:28  2024-06-12 23:54:28
19564153  sensor.history_sprinkler_26      0.172108298606343    2024-06-12 23:55:28  2024-06-12 23:55:28
19564248  sensor.history_sprinkler_26      0.188774965273009    2024-06-12 23:56:28  2024-06-12 23:56:28
19564354  sensor.history_sprinkler_26      0.205441631939676    2024-06-12 23:57:28  2024-06-12 23:57:28
19564458  sensor.history_sprinkler_26      0.222108298606343    2024-06-12 23:58:28  2024-06-12 23:58:28
19564587  sensor.history_sprinkler_26      0.238774965273009    2024-06-12 23:59:28  2024-06-12 23:59:28
19564639  switch.sprinkler_controller_3_2  off                  2024-06-13 00:00:00
19564642  sensor.history_sprinkler_26      0.0                  2024-06-13 00:00:00  2024-06-13 00:00:00
19564754  sensor.history_sprinkler_26      0.0166666666666667   2024-06-13 00:01:00  2024-06-13 00:01:00
19564865  sensor.history_sprinkler_26      0.0333333333333333   2024-06-13 00:02:00  2024-06-13 00:02:00
19564967  sensor.history_sprinkler_26      0.05                 2024-06-13 00:03:00  2024-06-13 00:03:00
19565070  sensor.history_sprinkler_26      0.0666666666666667   2024-06-13 00:04:00  2024-06-13 00:04:00
19565164  sensor.history_sprinkler_26      0.0833333333333333   2024-06-13 00:05:00  2024-06-13 00:05:00
19565253  sensor.history_sprinkler_26      0.1                  2024-06-13 00:06:00  2024-06-13 00:06:00
19565347  sensor.history_sprinkler_26      0.116666666666667    2024-06-13 00:07:00  2024-06-13 00:07:00
19565442  sensor.history_sprinkler_26      0.133333333333333    2024-06-13 00:08:00  2024-06-13 00:08:00
19565521  sensor.history_sprinkler_26      0.15                 2024-06-13 00:09:00  2024-06-13 00:09:00

And still going…

19598492  sensor.history_sprinkler_26      9.90027777777778     2024-06-13 09:54:01  2024-06-13 09:54:01
19598545  sensor.history_sprinkler_26      9.91694444444444     2024-06-13 09:55:01  2024-06-13 09:55:01
19598601  sensor.history_sprinkler_26      9.93361111111111     2024-06-13 09:56:01  2024-06-13 09:56:01
19598664  sensor.history_sprinkler_26      9.95027777777778     2024-06-13 09:57:01  2024-06-13 09:57:01
19598718  sensor.history_sprinkler_26      9.96694444444444     2024-06-13 09:58:01  2024-06-13 09:58:01
19598776  sensor.history_sprinkler_26      9.98361111111111     2024-06-13 09:59:01  2024-06-13 09:59:01
19598832  sensor.history_sprinkler_26      10.0002777777778     2024-06-13 10:00:01

There’s other oddities I’m running into using history stats so I might use an automation and manually track usage that way.

In order to track daily, monthly and yearly water usage for each circuit (16 total) here is what i did.
First of all define a template sensor based on volume attribute of each specific zone:

    - unique_id: irrigation_volume_id2
      name: '{{ "irrigation_volume_id2" if this.state == "unknown" else "Irrigation Consommation Kfé François" }}'
      state: '{{state_attr("binary_sensor.irrigation_unlimited_c1_z2","volume")}}'
      state_class: measurement
      unit_of_measurement: "l"

You may have noticed that volume attribute value is for one watering cycle, in other words it crosses day boundary.

Then define water meters accordingly to get daily, monthly and yearly consumptions:

  water_meter_id2_day:
    name: Consommation eau Kfé francois
    source: sensor.irrigation_volume_id2
    unique_id: "water_meter_id2_day"
    cycle: daily
  water_meter_id2_month:
    source: sensor.irrigation_volume_id2
    unique_id: "water_meter_id2_month"
    cycle: monthly
  water_meter_id2_year:
    source: sensor.irrigation_volume_id2
    unique_id: "water_meter_id2_year"
    cycle: yearly

I hope it helps, let us know

hi sorry I’ve tried to copy the code for this graphs but I see a blank graph.


my code is

type: custom:apexcharts-card
header:
  show: true
  title: Watering timeline
  show_states: false
graph_span: 10d
span:
  start: day
  offset: '-7day'
all_series_config:
  type: column
  group_by:
    duration: 1d
    func: sum
    fill: 'null'
  show:
    as_duration: minute
now:
  show: true
  label: Today
series:
  - entity: binary_sensor.irrigation_unlimited_c1_z1
    data_generator: |
      return entity.attributes.timeline.map((item) => {
        const sd = new Date(item.start);
        const ed = new Date(item.end);
        return [sd, (ed - sd) / 60000];
      });
  - entity: binary_sensor.irrigation_unlimited_c1_z3
    data_generator: |
      return entity.attributes.timeline.map((item) => {
        const sd = new Date(item.start);
        const ed = new Date(item.end);
        return [sd, (ed - sd) / 60000];
      });
  - entity: binary_sensor.irrigation_unlimited_c1_z2
    data_generator: |
      return entity.attributes.timeline.map((item) => {
        const sd = new Date(item.start);
        const ed = new Date(item.end);
        return [sd, (ed - sd) / 60000];
      });
yaxis:
  - decimals: 0
    apex_config:
      title:
        text: minutes
apex_config:
  tooltip:
    enabled: true
    x:
      format: dd MMM

Hi,
Using your add on for 2 years now. Great piece of software!
Another add on for home assistant is EMHASS, an energy management system. It would be a nice feature to be able to use EMHASS output to set the time for an irrigation sequence.
An idea?

This appears to be an awesome tool! Great work @rgc99!

I have a basic setup working -

  1. One controller
  2. 8 zones with min and max durations specified
  3. 1 sequence which I am thinking is the definition of a playlist for watering my 8 zones one by one. Currently my irrigation system controller will only allow one zone to be ON at one time.

This workes great. However, I am now trying to integrate this with my existing HASmartIrrigation (version 2) setup which provides me with an updated duration for each zone based on weather. And so far, I am stuck here.

I did come across this repo that @kolia created - GitHub - Kolia56/irrigation: Home assistant: Irrigation unlimited and Smart irrigation integration. However, I am still not understanding the logic behind how to best achieve the workflow.

Ideally, one of the schedules should be all zones getting watered based on duration specified by HASmartIrrigation sensors everyday at 3AM. The strength of irrigation_unlimited to me is going to come from the ability to create sequences/schedules on the fly!

I also see that the author of HASmartIrrigation posted some blueprints - HAsmartirrigation/blueprints at master · jeroenterheerdt/HAsmartirrigation · GitHub that can maybe help with what I want to achieve. But I really first want to understand how the logic should work for my case. Can someone please comment to explain how these two can work together?

I will not upgrade to Smart irrigation v2, since I get ET from my Davis VP2 and new version does not add anything usefull in my specific case. So I’m currently running 0.8. If you wish to better understand what I did, you’d better select 0.8 tag on HA Smart Irrigation (HASI) github to access the related readme.
I defined how much watering I need for the lawn based on this article.
I empirically defined a nominal budget watering time for all other zones that are drip lines that turns to be correct based on experience.
2’ before watering sequence starts an automation is fired asking HASI to compute watering time for the lawn. In other words I do not let HASI decide when it computes this value.
1’ before watering sequence starts, controller is adjusted accordingly with the value returned above to nominal watering time (2600 secondes or 40 minutes). It is caped to 150% and if less that 5% it is set to 0, hence there won’t be no watering.
At the end of the sequence, it watering occurred, bucket is reset, ie set to 0.

  - id: c6b40384-a7bd-4cf9-82f8-fc07f15905e5
    alias: Smart Irrigation adjustment
    description: Adjust watering times based on ET - Bucket reset
    trigger:
      - platform: template
        value_template: >
          {{ now().timestamp() | timestamp_custom('%H:%M') 
            == (state_attr('input_datetime.watering_s1_start', 'timestamp') - 120) | timestamp_custom('%H:%M', false) }}
        id: watering_duration_compute
      - platform: template
        value_template: >
          {{ now().timestamp() | timestamp_custom('%H:%M') 
            == (state_attr('input_datetime.watering_s1_start', 'timestamp') - 60) | timestamp_custom('%H:%M', false) }}
        id: watering_duration_set
      - platform: event
        event_type: irrigation_unlimited_finish
        id: "Finished"        
    # condition:
    #   condition: and
    #   conditions:
    #     - "{{ states('sensor.smart_irrigation_id7_daily_adjusted_run_time') | float(-1) >= 0 }}"
    condition: >
      {{has_value("sensor.smart_irrigation_id7_daily_adjusted_run_time")}}
    action:
      - choose:
        - conditions:
          - condition: trigger
            id: watering_duration_compute
          sequence:
          - service: smart_irrigation.smart_irrigation_id7_calculate_daily_adjusted_run_time
            data: {}
          # - service: notify.persistent_notification
          #   data:
          #     title: "Irrigation - calcul du temps d'arrosage"
          #     message: |
          #       Time: {{ as_local(now()).strftime('%c') }}            
        - conditions:
          - condition: trigger
            id: watering_duration_set
          sequence:
          - service: input_text.set_value
            target: 
              entity_id: input_text.smart_irrigation_id7_adjust_time
            data: # 2600 secondes = 00:40:00 nominal duration for lawn watering
            # all other circuits (drip line) are proportional to lawn watering
              value: >
                {{ timedelta(seconds=states('sensor.smart_irrigation_id7_daily_adjusted_run_time') | int(0)) }} - 
                {{(states('sensor.smart_irrigation_id7_daily_adjusted_run_time')| int(0) / 2600) | multiply (100) | round (0) }}%
          # - service: notify.persistent_notification
          #   data:
          #     title: "Irrigation - application du nouveau temps d'arrosage"
          #     message: |
          #       Time: {{ as_local(now()).strftime('%c') }}            
          - condition: state
            entity_id: input_boolean.irrigation_duration_smart
            state: "on"
          - service: input_number.set_value
            target:
              entity_id: input_number.arrosage_variation
            data:
              value: >
                {% set pct = (states('sensor.smart_irrigation_id7_daily_adjusted_run_time')| int(0) / 2600) | multiply (100) | round (0) %}
                {% if pct >= 150 %}
                  150
                {% elif pct <= 5 %}
                  0
                {% else %}
                  {{pct}}
                {% endif %}
        - conditions:
          - condition: and
            conditions:
              - condition: trigger
                id: Finished
              - condition: template
                value_template: >
                  {{trigger.event.data.schedule.index is integer and trigger.event.data.schedule.index + 1 == 1 }}
              - condition: numeric_state
                above: '0'
                entity_id: sensor.smart_irrigation_id7_daily_adjusted_run_time
          sequence:
          - service: smart_irrigation.smart_irrigation_id7_reset_bucket
          - service: notify.persistent_notification
            data:
              title: "Irrigation - Bucket reset"
              message: |
                Time: {{ as_local(now()).strftime('%c') }}             

    mode: single

EDIT: for non US users, the link “article” will redirect to the local Rainbird web site, making the article non reachable. In order to ease access to this very interesting document, it is available here below

**Irrigation Scheduling - Use "ET" to Save Water** How long or how often should I water? Who, or what, is **ET**? Anyone responsible for keeping landscape healthy and green may want answers to these questions.

Today’s irrigation systems use a controller, which is an automatic timer that regulates when and for how long your sprinklers run, depending on the watering schedule you enter. An automatic controller, set properly, is much more efficient than operating sprinklers manually.

A program is a set of instructions that tells the controller exactly when to run the sprinklers. It consists of Watering Days, Start Times, and Run Times. If your lawn needs one inch of water per week to stay healthy, how do you set the program? What do I base my Run Time on? Yes, irrigation scheduling can be quite a challenge.

High-tech, computerized Central Control systems provide updated and adjusted schedules on a daily basis to the field. But this level of scheduling precision demands software, special equipment, and expert dedication to design and maintenance. How then, can the average end-user achieve this degree of sophistication?

Irrigation professionals, landscape architects and homeowners alike, want a quick and easy solution to scheduling, good enough to get in the “ballpark”. True, the method described in this article may not reflect the accuracy necessary for sports turf management, but it can save water. It is derived from proven turf science, it beats guessing, and it helps establish a usable benchmark schedule for most residential and light commercial applications.

This benchmark is the key to what is known as ET Scheduling. “ET” stands for evapotranspiration. Water in the soil evaporates and plants transpire, or use water, daily. Hence the term, “ET”. Let’s say that you live in a hot, dry climate, and it is now the middle of July. Your turfgrass needs ¼ inch of water per day to stay green. Therefore, your evapotranspiration rate is 0.25 inches per day. This is the amount or depth of water that needs to be replaced by the irrigation system.

ET-based scheduling works well with solid-state controllers that have a feature called water budget. This lets you change you usual station run times without resetting each station. One hundred percent is your peak programmed run time. You can adjust this percentage up or down when you want more or less run time, according to the season and weather.

Once calculated, the end user can reprogram an entire system in less than one minute! There is no need to change each individual station run time, start time, or day schedule during spring or summer. That’s because water budget adjusts all run times, for every station.

The idea is to establish a Base Schedule Index (BSI) for each zone. This is the maximum amount of run time per station necessary to achieve proper watering during the hottest month in Summer. Next, apply a monthly water budget for off-peak scheduling, and you’re finished.

We will use factors such as Evapotranspiration (ET), Precipitation Rate (PR), Water Budget (WB), and Adjusted Run Time (ART) to calculate our schedules. Together, they reveal the amount of water to be replenished each irrigation cycle, adjusted for seasonal differences.

The Evapotranspiration (ET) rate equals the total loss of water by evaporation from the soil surface, plus the transpiration from turfgrass or ornamental plants, over a given area, in 24 hours. ET = inches/day

The Precipitation Rate (PR) of the sprinklers is similar to rainfall. It expresses the rate of applying water over a given area in one hour. Measured in inches per hour (in/hr), the PR tells us how fast we are filling the soil back up within the sprinkler zone.

PR = inches/hour

How to find the Precipitation Rate (PR) for each zone in your landscape:

  1. Find the approximate area covered by each zone in square feet.
  2. Calculate the gallons per minute (gpm) used by each zone. To accomplish this, add up the gpm output of each sprinkler head. The data for each sprinkler nozzle can be obtained from the manufacturer or supplier, or from the irrigation plan. Many nozzles have the gpm figure stamped or molded right on them. Generally, spray heads use about 0.75 gpm for ¼-circle, 1.5 gpm for ½ circle, and 3.0 gpm for full-circle heads. “Rotor” style heads use 2 to 5 gpm each, for most residential applications.

PR (in/hr) = 96.3 x gpm
Area (ft2)

Example:

There are 4 sprinklers on this zone. Each uses 3 gpm for a total of 12 gpm. They irrigate an area that measures 30’ x 30’, or 900 ft2.

PR = 96.3 x 12 gpm = 1.28 inches per hour

900 ft2

The Water Budget (WB) factor, is a coefficient that factors periodical changes in ET. Represented as a percentage, WB fine-tunes the scheduled run times to help reflect current weather conditions. WB need only be calculated once per given geographical area.

Water managers may correctly argue that this equation ignores soil infiltration rates, field capacity, crop coefficients, rooting depths, distribution uniformity, microclimates, and wilting coefficients. The criteria for BSI are simplicity and ballpark run times, calculated on the fly. Oversimplified? Yes, but it is based on a twist of established principles and data.

Current turfgrass studies indicate over-watering is a problem. The BSI equation assumes 100% watering efficiency, with no losses due to runoff or lack of distribution uniformity. In fact, this is not entirely true. Normal watering run times set only to the current ET and discounting all other factors would result in over-watering. The BSI equation, however, uses irrigation inefficiencies to its advantage. The actual water applied to the soil using the BSI equation will be 20% to 30% of adjusted ET by the mere fact that it never accounted for inefficiencies to begin with. This winds up being very close to optimum settings, without the hassle.

Okay, so how do we find ET? Historical ET data exists for every part of the country, every month of the year. Contact Rain Bird Corporation at 1-800-RAIN-BIRD or www.rainbird.com if you need help. You may also check with your County Agricultural Extension or local water authority.

Here is the Base Schedule Index (BSI) equation to satisfy the maximum daily water requirements for turfgrass:

BSI = Peak ET/PR x 60

Where: BSI = maximum summer run time in minutes

Peak ET = peak summer evapotranspiration rate in inches/day

PR = GPM x 96.3 / sprinkler zone area in square feet

Calculate and enter the Base Schedule Index run time per station into the controller.

Next, use the water budget (WB) equation to calculate the percentage to enter into the water budget feature of your program. You only need to do this once for any given geographical area, based on your historical ET data. BSI requires peak ET and assumes 100% water budget.

WB = Non-peak ET/ Peak ET

Where: WB = Water budget percentage to be entered seasonally

Non-peak ET = Historical ET data for remaining 11 non-peak months

Peak ET= Historical ET data for peak month

Calculate, document, and enter the water budget for the appropriate month into the controller.

Use the Adjusted Run Time equation if your controller does not have a water budget feature, or if the site has certain water restrictions, such as odd or even days only. In this case, find the cumulative run time necessary for a 2, 3, or 5-day schedule and program the run times accordingly. Be aware of long run times exceeding soil infiltration rates. Split the run times into several starts over the course of the day.

ART = BSI x WB

Where: ART = Adjusted Run Time in minutes, monthly or quarterly

BSI = Base Schedule Index in minutes

WB = Seasonal Adjustment percentage

Example: Calculate BSI, WB, and ART for Palm Springs, California:

Given: Max ET = July @ 0.29 in/day historical ET data

Rain Bird 5000 series rotor zone @ 0.75 in/hr (Precipitation Rate)

BSI = 0.29 in/day = 0.39 hours x 60 minutes/hour = 23.2 minutes

0.75 in/hr

Next, calculate a yearly schedule adjusting run times using Water Budget (WB).

WB = Non peak ET / Peak ET

If your controller does not have Water Budget by program, or you cannot water daily, use the ART equation.

Remember that the Water Budget calculations only need to be performed once for your area. You may apply them to all future projects. BSI however, must be calculated for each station or zone with similar precipitation rate characteristics.

ET Values correspond to Palm Springs, California - A hot, dry climate

Month Non peak ET Peak ET July Water Budget %
WB= Non peak ET/ Peak ET
BSI Daily Run Time
ART = BSI x WB

January 0.02 0.29 7% 23 2
February 0.04 0.29 14% 23 3
March 0.07 0.29 24% 23 5
April 0.12 0.29 41% 23 9
May 0.17 0.29 58% 23 13
June 0.23 0.29 79% 23 18
July 0.29 0.29 100% 23 23
August 0.25 0.29 86% 23 20
September 0.19 0.29 66% 23 15
October 0.11 0.29 39% 23 9
November 0.05 0.29 17% 23 4
December 0.03 0.29 10% 23 2
In/day In/day Water Budget Percentage
(BSI multiplier)
Min Minutes by month

Admittedly, this process requires some effort. However, the payback in water savings is significant. Give ET Scheduling a try. Your landscape will thank you!

My wife asked if there was a way to see a full schedule for the upcoming week for all the sequences. Some sequences run multiple times in a week. I do have future_span: 7.

I only see next_* in the entity attributes, so I’m guessing it’s not possible to do it that way, right? Not a big deal for me to look at the YAML, but just curious if anyone else has dome this in a dashboard card.

To clarify, looking for a way to see in the UI not just the next run for a sequence, but all the schedules that are active. I can imagine it’s not easy due to all the ways a schedule can be defined.

Thanks,

Thanks @kolia. Are those utility_meter sensors? I should try those.

Because of the apparent run-on problems I had with history_stats (and the frequent states writes) I’m trying a different approach now. I also decided to track the underlying entity that controls the switch as we still use those when working in the yard.

It’s probably not the best solution…

I use customize.yaml to add the (in my USA case) gallons per minute:

switch.sprinkler_valve_07:
  gallons_per_minute: 0.84

switch.sprinkler_valve_08:
  gallons_per_minute: 3.06

switch.sprinkler_valve_09:
  gallons_per_minute: 4.41

And then created a bunch of input_number sensors to store the total usage:

sprinkler_gallons_08:
  name: 'Total Gallons station 08'
  mode: box
  unit_of_measurement: gal
  step: 10000
  min: 0
  max: 1000000

Then use an automation to total the usage when any valve turns off (i.e. I trigger on any of my 27 valves). For better or worse, I only get one row added to the states table when the valve/switch turns off.

trigger:
  - platform: state
    entity_id:
      - switch.sprinkler_valve_01
      - switch.sprinkler_valve_02
      ...
      ...
      - switch.sprinkler_valve_26
      - switch.sprinkler_valve_27
    from: "on"action:
  - variables:
      seconds_on: "{{ (now() - trigger.from_state.last_changed).total_seconds() }}"
      gallons_per_sec: "{{ state_attr(trigger.entity_id , 'gallons_per_minute')|float / 60 }}"
      gallons_entity: >-
        {{ trigger.entity_id.replace( 'switch.sprinkler_valve_',
        'input_number.sprinkler_gallons_' ) }}
      cur_gallons: "{{ states(gallons_entity)|float }}"
      new_total: "{{ ((gallons_per_sec * seconds_on) + cur_gallons)|round(1) }}"
  - service: input_number.set_value
    target:
      entity_id: "{{ gallons_entity }}"
    data:
      value: "{{ new_total }}"
mode: parallel

Then I have a total usage, which somewhat surpizingly, has been pretty close to what the physical water meter is showing for usage. This ends up in the long-term statistics database table.

- platform: group
  name: "Gallons all Sprinklers"
  unique_id: gallons_all_sprinklers
  type: sum
  device_class: water
  state_class: total_increasing
  entities:
    - input_number.sprinkler_gallons_01
    - input_number.sprinkler_gallons_02
      ...
    - input_number.sprinkler_gallons_27

Finally, I can do a statistics-graph for the daily change:

Some day I’d like to figure out how to programmatically add sensors so I’m not repeating so much YAML config…

By the way, how are you getting the volume attribute to populate (below)?

I see there’s a test that includes volume/flow settings in test_volume_extensive.yaml but don’t see where it’s documented.

I tried adding the config, but unclear what the required entity_id was for.

Hi,
I’m using Irrigation Unlimited with Smart Integration v2. Still testing. I have 8 zones, 4 of them are lawn zones. At the beginning I have configured only lawn zones with Smart Irrigation. In Smart Irrigation I have configured 4 zones to calculate time for each valve. With the @rgc99 example I have made the automation to update each zone’s irrigation time and reset each zone’s bucket in Smart Irrigation after irrigating the zone.

yes they are utility meters.

This is a template sensor. So full code is

template: 
  - sensor:
    - unique_id: irrigation_volume_id2
      name: '{{ "irrigation_volume_id2" if this.state == "unknown" else "Irrigation Consommation Kfé François" }}'
      state: '{{state_attr("binary_sensor.irrigation_unlimited_c1_z2","volume")}}'
      state_class: measurement
      unit_of_measurement: "l"

Thank you! I understand that you don’t want to upgrade to v2. However, I think the logic you have explained should work the same as it doesn’t necessarily relate to how Smart Irrigation is doing the calculations in the backend. I will take some time this weekend to understand this code.

Take a look at the timeline. It may be what you are looking for. In the latest card development the future schedules can be shown along with the history under each zone.

The entity_id under the volume section is a HA sensor that monitors water usage. You can follow the development thread here.