Da das ursprüngliche Thema geschlossen wurde (https://community.gladysassistant.com/t/ia-demander-des-questions-sur-la-consommation-energetique/10355 ), starte ich es hier neu, denn es gibt einen kleinen Fehler bei der Anzahl der Tage im Februar!!
PS: Nur für meine persönliche Info, ist es möglich, ein geschlossenes Thema wieder zu öffnen?
Danke für das Feedback, ich habe nachgeforscht und die Ursache des Bugs gefunden
Es ist in diesem PR behoben:
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.
Und es wird in der nächsten Version von Gladys veröffentlicht
Also, ich habe die Anfrage mit der Version 4.84.2 wiederholt: und jetzt sind die Monate verschoben und der angezeigte Verbrauch ist der des nächsten Monats!
Gut gesehen, wir kommen voran! Ich habe die Fehlerquelle gefunden
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 bucket labels to respect the configured home timezone.
- Added a consistent default timezone when no home timezone is configured.
- Improved handling of hourly buckets across daylight-saving transitions, including ambiguous times.
- Ensured hourly, monthly, and yearly groupings produce accurate, consistently formatted results.
- Responses now clearly indicate the effective grouping and timezone used.
