Hi @pierre-gilles,
Thanks for merging #3270: CI will no longer break on daylight saving time change days 
Here’s the status of my 10 other open PRs on Gladys. They are all mergeable, with no conflicts with master. Cursor has approved the latest versions of 9 of them. #3200 is still awaiting review after the rebase.
The only red in their CI is the sun curve test, the one fixed by #3270: their branches don’t yet contain the fix. It will disappear at the next rebase.
Another test will soon break, unrelated to time: the energy calendars test (calendar.test.js) publishes a hardcoded date from 2022. It will fail starting on 01/01/2027, when this date falls outside the 5-year window.
Thermostat: Fixes (feedback from @mutmut)
- #3268 – fix: end of derogation at the right time despite time change
A derogation “until the next slot” ended one hour too early or too late when the time changed in between. The banners also display the day of the slot when it’s not today. This day is calculated by the server in Gladys’ timezone, not in the phone’s timezone.
Approved by Cursor. CodeRabbit’s comments have been addressed or answered. - #3269 – fix: derogation follows schedule changes
If the schedule is modified during a derogation “until the next slot,” its end is recalculated on the new next slot. An already expired derogation is not restarted. An empty schedule receives the default duration.
Approved by Cursor, CodeRabbit’s feedback addressed.
Thermostat: Features
To be merged in this order, as they stack: #3200 → #3201 → #3218. Then #3219, #3225, and #3258, in any order.
- #3200 – air conditioning, multiple probes, filter by room
Control of air conditioners (air-conditioning, mode and on/off), average of multiple temperature probes, selectors filtered by room. Also adds the “active preset” feature, with its migration, to trigger scenes when the schedule changes preset. Finally, an air conditioner turned on by remote during an “Off” slot creates a derogation until the next slot.
Rebased, awaiting a new review from Cursor. - #3201 – radiators with pilot wire
Approved by Cursor. - #3218 – delay before turning off heating when a window opens
Approved by Cursor, CodeRabbit’s feedback addressed. Your decision: the default delay, set to 60 s for now. - #3219 – change thermostat schedule from a scene
Approved by Cursor. - #3225 – animation of the gauge towards the new setpoint
Approved by Cursor. - #3258 – “All day” option in schedule ranges
Approved by Cursor.
Scenes
- #3015 – “time ranges” trigger
A complete weekly schedule fits in a single scene. It launches at the start and end of each range (including those that cross midnight), with ascene.in-time-rangecondition.
Rebased (conflicts resolved with scene updates), Spanish translation added, approved by Cursor.
Dashboard
- #3028 – tide widget
Tide clock, next high and low tides, current water height, day curve, and tabs for 7 days. The coefficient is displayed on French coasts. The calculation is done locally once the station data is downloaded.
I’ve left this PR open for now because, despite the graphical integration I’ve done, I still can’t do what I want with external integrations.
Thanks!
Appendix: A test that will break on 31/12/2026
In short: from 31/12/2026 at midnight (Paris time), the “Server test” job will be red on all PRs and on master, due to a single test. The code is correct; it’s the test that depends on the current date. This is the same type of issue as the sun test fixed by #3270.
The affected test
server/test/lib/energy-contract/manager/calendar.test.js (around line 292), added with energy contracts (#3130). It checks that the initial filling of a tariff calendar only recalculates costs from the start of the first contract (01/01/2025). To do this, it publishes a Tempo color with a hardcoded date:
await energyContract.publishCalendarEntries('tempo', [{ date: '2022-01-01', value: 'blue' }], ...);
Why it will break
calendar.publish.js refuses dates older than 5 years (PAST_WINDOW_MS = 5 * 365 days), which is intentional. But the window advances each day while the test date is fixed:
- On 01/01/2022 in Paris, it starts at
2021-12-31T23:00Z. - The window counts 1,825 days, without leap years.
- Between 01/01/2022 and 01/01/2027, there are 1,826 days, because 2024 is a leap year.
The date thus falls outside the window on 30/12/2026 at 23:00 UTC. The publication is then refused with starts_at must be between 5 years ago and 7 days ahead.
Verified by running this test on master with the clock offset:
| Clock | Result |
|---|---|
| 30/12/2026 22:58 UTC | 10 tests pass |
| 30/12/2026 23:01 UTC |  1 failure |
Possible fixes
- Bring the date closer (e.g.,
2024-06-01): one line to change, but the problem returns mid-2029. - Freeze the clock during this test with sinon’s fake timers (
shouldAdvanceTime, because the test also relies on a real delay): the test no longer depends on the day it runs.
I propose option 2, in a small separate PR. I can take care of it if you want.