v2026.08.05

This is the first stable release since v2026.07.11, and it lands everything from four beta builds at once. Most of it changes watering behaviour on purpose, and most of it was found on an imperial install that neither maintainer runs. If you use metric and a zero elevation, very little here reaches you; if you use US customary, please read the unit-system paragraphs before installing.

Accuracy release: several fixes that change the numbers, and two opt-in ways to feed the calculation far better data. Almost all of this came from @clarejor, who reported and fixed most of it against a real imperial install.

An interrupted distributor cycle could leave your pump running against a closed valve. A distributor cycle claims the shared master (pump) for as long as it actually needs it, and the pump switches off once the last claim is released. If a cycle hit an unexpected error part-way through a sweep — a failed service call, a storage write that did not complete — it closed the inlet valve defensively but never released its claim, so the configured "switch master off after" never fired. The pump then ran against a closed inlet until the next cycle for that same distributor came round, which on a daily schedule is roughly a day. Found and fixed by @Eifel-Joe. A follow-up on top of it: on that same error path, a distributor configured not to use the master could switch off a master it had never turned on. This only affects installs using the experimental water distributor together with a master switch.

Changing Home Assistant's unit system no longer corrupts your zones. Zone depths, size and throughput are stored in whichever units you see in the UI, but nothing recorded which unit system wrote them — so switching Home Assistant between metric and US customary silently changed what every one of those numbers meant, by a factor of 25.4 for depths and 10.76 and 3.79 for area and flow. There was no error and no log line, and the panel kept showing the same digits. The worst case was the irrigation trigger: a threshold of -10 mm became -10 inches, a deficit no zone ever reaches, so deficit-gated watering simply stopped. This release records the unit system alongside your data and converts all seven affected values whenever it changes — including a change made in configuration.yaml, which previously went completely unnoticed. Your existing values keep their meaning; the digits will change if you have ever switched systems.

Changing the unit system in the UI now does anything at all. Separately from the above, the handler that reacts to a live unit-system change crashed on its own log line before it did any work, so switching units in the Home Assistant UI produced no conversion and not even a display refresh — units stayed wrong until the next restart. Fixed, and the handler is now covered by tests that assert on the resulting conversion rather than on being called.

And the converted values now actually reach your sensors. Reported by @clarejor while verifying a beta build on their imperial install. The conversion above wrote the correct numbers to storage, but the zone sensors never re-read them: the bucket sensor and the zone duration sensor's attributes kept showing the pre-conversion digits under the new unit label — a factor of 25.4 out, and indistinguishable from a real reading rather than looking like a display glitch. Because sensor.<zone>_bucket is recorded in long-term statistics, that wrong number was also being written into your history for as long as it lasted. Watering itself was never affected, since the runner reads storage rather than the entities. Each converted zone now announces itself so every entity picks the new value up immediately.

Atmospheric pressure is now calculated correctly, so evapotranspiration changes. The conversion from sea-level to station pressure was dimensionally wrong and did almost nothing: at 311 m it moved 1020 hPa by 0.00002 hPa, where the real correction is about 37. Station pressure feeds the psychrometric constant in the FAO-56 equation, so every affected install has been calculating ET from a pressure that was too high. This affects sensor groups configured with relative pressure and all four weather services. If your elevation is set to 0 nothing changes for you; otherwise expect your ET numbers — and therefore your watering durations — to shift slightly.

A zone could stop calculating forever after a one-in-a-million write. Stored timestamps were written with isoformat() but read back with a pattern that required a fractional-seconds part, which isoformat() omits when the microseconds happen to be exactly zero. If that landed on a zone's consumption watermark, the value could never be read — and because the watermark is read at the start of a calculation and only replaced at the end, that zone never calculated again. It failed quietly: the other zones carried on and one line went to the log.

The zone bucket sensor was labelled mm on imperial installs while reporting inches. sensor.<zone>_bucket published the stored value, which is in your display units, under a hardcoded mm — so a bucket of -0.81 in read as -0.81 mm, a factor of 25.4 out. The sibling zone sensors and the panel were always correct; this one entity was the outlier. Metric installs are unaffected. If you are on US customary, Home Assistant will raise a one-time statistics prompt for this entity because its unit changed — the recorded history was inches mislabelled as millimetres, so there is no correct history to preserve.

