From 37d66ce5d9043b043cc4442ef552a4ec97259b83 Mon Sep 17 00:00:00 2001 From: Joshua Date: Mon, 28 Sep 2026 23:12:27 -0400 Subject: [PATCH 1/3] release: advance version to 0.9.6 and add the 0.9.6 release notes --- RELEASE_NOTES.md | 51 +++++++++++++++++++++++ custom_components/nestquest/manifest.json | 2 +- pyproject.toml | 2 +- uv.lock | 2 +- 4 files changed, 54 insertions(+), 3 deletions(-) diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md index 5f77c7a..7e857c3 100644 --- a/RELEASE_NOTES.md +++ b/RELEASE_NOTES.md @@ -1,5 +1,56 @@ # NestQuest Release Notes +## Version 0.9.6 — 2026-09-28 + +### Scope + +Patch release carrying the household time-zone fix onto `main` (PR #275, task +6351b36d "Time zone errors"). + +### Behaviour + +- The Home Assistant integration now reports `hass.config.time_zone` to the API + in an `X-NestQuest-Timezone` header on every panel request. +- While the API's `timezone` setting has never been explicitly chosen + (`timezone_configured` false), the API adopts and persists the reported zone + (under the settings lock), so the panel's overdue/today calculation, the + admin plane and the missed-sweep scheduler are all household-local even when + the API host runs UTC. No manual setup is required. +- The missed-sweep scheduler re-plans immediately when the adopted zone changes + while it is sleeping, and re-reads the stored zone before sweeping, so it no + longer fires at the old (UTC) rollover. +- An admin-chosen zone — including an explicit choice of empty (API-host local) + — still wins over the reported zone. An invalid reported zone is logged and + ignored; the panel keeps serving on the stored settings. + +### Requirements + +- Home Assistant floor 2024.6.0 (unchanged). + +### Breaking changes + +- None. The database schema is unchanged at version 9: no migration and no + database backup is required for this release. +- Deployment note: this fix needs BOTH the API service and the HA integration + upgraded. The integration supplies the zone and the API adopts it; upgrading + only one side leaves the previous behaviour. An install whose `timezone` was + previously set — or explicitly cleared to host-local — keeps that choice. + +### Known limitations + +- If `timezone` is empty and `timezone_configured` is true (an explicit + "host local" choice), that choice is respected and the API host's zone (UTC + on the standard deployment) still applies until an admin selects a zone in + the admin Preferences. +- A change to Home Assistant's own `time_zone` takes effect after the + integration reloads or Home Assistant restarts. + +### Rollback + +- No schema change: rolling back to 0.9.5 requires no database restore. The API + and the integration may be rolled back independently; rolling back only the + integration restores the previous stored-setting-only behaviour. + ## Version 0.9.5 — 2026-09-27 ### Scope diff --git a/custom_components/nestquest/manifest.json b/custom_components/nestquest/manifest.json index 3ad819a..f20fcd1 100644 --- a/custom_components/nestquest/manifest.json +++ b/custom_components/nestquest/manifest.json @@ -15,5 +15,5 @@ "iot_class": "local_polling", "issue_tracker": "https://github.com/Maniacs-Mansion/NestQuest/issues", "requirements": [], - "version": "0.9.5" + "version": "0.9.6" } diff --git a/pyproject.toml b/pyproject.toml index e43c4c0..dc033c8 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "nestquest" -version = "0.9.5" +version = "0.9.6" description = "NestQuest Home Assistant Integration" readme = "README.md" requires-python = ">=3.11" diff --git a/uv.lock b/uv.lock index 7d8909a..5894754 100644 --- a/uv.lock +++ b/uv.lock @@ -373,7 +373,7 @@ wheels = [ [[package]] name = "nestquest" -version = "0.9.5" +version = "0.9.6" source = { virtual = "." } [package.dev-dependencies] From 8a5872c7283bbf992933df89bfecbdb986a3958a Mon Sep 17 00:00:00 2001 From: Joshua Date: Mon, 28 Sep 2026 23:44:23 -0400 Subject: [PATCH 2/3] release: qualify the 0.9.6 notes for the explicit-choice fix and legacy stored zones --- RELEASE_NOTES.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md index 7e857c3..7771be2 100644 --- a/RELEASE_NOTES.md +++ b/RELEASE_NOTES.md @@ -5,7 +5,8 @@ ### Scope Patch release carrying the household time-zone fix onto `main` (PR #275, task -6351b36d "Time zone errors"). +6351b36d "Time zone errors"), plus its release-review correction (PR #277, task +45243478). ### Behaviour @@ -20,8 +21,10 @@ Patch release carrying the household time-zone fix onto `main` (PR #275, task while it is sleeping, and re-reads the stored zone before sweeping, so it no longer fires at the old (UTC) rollover. - An admin-chosen zone — including an explicit choice of empty (API-host local) - — still wins over the reported zone. An invalid reported zone is logged and - ignored; the panel keeps serving on the stored settings. + — still wins over the reported zone: any admin update that supplies + `timezone` is recorded as an explicit choice (`timezone_configured` true). An + invalid reported zone is logged and ignored; the panel keeps serving on the + stored settings. ### Requirements @@ -33,11 +36,18 @@ Patch release carrying the household time-zone fix onto `main` (PR #275, task database backup is required for this release. - Deployment note: this fix needs BOTH the API service and the HA integration upgraded. The integration supplies the zone and the API adopts it; upgrading - only one side leaves the previous behaviour. An install whose `timezone` was - previously set — or explicitly cleared to host-local — keeps that choice. + only one side leaves the previous behaviour. An install that sets or clears + its zone on 0.9.6 or later keeps that choice; see Known limitations for a zone + stored by an older release. ### Known limitations +- A zone stored by a release before 0.9.6 without the explicit-choice marker + (for example through the previously documented + `PATCH /api/v1/admin/settings {"timezone": ...}`) is not distinguishable from + an automatically adopted value, so 0.9.6 adopts Home Assistant's reported zone + over it once. If a zone different from Home Assistant's is intended, re-save + it in the admin Preferences, which now records the explicit choice. - If `timezone` is empty and `timezone_configured` is true (an explicit "host local" choice), that choice is respected and the API host's zone (UTC on the standard deployment) still applies until an admin selects a zone in From 29674f7138f333a2b890a7be37a1bec48939fd56 Mon Sep 17 00:00:00 2001 From: Joshua Date: Mon, 28 Sep 2026 23:56:11 -0400 Subject: [PATCH 3/3] release: honor an explicit timezone_configured value in the 0.9.6 notes wording --- RELEASE_NOTES.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md index 7771be2..30b8fbc 100644 --- a/RELEASE_NOTES.md +++ b/RELEASE_NOTES.md @@ -21,10 +21,11 @@ Patch release carrying the household time-zone fix onto `main` (PR #275, task while it is sleeping, and re-reads the stored zone before sweeping, so it no longer fires at the old (UTC) rollover. - An admin-chosen zone — including an explicit choice of empty (API-host local) - — still wins over the reported zone: any admin update that supplies - `timezone` is recorded as an explicit choice (`timezone_configured` true). An - invalid reported zone is logged and ignored; the panel keeps serving on the - stored settings. + — still wins over the reported zone. A timezone-only admin update is recorded + as an explicit choice (`timezone_configured` true); an explicitly supplied + `timezone_configured` value in the same update is honored as given. An invalid + reported zone is logged and ignored; the panel keeps serving on the stored + settings. ### Requirements