v2026.8.1

Bugfix release for v2026.7.1.

Two of these are long-standing and silent: precipitation from OpenWeatherMap was always read as 0, and a sensor group created from the panel never fetched anything at all. If you use either, this release changes what your zones calculate.

Fixed

• A sensor group created from the panel never fetched any data (#809, #781). Every field was stored without a source, so the group reported no weather service, no sensor and no static value: nothing was fetched for it and every zone linked to it failed to calculate with "No weather data to parse". The panel hid this, because the source dropdown shows "weather service" as its first option and with nothing stored the browser selected it, so the group looked configured. New groups now get a real source per field, and groups already saved without one are repaired on upgrade. Thanks to @mk13139 for the diff of the diagnostics before and after, which pinned it down, and to @DenisPlima for the earlier report.
• Precipitation from OpenWeatherMap was always 0 (#788). One Call returns rain as a nested object, and the mapping read a flat rain.1h key that never existed, so no OWM user has ever had rain counted in the water balance. Thanks to @SebastianSchultz.
• A rainy day filled the bucket with several times the rain that fell (#787). Precipitation defaults to the "delta" aggregate, which assumes a monotonic rain counter: it adds up the increases and discards every decrease. Open-Meteo does not deliver a counter, it delivers today's total with the rest of the day forecast, so that total moves both ways during the day. The result was the highest forecast ever seen with every downward correction thrown away: a day forecast at 25 mm and settling at 2.7 mm of actual rain filled the bucket with 25 mm. Open-Meteo precipitation now defaults to the "last" aggregate, which is that daily total. An aggregate you configured yourself still wins, and a rain gauge of your own keeps "delta". Thanks to @Megalos for the diagnostics that made the arithmetic reproducible.
• A "Days between irrigation" of 5 watered every 3 days (#802). The days counter was incremented twice on a skipped day. Thanks to @LoneWolf345 and @frostt01.
• Irrigation could start when the skip conditions could not be evaluated (#804). An error while checking the skip conditions let the start event fire anyway. It now fails safe and does not water. Thanks to @frostt01.
• Changing the start trigger took effect only after a restart (#800). Saving a trigger in the panel wrote it to the store without re-registering the sun tracker, so the Info tab showed the new time while irrigation still began at the old one. Thanks to @carlnrtn.
• A fixed-offset start trigger was dropped on days when no zone needed water. A trigger with "account for duration" off fires at a fixed offset and does not need the duration, but registration bailed out on a zero total duration before looking at the trigger at all.
• Recurring schedules never ran their "calculate" action. Both branches raised a TypeError instead of calculating. Reported by @frankyhun in #793.
• Reloading the integration leaked callbacks and timers (#805): the core config listener and the pending automatic-update delays were not released on unload. Thanks to @frostt01.
• Manual latitude and longitude were not redacted in diagnostics (#806). Thanks to @frostt01.
• Open-Meteo crashed on restart when the API key was empty, since a keyless service stores no key. Thanks to @jbjardine (#796).
• Waiting on a linked valve service. The valve service call now waits for the service to complete, bounded to 30 seconds so a service that never returns cannot hold up the run. Thanks to @jbjardine (#797).

Known limitation

Precipitation is still not apportioned to the calculation interval, and the three weather services disagree on what they report (OpenWeatherMap gives an hourly amount, Pirate Weather an instantaneous rate, Open-Meteo a daily total). The proper source-aware handling is tracked in #764 and #571. If you use OpenWeatherMap with an update interval of exactly one hour, setting the Precipitation aggregate to "sum" gets you closer in the meantime.

Build

• Frontend build toolchain updated, and the js-yaml and brace-expansion advisories in it resolved. These are build-time only and were never shipped to users.

Full Changelog: v2026.7.1...v2026.8.1