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 [Archive] Demande de fonctionnalités dashboard , feature-request-core , graphique	104	1774	October 14, 2024
Intégration Z-Wave JS UI [Archive] Demande de fonctionnalités feature-integration	64	1608	January 15, 2024
Gladys Assistant 4.66 : Suivi de l'énergie et Zigbee2mqtt 2.7.1! Actualités	187	1277	April 20, 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-request-core , api , feature-state	32	994	October 6, 2023
Plusieurs erreurs/manques pour Tasmota POW-R2 Développement node-red	60	1972	July 3, 2023

Improved recalculation of energy tracking

Related topics