This is a pre-release. It carries a large batch of work on the calculation core, and the point of shipping it this way is to have it run somewhere real before it reaches everyone. If you would rather wait, do nothing: HACS will not offer it unless you have enabled beta versions.
Read this first: your zones may receive more rain than before
If your weather service is Open-Meteo, this release credits you roughly four times more rain than v2026.9.0 did, and that is the correction, not the bug.
Open-Meteo's current.precipitation is the rain of the last 15 minutes, not the last hour. It was being integrated as if it were an hourly rate, so about a quarter of the rain that fell reached the water balance. Zones watered after rain that had already been counted for them.
Rain now comes from Open-Meteo's hourly history over the calculation's own interval, which covers every hour whatever your update schedule. Found, measured and fixed by @frankyhun (#835, #836), with the evidence on the issue. The timestamp convention it rests on was checked against the live API over 96 hours before merging.
OpenWeatherMap and Pirate Weather are unaffected.
Rain that was being discarded
A sensor group with no Precipitation source lost all its rain. Every calculation fills the fields with no reading from the group's last known values, and nothing checked whether the group still had a source for what it was carrying over. Since v2026.8.2 a weather service feeds rain through Current Precipitation and the migration leaves Precipitation with no source, so the 0.0 it last held was carried into every calculation and won, because a depth takes precedence over a rate. The rain was collected, converted, displayed, then thrown away. Reported by @cracyfloyd (#834), and it affected every weather service.
A cumulative rain gauge read the wrong starting total. A gauge that counts up reports a total, so a window's rain is the last total minus the total it started from. That starting total came from the sensor group's last calculation, which is one value for the whole group: on a group read by two zones on different schedules, the second measured its window against the first zone's total and silently lost the rain in between.
The scheduled clearing of weather data is retired. It ran at a fixed time while the calculation time is yours to choose, so moving your calculation earlier discarded everything collected between the two, every night. A user calculating at 18:55 against the default 23:59 clear was losing five hours of readings a day. Pruning after each calculation and a seven-day cap already bound the stored data, so the timer could only destroy readings nobody had read. The setting no longer does anything and has gone from the panel; the manual "clear all weather data" action is untouched.
Settings that did not survive a restart
Three things were rebuilt from the stored file field by field at startup, and were left out of that list. Each restart replaced them with defaults and the next save made it permanent.
- Seasonal adjustments and recurring schedules. Configuration you entered, silently emptied by the first restart after you set it.
- The calculation explanation. The only place the water balance shows its work, gone on every restart until the next nightly calculation.
- A zone's last calculation time, which had never been set on any installation.
There is now a test that reads the source and fails naming any field a storage entry declares but does not read back, so this class of bug cannot return quietly.
Each zone reads its own weather data
Calculating one zone used to empty the sensor group's whole buffer. Two zones on the same group raced: whichever calculated first consumed the readings and the other computed from whatever had arrived since, under-watering with nothing in the log.
Each zone now records how far it has read, takes only what arrived after that, and the buffer keeps what the slowest reader still needs, capped at a week. The interval that scales evapotranspiration and the rain window follow the same mark.
New in the panel
- A Setup tab, first in the list: a guided way to create your first zone, one question at a time and only the questions your previous answers leave open. It creates the module, the sensor group and the zone, and locks nothing.
- The Info tab rebuilt around the next start: when it is and why then, whether it would be skipped and on what numbers, and where every zone stands right now. "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. The weather service tab keeps its own retrieval history.
- The calculation modes are named by what they do, Manual, Standard and Advanced, rather than by the algorithm behind them, and a sensor group now offers only the sources the mode it feeds actually reads.
- A skipped start fires an event.
smart_irrigation_irrigation_skippedcarries the trigger and the reason, so a day held back is something an automation can hear instead of an event that never arrives (#841). - An opt-in calculation log records the whole chain behind a duration, from each raw reading to the result.
- A dry run on the calculate services: compute without committing anything.
- Durations read as hh:mm:ss with the water volume beside them, dates are written in the language the panel is running in, and the panel picks up a new version without a hard refresh.
Also fixed
- A fixed-time start trigger silently reverted to 06:00 when reopened, so it fired at an hour you had not chosen. Reported by @maisun (#816).
- The calculation explanation stated the crop factor among the duration steps, where it is not applied, said its closing sentence twice, and told a deficit below the irrigation threshold that the bucket was at or above zero. Reported in full by @Megalos (#817, #832).
- A rain forecast paused greenhouse zones, which rain cannot reach.
- A stale zone save from a settings page left open reverted what a run had recorded.
- The weather service API key and the configuration backup are admin-only.
- The shipped blueprints work, and are installed for you on setup.
- A sensor group drops its readings when a source changes, rather than mixing two meanings of the same field.
Thanks
@frankyhun for #835 and #836, the second real calculation bug found in our core in three weeks, and for the history tab and the calculation log. @Megalos for #817 and #832 and for years of patient reports on the water balance. @cracyfloyd for #834, @maisun for #816, @msconfig87 and @etofi for #841, and @JustChr, whose comparison of his fork's weather buffer against ours pointed at the cumulative-gauge bug above.
Trying it
Enable beta versions for Smart Irrigation in HACS, update, and restart. If something is wrong, the Info tab is the fastest way to see what the integration thinks it is about to do, and #841 aside, an issue with a diagnostics file is the surest way to get it fixed.