Hallo @pierre-gilles,
Danke, dass du #3270 gemerged hast: Die CI wird nicht mehr an den Zeitumstellungs-Tagen brechen ![]()
Hier ist der Stand meiner 10 anderen offenen PRs auf Gladys. Sie sind alle mergebar, ohne Konflikte mit master. Cursor hat die letzten Versionen von 9 davon abgesegnet. #3200 wartet noch auf eine erneute Überprüfung nach dem Rebase.
Der einzige rote Punkt in ihrer CI ist der Sonnkurventest, der durch #3270 behoben wurde: Ihre Branches enthalten die Korrektur noch nicht. Er wird beim nächsten Rebase verschwinden.
Ein anderer Test wird bald brechen, ohne Bezug zur Zeit: Der Test der Energie-Kalender (calendar.test.js) veröffentlicht ein hartcodiertes Datum von 2022. Er wird ab dem 01.01.2027 scheitern, wenn dieses Datum aus dem 5-Jahres-Fenster fällt.
Thermostat: Korrekturen (Feedback von @mutmut)
- #3268 – fix: Beendigung der Ausnahmeregelung zum richtigen Zeitpunkt trotz Zeitumstellung
Eine Ausnahmeregelung „bis zum nächsten Zeitfenster“ endete eine Stunde zu früh oder zu spät, wenn die Zeit dazwischen wechselte. Die Bänder zeigen auch den Tag des Zeitfensters an, wenn es nicht heute ist. Dieser Tag wird vom Server in der Zeitzone von Gladys berechnet, nicht in der des Telefons.
Abgesegnet von Cursor. Die Anmerkungen von CodeRabbit wurden behandelt oder beantwortet. - #3269 – fix: Die Ausnahmeregelung folgt den Änderungen im Zeitplan
Wenn der Zeitplan während einer Ausnahmeregelung „bis zum nächsten Zeitfenster“ geändert wird, wird das Ende auf das neue nächste Zeitfenster neu berechnet. Eine bereits abgelaufene Ausnahmeregelung wird nicht neu gestartet. Ein geleerter Zeitplan erhält die Standarddauer.
Abgesegnet von Cursor, CodeRabbit-Feedback behandelt.
Thermostat: Funktionen
In dieser Reihenfolge mergen, da sie aufeinander aufbauen: #3200 → #3201 → #3218. Danach #3219, #3225 und #3258, in beliebiger Reihenfolge.
- #3200 – Klimaanlagen, mehrere Sensoren, Filter nach Raum
Steuerung der Klimaanlagen (air-conditioning, Modus und Ein/Aus), Durchschnitt mehrerer Temperatursensoren, Filter nach Raum. Fügt auch die Funktion „aktiver Voreinstellung“ mit Migration hinzu, um Szenen auszulösen, wenn der Zeitplan die Voreinstellung ändert. Schließlich erstellt eine während eines „Aus“-Fensters per Fernbedienung eingeschaltete Wärmepumpe eine Ausnahmeregelung bis zum nächsten Fenster.
Rebaset, wartet auf eine erneute Überprüfung durch Cursor. - #3201 – Radiatoren mit Pilotdraht
Abgesegnet von Cursor. - #3218 – Verzögerung vor dem Abschalten der Heizung, wenn ein Fenster geöffnet wird
Abgesegnet von Cursor, CodeRabbit-Feedback behandelt. Deine Entscheidung: Die Standardverzögerung, derzeit auf 60 s festgelegt. - #3219 – Zeitplan der Thermostate von einer Szene aus ändern
Abgesegnet von Cursor. - #3225 – Animation der Anzeige zur neuen Solltemperatur
Abgesegnet von Cursor. - #3258 – Option „Ganzer Tag“ in den Zeitplanbereichen
Abgesegnet von Cursor.
Szenen
- #3015 – Auslöser „Zeitbereiche“
Ein vollständiger wöchentlicher Zeitplan passt in eine einzige Szene. Sie startet zu Beginn und am Ende jedes Bereichs (einschließlich derjenigen, die Mitternacht überschreiten), mit einer Bedingungscene.in-time-range.
Rebaset (Konflikte mit den neuen Szenen gelöst), spanische Übersetzung hinzugefügt, abgesegnet von Cursor.
Dashboard
- #3028 – Gezeiten-Widget
Gezeitenuhr, nächste Hoch- und Niedrigwasser, aktuelle Wasserhöhe, Tageskurve und Registerkarten für 7 Tage. Der Koeffizient wird an der französischen Küste angezeigt. Die Berechnung erfolgt lokal, nachdem die Stationsdaten heruntergeladen wurden.
Ich habe diese PR vorerst offen gelassen, da ich trotz der grafischen Integration, die ich vorgenommen habe, noch nicht das tun kann, was ich mit den externen Integrationen möchte.
Danke!
Anhang: Ein Test, der am 31.12.2026 brechen wird
Kurz gesagt: Ab dem 31.12.2026 um Mitternacht (Paris-Zeit) wird der Job „Server test“ auf allen PRs und auf master rot sein, aufgrund eines einzigen Tests. Der Code ist korrekt, der Test hängt vom aktuellen Datum ab. Es ist das gleiche Problem wie der Sonnen-Test, der durch #3270 behoben wurde.
Der betroffene Test
server/test/lib/energy-contract/manager/calendar.test.js (etwa Zeile 292), hinzugefügt mit den Energieverträgen (#3130). Er überprüft, ob die anfängliche Befüllung eines Tarifkalenders die Kosten erst ab dem Beginn des ersten Vertrags (01.01.2025) neu berechnet. Dazu veröffentlicht er eine Tempo-Farbe mit einem festen Datum:
await energyContract.publishCalendarEntries('tempo', [{ date: '2022-01-01', value: 'blue' }], ...);
Warum er brechen wird
calendar.publish.js lehnt Daten von mehr als 5 Jahren ab (PAST_WINDOW_MS = 5 * 365 Tage), was beabsichtigt ist. Aber das Fenster rückt jeden Tag vor, während das Datum des Tests fest ist:
- Der 01.01.2022 in Paris beginnt um
2021-12-31T23:00Z. - Das Fenster umfasst 1.825 Tage, ohne Schaltjahre.
- Zwischen dem 01.01.2022 und dem 01.01.2027 gibt es 1.826 Tage, da 2024 ein Schaltjahr ist.
Das Datum fällt also am 30.12.2026 um 23:00 UTC aus dem Fenster. Die Veröffentlichung wird dann mit starts_at must be between 5 years ago and 7 days ahead abgelehnt.
Überprüft durch das Ausführen dieses Tests auf master mit verschobener Uhrzeit:
| Uhrzeit | Ergebnis |
|---|---|
| 30.12.2026 22:58 UTC | |
| 30.12.2026 23:01 UTC |
Mögliche Korrekturen
- Datum näher rücken (z. B.
2024-06-01): eine Zeile zu ändern, aber das Problem kehrt Mitte 2029 zurück. - Uhrzeit während dieses Tests einfrieren mit den Fake-Timern von sinon (
shouldAdvanceTime, da der Test auch auf eine echte Verzögerung angewiesen ist): Der Test hängt nicht mehr vom Tag ab, an dem er läuft.
Ich schlage Nr. 2 in einer separaten kleinen PR vor. Ich kann mich darum kümmern, wenn du möchtest.