As the original topic was closed (https://community.gladysassistant.com/t/ia-demander-des-questions-sur-la-consommation-energetique/10355 ), I’m restarting it here because there’s a tiny bug with the number of days in February!!
PS: For my personal info, is it possible to reopen a closed topic?
Thanks for the feedback, I investigated and found the source of the bug
It’s fixed in this PR:
master ← claude/gladys-ia-releves-edf-83tqug
ouvert 03:40PM - 01 Aug 26 UTC
### 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.
And it will be released in the next version of Gladys
Well, I made the same request with release 4.84.2: and now the months are offset and the consumption indicated is that of the following month!
Well spotted, we’re making progress! I found the source of the bug
master ← claude/gladys-ia-releves-edf-83tqug
ouvert 09:04AM - 03 Aug 26 UTC
### 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
<sub>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.</sub>
🤖 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.