A wildly implausible solar radiation reading is now capped. This one is not opt-in, so it is worth reading even if you change nothing else. If your Solar Radiation comes from a sensor reporting an instantaneous rate — W/m² or W/sq ft — each reading is now checked against the most a cloudless sky could physically deliver at that moment, and capped at 1.3 times it if it exceeds that. Broken-cloud edge enhancement really can push a pyranometer above clear sky briefly, hence the headroom; nothing physical stays there. The case this exists for is a sensor that sticks: one stuck at a constant 722 W/m² for nineteen hours, including the whole night, produces an impossible amount of evapotranspiration and quietly under-waters every zone in that sensor group. A cap that fires is logged as a warning and re-logged hourly for as long as it keeps firing, because a sensor that needs capping is a sensor worth looking at. Static values, weather-service radiation, and sensors reporting a daily total in MJ/day are all left exactly as they were.

New, off by default: hourly evapotranspiration. By default the FAO-56 equation is run once per calculation, over the window's average weather, and cloud cover biases that systematically — fed one identical hourly series across 362 days it returns 1.14 times the reference on overcast days and 0.93 times on clear ones. With this on (Setup → Experimental) the equation is run for each hour and the hours are summed, which removes that bias, and the water balance is replayed hour by hour so rain and drainage are booked when they actually happened rather than all at the start of the window. That second half matters more than it sounds: booking a day's rain at the window start overflows your maximum bucket and discards water that never overflowed in reality, measured at 186 mm a year on one install. Expect the daily figure to move by up to 12 percent, in either direction depending on the sky. It needs a Solar Radiation source that is measured rather than estimated, and it steps aside on any day where a forecast is blended in or the window cannot be reduced to hourly rows — so no series is ever invented. This is its own switch and is not tied to continuous updates below: a normal hourly-polled install can turn it on and benefit.

New, off by default: continuous updates. Weather sensors are normally read once per update tick, so daily minimum and maximum temperature come from around 24 spot samples rather than the day's real extremes, and every time-weighted average is only as fine as the poll interval. With continuous updates enabled (Setup → Experimental) the integration subscribes to your mapped sensors and records a reading whenever one changes, with a per-field deadband and a per-group debounce so the extra fidelity does not turn into constant storage writes. Existing installs are untouched unless you turn it on — including how averages are calculated, which stays exactly as it was for anyone still polling.

New, off by default: log the runs that did not happen. Contributed by @Eifel-Joe. A scheduled run that skips a zone because it simply has no water demand currently leaves no trace, so a zone that has quietly stopped watering looks the same in its history as a zone that was never scheduled. Turn on run history logging (General → Run history logging) and each such skip is recorded in the zone's run history, at most one per zone per day, and suppressed while a rain delay is active so it cannot double up with the existing paused entries. Run history is capped at 50 entries, and no-demand entries can never crowd your real runs out of it — they take at most one of those slots. Existing installs are untouched unless you turn it on.

Also fixed: with continuous updates enabled, "Clear all weather data" could leave a zone unable to record new readings for a while, because the filter that suppresses tiny sensor movements kept comparing against a value from before the reset. The continuous-updates settings card is also now translated into all eight bundled languages instead of falling back to English.

---

Also in this release: a maintenance pass on long-standing internal issues. None of these was reported by a user, and most were latent rather than actively breaking — but several would have been very hard to diagnose from the outside, so they are worth naming.

• **An unreadable transl...

v2026.08.04

This is a pre-release, and it replaces the v2026.08.03 beta. Everything in that beta is included here unchanged; what is new is a maintenance pass described at the bottom. The rest still changes watering behaviour on purpose and most of it was found on an imperial install that neither maintainer runs. If you use metric and a zero elevation, very little here reaches you; if you use US customary, please read the unit-system paragraphs before installing. Feedback on this build is what decides when it goes stable.

Accuracy release: several fixes that change the numbers, and an opt-in way to feed the calculation far better data. Almost all of this came from @clarejor, who reported and fixed most of it against a real imperial install.

