altmenorg/HAsmartirrigation v2026.9.1 on GitHub

This is the stable release of the five betas published since v2026.9.0. It is a large batch on the water balance, with a rebuilt panel, and it changes the numbers a number of installations get. The changes that do are listed first.

Read this first: what may change for you

Open-Meteo credits roughly four times more rain. Its current.precipitation is the rain of the last 15 minutes, not of the last hour, and it was integrated as an hourly rate, so about a quarter of the rain that fell reached the water balance. Rain now comes from Open-Meteo's hourly history over the calculation's own interval. Found, measured and fixed by @frankyhun (#835, #836). OpenWeatherMap and Pirate Weather are unaffected.
A sensor group with no Precipitation source no longer loses its rain. Since v2026.8.2 a weather service feeds rain through Current Precipitation, which left Precipitation with no source, and the 0.0 it last held was carried into every calculation and won. The rain was collected, converted, displayed, then thrown away. Reported by @cracyfloyd (#834), and it affected every weather service.
A sensor group field with no unit set is read in the unit the sensor itself reports. Groups created by the setup wizard have no unit on their fields, and a wind sensor in km/h was read as m/s, a thermometer in °F as °C. A unit you did set still wins.
Seasonal adjustments do what the documentation says. The threshold adjustment was added to the stored bucket at every calculation, so -5 mm became -10 mm the next day and the zone was watered more and more all season, while the multiplier adjustment never applied at all.
Solar azimuth start triggers fire at a different time, which is the correction. The longitude was applied the wrong way round, the equation of time was missing, local time was handed in where UTC was expected, and manual coordinates gave the latitude but not the longitude. The azimuth is now astral's, the one Home Assistant's own sun uses. Sunrise, sunset and clock-time triggers are unaffected.
Solar radiation aggregated by Riemann sum is the day's mean rate again. The integral was handed to PyETO as the day's value: over half an hour of constant sun it produced 40% less evaporation than the Average aggregate.
Drainage above field capacity follows the law it claims. It was computed as one 24-hour step at the starting rate, which emptied an 8 mm surplus the law itself drains to 4.3 mm. Reported with the arithmetic by @Megalos (#783).

Rain and weather

A cumulative rain gauge reads its own starting total, per zone, instead of the group's last calculation, and a total revised downward by a web service is no longer counted twice on the way back up. Reported by @Megalos.
The scheduled clearing of weather data is retired. It ran at a fixed time while the calculation time is yours, so a calculation at 18:55 against the default 23:59 clear lost five hours of readings a day. Pruning after each calculation and the seven-day cap already bound the stored data.
Each zone reads its own weather data. Calculating one zone emptied the group's whole buffer, so two zones on one group raced and the loser computed from whatever had arrived since. Continuous updates follow the same per-zone mark, and a group shared with a manual or disabled zone is pruned as promised.
MJ/day/sq ft solar radiation reached the calculation 116 times too small.
The pressure from OpenWeatherMap, Pirate Weather or a sensor marked relative is brought down to the site's height (FAO-56), and PyETO prices each day under the sun of that day rather than the sun of the day the clock shows.
Open-Meteo forecast days use the day's mean wind, not its windiest hour.

New

Evapotranspiration hour by hour, off by default: Settings > General > Automatic duration calculation (#818). PyETO sums the FAO-56 hourly equation over each hour since the zone's last calculation instead of running the daily equation on the averages of the window. An average day hides whether the sun and the heat came together: against a reference implementation over a year of hourly data, the daily form read 1.14x on overcast days and 0.93x on clear ones, the hourly sum stayed within 1.02 to 1.04 in every sky. It needs temperature, humidity, wind and solar radiation, and falls back to the daily equation rather than leaving a zone without a calculation.
Four conditions that skip a run, all off by default: a rain sensor, freeze, wind, and soil moisture per zone. A zone held back by its soil keeps its bucket, so the deficit rolls over. A sensor that cannot be read never stops a run.
Blueprints for off-the-shelf controllers: Rain Bird, Hunter Hydrawise, Rachio, OpenSprinkler and Orbit B-hyve. Smart Irrigation decides how long each zone waters and the controller runs the valves. Turn off the controller's own schedule for those zones, or it waters on top. They are written against each integration's documented actions but not yet confirmed on real hardware: if you own one, a word in the discussions is the most useful contribution there is.
A skipped start fires an event. smart_irrigation_irrigation_skipped carries the trigger and the reason, so a day held back is something an automation can hear (#841).
A dry run on the calculate services, and an opt-in calculation log that records the whole chain behind a duration, from each raw reading to the result.

The panel

A Setup tab, first in the list: a guided way to create your first zone, one question at a time, asking only what your previous answers leave open.
The Info tab rebuilt around the next start: when it is and why then, whether it would be skipped and on what numbers (#794), and where every zone stands. "Now" re-runs the calculation over the readings collected since the last one and writes nothing.
A History tab: what actually ran, by day, with durations and volumes, and when each zone last watered (#791).
The calculation modes are named by what they do, Manual, Standard and Advanced, and a sensor group offers only the sources the mode it feeds actually reads.
Editing a zone sends only what you changed. The page posted its whole copy of the zone, so a page left open across the nightly calculation reverted its bucket and its explanation on the next edit. Two settings edited within half a second are both saved, and a sensor can be removed from a zone.
Durations read as hh:mm:ss with the volume beside them, dates follow the panel's language, and the panel picks up a new version without a hard refresh.

Settings that did not survive a restart

Seasonal adjustments, recurring schedules, the calculation explanation and a zone's last calculation time were rebuilt field by field at startup and left out of that list, so each restart replaced them with defaults and the next save made it permanent. A test now reads the source and fails naming any field the storage declares but does not read back.

Watering and the bucket

Direct valve control with no maximum duration (-1) credited every run with -1 second, so the bucket never refilled and the zone was watered again at every start.
Zones entered as a precipitation rate are credited from that rate, not from the size and throughput the panel hides for them.
Setting a bucket by set_bucket, reset_bucket, set_zone or the reset button keeps the evaporation from before it out of the next calculation, as it already did for the rain.
A fixed-time start trigger no longer reverts to 06:00 when reopened, so it fires at the hour you chose. Reported by @maisun (#816).
The watering calendar credits the rain: the month's rain was added to the evaporation and subtracted again, so the need came out equal to the evaporation whatever it rained.
The calculation explanation no longer states the crop factor among the duration steps, repeats its closing sentence, or tells a deficit below the threshold that the bucket is at or above zero. Reported in full by @Megalos (#817, #832).
A rain forecast no longer pauses greenhouse zones, which rain cannot reach.

Thanks

@frankyhun for #835 and #836 and for the history tab and the calculation log, @Megalos for #783, #817 and #832 and for years of patient reports on the water balance, @cracyfloyd for #834, @maisun for #816, @gwilbor for #791, @msconfig87 and @etofi for #841, and JustChr, whose fork's hourly equation and row builder are the basis of the hourly calculation here, and whose comparison of his weather buffer against ours pointed at the cumulative-gauge bug.

Upgrading

Update through HACS and restart. Nothing to do by hand: stored data is migrated on load. If your zones water differently from before, the Info tab shows what the integration thinks it is about to do and why, and the calculation explanation on the zone shows the water balance behind it.