Hallo zusammen, hallo @pierre-gilles
Ich habe gerade ein PR und ein Issue zum Thema Verbrauchsverfolgung eröffnet, und da das Thema über meinen persönlichen Fall hinausgeht, können wir es auch hier besprechen.
Der Kontext. Ich habe mir gerade einen Lixee TIC zugelegt und mache mich nun an die Verbrauchsverfolgung.
Ich bin bei EDF im Tarif Zen Week-End, Option Spitzen- und Niedertarif + WE. Unter der Woche ist es klassischer HP/HC (bei mir 4:30-8:30 und 12:30-16:30), aber am Samstag, Sonntag und an Feiertagen gilt der reduzierte Tarif den ganzen Tag, auch zu Spitzenzeiten. Ich wollte diesen Vertrag zum Repository energy-contracts hinzufügen und bin gegen eine Wand gelaufen.
Das Problem. Gladys kann keinen Tarif darstellen, der vom Wochentag abhängt. Das Feld hour_slots ist eine Liste von Halbstunden, die auf alle Tage gleich angewendet wird, und die Vertragstypen beschränken sich auf base, peak-off-peak und edf-tempo. Es gibt einfach keine „Tag“-Achse im Datenmodell.
Das ist kein Einzelfall: Engie (Elec Week-end), OHM Energie (Abend & Week-End), Enercoop (Flexibilität Nacht & Week-End) und Électricité de Strasbourg bieten alle das Äquivalent an. Das ist die Standardgeschäftsantwort auf die Reform der Niedertarifzeiten, die von der CRE und Enedis eingeleitet wurde, daher werden diese Angebote eher zunehmen als verschwinden.
Was ich trotzdem gemacht habe. Ich habe den Vertrag als einfachen peak-off-peak eingereicht, wobei ich den Wochenendvorteil fallen gelassen habe: energy-contracts#16. Die Tarife stammen aus dem offiziellen EDF-Tarif vom 1. August 2026 (22,60 c€/kWh im HP unter der Woche, 16,92 im HC), alle 8 Leistungsstufen von 6 bis 36 kVA sind abgedeckt.
Ich möchte transparent sein, was das wert ist: Die Näherung überhöht die Rechnung um etwa 5,5 % bei einem flachen Verbrauchsprofil und deutlich mehr, wenn man absichtlich große Verbräuche auf das Wochenende verlegt — genau das, was das Angebot fördert. Der Bias ist systematisch und immer in die gleiche Richtung, er gleicht sich nicht im Laufe der Zeit aus. Es ist besser als nichts, aber es ist nicht fair.
Die eigentliche Frage. Ich habe Gladys#2999 eröffnet, um diese Dimension hinzuzufügen. Drei Ansätze werden dort beschrieben, der, der mir am sparsamsten erscheint: day_type erweitern mit Werten, die aus dem Kalender abgeleitet werden (weekend, holiday, weekday) statt importiert. Die Mechanik existiert bereits für Tempo, nur dass hier der Wert berechnet wird statt von RTE zu kommen. Bonus, das würde auch die Angebote „+ 1 Tag nach Wahl in der Woche“ wie Zen Week-End Plus abdecken.
Es bliebe noch zu entscheiden, woher die Feiertage kommen — die API jours-feries von api.gouv.fr oder eine kleine statische Tabelle. Zu beachten ist, dass diese Angebote in der Regel nur die nationalen Feiertage berücksichtigen, ohne die Besonderheiten von Elsass-Lothringen.
Was ich suche. Zuerst möchte ich wissen, ob andere betroffen sind — wenn Sie einen dieser Tarife haben, sagen Sie es bitte, das hilft, das Interesse einzuschätzen. Dann eine Meinung der Maintainer zur Richtung: Ich bin bereit, das PR für den Kern von Gladys zu machen, aber ich möchte lieber ein grünes Licht für den Ansatz, bevor ich Code schreibe, weil es constants.js, die Servervalidierung, den Zeitschlitzselektor der Frontend und die Übersetzungen betrifft.
Danke! (und wir danken Claude nebenbei, oder?)
