gru/gree-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.8.5

Browse Source
This commit is contained in:
Mateusz Gruszczyński
2026-08-28 10:12:48 +02:00
parent eb325cc0c8
commit 556a031358
8 changed files with 65 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BUILD_REPORT.md
+18 -42
View File
@@ -1,53 +1,29 @@
# GREE Controller v0.8.4 - build and validation report
# GREE Controller v0.8.5 - build and validation report
## 0.8.4 Scheduled Temporary Quick Thermostat start and ownership hardening
## 0.8.5 Temporary temperature-condition activation fix
Source baseline: v0.8.3.
Source baseline: v0.8.4.
### Changes
### Fix
- Added independent Temporary Quick Thermostat start rules: immediately, after a delay, or at an absolute date/time.
- Delayed sessions are persisted without taking local thermostat ownership before `started_at`; the controller wakes at the scheduled start and activates the saved target then.
- Duration, absolute finish validation, safety timeout and next-schedule-boundary calculations are anchored to the effective start time.
- Added pending-session countdown/status to the Quick Thermostat button and modal; after activation the same control switches to the existing finish countdown/status.
- Active Temporary Quick Thermostat targets keep priority over schedule transitions and schedule edits.
- Direct device automations remain blocked by local thermostat ownership while the temporary session is active; group climate mode/preset actions are deferred for an actively owned zone, while group power state may change underneath and becomes effective after hand-back.
- Before a delayed start, normal schedule/automation ownership is unchanged unless another pre-existing local/manual override already owns the zone.
- Local Quick Thermostat ON can use the zone's last Heat/Cool mode when inherited house climate mode is `off`; whole-house master power remains authoritative.
- Cancelling a pending session does not clear unrelated manual quick-control state.
- Added Rust regression tests for delayed-session ownership, pre-start temperature conditions, schedule target priority and local Quick Thermostat operation with inherited house mode `off`.
- Bumped controller and Home Assistant integration version to 0.8.4 and rotated the PWA service-worker cache key.
### Ownership/priority scenarios reviewed
| Scenario | Expected result |
| --- | --- |
| Delayed session before start | Normal schedule and automations continue; pending session owns nothing yet. |
| Start time reached | Session acquires local thermostat ownership, enables the zone if needed and applies its saved target. |
| Schedule transitions while active | Schedule may advance internally, but `manual_setpoint` from Temporary Quick Thermostat remains effective. |
| Schedule edited while active | Generic schedule-boundary override timer is not re-armed, so the temporary target is not cleared. |
| Direct-device automation while active | Suppressed by local thermostat ownership. |
| Group mode/preset automation while active | Climate change is deferred for the owned zone; it cannot clear/change the temporary target. |
| Group power automation while active | Group gate can change underneath, but local temporary ownership keeps the zone running; the gate applies after hand-back. |
| Temporary finish | Local ownership is cleared and the currently applicable schedule/group/house state is recalculated. |
| Session started from disabled zone | Zone is temporarily enabled, then restored to disabled and its unit is stopped after hand-back. |
- Corrected Temporary Quick Thermostat temperature-condition activation detection.
- `activated_at` now correctly marks a session as active for `temperature_reached` and `temperature_stable` evaluation.
- Existing `local_thermostat_power == true` remains a compatibility/recovery marker for sessions persisted by earlier releases.
- Future delayed sessions still cannot evaluate or complete their temperature condition before `started_at`.
- The change directly addresses the v0.8.4 updater failures:
- `temporary_stable_condition_requires_continuous_hold_time`
- `temporary_stable_condition_resets_when_temperature_leaves_range`
### Validation executed in this environment
- `node --check web/app.js`
- `node --check web/theme-init.js`
- `node --check web/sw.js`
- parsed all JSON files, including PL/EN language packs and Home Assistant manifest
- checked duplicate HTML IDs
- checked that newly referenced PL/EN translation keys exist
- `python3 -m compileall -q home-assistant scripts make_zip.py`
- `bash -n scripts/*.sh`
- checked version consistency across Cargo.toml, Cargo.lock, README and Home Assistant manifest
- JavaScript syntax checks for `web/app.js`, `web/theme-init.js`, `web/sw.js`
- JSON parsing for project JSON files
- Python syntax compilation for Python sources
- shell syntax checks for `scripts/*.sh`
- version consistency checks
- regenerated and verified `FILE_MANIFEST.sha256`
- tested the final ZIP with `unzip -t`
- final ZIP integrity check
### Rust toolchain note
This execution environment does not contain `cargo`, `rustc` or `rustfmt`, so the Rust regression tests and full compilation cannot be executed here. The tests are included in `src/engine.rs`, and the installer/updater still runs `cargo test --all-targets` before replacing the running service.
---
This environment does not contain `cargo`, `rustc` or `rustfmt`, so Rust tests cannot be executed here. The supplied deployment log confirms v0.8.4 compiled and 46/48 tests passed; this hotfix changes the activation predicate responsible for the two failures. `scripts/update.sh` will run the full Rust test suite before replacing the service.