An interrupted distributor cycle could leave your pump running against a closed valve. A distributor cycle claims the shared master (pump) for as long as it actually needs it, and the pump switches off once the last claim is released. If a cycle hit an unexpected error part-way through a sweep — a failed service call, a storage write that did not complete — it closed the inlet valve defensively but never released its claim, so the configured "switch master off after" never fired. The pump then ran against a closed inlet until the next cycle for that same distributor came round, which on a daily schedule is roughly a day. Found and fixed by @Eifel-Joe. A follow-up on top of it: on that same error path, a distributor configured not to use the master could switch off a master it had never turned on. This only affects installs using the experimental water distributor together with a master switch.

Changing Home Assistant's unit system no longer corrupts your zones. Zone depths, size and throughput are stored in whichever units you see in the UI, but nothing recorded which unit system wrote them — so switching Home Assistant between metric and US customary silently changed what every one of those numbers meant, by a factor of 25.4 for depths and 10.76 and 3.79 for area and flow. There was no error and no log line, and the panel kept showing the same digits. The worst case was the irrigation trigger: a threshold of -10 mm became -10 inches, a deficit no zone ever reaches, so deficit-gated watering simply stopped. This release records the unit system alongside your data and converts all seven affected values whenever it changes — including a change made in configuration.yaml, which previously went completely unnoticed. Your existing values keep their meaning; the digits will change if you have ever switched systems.

Changing the unit system in the UI now does anything at all. Separately from the above, the handler that reacts to a live unit-system change crashed on its own log line before it did any work, so switching units in the Home Assistant UI produced no conversion and not even a display refresh — units stayed wrong until the next restart. Fixed, and the handler is now covered by tests that assert on the resulting conversion rather than on being called.

And the converted values now actually reach your sensors. Reported by @clarejor while verifying the previous build on their imperial install. The conversion above wrote the correct numbers to storage, but the zone sensors never re-read them: the bucket sensor and the zone duration sensor's attributes kept showing the pre-conversion digits under the new unit label — a factor of 25.4 out, and indistinguishable from a real reading rather than looking like a display glitch. Because sensor.<zone>_bucket is recorded in long-term statistics, that wrong number was also being written into your history for as long as it lasted. Watering itself was never affected, since the runner reads storage rather than the entities. Each converted zone now announces itself so every entity picks the new value up immediately.

Atmospheric pressure is now calculated correctly, so evapotranspiration changes. The conversion from sea-level to station pressure was dimensionally wrong and did almost nothing: at 311 m it moved 1020 hPa by 0.00002 hPa, where the real correction is about 37. Station pressure feeds the psychrometric constant in the FAO-56 equation, so every affected install has been calculating ET from a pressure that was too high. This affects sensor groups configured with relative pressure and all four weather services. If your elevation is set to 0 nothing changes for you; otherwise expect your ET numbers — and therefore your watering durations — to shift slightly.

A zone could stop calculating forever after a one-in-a-million write. Stored timestamps were written with isoformat() but read back with a pattern that required a fractional-seconds part, which isoformat() omits when the microseconds happen to be exactly zero. If that landed on a zone's consumption watermark, the value could never be read — and because the watermark is read at the start of a calculation and only replaced at the end, that zone never calculated again. It failed quietly: the other zones carried on and one line went to the log.

The zone bucket sensor was labelled mm on imperial installs while reporting inches. sensor.<zone>_bucket published the stored value, which is in your display units, under a hardcoded mm — so a bucket of -0.81 in read as -0.81 mm, a factor of 25.4 out. The sibling zone sensors and the panel were always correct; this one entity was the outlier. Metric installs are unaffected. If you are on US customary, Home Assistant will raise a one-time statistics prompt for this entity because its unit changed — the recorded history was inches mislabelled as millimetres, so there is no correct history to preserve.

New, off by default: continuous updates. Weather sensors are normally read once per update tick, so daily minimum and maximum temperature come from around 24 spot samples rather than the day's real extremes, and every time-weighted average is only as fine as the poll interval. With continuous updates enabled (Setup → Experimental) the integration subscribes to your mapped sensors and records a reading whenever one changes, with a per-field deadband and a per-group debounce so the extra fidelity does not turn into constant storage writes. Existing installs are untouched unless you turn it on — including how averages are calculated, which stays exactly as it was for anyone still polling.

