This release changes how rain reaches the water balance. If you use a weather service, your zones will calculate differently after updating, and for the better: the rain credited to the bucket is now the rain that actually fell over the interval being calculated, rather than a figure that was partly forecast and, depending on your service, either over- or under-counted.
Set your automatic weather data update interval to 1 hour or shorter. The weather services report the rain of the last hour only, so collecting less often leaves the hours in between unobserved and that rain is never counted. A warning is logged if the interval is longer.
How rain is counted
Two fields carry precipitation and they are different physical quantities, which was never stated and never enforced. Total precipitation is a depth in mm accumulated over the interval. Current precipitation is a rate in mm/h that has to be integrated over the interval to become one. Only one of them feeds the bucket now, or the rain would be counted twice.
- The precipitation rate never reached the calculation at all (#571). It was collected, unit-converted, stored and shown in the panel, and no part of the calculation ever read it. The docs even said "Current precipitation (unused)". A sensor group mapping a rain rate sensor and no accumulating total watered straight through the rain. Thanks to @Chumba for a report whose title was exactly right and which took far too long to be taken literally.
- The weather services now supply the rate rather than a total (#764). All three copied their precipitation figure into the depth field, where the "delta" aggregate treats its input as an accumulating counter and adds only the increases. None of them supplies that. OpenWeatherMap and Pirate Weather report the last hour, so the rain was undercounted; Open-Meteo reports a daily figure that is forecast for the rest of the day, so it kept the highest forecast ever seen. Thanks to @Megalos, who has been arguing this since July and was right about the forecast.
- Rain between the calculation and the start of irrigation now shortens the run (#810). The duration is worked out at 23:00 and irrigation starts hours later; rain in between was ignored, so a 12 mm deficit followed by 8 mm of rain overnight still watered 12 mm on wet ground. The bucket is deliberately not credited there, since it is a running balance and the next calculation adds the same rain. The run still starts when it was scheduled to, so a shortened run finishes early rather than starting late. Thanks to @Megalos.
- If you have a rain gauge of your own that accumulates, keep mapping total precipitation to it. It takes precedence over the service rate and the two are never added together.
Fixed
- Solar radiation aggregated by Riemann sum came out about a hundred times too large (#363). A key's samples were paired against the flat list of record timestamps, and a record does not carry every key: continuous updates append one record per sensor change, and a value is missing whenever its sensor was unavailable. The lengths never matched, the guard fell through and the integration used one day per sample. That is the configuration the docs recommend for continuous updates, and it fed straight into PyETO. Each trapezoid is now integrated over the interval between the two samples it joins, so unevenly spaced samples come out right too. Thanks to @jata1 and @wauswaus for two years of patience.
- Irrigation started hours too early when zones run in parallel (#552). A start trigger that finishes at sunrise subtracts the length of the whole run, and that was always the sum of every zone's duration. Zones watered at once are done when the longest one is. The zone sequencing setting already said which it was but only the valve executor read it; the run length now follows it, and the setting is no longer hidden behind direct valve control. Thanks to @iGranDav for the report and @rrozema, whose objection is why nothing changes for a sequential setup.
- A pressure sensor set to millibar was silently dropped from the record, leaving PyETO reporting pressure as missing on a sensor that was working. The panel stores "millibar" and the conversions only knew that unit as "mbar".
- The panel no longer offers the weather service for total precipitation, since it no longer supplies one and picking it did nothing. Sensor groups pointing there are moved on upgrade, and the rate is pointed at the service in the same pass so no group loses its rain.
Added
- Wind speed in knots (#801). METARs quote knots and the closest unit on offer was mile/h, a 15% error straight into the FAO-56 wind term. Thanks to @tb59427.
- An
etoattribute on each zone (#528).et_valueis named as though it were the evapotranspiration but holds the net precipitation, which is why it goes positive on a rainy day. It keeps its name so nothing breaks, the documentation now says what it holds, andetocarries the reference evapotranspiration as the positive number the literature quotes. Thanks to @namorg89.
Build and CI
- Tests now run on Python 3.14, which Home Assistant requires from 2026.3 onwards. The matrix was on 3.13, a combination no user can install.
- The test requirements no longer pin by hand what
pytest-homeassistant-custom-componentalready pins, which is what made two dependency bumps unresolvable. - Frontend toolchain updated.
intl-messageformat11 makes the shipped bundle 7 KB smaller.
Full Changelog: v2026.8.1...v2026.8.2