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.