New, off by default: log the runs that did not happen. Contributed by @Eifel-Joe. A scheduled run that skips a zone because it simply has no water demand currently leaves no trace, so a zone that has quietly stopped watering looks the same in its history as a zone that was never scheduled. Turn on run history logging (General → Run history logging) and each such skip is recorded in the zone's run history, at most one per zone per day, and suppressed while a rain delay is active so it cannot double up with the existing paused entries. Run history is capped at 50 entries, and no-demand entries can never crowd your real runs out of it — they take at most one of those slots. Existing installs are untouched unless you turn it on.

Also fixed: with continuous updates enabled, "Clear all weather data" could leave a zone unable to record new readings for a while, because the filter that suppresses tiny sensor movements kept comparing against a value from before the reset. The continuous-updates settings card is also now translated into all eight bundled languages instead of falling back to English.

---

New in this build: a maintenance pass on long-standing internal issues. None of these was reported by a user, and most were latent rather than actively breaking — but several would have been very hard to diagnose from the outside, so they are worth naming.

• An unreadable translation file could stop a zone calculating. If a language file could not be opened or was truncated — an interrupted update, for instance — the helper that looks up translated text returned nothing at all instead of falling back, and the calculation that was building an explanation string failed outright for that zone. It now falls back to the untranslated key, which is visibly ugly and entirely harmless.
• Uninstalling left a dead dashboard resource behind. The card registers itself with Lovelace, and nothing removed that registration on uninstall, so every dashboard load afterwards kept requesting a file that no longer existed. Removing the integration now cleans up after itself. A resource you added by hand is never touched.
• The card's "config error" problem is less likely to come back. The check that decides whether the card can be registered properly — rather than through a fallback that races the dashboard render — depended on an internal Home Assistant class name. If Home Assistant ever renamed it, the check would have quietly failed into the racy path, producing exactly the intermittent "custom element doesn't exist" error some of you have seen, with nothing in the logs to explain it. It now tests for the capability instead of the name.
• Reloading the integration no longer accumulates dead internal routes, and the recurring-schedule event's timestamp is now consistently in local time rather than local or UTC depending on which kind of schedule fired it.
• Non-admin users can no longer read your weather-service API keys or your latitude and longitude over the websocket API. The zones card is unchanged for everyone, including its ability to start a run — that is what the card is for.
• Two more translation gaps closed (the "reset water usage" button was English-only in six languages), a batch of dead leftover translation keys removed, and the whole set is now checked automatically so these gaps cannot come back unnoticed.

Your storage is migrated automatically on first start (version 13). No configuration changes are needed.

v2026.08.03

This is a pre-release, and it replaces the v2026.08.02 beta. Everything in that beta is included here unchanged; what is new is the unit-system display fix and the opt-in no-demand logging below. The rest still changes watering behaviour on purpose and most of it was found on an imperial install that neither maintainer runs. If you use metric and a zero elevation, very little here reaches you; if you use US customary, please read the unit-system paragraphs before installing. Feedback on this build is what decides when it goes stable.

Accuracy release: several fixes that change the numbers, and an opt-in way to feed the calculation far better data. Almost all of this came from @clarejor, who reported and fixed most of it against a real imperial install.

An interrupted distributor cycle could leave your pump running against a closed valve. A distributor cycle claims the shared master (pump) for as long as it actually needs it, and the pump switches off once the last claim is released. If a cycle hit an unexpected error part-way through a sweep — a failed service call, a storage write that did not complete — it closed the inlet valve defensively but never released its claim, so the configured "switch master off after" never fired. The pump then ran against a closed inlet until the next cycle for that same distributor came round, which on a daily schedule is roughly a day. Found and fixed by @Eifel-Joe. A follow-up on top of it: on that same error path, a distributor configured not to use the master could switch off a master it had never turned on. This only affects installs using the experimental water distributor together with a master switch.

Changing Home Assistant's unit system no longer corrupts your zones. Zone depths, size and throughput are stored in whichever units you see in the UI, but nothing recorded which unit system wrote them — so switching Home Assistant between metric and US customary silently changed what every one of those numbers meant, by a factor of 25.4 for depths and 10.76 and 3.79 for area and flow. There was no error and no log line, and the panel kept showing the same digits. The worst case was the irrigation trigger: a threshold of -10 mm became -10 inches, a deficit no zone ever reaches, so deficit-gated watering simply stopped. This release records the unit system alongside your data and converts all seven affected values whenever it changes — including a change made in configuration.yaml, which previously went completely unnoticed. Your existing values keep their meaning; the digits will change if you have ever switched systems.

