A fix for one defect in v2026.9.1, which stopped the calculation on a default install. Update if you are on v2026.9.1 or on any of its betas.
A zone on the sensor group with id 0 was never calculated
The sensor group created on a fresh install has id 0. The calculation fetched a zone's group behind a truthiness check, and 0 is falsy, so the group was never read: the zone had no weather data and every calculation logged
[async_calculate_all] Error calculating zone <name>: no sensor data available
even though the group was collecting readings normally. Any zone pointing at the default sensor group could not be calculated, and the only way around it was to create a second group. Zones on a group created later were never affected. The defect came in with the per-zone reading window in v2026.9.1-beta1, so it has been out for four days.
Nothing was lost while it lasted: the readings were collected and kept, so the first calculation after this update reads the whole window.
A sensor group's buffer is a list
It defaulted to the string "[]", which is truthy, so a reader that checks whether the buffer holds anything took it for a buffer with readings in it. It logged an error on the first update of a new group, and appending a reading to a group that had never been updated could fail. The buffer is a list now: on a new group, on one loaded from disk, and on one sent through the API, where a JSON string is decoded rather than discarded.
Both reported by @DGP-191 in #846, with the line, the cause and the fix. This is the report a maintainer hopes for.