Zusammenfassung der laufenden PRs, die mich betreffen

Hallo @pierre-gilles,

Danke, dass du #3270 gemerged hast: Die CI wird nicht mehr an den Zeitumstellungs-Tagen brechen :folded_hands:

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.

:warning: 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.

:thermometer: 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.
    :white_check_mark: 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.
    :white_check_mark: Abgesegnet von Cursor, CodeRabbit-Feedback behandelt.

:thermometer: 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.
    :yellow_circle: Rebaset, wartet auf eine erneute Überprüfung durch Cursor.
  • #3201 – Radiatoren mit Pilotdraht
    :white_check_mark: Abgesegnet von Cursor.
  • #3218 – Verzögerung vor dem Abschalten der Heizung, wenn ein Fenster geöffnet wird
    :white_check_mark: 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
    :white_check_mark: Abgesegnet von Cursor.
  • #3225 – Animation der Anzeige zur neuen Solltemperatur
    :white_check_mark: Abgesegnet von Cursor.
  • #3258 – Option „Ganzer Tag“ in den Zeitplanbereichen
    :white_check_mark: Abgesegnet von Cursor.

:spiral_calendar: 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 Bedingung scene.in-time-range.
    :white_check_mark: Rebaset (Konflikte mit den neuen Szenen gelöst), spanische Übersetzung hinzugefügt, abgesegnet von Cursor.

:ocean: 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!

:alarm_clock: 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 :white_check_mark: 10 Tests bestanden
30.12.2026 23:01 UTC :cross_mark: 1 Fehler

Mögliche Korrekturen

  1. Datum näher rücken (z. B. 2024-06-01): eine Zeile zu ändern, aber das Problem kehrt Mitte 2029 zurück.
  2. 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.

Hallo @Will_71,

Vielen Dank für die große Arbeit und für die sehr klare Zusammenfassung!

Ich habe eine Überprüfung deiner 10 PRs durchgeführt: Code-Review, plus ein Test der Oberfläche auf jedem Zweig, mit simulierten Geräten (MQTT für die Fenster und den Pilotdraht). Alles ist als Kommentar auf jeder GitHub-PR gepostet. Insgesamt funktioniert es wirklich gut. Hier sind die wichtigsten Punkte:

  • #3268 / #3269 : OK. Es gibt noch einen Punkt, der auf jeder korrigiert werden muss: Die Bezeichnung „morgen“ bleibt nach Mitternacht angezeigt, und eine Ausnahme von 30 Minuten kann bis zum nächsten Punkt des Zeitplans verlängert werden.
  • #3200 : Die Klimaanlage, der Durchschnitt der Sensoren und der Filter pro Raum funktionieren gut. Allerdings kann ein falsch interpretierter Stopp der Klimaanlage (Timeout, Stromausfall, Fernbedienung in einem Off-Zeitraum) den Thermostat dauerhaft abschalten. Kleiner Punkt: Ein Komfort von 21 °C standardmäßig im Kühlmodus ist kalt.
  • #3201 : Top in der Oberfläche. Ein echtes Problem: Sobald der Heizkörper vom Modul aus abgeschaltet wurde, kann er nicht mehr vom Modul aus neu gestartet werden.
  • #3218 : OK. Es muss nur die Verzögerung begrenzt werden, da ein enormer Wert den Timer überläuft.
  • #3219 : OK. Der Test „Dienst gestoppt“ funktioniert nicht, und die Zusammenfassung der Karte zeigt die rohe Kennung des Zeitplans an.
  • #3225 : OK, nur noch ein wenig Feinschliff.
  • #3258 : „Kopieren nach“ an einem Tag in „Ganzer Tag“ schaltet die Heizung für den Rest des Tages ab. Das muss vor dem Mergen korrigiert werden, da es der typische Gebrauch für die Ferien ist.
  • #3015 : Problem bei der Zeitumstellung für die Bereiche, die zwischen 2 und 3 Uhr beginnen oder enden, und ein Eingabefehler im Editor (die Zeilen werden neu geordnet, während man tippt).
  • #3028 : Wie du sagtest, ist es besser, eine externe Integration zu verwenden. Ich habe in der Überprüfung notiert, was beim Portieren übernommen werden muss.

Zwei allgemeine Anmerkungen:

  • Jede PR läuft allein auf master, aber #3200, #3201 und #3218 sind miteinander in Konflikt. Beim Rebase werden einige Zeilen nicht von git gemeldet, aber sie werden brechen; ich habe sie in den Überprüfungen aufgelistet.
  • Der „Server-Test“ rot auf allen PRs kommt vom Test der Sonnenkurve bei der Zeitumstellung, korrigiert durch #3270. Ein Merge von master reicht aus.

Nochmals vielen Dank, das ist ein super Beitrag zum Thermostat! :folded_hands:

Danke für dein Feedback. Ich kümmere mich so schnell wie möglich darum.

Bei den PRs, die in Konflikt stehen, ja, das war geplant, aber ich wollte nichts vermischen, da die Anfragen und Fehler während der Tests aufgetreten sind, sodass die einzelnen PRs nicht gleichzeitig eröffnet wurden.

Ich halte dich auf dem Laufenden, sobald ich weitergekommen bin.

Bei der PR zu den Gezeiten ist die externe Integration bereits seit einigen Tagen veröffentlicht, aber ich habe die PR vorerst offen gelassen, weil es einige grafische Punkte gibt, die ich nicht reproduzieren kann.