Changing the unit system in the UI now does anything at all. Separately from the above, the handler that reacts to a live unit-system change crashed on its own log line before it did any work, so switching units in the Home Assistant UI produced no conversion and not even a display refresh — units stayed wrong until the next restart. Fixed, and the handler is now covered by tests that assert on the resulting conversion rather than on being called.

And the converted values now actually reach your sensors. New in this build, reported by @clarejor while verifying the previous one on their imperial install. The conversion above wrote the correct numbers to storage, but the zone sensors never re-read them: the bucket sensor and the zone duration sensor's attributes kept showing the pre-conversion digits under the new unit label — a factor of 25.4 out, and indistinguishable from a real reading rather than looking like a display glitch. Because sensor.<zone>_bucket is recorded in long-term statistics, that wrong number was also being written into your history for as long as it lasted. Watering itself was never affected, since the runner reads storage rather than the entities. Each converted zone now announces itself so every entity picks the new value up immediately.

Atmospheric pressure is now calculated correctly, so evapotranspiration changes. The conversion from sea-level to station pressure was dimensionally wrong and did almost nothing: at 311 m it moved 1020 hPa by 0.00002 hPa, where the real correction is about 37. Station pressure feeds the psychrometric constant in the FAO-56 equation, so every affected install has been calculating ET from a pressure that was too high. This affects sensor groups configured with relative pressure and all four weather services. If your elevation is set to 0 nothing changes for you; otherwise expect your ET numbers — and therefore your watering durations — to shift slightly.

A zone could stop calculating forever after a one-in-a-million write. Stored timestamps were written with isoformat() but read back with a pattern that required a fractional-seconds part, which isoformat() omits when the microseconds happen to be exactly zero. If that landed on a zone's consumption watermark, the value could never be read — and because the watermark is read at the start of a calculation and only replaced at the end, that zone never calculated again. It failed quietly: the other zones carried on and one line went to the log.

The zone bucket sensor was labelled mm on imperial installs while reporting inches. sensor.<zone>_bucket published the stored value, which is in your display units, under a hardcoded mm — so a bucket of -0.81 in read as -0.81 mm, a factor of 25.4 out. The sibling zone sensors and the panel were always correct; this one entity was the outlier. Metric installs are unaffected. If you are on US customary, Home Assistant will raise a one-time statistics prompt for this entity because its unit changed — the recorded history was inches mislabelled as millimetres, so there is no correct history to preserve.

New, off by default: continuous updates. Weather sensors are normally read once per update tick, so daily minimum and maximum temperature come from around 24 spot samples rather than the day's real extremes, and every time-weighted average is only as fine as the poll interval. With continuous updates enabled (Setup → Experimental) the integration subscribes to your mapped sensors and records a reading whenever one changes, with a per-field deadband and a per-group debounce so the extra fidelity does not turn into constant storage writes. Existing installs are untouched unless you turn it on — including how averages are calculated, which stays exactly as it was for anyone still polling.

New, off by default: log the runs that did not happen. New in this build, contributed by @Eifel-Joe. A scheduled run that skips a zone because it simply has no water demand currently leaves no trace, so a zone that has quietly stopped watering looks the same in its history as a zone that was never scheduled. Turn on run history logging (General → Run history logging) and each such skip is recorded in the zone's run history, at most one per zone per day, and suppressed while a rain delay is active so it cannot double up with the existing paused entries. Run history is capped at 50 entries, and no-demand entries can never crowd your real runs out of it — they take at most one of those slots. Existing installs are untouched unless you turn it on.

Also fixed: with continuous updates enabled, "Clear all weather data" could leave a zone unable to record new readings for a while, because the filter that suppresses tiny sensor movements kept comparing against a value from before the reset. The continuous-updates settings card is also now translated into all eight bundled languages instead of falling back to English.

Your storage is migrated automatically on first start (version 13). No configuration changes are needed.

v2026.08.02

