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
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.
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 -
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
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:
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.