altmenorg/HAsmartirrigation v2026.9.3-beta2

on GitHub

This is a pre-release. HACS only offers it if you have enabled beta versions. It follows beta 1 by a day and is mostly its bug reports, one of which changes what every installation calculates. If you are on beta 1, update; if you are not, read the beta 1 notes first, since everything in them is also in this.

The evapotranspiration was too low, for everybody

Over a day, the saturation vapour pressure is the mean of the two extremes, e°(Tmax) and e°(Tmin). We were computing it from the mean temperature. The curve is convex, so the mean temperature always gives a lower figure, and FAO-56 says in as many words that it understates the vapour pressure deficit and with it the evapotranspiration. It is a documented pitfall and we were in it.

@Megalos measured our daily figure against the hourly reference evapotranspiration Open-Meteo publishes for his own location and found ours 20 to 30% short. On the day he reported, a 16 K spread between night and afternoon, this accounted for 13% of it:

Your zones will evaporate more than they did, and water sooner. The size of the change follows the spread between your night and afternoon temperatures: a clear spring day moves a lot, an overcast one barely at all. Nothing else in the equation moved, and the hourly calculation was never affected, because at hourly resolution the single-temperature form is the correct one.

The rest of that gap, about 10%, is the difference between integrating the equation hour by hour and evaluating the daily form once. That is expected, and it is one of the reasons the hourly calculation exists.

A day the equation cannot price no longer counts as zero

Penman-Monteith needs five inputs: the two temperatures, dew point, wind and pressure. A day missing one of them returns zero, and that zero was averaged in with the days that could be computed. So with three forecast days from a service that does not report dew point or pressure, a real 4 mm day came out as 1 mm, and the zone was watered a quarter of what it needed, with nothing but a warning in the log to say so. Such a day is left out of the average now, and it stays in the calculation log with the list of what it was missing.

A zone was watered twice

Direct valve control had no idea a zone was already being watered. Two presses of "irrigate now" opened the same valve twice and credited the bucket twice for water that flowed once. In sequential mode it was worse: watering a zone that was queued behind others ran it now and again when the queue reached it. A zone is watered once per cycle now, and a sequential cycle re-checks each zone at the moment it dispatches it rather than when it listed it.

Cycle and soak

Clay and compacted soil have an infiltration rate: past it the water runs off the surface or puddles, and the zone is billed for water the roots never see. Two settings under Settings > General, on the advanced panel, both off by default:

• Water in several passes, with a soak between them: the same water in shorter passes, so the soil takes it in. Sand does not need it, loam rarely more than two passes, clay and slopes are what it is for. A run too short to split is left alone.
• Pause between zones, for the line pressure to recover or a slow valve to finish closing.

Both lengthen the run without adding water to it, and a start trigger that has to finish at sunrise works back from the whole thing, soaking and pauses included. Documentation.

The beta 1 reports

All from @Megalos, who took a day-old beta apart with diagnostics files and arithmetic.

• The daily ET deficiency shown next to the bucket was the reference evapotranspiration, with no crop factor: two zones on one sensor group growing different things showed the same need, and it disagreed with the bucket beside it. It is this zone's own need now, ET0 × Kc. The reference figure is kept as its own eto attribute, free of the crop factor, because holding that against a weather service is what found the bug above (#850).
• An engine setting saved on its own was dropped. Setting a zone's look-ahead to 0 days and coming back showed 2 again (#851).
• A soil or a planting chosen in words writes the drainage rate or the crop factor it stands for, and that value now appears immediately instead of after leaving the tab (#852).
• A unit printed as [object Object] in the zone status band (#849).
• The zone's engine list is gone. Every zone has its own engine since beta 1, so it offered two entries with the same name, and the choice is made above it in plain words (#864).
• A valve can be linked without observed watering, so Smart Irrigation can run it without crediting the bucket for every other use of that tap: filling a paddling pool, hosing the terrace (#854).
• The first zone of an installation rendered from a stale card after an edit, because zone id 0 was read as no zone. Same family as #846.
• Zone 0 with sensor group 0 was never calculated at all in beta 5 and earlier; that was #846, fixed in v2026.9.2 and so in both betas (#847).
• The documentation said watering as soon as anything is missing suits a lawn. It suits nothing; it is what installations did before the threshold existed (#865). The modules page still described a choice that has moved to the zone (#864).

Trying it

Enable beta versions for Smart Irrigation in HACS, update, restart. The Home page says what the integration thinks it is about to do. If your zones start watering more than they used to, that is the first section of these notes, and it is the correct amount rather than the previous one; if you think otherwise, an issue with a diagnostics file and the figure you are comparing against is the fastest way to settle it, as this release shows.