This is a pre-release, and it replaces the v2026.08.01 beta. Everything in that beta is included here unchanged; what is new is the distributor pump fix below. The rest still changes watering behaviour on purpose and most of it was found on an imperial install that neither maintainer runs. If you use metric and a zero elevation, very little here reaches you; if you use US customary, please read the unit-system paragraphs before installing. Feedback on this build is what decides when it goes stable.

Accuracy release: several fixes that change the numbers, and an opt-in way to feed the calculation far better data. Almost all of this came from @clarejor, who reported and fixed most of it against a real imperial install.

An interrupted distributor cycle could leave your pump running against a closed valve. A distributor cycle claims the shared master (pump) for as long as it actually needs it, and the pump switches off once the last claim is released. If a cycle hit an unexpected error part-way through a sweep — a failed service call, a storage write that did not complete — it closed the inlet valve defensively but never released its claim, so the configured "switch master off after" never fired. The pump then ran against a closed inlet until the next cycle for that same distributor came round, which on a daily schedule is roughly a day. Found and fixed by @Eifel-Joe. A follow-up on top of it: on that same error path, a distributor configured not to use the master could switch off a master it had never turned on. This only affects installs using the experimental water distributor together with a master switch.

Changing Home Assistant's unit system no longer corrupts your zones. Zone depths, size and throughput are stored in whichever units you see in the UI, but nothing recorded which unit system wrote them — so switching Home Assistant between metric and US customary silently changed what every one of those numbers meant, by a factor of 25.4 for depths and 10.76 and 3.79 for area and flow. There was no error and no log line, and the panel kept showing the same digits. The worst case was the irrigation trigger: a threshold of -10 mm became -10 inches, a deficit no zone ever reaches, so deficit-gated watering simply stopped. This release records the unit system alongside your data and converts all seven affected values whenever it changes — including a change made in configuration.yaml, which previously went completely unnoticed. Your existing values keep their meaning; the digits will change if you have ever switched systems.

Changing the unit system in the UI now does anything at all. Separately from the above, the handler that reacts to a live unit-system change crashed on its own log line before it did any work, so switching units in the Home Assistant UI produced no conversion and not even a display refresh — units stayed wrong until the next restart. Fixed, and the handler is now covered by tests that assert on the resulting conversion rather than on being called.

Atmospheric pressure is now calculated correctly, so evapotranspiration changes. The conversion from sea-level to station pressure was dimensionally wrong and did almost nothing: at 311 m it moved 1020 hPa by 0.00002 hPa, where the real correction is about 37. Station pressure feeds the psychrometric constant in the FAO-56 equation, so every affected install has been calculating ET from a pressure that was too high. This affects sensor groups configured with relative pressure and all four weather services. If your elevation is set to 0 nothing changes for you; otherwise expect your ET numbers — and therefore your watering durations — to shift slightly.

A zone could stop calculating forever after a one-in-a-million write. Stored timestamps were written with isoformat() but read back with a pattern that required a fractional-seconds part, which isoformat() omits when the microseconds happen to be exactly zero. If that landed on a zone's consumption watermark, the value could never be read — and because the watermark is read at the start of a calculation and only replaced at the end, that zone never calculated again. It failed quietly: the other zones carried on and one line went to the log.

The zone bucket sensor was labelled mm on imperial installs while reporting inches. sensor.<zone>_bucket published the stored value, which is in your display units, under a hardcoded mm — so a bucket of -0.81 in read as -0.81 mm, a factor of 25.4 out. The sibling zone sensors and the panel were always correct; this one entity was the outlier. Metric installs are unaffected. If you are on US customary, Home Assistant will raise a one-time statistics prompt for this entity because its unit changed — the recorded history was inches mislabelled as millimetres, so there is no correct history to preserve.

New, off by default: continuous updates. Weather sensors are normally read once per update tick, so daily minimum and maximum temperature come from around 24 spot samples rather than the day's real extremes, and every time-weighted average is only as fine as the poll interval. With continuous updates enabled (Setup → Experimental) the integration subscribes to your mapped sensors and records a reading whenever one changes, with a per-field deadband and a per-group debounce so the extra fidelity does not turn into constant storage writes. Existing installs are untouched unless you turn it on — including how averages are calculated, which stays exactly as it was for anyone still polling.

Also fixed: with continuous updates enabled, "Clear all weather data" could leave a zone unable to record new readings for a while, because the filter that suppresses tiny sensor movements kept comparing against a value from before the reset.

