This is a pre-release. HACS only offers it if you have enabled beta versions. Two things in it change how much your zones water, both because they were wrong before, and both are the first two sections. If you are on beta 1 or beta 2, update; if you are on the stable release, read the beta 1 notes and the beta 2 notes as well, since everything in them is also in this.
A night was losing fourteen times too little heat
The net long-wave radiation of an hour depends on cloud, through the ratio of measured to clear-sky sunshine. After dark there is no sun to take that ratio of, and the hourly calculation assumed the value that loses the least. FAO-56's own worked example publishes a long-wave loss of 0.100 MJ/m² for a night hour where that gives 0.007.
Too little loss is too much net radiation, which is water evaporated at night that did not evaporate. Measured on a synthetic clear day: 2.5% of the total in June, 14% in December, where the night is fifteen hours long and the day evaporates little. The daylight of the window now says what the sky was like, sum against sum, which is also the ratio the daily equation uses for its own long-wave term, so the two forms cannot disagree about the same sky.
This only affects installations using the hourly calculation. If your zones read a little high before, this is why.
A new installation starts on the hourly calculation
It is the better arithmetic: the daily equation averages a cool humid night with a hot dry afternoon, and evapotranspiration is not linear in its terms. Nothing stops it running anywhere now (see the next section).
An installation that already exists is not switched. The two forms give different numbers, and nobody's watering should change on an update without being asked. The switch is where it was, under Settings > General, and it no longer describes restrictions it does not have.
The hourly calculation no longer needs a measured sun
It needs the radiation of each hour, and there are three ways to have it: a radiation or illuminance sensor, the weather service's own hourly history, or — new — the day's temperature range. FAO-56 Eq. 50 turns that range into the day's radiation, the same equation the daily form falls back on, and the sun's own path over that day says which hours received it. Summed over a day the estimate is exactly what the daily equation would have used, so a zone is credited with no more sun than before; what changes is that it is placed on the hours it belongs to.
A greenhouse with no sensor of its own keeps the daily equation: no reading of the sky describes what reaches a plant under glass. A lux sensor inside answers it properly, and the sensor group takes one.
The calculation log records whether a run's sun was measured or estimated.
The hourly modules are ours now
hourly_et.py and hourly_rows.py came from another fork, with credit, under MIT. They are rewritten: the equations from FAO Irrigation and Drainage Paper 56 itself, every function naming the numbered equation it implements, and the row builder designed from what the calculation actually hands it. FAO-56's Example 19 reproduces every published intermediate — Ra 3.543, Rso 2.658, Rns 1.887, Rnl 0.137, Rn 1.749, G 0.175, ETo 0.63 mm for the daylight hour — and the suite passes under four timezones.
Calculating hour by hour at all is still that fork's idea, and the README says so.
A zone that has stopped being calculated says so
One zone can freeze while everything else works: the panel is fine, the other zones update every night, and the frozen one keeps watering on the weather of days ago. It happened for five days to a beta tester, and the only trace anywhere was a line in the log.
The Home page now names any automatic zone whose last calculation is more than half a day behind the others, with the date, or every zone when the newest calculation of all is a day and a half old.
The panel stops promising a start that is not scheduled
The time on the Home page is arithmetic: a sunrise, an offset, a duration. Whether anything is armed to act on it is a different question, and the page never asked it, which is what a countdown that reaches zero and rolls over to tomorrow looks like from the outside. It now says "a run is owed, and nothing is scheduled to start it" instead, and midnight arms the trigger again, so nothing can stay unarmed until a restart.
Cycle and soak, and a pause between zones
Clay and compacted soil have an infiltration rate: past it the water runs off or puddles, and the zone is billed for water the roots never see. Two settings on the advanced panel, both off by default: water in several passes with a soak between them, and a pause between zones for the line pressure to recover. Both lengthen the run without adding water to it, and a trigger that has to finish at sunrise works back from the whole thing. Documentation.
A zone is watered once per cycle
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, watering a zone queued behind others ran it now and again when the queue reached it.
The live estimate as an entity
Every zone now has a Live bucket sensor beside its Bucket one: the same calculation run over the readings collected since the last one, without committing anything, recomputed as the zone's readings arrive and no more often than every thirty seconds. Its live attribute is false when there is nothing to estimate from yet, and the value is then the committed bucket, so a graph has no holes. Asked for by @Megalos (#853).
A binary rain sensor is worth more than a veto
Where rain arrives in millimetres, the water balance carries it. Where the only rain information is a binary sensor, all we could do was veto the day it was on: a garden that took two days of rain watered at full duration on the first dry evening.
On the advanced panel, that sensor's own history can now shorten runs instead: how much of each of the last five days it spent reporting rain, weighted so that yesterday counts for more than four days ago. It applies only to a zone whose sensor group reports no rain in millimetres at all, and it never touches the water balance, because it does not know how much fell — the deficit stays and is watered off once the weather turns. Off by default. The idea comes from kloggy's HA-Irrigation-Version2 package.
Smaller, and mostly from one beta tester
@Megalos took the last two betas apart with diagnostics files and arithmetic. Beyond the two model bugs above:
- The look-ahead help said the wrong thing. "Shared by every zone calculated the same way" has been false since every zone got its own engine, which is what made him expect the setting on a zone that cannot have it (#851).
- Leftover engines are removed on load. His installation had four for two zones, one holding its forecast days as the string "2". They are invisible and not harmless: an engine is picked up by name when something creates a zone without one.
- The daily ET deficiency says what it is: ETc, the reference evapotranspiration times the crop factor, seasonal adjustment included, before the interval scaling and before rain (#850).
- The watering calendar had hardcoded English labels in a translated panel, and printed a sentence naming the algorithm. It now says, in your language, that its months are modelled from your latitude rather than from your weather, so a continental summer reads hotter than it is.
- The zones documentation described a Module to choose, which has not existed since the panel started asking the question in words (#864).
Removed
The Irrigation Unlimited sync services (sync_with_irrigation_unlimited, send_zone_data_to_irrigation_unlimited, get_irrigation_unlimited_status) are gone. They could not work for anybody: they read a flag that was never a setting of this integration, so they always refused, quietly, with a warning in the log. That cost at least one person an evening of looking for a mistake in their own configuration. Use the Irrigation Unlimited blueprint, which hands IU the calculated duration through its own adjust_time action.
Documentation
- The output contract: one page for anybody driving the water themselves or integrating with Smart Irrigation. What is published, when it changes, how to consume it as seconds, minutes or a percentage, what to send back, and what is not promised.
- From nothing to a watered garden: the whole path in half an hour, for somebody who has none of it yet — a machine, a valve, Home Assistant, a zone that waters itself.
Trying it
Enable beta versions for Smart Irrigation in HACS, update, restart. 1513 tests, and the equations are checked against the FAO's own worked example.
If your figures move, the first two sections are why. If they move in a way those sections do not explain, an issue with a diagnostics file and the figure you are comparing against is what makes it findable — which is exactly how both model bugs in this release were found.