boncourant
Se connecter

Tempo cost computation — 2025.02.1


Source


CRE délibération n° 2025-09 du 30 janvier 2025, portant décision sur les

tarifs réglementés de vente d'électricité (TRV Bleu, option Tempo).

Entrée en vigueur : 1ᵉʳ février 2025.


What this method does


Compute the annual cost of EDF's Tempo tariff (or any supplier replicating

its 3-colour × HP/HC grid) for a residential PDL over a given date range,

typically a full Tempo year (1 September → 31 August).


For each calendar day in [start_date, end_date):


  • Look up the day's colour (Bleu / Blanc / Rouge) via

    • MethodContext.calendar — a TempoCalendarLike supplied by the caller.

  • Compute the day's HP / HC kWh:

    • - Declared branch (B2C default — Linky consent is rare):

    kwh_per_day = total_kwh / days_covered, split by hp_share.

    - Hourly branch (Linky branch):

    sum kwh_per_hour[h] over the 24 hours of the day, splitting by the

    supplied hp_hours_mask[h].

  • Multiply by the colour's HP and HC tariffs (€/kWh) to get the day's

    • energy cost.


    Annual cost = abonnement × (days_covered / 365) + Σ daily energy €.


    Calendar source of truth (load-bearing detail)


    The day-colour calendar lives outside the method to keep apply() pure:


  • Historical days (yesterday and earlier in the current Tempo year):

    • RTE Tempo API

    https://digital.iservices.rte-france.com/open_api/tempo_like_supply_contract/v1/tempo_like_calendars.

    Refreshed daily by lib/ingestion/tempo/fetch-day-ahead.ts (Cloud

    Scheduler, 11:00 Europe/Paris). The method reads, never fetches.

  • Tomorrow's colour: RTE publishes ~10:30 Paris time the day before.

    • The 11:00 ingester writes the new day into tempo-historical.json.

  • Future days beyond tomorrow: statistical prior in

    • tempo-projected.json (all summer = Bleu; per-CRE-quota distribution of

    Blanc/Rouge in winter — 22 Rouge + 43 Blanc per Tempo year, rest Bleu).


    When any day in the range resolves to a projected colour, the method

    emits MethodWarning { code: "TEMPO_PROJECTED", reason: "X jour(s) … " }

    so the brief can label the figure "estimation" rather than "actual".


    Replay guarantee


    MethodResult.intermediates.calendar_fingerprint = sha256(merged calendar

    JSON) truncated to 16 hex chars. Persisted alongside the canonical

    (method_id, method_version, input_hash) triple. Two calls with the same

    inputs and the same calendar_fingerprint return byte-identical

    output — replayable even after the calendar evolves.


    Worked example (declared branch)


    Flat 4 800 kWh/year profile, 60 % HP / 40 % HC, over the 2024-09 →

    2025-08 Tempo year (365 days = 300 Bleu + 43 Blanc + 22 Rouge per the

    shipped tempo-historical.json; CRE quota is 22 Rouge + 43 Blanc, the

    rest Bleu, so 365 − 43 − 22 = 300 Bleu):


  • Daily kWh = 4 800 / 365 ≈ 13.151 kWh/day
  • Daily HP = 7.890 kWh, daily HC = 5.260 kWh
  • Bleu kWh = 300 × 13.151 ≈ 3 945.4 kWh (HP 2 367.2 + HC 1 578.1)
  • Blanc kWh = 43 × 13.151 ≈ 565.5 kWh
  • Rouge kWh = 22 × 13.151 ≈ 289.3 kWh

    • Multiplied by the CRE-published 6 kVA Tempo TRV grille (caller supplies

    the actual €/kWh values via the prices input), the method returns a

    total within €1 of EDF's online Tempo simulator over the same year.


    Out of scope


  • Abonnement variation across kVA tiers — the caller supplies the right

    • abonnement_eur_per_year for the user's puissance.

  • HP/HC zone schedule (peak hours start times) — for the hourly branch

    • the caller supplies the boolean mask; for the declared branch only the

    share matters.

  • TURPE / CTA / taxes — those live in their own methods

    • (turpe.bt, the simulator tax pipeline).