Your storage is migrated automatically on first start (version 13). No configuration changes are needed.

v2026.08.01

This is a pre-release. It changes watering behaviour on purpose and most of it was found on an imperial install that neither maintainer runs. If you use metric and a zero elevation, very little here reaches you; if you use US customary, please read the first three paragraphs before installing. Feedback on this build is what decides when it goes stable.

Accuracy release: several fixes that change the numbers, and an opt-in way to feed the calculation far better data. Almost all of this came from @clarejor, who reported and fixed most of it against a real imperial install.

Changing Home Assistant's unit system no longer corrupts your zones. Zone depths, size and throughput are stored in whichever units you see in the UI, but nothing recorded which unit system wrote them — so switching Home Assistant between metric and US customary silently changed what every one of those numbers meant, by a factor of 25.4 for depths and 10.76 and 3.79 for area and flow. There was no error and no log line, and the panel kept showing the same digits. The worst case was the irrigation trigger: a threshold of -10 mm became -10 inches, a deficit no zone ever reaches, so deficit-gated watering simply stopped. This release records the unit system alongside your data and converts all seven affected values whenever it changes — including a change made in configuration.yaml, which previously went completely unnoticed. Your existing values keep their meaning; the digits will change if you have ever switched systems.

Changing the unit system in the UI now does anything at all. Separately from the above, the handler that reacts to a live unit-system change crashed on its own log line before it did any work, so switching units in the Home Assistant UI produced no conversion and not even a display refresh — units stayed wrong until the next restart. Fixed, and the handler is now covered by tests that assert on the resulting conversion rather than on being called.

Atmospheric pressure is now calculated correctly, so evapotranspiration changes. The conversion from sea-level to station pressure was dimensionally wrong and did almost nothing: at 311 m it moved 1020 hPa by 0.00002 hPa, where the real correction is about 37. Station pressure feeds the psychrometric constant in the FAO-56 equation, so every affected install has been calculating ET from a pressure that was too high. This affects sensor groups configured with relative pressure and all four weather services. If your elevation is set to 0 nothing changes for you; otherwise expect your ET numbers — and therefore your watering durations — to shift slightly.

A zone could stop calculating forever after a one-in-a-million write. Stored timestamps were written with isoformat() but read back with a pattern that required a fractional-seconds part, which isoformat() omits when the microseconds happen to be exactly zero. If that landed on a zone's consumption watermark, the value could never be read — and because the watermark is read at the start of a calculation and only replaced at the end, that zone never calculated again. It failed quietly: the other zones carried on and one line went to the log.

The zone bucket sensor was labelled mm on imperial installs while reporting inches. sensor.<zone>_bucket published the stored value, which is in your display units, under a hardcoded mm — so a bucket of -0.81 in read as -0.81 mm, a factor of 25.4 out. The sibling zone sensors and the panel were always correct; this one entity was the outlier. Metric installs are unaffected. If you are on US customary, Home Assistant will raise a one-time statistics prompt for this entity because its unit changed — the recorded history was inches mislabelled as millimetres, so there is no correct history to preserve.

New, off by default: continuous updates. Weather sensors are normally read once per update tick, so daily minimum and maximum temperature come from around 24 spot samples rather than the day's real extremes, and every time-weighted average is only as fine as the poll interval. With continuous updates enabled (Setup → Experimental) the integration subscribes to your mapped sensors and records a reading whenever one changes, with a per-field deadband and a per-group debounce so the extra fidelity does not turn into constant storage writes. Existing installs are untouched unless you turn it on — including how averages are calculated, which stays exactly as it was for anyone still polling.

Also fixed: with continuous updates enabled, "Clear all weather data" could leave a zone unable to record new readings for a while, because the filter that suppresses tiny sensor movements kept comparing against a value from before the reset.

Your storage is migrated automatically on first start (version 13). No configuration changes are needed.

v2026.07.11

Reliability release: four lifecycle fixes around valves, schedules and pump/master control.

Valves are now always closed again. No run path guaranteed the valve was shut if something went wrong mid-run — an error, or Home Assistant shutting down or reloading, could leave a valve physically open with nothing scheduled to close it. All three run paths (normal, flow-metered slot, rotation slot) now close the valve on every exit path.

