This is a release candidate, and the last feature release before the stable v2026.10.1, planned in a few days. From now on only bugs are fixed: anything reported before the stable ships will be looked at for it, and new features wait for the next cycle.
It changes how much water some zones get, so please read the first section.
What changes in the amounts
These came from a review of the whole calculation. Each fixes a case where the number was wrong, and each has a test that fails without it.
- Short calculation windows now read a whole day of weather. The daily equation prices a day, and it was handed the minimum, maximum and sun of the calculation's window, whatever its length. Two calculations a day, a manual calculation, the live estimate and above all continuous updates priced a "day" that was not one. Continuous updates came out about 60% low, two calculations a day 6 to 19% low. A window shorter than 20 hours now takes those values from the last 24 hours, and the rate is scaled to the window as before. To allow this, the readings of the last day are kept after a calculation, and the data points a zone shows count only the readings it has not read yet.
- Long windows are priced one day at a time. A calculation after a few days down used to treat all of them as one day, about 13% high over three days.
- The hourly calculation counts the night's dew. A calm humid night has slightly negative hours. They were set to zero one by one, which put a whole day about 4% high; a window is now summed with its sign and bounded at zero as a whole, so a night alone still never adds water (#866).
- Missing dew point or pressure no longer means zero evapotranspiration. The daily equation required both. It now takes the vapour pressure from the dew point, else the humidity, else the minimum temperature, and the pressure from the elevation, as FAO-56 describes. The hourly equation also works the humidity out from the dew point when there is no humidity sensor.
- Averages are weighted by time. A sensor reporting on change bunches its readings while the value moves; a plain average gave that part too much weight.
- Glitches and dead sensors are left out. A reading outside what a sensor can report (an 85 C spike, a negative rain total) is dropped with a warning. A temperature, humidity or dew point sensor that has not reported for 6 hours is left out of the hourly reading.
- Rain counters. A small drop just after midnight is a correction of a yearly or lifetime total, not a reset worth hundreds of millimetres; a drop by more than half during the day is a reset. The autumn clock change no longer subtracts rain.
- Greenhouse without a light sensor. Its estimated sun is dimmed by the glass (transmission 0.65) instead of taking the sky's.
- Wind sensor height. A sensor group's wind sensor has a new, optional "Anemometer height" setting. A weather station at 10 m reads about a third more wind than at 2 m, where the equations want it. Left empty, which is what every existing group has, nothing changes.
What changes in the decisions
- The rain forecast holds a run back only when it is worth it. The forecast is weighted by its probability when the service gives one (Open-Meteo), it no longer holds back a zone that is short by more than twice the rain expected, and never more than two days in a row: showers forecast day after day that keep missing no longer dry a zone out.
- A moist soil sensor now resets the bucket, instead of only skipping the run and watering the whole deficit the first dry morning. A binary rain sensor's history now credits the bucket with the share of the run it removed.
- A start that has already gone by starts now. When a run that should finish by sunrise, sunset or a clock time could not start in time (a run longer than the night, a calculation set inside the watering window, a restart at the start time), it used to wait until the next day. If the moment is still ahead, it starts at once. A restart after the morning's run does not run it again.
- The live estimate of a zone that looks ahead uses the forecast Open-Meteo sent with its last reading, with no new request. It used to ignore it, so Info and Zones could disagree. The same idea was seen in JustChr's fork; none of its code is used here.
New: credit_watering
If your own automation or a blueprint runs the zones, smart_irrigation.credit_watering credits the bucket with the water a run delivered: the zone's rate times the seconds it ran, less its lead time. reset_bucket sets the bucket to 0 whatever the run did, so a run cut short by the zone's maximum duration lost the deficit it had not watered.
The controller blueprints (Rain Bird, Hydrawise, Rachio, B-hyve, OpenSprinkler) and the standard one now use it. Automations made from them keep working; re-import the blueprint to get the new version. reset_bucket still works. Do not use either with observed watering or direct valve control, which credit the bucket themselves.
Storage
The store is written ten seconds after a change instead of at once, so a burst of continuous updates is one write. The valves that are open and the buckets are still written at once, so a power cut cannot leave a valve open after a restart or lose a watering credit.
Trying it
Enable beta versions for Smart Irrigation in HACS, update, restart, and reload the browser (or reset the companion app's frontend cache) so the panel and the card are the new ones. 1816 backend tests and 84 frontend tests.