Hola @pierre-gilles,
Gracias por fusionar #3270: la CI ya no fallará los días de cambio de hora 
Aquí está el estado de mis otras 10 PRs abiertas en Gladys. Todas están listas para fusionarse, sin conflictos con master. Cursor ha aprobado las últimas versiones de 9 de ellas. #3200 aún espera una revisión después del rebase.
El único error en su CI es la prueba de la curva del sol, la corregida por #3270: sus ramas aún no contienen la corrección. Desaparecerá en el próximo rebase.
Otra prueba fallará pronto, sin relación con la hora: la de los calendarios de energía (calendar.test.js) publica una fecha fija de 2022. Fallará a partir del 01/01/2027, cuando esta fecha salga de la ventana de 5 años.
Termostato: correcciones (comentarios de @mutmut)
- #3268 – fix: fin de la excepción en el momento correcto a pesar del cambio de hora
Una excepción « hasta el próximo intervalo » terminaba una hora demasiado temprano o tarde cuando la hora cambiaba entre tanto. Las bandas también muestran el día del intervalo cuando no es hoy. Este día se calcula por el servidor en la zona horaria de Gladys, no en la del teléfono.
Aprobado por Cursor. Los comentarios de CodeRabbit están tratados o han recibido una respuesta. - #3269 – fix: la excepción sigue las modificaciones del horario
Si se modifica el horario durante una excepción « hasta el próximo intervalo », su fin se recalcula en el nuevo próximo intervalo. Una excepción ya expirada no se reinicia. Un horario vacío recibe la duración por defecto.
Aprobado por Cursor, comentarios de CodeRabbit tratados.
Termostato: funcionalidades
Para fusionar en este orden, ya que se apilan: #3200 → #3201 → #3218. Luego #3219, #3225 y #3258, en el orden que se quiera.
- #3200 – aire acondicionado, varias sondas, filtro por habitación
Control de los aires acondicionados (air-conditioning, modo y encendido/apagado), promedio de varias sondas de temperatura, selectores filtrados por habitación. También se añade la funcionalidad « preset activo », con su migración, para activar escenas cuando el horario cambia de preset. Finalmente, una bomba de calor encendida por el mando a distancia durante un intervalo « Apagado » crea una excepción hasta el próximo intervalo.
Rebasado, en espera de una nueva revisión de Cursor. - #3201 – radiadores fil piloto
Aprobado por Cursor. - #3218 – retraso antes de apagar la calefacción cuando se abre una ventana
Aprobado por Cursor, comentarios de CodeRabbit tratados. Tu decisión: el retraso por defecto, fijado a 60 s por ahora. - #3219 – cambiar el horario de los termostatos desde una escena
Aprobado por Cursor. - #3225 – animación de la escala hacia la nueva consigna
Aprobado por Cursor. - #3258 – opción « Todo el día » en los intervalos del horario
Aprobado por Cursor.
Escenas
- #3015 – desencadenante « intervalos horarios »
Un horario semanal completo cabe en una sola escena. Se lanza al inicio y al final de cada intervalo (incluyendo aquellos que pasan la medianoche), con una condiciónscene.in-time-range.
Rebasado (conflictos resueltos con las novedades de las escenas), traducción al español añadida, aprobado por Cursor.
Dashboard
- #3028 – widget de las mareas
Reloj de mareas, próxima pleamar y bajamar, altura del agua actual, curva del día y pestañas de 7 días. El coeficiente se muestra en las costas francesas. El cálculo se hace localmente, una vez descargados los datos de la estación.
Por ahora he dejado esta PR abierta porque, a pesar de la integración que he hecho a nivel gráfico, aún no puedo hacer lo que quiero con las integraciones externas.
Gracias !
Anexo: una prueba que fallará el 31/12/2026
En resumen: a partir del 31/12/2026 a medianoche (hora de París), el trabajo « Server test » estará rojo en todas las PRs y en master, debido a una sola prueba. El código es correcto, es la prueba la que depende de la fecha del día. Es el mismo tipo de problema que la prueba del sol corregida por #3270.
La prueba afectada
server/test/lib/energy-contract/manager/calendar.test.js (alrededor de la línea 292), añadida con los contratos de energía (#3130). Verifica que el relleno inicial de un calendario de tarifas solo recalcula los costes a partir del inicio del primer contrato (01/01/2025). Para ello, publica un color Tempo con una fecha fija:
await energyContract.publishCalendarEntries('tempo', [{ date: '2022-01-01', value: 'blue' }], ...);
Por qué fallará
calendar.publish.js rechaza las fechas de más de 5 años (PAST_WINDOW_MS = 5 * 365 días), lo cual es intencional. Pero la ventana avanza cada día mientras que la fecha de la prueba es fija:
- El 01/01/2022 en París comienza a
2021-12-31T23:00Z. - La ventana cuenta 1 825 días, sin los años bisiestos.
- Entre el 01/01/2022 y el 01/01/2027 hay 1 826 días, porque 2024 es bisiesto.
La fecha sale de la ventana el 30/12/2026 a las 23:00 UTC. La publicación es entonces rechazada con starts_at must be between 5 years ago and 7 days ahead.
Verificado ejecutando esta prueba en master con el reloj desplazado:
| Reloj | Resultado |
|---|---|
| 30/12/2026 22:58 UTC | 10 pruebas pasan |
| 30/12/2026 23:01 UTC |  1 fallo |
Posibles correcciones
- Acercar la fecha (por ejemplo
2024-06-01): una línea para cambiar, pero el problema vuelve a mediados de 2029. - Congelar el reloj durante esta prueba con los temporizadores falsos de sinon (
shouldAdvanceTime, ya que la prueba también se basa en un retraso real): la prueba ya no depende del día en que se ejecuta.
Propongo la 2, en una pequeña PR aparte. Puedo encargarme de ello si quieres.