Schedules no longer fire twice after a reload. The recurring-schedule listeners were never released when the integration reloaded, so the old ones stayed armed alongside the new set. Since changing any option triggers a reload, schedules could accumulate extra firings — each one a real irrigation run. Reloading now releases them properly.

The pump / master switch stays on for the whole cycle. It was switched off based on a guess made before the run started, which was wrong in every configuration we measured. With sequential sequencing it powered down after the longest single zone, so later zones opened against a dead pump, delivered no water, and still credited their buckets as if they had watered. Zones with a flow sensor, rotation with absorption waits, and self-closing zones were all mis-timed too. The master is now held for as long as runs are actually in progress and released when the last one finishes, so it is no longer predicted at all.

Irrigation runs are tracked tasks. Runs were started in a way that left them eligible for garbage collection mid-execution and invisible to Home Assistant's shutdown handling.

No configuration changes are needed and no storage migration is involved.

v2026.07.10

Three contributed fixes from @clarejor, plus documentation.

Fixed: imperial installs never irrigated on deficit (#62)

If your Home Assistant is set to imperial units, this is the important one.

The zone depth defaults — minimum deficit to irrigate, maximum bucket and drainage rate — are authored in millimetres, but these fields are stored in the units Home Assistant is configured for. On an imperial install the raw constants were stored verbatim and therefore meant inches:

Setting	Was stored as	Meaning
Minimum deficit to irrigate	-10	−254 mm
Maximum bucket	24	610 mm
Drainage rate	20	508 mm/h

Irrigation triggers when bucket < minimum deficit, and no realistic bucket ever reaches −254 mm — so every deficit-gated run was silently suppressed, with no error and no log line.

Defaults are now materialised per unit system, and a storage migration (v11 → v12) repairs values already on disk. The migration is scoped tightly: imperial installs only, and only where the stored value is exactly the unconverted millimetre constant, so any value you chose deliberately is left alone. It is idempotent and logs each change at INFO.

Metric installs are completely unaffected — no conversion is needed there, and the migration skips them entirely.

Imperial installs: expect different watering after updating. Beyond deficit-gated runs starting to fire at all, your maximum bucket becomes a 24 mm ceiling that actually binds (it was 610 mm), and drainage becomes roughly 25× slower (20 mm/h rather than 508 mm/h). Both are the intended design. Check your zone settings after updating if you had tuned around the old behaviour.

Improved: far less disk writing (#63)

Every save reserialized the whole store — configuration, zones, modules and every sensor group's full reading buffer — and replaced the file, with no coalescing window. Because the buffer grows between calculations while each write rewrote all of it, total bytes written scaled with the square of the readings per cycle. Noticeable on SD-card and eMMC installs, and dominant at short poll intervals.

Reading buffers now live apart from the routine save payload, so ingesting a reading costs nothing on disk, and writes are coalesced over a 30 second window. Same storage file, same format, no migration, and no change to watering behaviour.

Trade-off worth knowing: a hard power-cut can now lose up to 30 seconds of configuration changes and up to 10 minutes of buffered sensor readings. A clean restart or shutdown loses nothing.

Fixed: "reset all weather data" appeared to do nothing (#64)

Clearing the buffers — via the reset action or by changing a sensor group's source — left each zone's Weather data points count showing the pre-reset number until some later poll happened to overwrite it, so the action looked like it had failed. The count is now reset with the buffer, and the affected zone entities refresh immediately.

Documentation

The zone settings and how-it-works pages now state the depth defaults per unit system rather than as flat millimetre numbers, and make explicit that zone depth values are stored in your configured units.

v2026.07.09

Fix: start-anchored sunrise/sunset schedules now fire.

HA invokes sunrise/sunset tracker callbacks with no arguments, but the start-anchor path passed a one-arg callback, so at fire time it raised TypeError and the schedule silently never ran. Finish-at-sunrise and at-time schedules were unaffected. Reported on issue #32 by AlessandroTischer.

v2026.07.08

What's Changed

• fix: correctness findings from a post-merge adversarial review (scheduler / distributor / self-closing / store) by @Eifel-Joe in #60

Full Changelog: v2026.07.07...v2026.07.08

v2026.07.07

Full Changelog: v2026.07.06...v2026.07.07