# IA : demande des relevés de consommation edf **URL:** \ **Category:** Configuration\ **Created:** [Juillet 31, 2026, 6:59 UTC](https://community.gladysassistant.com/t/ia-demande-des-releves-de-consommation-edf/10418 "2026-07-31T18:59:20Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Chris75](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/c/6a8cbe/32.png) [@Chris75](https://community.gladysassistant.com/u/Chris75)\ **Post date:** [Juillet 31, 2026, 6:59 UTC](https://community.gladysassistant.com/t/ia-demande-des-releves-de-consommation-edf/10418/1 "2026-07-31T18:59:21Z")
Comme le sujet original a été fermé ([https://community.gladysassistant.com/t/ia-demander-des-questions-sur-la-consommation-energetique/10355](https://community.gladysassistant.com/t/ia-demander-des-questions-sur-la-consommation-energetique/10355) je le relance ici car il y a un tout petit bug sur le nombre de jour du mois de février !! A part cela ça fonctionne très bien et l’IA s’en sort bien avec cette release ! ![Capture d'écran 2026-07-31 100552](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/8/c/8c0d1f51e78b1449aee94bd7dc60d3cc5f400408.png) PS : pour mon info perso , est-il possible de rouvrir un sujet fermé ? ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 1, 2026, 4:02 UTC](https://community.gladysassistant.com/t/ia-demande-des-releves-de-consommation-edf/10418/2 "2026-08-01T16:02:19Z")
Merci pour le retour, j’ai investigué et j’ai trouvé la source du bug 🙂 C’est corrigé dans cette PR : > > > \### Description > > This PR improves the date handling in the \`device.get-energy-co…nsumption\` MCP tool to be more lenient and user-friendly: > > \*\*Changes:\*\* > 1. \*\*Relaxed date validation\*\*: Instead of rejecting dates with invalid months (13+) or days (32+), the tool now only validates that months are 01-12 and days are 01-31. This allows the tool to accept dates that models commonly generate incorrectly. > > 2. \*\*Smart date clamping\*\*: Out-of-range days are now clamped to the last valid day of their month: > - February 29th on non-leap years → February 28th > - April 31st → April 30th > - February 29th on leap years → February 29th (preserved) > > This handles the common case where models try to specify "end of month" but get the day wrong. > > 3. \*\*Improved error messages\*\*: When dates fail validation (e.g., month 13, day 0), the error message now clearly explains the constraints. > > 4. \*\*Echo effective dates\*\*: The response now reports the actual dates used (after clamping), not the raw input, so users see what period was queried. > > 5. \*\*Updated documentation\*\*: The tool description now explains the clamping behavior and recommends using \`group\_by: month\` for multi-month queries instead of multiple calls. > > \*\*Why:\*\* LLMs frequently generate invalid dates like "2026-02-30" when trying to specify month-end ranges. Rather than failing the entire request, we now interpret the intent and clamp to valid dates, making the tool more robust and user-friendly. > > \### Checklist > > \- \[x\] Tests pass: Added comprehensive test cases covering invalid months, invalid days, leap year handling, and 30-day month clamping > \- \[x\] Linter and prettier pass > \- \[x\] No breaking changes: The tool is more permissive; existing valid inputs work identically > > https://claude.ai/code/session\_01C7nwArkBMo29eZn6o3o87f > > > \## Summary by CodeRabbit > > \* \*\*New Features\*\* > \* Energy-consumption date ranges now accept day values from 1–31. > \* Dates beyond a month’s final day are automatically adjusted to that month’s last valid day. > \* Leap-year February 29 remains supported, including for years before 0100. > > \* \*\*Bug Fixes\*\* > \* Improved date validation messages to clarify accepted formats and numeric ranges. > \* Returned periods now reflect the normalized, effective dates. Et ça partira dans la prochaine version de Gladys 🙂 ---
**Author:** ![Chris75](https://gladys-assistant-community.b-cdn.net/letter_avatar_proxy/v4/letter/c/6a8cbe/32.png) [@Chris75](https://community.gladysassistant.com/u/Chris75)\ **Post date:** [Août 2, 2026, 8:41 UTC](https://community.gladysassistant.com/t/ia-demande-des-releves-de-consommation-edf/10418/3 "2026-08-02T20:41:45Z")
bon j’ai refait la même demande avec la release 4.84.2 : et maintenant les mois sont décalés et la conso indiquée est celle du mois suivant ! la conso indiquée de décembre 2025 (que je n’ai pas demandée) est celle de janvier 2026 … et ainsi de suite ! ![Capture d'écran 2026-08-02 223944](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/4/1/41291ae91821f306d5fd092212ba68d4ff0ec07b.png) ---
**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\ **Post date:** [Août 3, 2026, 9:07 UTC](https://community.gladysassistant.com/t/ia-demande-des-releves-de-consommation-edf/10418/4 "2026-08-03T09:07:24Z")
Bien vu, on avance ! J’ai trouvé la source du bug 😉 > > > \### Description > > Follow-up to #2740, reported on the forum after 4.84.2 shipped.… > > Asked for a monthly consumption table over a year, the AI now makes a single \`group\_by: month\` call (as #2740's tool description tells it to), and every row came back shifted by one month: the first row was labelled \*\*December 2025\*\* and carried \*\*January 2026\*\*'s consumption. > > \`t\_device\_feature\_state.created\_at\` is a \`TIMESTAMPTZ\`, so DuckDB truncates the buckets in the local timezone and a monthly bucket is local midnight on the 1st. The tool passed that \`Date\` straight into its response, where it serializes as a UTC instant: in Paris, local \`2026-01-01\` becomes \`2025-12-31T23:00:00.000Z\`, and the model reads December. > > Reproduced against real DuckDB in \`Europe/Paris\`: > > \`\`\` > sum=118.247 before: 2025-12-31T23:00:00.000Z after: 2026-01 > sum=121.17 before: 2026-01-31T23:00:00.000Z after: 2026-02 > sum=126.954 before: 2026-02-28T23:00:00.000Z after: 2026-03 > \`\`\` > > The bug is not new — the energy dashboard formats the same values with \`dayjs(...).format('MMM YYYY')\` in local time and displays correctly, which is why only the AI answer was affected. #2740 made it visible by moving the model from twelve one-month calls (where it labelled rows from its own request dates) to a single grouped call that relies on the bucket dates. > > \*\*Fix:\*\* report the local calendar date at the granularity that was grouped by, so no offset is left for the model to misread: > > | \`group\_by\` | reported as | > | --- | --- | > | \`year\` | \`2026\` | > | \`month\` | \`2026-01\` | > | \`day\` / \`week\` | \`2026-07-12\` | > | \`hour\` | \`2026-07-12 08:00\` | > > Test fixtures now use local \`Date\` objects like DuckDB actually returns, which also makes the assertions independent of the machine timezone — the suite passes in \`Europe/Paris\`, \`UTC\`, \`America/New\_York\` and \`Pacific/Auckland\`. > > The other caller of \`getConsumptionByDates\` (the weekly digest) only sums values and never exposes a bucket date, so it is unaffected. > > \## Forum > > Forum: https://community.gladysassistant.com/t/ia-demande-des-releves-de-consommation-edf/10418 > > \### Checklist > > \- \[x\] Tests pass: \`cd server && npm run coverage\` (Codecov requires 100% coverage on changed lines) and Cypress (\`npm run cypress:run\`) if the UI changed > \- \[x\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`) > \- \[x\] No undocumented breaking change > > \Note on the first item: I ran the MCP and energy-sensor suites (147 passing) plus the changed-file linters locally, not the full \`npm run coverage\` or Cypress — no UI changed. CI covers both.\ > > 🤖 Generated with \[Claude Code\](https://claude.com/claude-code) > > https://claude.ai/code/session\_01C7nwArkBMo29eZn6o3o87f > > \--- > \_Generated by \[Claude Code\](https://claude.ai/code/session\_01C7nwArkBMo29eZn6o3o87f)\_ > > > > \## Summary by CodeRabbit > > \- \*\*Bug Fixes\*\* > - Corrected energy consumption date and month labels to respect local time zones. > - Ensured grouping settings are applied consistently to both requests and results. > - Improved accuracy for hourly, monthly, and yearly energy consumption totals.