Improved recalculation of energy tracking

pierre-gilles · May 22, 2026, 11:41am

I reviewed and responded to the PR here:

github.com/GladysAssistant/Gladys

core: Energy monitoring - extend destroyStatesFrom (device) and wrapper (job) for partial recalc support - PR1 (#2528#pullrequestreview-4345086049)

master ← Terdious:energy-recalc-pr1-utilities

ouvert 02:32PM - 18 May 26 UTC

Terdious

+215 -19

### Pull Request check-list To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items: - [x] If your changes affect the code, did you write the tests? - [x] Are tests passing? (`npm test` on both front/server) - [x] Is the linter passing? (`npm run eslint` on both front/server) - [x] Did you run prettier? (`npm run prettier` on both front/server) - [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community ([forum](https://community.gladysassistant.com/)) for testing before merging. - [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. ### Description of change ## Summary > This PR is the first independent slice extracted from #2413 as discussed > on https://community.gladysassistant.com/t/amelioration-re-calcul-suivi-de-lenergie/10069 ; > the rest of #2413 will follow in subsequent PRs only if this one is merged. Extends two existing core primitives with an optional parameter, in preparation for upcoming energy-monitoring features (selective recalculation, date-range recalculation). The change is intentionally **incremental** rather than introducing sibling functions: every pre-existing caller keeps the same effective behavior, no new file is added, no new public surface area is exposed. - `device.destroyStatesFrom(selector, from, to = new Date())` — adds an optional `to` upper bound (inclusive) defaulting to `now`. - `job.wrapper(type, func, { detached = false } = {})` — adds an optional `{ detached }` option flag. When false (default), the wrapper body is byte-for-byte identical to master; when true, the wrapper starts the job, runs `func` in the background, returns the started job immediately and never re-throws to the caller. ## Details ### `device.destroyStatesFrom(selector, from, to = new Date())` - The existing function previously had the signature `(selector, from)`. - The new optional `to` parameter defaults to `new Date()`, so every pre-existing caller keeps the same effective behavior: the SQL goes from `WHERE created_at >= from` to `WHERE created_at >= from AND created_at <= now`, which is identical in practice. - When `to` is explicitly provided, the function deletes only states inside `[from, to]` (both inclusive). - When `from > to`, the SQL is naturally empty and the function silently no-ops — documented in the JSDoc and covered by an explicit test. - Continues to throw `NotFoundError('DeviceFeature not found')` for unknown selectors. Continues to use parameterized DuckDB DELETE (no string interpolation in SQL). ### `job.wrapper(type, func, { detached = false } = {})` - The existing function previously had the signature `(type, func)`. - When `detached === false` (default), the wrapper performs the exact same SQL sequence as on master (`start` → `await func` → `finish(SUCCESS)` / on error `finish(FAILED)` then re-throw) and returns the same value (`res`). The shared body is now extracted into a local IIFE (`runAndFinish`) so the legacy and detached modes share it instead of duplicating it. - When `detached === true`, the wrapper calls `this.start(type)`, fires `runAndFinish()` without awaiting it, and returns the started `job` immediately. Errors thrown by `func` are reported on the job (status=FAILED) and never re-thrown to the caller; a secondary `try/catch` falls back to `logger.error('job.wrapper: failed to finish job ...')` if `finish(FAILED)` itself rejects. - This is the fire-and-forget mode needed by long-running "from beginning" recalculations that would otherwise hold the HTTP request open until completion. ### Tests - `server/test/lib/device/device.destroyStatesFrom.test.js`: - the 5 pre-existing master tests are unchanged, - 2 new tests cover the bounded form: a happy path with a range cut-out (states inside `[from, to]` deleted, states outside kept) and an inverted-range silent no-op. - `server/test/lib/job/job.test.js`: - the existing `describe('job.wrapper')` legacy tests are unchanged, - the new `describe('job.wrapper with { detached: true }')` block carries 3 tests covering success path, failure path, and the secondary log path when `job.finish` itself rejects, - a small additional test on `updateProgress` asserts it rejects when the job id is unknown — easy win for coverage of a pre-existing branch. ### Coverage - `device.destroyStatesFrom.js`: **100%** statements / lines / functions / branches. - `job.wrapper.js`: **100%** statements / lines / functions; branch coverage at 75% (one defensive guard `if (error && error.toString)` is not exercised — identical to the pre-existing situation on master, no new uncovered branch introduced). ### Tested manually - A long-running "from beginning" recalculation on my own production instance now returns the HTTP response immediately and runs as a background job (progress visible in the jobs page) — this is the actual functional motivation for the `{ detached }` mode and the reason this PR is the prerequisite for the follow-ups. ## Scope Diff vs base branch (`master`): | Area | Insertions | Deletions | |---|---|---| | server (production) | 67 | 13 | | server (tests) | 148 | 6 | | **Total** | **215** | **19** | Files touched: - `server/lib/device/device.destroyStatesFrom.js` — `+23 / -4` (add optional `to` parameter) - `server/lib/job/job.wrapper.js` — `+25 / -13` (factor out shared body, add `{ detached }` option) - `server/test/lib/device/device.destroyStatesFrom.test.js` — `+87 / 0` (2 new tests for the bounded form) - `server/test/lib/job/job.test.js` — `+80 / -6` (3 new tests for the detached mode + 1 on `updateProgress`) No new file, no new public function, no new prototype binding on `DeviceManager` or `Job`. ## Summary by CodeRabbit * **New Features** * Jobs can now run in detached/background mode, enabling non-blocking job execution * Device state deletion now supports specifying an optional date range (from and to) for more precise cleanup * **Tests** * Added comprehensive test coverage for detached job execution and error handling * Added test cases for bounded date range state deletion, including edge cases [![Review Change Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/GladysAssistant/Gladys/pull/2528?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)

Topic		Replies	Views
Affichage des graphiques pour les capteurs binaires Demandes livrées dashboard , feature-core , graphique	103	2093	October 14, 2024
Intégration Z-Wave JS UI Demandes livrées feature-integration	63	2038	January 15, 2024
Gladys Assistant 4.66 : Suivi de l'énergie et Zigbee2mqtt 2.7.1! Actualités	183	1811	April 4, 2026
API : permettre aux intégrations externes de déclarer leurs propres types de contrat énergie Demande de fonctionnalités	8	171	October 2, 2026
Ajout d'une requête APIRest Gladys permettant de récupérer les états des features sur une plage Demande de fonctionnalités feature-core , api , feature-state	32	1064	October 6, 2023

Improved recalculation of energy tracking

Related topics