Salut @pierre-gilles,
Merci d’avoir mergé #3270 : la CI ne cassera plus les jours de changement d’heure 
Voici où en sont mes 10 autres PRs ouvertes sur Gladys. Elles sont toutes fusionnables, sans conflit avec master. Cursor a approuvé les dernières versions de 9 d’entre elles. #3200 attend encore sa relecture après le rebase.
Le seul rouge de leur CI est le test de la courbe du soleil, celui corrigé par #3270 : leurs branches ne contiennent pas encore la correction. Il disparaîtra au prochain rebase.
Un autre test va casser bientôt, sans rapport avec l’heure : celui des calendriers d’énergie (calendar.test.js) publie une date de 2022 en dur. Il échouera à partir du 01/01/2027, quand cette date sortira de la fenêtre des 5 ans.
Thermostat : corrections (retours de @mutmut)
- #3268 – fix : fin de dérogation au bon moment malgré le changement d’heure
Une dérogation « jusqu’au prochain créneau » se terminait une heure trop tôt ou trop tard quand l’heure changeait entre-temps. Les bandeaux affichent aussi le jour du créneau quand ce n’est pas aujourd’hui. Ce jour est calculé par le serveur dans le fuseau de Gladys, pas dans celui du téléphone.
Approuvée par Cursor. Les remarques de CodeRabbit sont traitées ou ont reçu une réponse. - #3269 – fix : la dérogation suit les modifications du planning
Si on modifie le planning pendant une dérogation « jusqu’au prochain créneau », sa fin est recalculée sur le nouveau prochain créneau. Une dérogation déjà expirée n’est pas relancée. Un planning vidé reçoit la durée par défaut.
Approuvée par Cursor, retours CodeRabbit traités.
Thermostat : fonctionnalités
À merger dans cet ordre, car elles s’empilent : #3200 → #3201 → #3218. Ensuite #3219, #3225 et #3258, dans l’ordre qu’on veut.
- #3200 – clim, plusieurs sondes, filtre par pièce
Pilotage des climatisations (air-conditioning, mode et marche/arrêt), moyenne de plusieurs sondes de température, sélecteurs filtrés par pièce. Ajoute aussi la fonctionnalité « preset actif », avec sa migration, pour déclencher des scènes quand le planning change de preset. Enfin, une PAC allumée à la télécommande pendant un créneau « Arrêt » crée une dérogation jusqu’au prochain créneau.
Rebasée, en attente d’une nouvelle relecture de Cursor. - #3201 – radiateurs fil pilote
Approuvée par Cursor. - #3218 – délai avant de couper le chauffage quand une fenêtre s’ouvre
Approuvée par Cursor, retours CodeRabbit traités. Ta décision : le délai par défaut, fixé à 60 s pour l’instant. - #3219 – changer le planning des thermostats depuis une scène
Approuvée par Cursor. - #3225 – animation de la jauge vers la nouvelle consigne
Approuvée par Cursor. - #3258 – option « Toute la journée » dans les plages du planning
Approuvée par Cursor.
Scènes
- #3015 – déclencheur « plages horaires »
Un planning hebdomadaire complet tient dans une seule scène. Elle se lance au début et à la fin de chaque plage (y compris celles qui passent minuit), avec une conditionscene.in-time-range.
Rebasée (conflits résolus avec les nouveautés des scènes), traduction espagnole ajoutée, approuvée par Cursor.
Dashboard
- #3028 – widget des marées
Horloge de marée, prochaines pleine et basse mer, hauteur d’eau actuelle, courbe du jour et onglets sur 7 jours. Le coefficient s’affiche sur les côtes françaises. Le calcul se fait en local, une fois les données de la station téléchargées.
J’ai pour l’instant laisser cette PR ouverte car malgré l’intégration que j’ai faite au niveau graphique je ne peux pas encore faire ce que je veux avec les intégrations externe.
Merci !
Annexe : un test qui va casser le 31/12/2026
En bref : à partir du 31/12/2026 à minuit (heure de Paris), le job « Server test » sera rouge sur toutes les PRs et sur master, à cause d’un seul test. Le code est correct, c’est le test qui dépend de la date du jour. C’est la même famille de problème que le test du soleil corrigé par #3270.
Le test concerné
server/test/lib/energy-contract/manager/calendar.test.js (vers la ligne 292), ajouté avec les contrats d’énergie (#3130). Il vérifie que le remplissage initial d’un calendrier de tarifs ne recalcule les coûts qu’à partir du début du premier contrat (01/01/2025). Pour ça, il publie une couleur Tempo avec une date en dur :
await energyContract.publishCalendarEntries('tempo', [{ date: '2022-01-01', value: 'blue' }], ...);
Pourquoi il va casser
calendar.publish.js refuse les dates de plus de 5 ans (PAST_WINDOW_MS = 5 * 365 jours), ce qui est voulu. Mais la fenêtre avance chaque jour alors que la date du test est fixe :
- Le 01/01/2022 à Paris commence à
2021-12-31T23:00Z. - La fenêtre compte 1 825 jours, sans les années bissextiles.
- Entre le 01/01/2022 et le 01/01/2027, il y a 1 826 jours, car 2024 est bissextile.
La date sort donc de la fenêtre le 30/12/2026 à 23:00 UTC. La publication est alors refusée avec starts_at must be between 5 years ago and 7 days ahead.
Vérifié en lançant ce test sur master avec l’horloge décalée :
| Horloge | Résultat |
|---|---|
| 30/12/2026 22:58 UTC | 10 tests passent |
| 30/12/2026 23:01 UTC |  1 échec |
Corrections possibles
- Rapprocher la date (par exemple
2024-06-01) : une ligne à changer, mais le problème revient mi-2029. - Figer l’horloge pendant ce test avec les faux timers de sinon (
shouldAdvanceTime, car le test s’appuie aussi sur un vrai délai) : le test ne dépend plus du jour où il tourne.
Je propose la 2, dans une petite PR à part. Je peux m’en occuper si tu veux.