# Semaine ultra intensive sur Gladys **URL:** \ **Category:** Actualités\ **Created:** [Juillet 23, 2026, 11:43 UTC](https://community.gladysassistant.com/t/semaine-ultra-intensive-sur-gladys/10374 "2026-07-23T11:43:50Z")\ **Posts on this page:** 1\ **Showing post:** 21
**Author:** ![Terdious](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/terdious/32/6316_2.png) [@Terdious](https://community.gladysassistant.com/u/Terdious)\ **Post date:** [Juillet 30, 2026, 5:13 UTC](https://community.gladysassistant.com/t/semaine-ultra-intensive-sur-gladys/10374/21 "2026-07-30T05:13:48Z")
Hey @pierre-gilles, Tout roule ? Tu tiens le coup j’espère ? Pourras-tu regarder les PR suivantes pendant ta semaine intensive pour avancer sur intégrations externes ? > > > \### 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: > > \- \[\] If your changes affect the code, did you write the tests? > \- \[\] Are server tests passing with coverage? (\`cd server && npm run coverage\`) — Codecov requires \*\*100% coverage on lines changed in this PR\*\* > \- \[\] Did Cypress E2E tests pass? (\`npm run cypress:run\` from repo root, if UI changed) > \- \[\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[\] If you are adding a new feature/service, did you run the integration comparator? (\`npm run compare-translations\` on front) > \- \[\] 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) > \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com). > \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com). > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > New device feature category for plug-in battery storage systems (e.g. Zendure SolarFlow, Anker Solix, EcoFlow PowerStream): > > \- server: battery-storage category with battery-level, charge-power, discharge-power, charge-index, discharge-index and battery-energy-remaining types, allowed units (watt, kilowatt-hour, percent) > \- front: category icons and en/fr/de translations > > Needed by external integrations reporting battery storage telemetry, starting with the Zendure integration (Terdious/gladys-zendure). Also to be mirrored in the integration-sdk-js device constants. > > Update: following the index-vs-energy question, the two cumulative counters were renamed \`charge-index\` / \`discharge-index\` to match the core's meter-index vocabulary (energy-sensor.index & the energy-monitoring allowlist). > > The remaining energy-flow telemetry is handled by the companion PR #2693: it adds the missing instantaneous \`power\` type on \`energy-production-sensor\` and introduces two dedicated read-only categories — \`grid-sensor\` (grid exchange: \`input-power\`, \`output-power\`, signed \`power\`, \`input-index\`, \`output-index\`) and \`home-output-sensor\` (power delivered to the home: \`power\`, \`index\`, \`off-grid-power\`, \`off-grid-index\`) — so each subsystem stays distinguishable for automations and future auto-dashboards. This PR keeps its scope to the single new \`battery-storage\` category. > > Claude-Session: https://claude.ai/code/session\_012157sX3FKhVYmndWLJdhfo > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Added support for the new \`battery-storage\` device feature category. > \* Included battery metrics such as state-of-charge, charge/discharge power, charged/discharged energy, and remaining stored energy. > \* Added matching units, default ranges, and preview values for battery-storage features. > \* Updated UI icons and provided German, English, and French translations for the new category. > > > \### 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: > > \- \[\] If your changes affect the code, did you write the tests? > \- \[\] Are server tests passing with coverage? (\`cd server && npm run coverage\`) — Codecov requires \*\*100% coverage on lines changed in this PR\*\* > \- \[\] Did Cypress E2E tests pass? (\`npm run cypress:run\` from repo root, if UI changed) > \- \[\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[\] If you are adding a new feature/service, did you run the integration comparator? (\`npm run compare-translations\` on front) > \- \[\] 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) > \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com). > \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com). > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > Companion of #2682 (battery-storage): this PR adds ALL the non-battery energy-flow telemetry in one place, so the taxonomy lands in two reviewable halves (battery / flows). > > \*\*1. \`energy-production-sensor.power\`\*\* — instantaneous production power (watt, \>= 0) that solar inverters and hybrid storage systems report. Also adds the category's missing \`DEVICE\_FEATURE\_UNITS\_BY\_CATEGORY\` entry (its absence hid the unit selector entirely in the device edit form). > > \*\*2. \`grid-sensor\`\*\* (new category) — a device's own grid exchange: \`input-power\`, \`output-power\`, \`power\` (signed: import +, export −, min \< 0), \`input-index\`, \`output-index\`. > > \*\*3. \`home-output-sensor\`\*\* (new category) — power delivered to the home/loads: \`power\`, \`index\`, \`off-grid-power\`, \`off-grid-index\` (backup port). > > Conventions: \`-power\` = instantaneous watts, \`-index\` = cumulative kWh meter reading (aligned with \`energy-sensor.index\` / energy-monitoring vocabulary); the \`-sensor\` suffix auto-classifies both new categories as read-only. Per-type default units, proper min/max (incl. signed grid power) and en/fr/de labels included. > > Implementation note: the per-category blocks in \`getFeatureDefaultValues\` / \`getFeaturePreviewValue\` are placed before the pre-existing type-only checks (\`type === 'power'\` for light), which would otherwise capture these types. Existing category behavior is unchanged. > > Distinct category/type per flow keeps automations and future auto-dashboards able to tell flows apart — same per-subsystem decomposition as the electric-vehicle categories. Open to renaming. > > Claude-Session: https://claude.ai/code/session\_012157sX3FKhVYmndWLJdhfo > > > \## Summary by CodeRabbit > > \## Release Notes > > \* \*\*New Features\*\* > \* Added “Production power” support on device pages, with correct unit handling (W/kW), sensible default ranges, and updated preview values. > \* Implemented category-specific handling for grid and home output sensors, including power/index preview behavior. > > \* \*\*Improvements\*\* > \* Added missing localized labels for production power in English, French, and German. > \* Updated the corresponding category icon for production power. > > > \### 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: > > \- \[\] If your changes affect the code, did you write the tests? > \- \[\] Are server tests passing with coverage? (\`cd server && npm run coverage\`) — Codecov requires \*\*100% coverage on lines changed in this PR\*\* > \- \[\] Did Cypress E2E tests pass? (\`npm run cypress:run\` from repo root, if UI changed) > \- \[\] Is the linter passing? (\`npm run eslint\` on both front/server) > \- \[\] Did you run prettier? (\`npm run prettier\` on both front/server) > \- \[\] If you are adding a new feature/service, did you run the integration comparator? (\`npm run compare-translations\` on front) > \- \[\] 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. An AMD64 preview image is built automatically for non-draft PRs; for ARM64, comment \`/build-arm64\` on the PR. > \- \[\] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) > \- \[\] If you are adding a new features/services which needs explanation, did you modify the user documentation? See \[the GitHub repo\](https://github.com/GladysAssistant/v4-website) and the \[website\](https://gladysassistant.com). > \- \[\] Did you add fake requests data for the demo mode (\`front/src/config/demo.js\`) so that the demo website is working without a backend? (if needed) See \[https://demo.gladysassistant.com\](https://demo.gladysassistant.com). > > NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. > > \### Description of change > > Extend the air-conditioning device category with three feature types so integrations can expose the full control surface of an AC unit: > > \- FAN\_SPEED ('fan-speed') with the AC\_FAN\_SPEED values (auto/low/low-mid/mid/mid-high/high/mute/turbo); > \- SWING\_HORIZONTAL ('swing-horizontal') with AC\_SWING\_HORIZONTAL (off/same/opposite); > \- SWING\_VERTICAL ('swing-vertical') with AC\_SWING\_VERTICAL (off/swing/position 1-5). > > Front: dashboard dropdown widgets for the three new types (device-in-room), icons, EN/FR/DE labels, and the air-conditioning mode widget now offers the drying and fan modes and honours the feature supported\_options (#2567) so a device only shows the modes it actually supports (cold-only units, no mute/turbo...). Features without supported\_options keep the full list. > > Extracted from the Tuya air-conditioner work (#2591) so the feature types can be reused by any integration (external integrations included) independently of the Tuya service. > > > \## Summary by CodeRabbit > > \- \*\*New Features\*\* > - Added new air-conditioning controls for \*\*fan speed\*\* and \*\*horizontal/vertical swing\*\*. > - Expanded air-conditioning mode support to include \*\*heating, drying, and fan\*\*. > \- \*\*Improvements\*\* > - Air-conditioning mode selection is now a \*\*dropdown\*\* showing only options supported by the device. > - Fan speed and swing selectors likewise show \*\*only supported choices\*\*. > - Updated \*\*English, German, and French\*\* labels for the new controls, and added matching icons. > > > \### Pull Request check-list > > \- \[x\] If your changes affect the code, did you wr…ite the tests? (30 new/updated tests, mirroring the consumption-from-index suites) > \- \[x\] Are server tests passing with coverage? — 100% coverage (stmts/branch/funcs/lines) on every file changed by this PR > \- \[x\] Did Cypress E2E tests pass? (no UI change — only i18n job labels) > \- \[x\] Is the linter passing? (0 errors) > \- \[x\] Did you run prettier? (front + server) > \- \[x\] compare-translations: the two new job-label keys are added to en/fr/de > \- \[\] Real-life test: will be exercised by gladys-zendure once the battery/energy-flow taxonomy PRs land (15 real devices available for testing) > \- \[x\] API documentation: apidoc comments added for the new endpoint > \- \[\] User documentation: to be added once the whole energy-production story (taxonomy + this pipeline) is merged > > \### Description of change > > Today \`energy-monitoring\` turns cumulative \*\*consumption\*\* meter indexes into > \`thirty-minutes-consumption\` states (then cost). Production meters had no > equivalent: \`energy-production-sensor\` already defines \`index\` and > \`thirty-minutes-production\` types, but nothing computed them. > > This PR mirrors the consumption pipeline for production: > > \- New \`PRODUCTION\_INDEX\_FEATURE\_TYPES\` allowlist (\`energy-production-sensor.index\`). > Production is deliberately NOT added to \`ENERGY\_INDEX\_FEATURE\_TYPES\` — that > would pair a solar index with a \`thirty-minutes-consumption\` feature and count > production as consumption. > \- \`calculateProductionFromIndex\`: 30-minute index deltas → \`thirty-minutes-production\` > states (paired via \`energy\_parent\_id\`), with unit conversion and counter-reset > handling. Uses a production-specific \`ENERGY\_PRODUCTION\_INDEX\_LAST\_PROCESSED\` > device param so a device carrying both consumption and production indexes never > corrupts either cursor. > \- Scheduled in the existing 30-minute job (consumption → production → cost). > \- \`calculateProductionFromIndexFromBeginning\` + new authenticated endpoint > \`POST /api/v1/service/energy-monitoring/calculate-production-from-index-from-beginning\` > to rebuild history after adding a device. > \- Two new \`JOB\_TYPES\` + front i18n job labels (en/fr/de). > > Follow-up (separate PR, needs a semantic decision): deriving > \`thirty-minutes-production-revenue\` / solar savings from these production states — > self-consumption × contract price vs export at a feed-in tariff. > > 🤖 Generated with \[Claude Code\](https://claude.com/claude-code) > > https://claude.ai/code/session\_012157sX3FKhVYmndWLJdhfo > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Added scheduled 30-minute energy production calculations derived from meter index data. > \* Added an option to recalculate energy production history from the beginning of available data. > \* Added a secured API endpoint to trigger full historical recalculation. > \* Added job type labels for energy production from index in English, French, and German. > \* \*\*Bug Fixes\*\* > \* Improved production computation for counter resets, missing/invalid linked features, and unit conversion. > \* \*\*Tests\*\* > \* Expanded coverage for the new scheduled flow, historical recalculation, API endpoint, and edge cases. > > > \## Description > > When \`CAMERA\_URL\` points to an HLS manifest (\`.m3u8\`) instead of… an RTSP URL — e.g. Netatmo cameras exposing \`/live/files/{quality}/index.m3u8\` — ffmpeg's HLS demuxer starts reading \*\*3 segments behind the live edge\*\* (\`live\_start\_index\` default = \`-3\`). With Netatmo's 2-second segments this adds ~4–6 s of fixed glass-to-glass latency on top of the re-encoding pipeline. > > This PR passes \`-live\_start\_index -1\` as an \*\*input option\*\* (before \`-i\`), \*\*only when the URL contains \`.m3u8\`\*\*, so: > \- HLS cameras start ~2 segments closer to the live edge (measured ~10–15 s → ~6–8 s end-to-end on a Netatmo NACamera); > \- RTSP cameras are untouched (the option is never added for them). > > \## Tests > > \- Added two unit tests in \`rtspCamera.streaming.test.js\` asserting the ffmpeg args: \`-live\_start\_index -1\` is placed before \`-i\` for an \`.m3u8\` URL, and absent for a non-HLS URL. > \- \`npx mocha ./test/bootstrap.test.js ./test/services/rtsp-camera/rtspCamera.streaming.test.js\`: 20 passing, 0 failing. > \- Validated on a real bench (Gladys + Netatmo NACamera streamed over the LAN through the external gladys-netatmo integration). > > 🤖 Generated with \[Claude Code\](https://claude.com/claude-code) > > https://claude.ai/code/session\_016vS9MKCHbLnYJEhqnnX34K > > \--- > \_Generated by \[Claude Code\](https://claude.ai/code/session\_016vS9MKCHbLnYJEhqnnX34K)\_ --- _[View the full topic](https://community.gladysassistant.com/t/semaine-ultra-intensive-sur-gladys/10374)._