This is a pre-release, and it fixes three faults found in beta 3 within hours of it going out. If you are on beta 3, update. One of the three means a bucket could gain water on a dry night, and it is the second time this release cycle that a change of ours made a real figure move in the wrong direction, so it is worth being plain about what happened.
All three were reported by @Megalos, from diagnostics files.
A dry night was adding water to the bucket
On a calm humid night the hourly equation returns a small negative value: the surface loses more heat than it receives, and there is not enough wind or dryness to offset it. That is condensation, and it is real — but it is dew on the leaves, not water in the root zone, and it evaporates in the morning. Summed over one night it credited 0.05 mm that never fell, so a zone at -1.57 mm read -1.53 mm by dawn (#866).
The hourly value is now never negative, which is what FAO-56's own worked example prints for exactly such an hour.
Where this came from. The flaw was there before, an order of magnitude smaller. The night-cloudiness fix in beta 3 deepened the long-wave loss of a night hour, which is correct and was the point, and it deepened this negative with it. We had a test on that worked example and it passed: it asserted the night hour came out at 0.00 within five thousandths, which a value of -0.003 satisfies. It checked a magnitude where the thing that mattered was a sign. The tests added here assert the invariant instead: without rain, a bucket never rises.
Only installations on the hourly calculation were affected.
One zone that could not be calculated took the whole night with it
A zone whose evapotranspiration is provided — by a sensor or a service — needs that value in its sensor group. Without it the engine returns nothing, and the zone calculation then assigned into that nothing and raised. The exception escaped the whole nightly run, so:
- every zone after it in the loop went uncalculated;
- the readings nobody needs any more were never pruned, which is why 32 of them were still there eleven minutes after the calculation (#867);
- the start trigger was never re-armed, which is a run that does not happen.
One zone that cannot be calculated now costs that zone, and says so in the log.
And it could not be calculated because of us
Open-Meteo publishes a reference evapotranspiration. The sensor group offers the field as coming from the weather service. The path that fills the readings buffer never recorded it — only the forecast path parsed it. So "provided by a sensor or a service" could not work at all with the service we recommend, and such a zone was simply never calculated (#847).
Today's reference evapotranspiration is now part of every reading, so that method works with Open-Meteo.
The setup assistant is no longer a tab
It invited an installation that was already set up to set itself up, which somebody with two zones asked about, fairly. It is one click away under Settings, for a first zone, another one, or a fresh start. Its address still works.
Trying it
Enable beta versions for Smart Irrigation in HACS, update, restart. 1533 tests.
If you are on the hourly calculation and your buckets have been drifting upward overnight, this is the release that stops it. As always, an issue with a diagnostics file is what makes a figure like that findable — the last three releases were all corrected from them.