The Consumption Tab

Where it lives and what it produces

Open /consumption, or click the lightning-bolt icon in the left navigation rail. The page is organised as a row of source sub-tabs across the top. The first, Main, is always present and holds the primary load. A trailing + tab adds further sources. Everything you enter here is combined into a single annual load series (summed for extra loads, co-simulated for vehicles) that the simulation engine subtracts from production to compute self-consumption, grid exchange and the bill.

The tab works on the open project. Until one is open the rail entry is greyed out, and the page shows only No working project yet — open or import one on the Project tab first.

The engine works internally on a fine, roughly 5-minute series. You rarely enter data at that resolution: instead you give monthly totals and a repeating daily shape, and pvSpline interpolates. When you import real Enedis metering, the measured half-hourly curve is used directly and interpolated up. The project's Interpolation method and Time resolution, on Production, choose how that fine series is rebuilt and at what step (The Configuration card).

Validation feedback while you type

About a third of a second after you stop typing, the app re-checks the project against its rule table and marks what it finds in three places at once:

• the Consumption icon in the rail is tinted by the worst issue on this tab, with the messages in its tooltip;

• any month whose peak-hours cell is 0 gets a warning border, with Peak consumption January is 0 (or Consumption January is 0 in a single-column rate scheme) as its tooltip. All twelve months must be filled for the project to be valid;

• if the project carries neither a measured Enedis series nor a manual grid with values in it, the rail tooltip lists Consumption data not loaded (Enedis or manual entry); on a project with a delivery point, the Enedis download control carries the same flag.

Softer warnings join the rail tooltip without blocking anything: Some peak-consumption months are 0 (incomplete data?), No off-peak consumption entered (all off-peak hours are 0), and Off-peak consumption values are hidden at this tariff granularity but still counted — switch to a Peak/Off-peak granularity to review them. When a split tariff carries off-peak consumption but its schedule holds no peak-hour window, every hour counts as peak: the tooltip says so, starting No peak-hour ranges are set, and the + button of the schedule on the Project tab is flagged as the place to fix it. Add the peak hours there, the hours outside the off-peak hours your bill prints, not the off-peak hours themselves (The project's consumption-rate and grid-pricing cards).

Consumption sources and the source tabs

Each sub-tab across the top is one consumption source. The Main tab cannot be closed; every other source tab carries a close button.

The Main editor

The Main sub-tab is laid out as up to three cards: Monthly consumption (kWh) on the left, and a stacked Production vs Consumption graph over a Daily power curve editor on the right. On a narrow window — or a phone — they stack into one column.

Monthly consumption

This card sets how much energy is used each month. Its first row is a mode row that changes shape with the project:

• on a project with an authorised delivery point, a Manual checkbox appears first. Unticked (the default), the measured Enedis series is what the engine bills and the row carries the Enedis download button. Ticked, the row swaps to the Profile and Annual controls and the engine regenerates the load from the grid below;

• on a project with no delivery point — everything you build by hand — there is nothing to override, so the checkbox is hidden and the Profile and Annual controls are always there.

Below that sits the twelve-month grid you fine-tune by hand.

The grid has one row per month. Depending on the rate granularity set on the Project tab, each month shows either a single Consumption (kWh) value (flat rate or hourly-CSV tariff) or a split HP (kWh) (peak) and HC (kWh) (off-peak) pair. In Tempo (EDF) mode the headers name the fixed windows (HP 6h–22h (kWh), HC 22h–6h (kWh)); in the seasonal mode the peak hours follow the winter and summer schedules on the rate card.

Tempo registers.

When the rate granularity is Tempo (EDF), a Tempo registers (kWh/year) block appears above the grid: six cells for Blue, White and Red days, each split into peak (HP) and off-peak (HC). Type the six annual meter readings from an EDF Tempo bill and click Fill the months to spread each colour across the twelve months in proportion to that colour's day-count in the active Tempo calendar. This is a one-off copy; the monthly cells stay editable afterwards, and editing one returns the Profile selector to Custom.

Where each month's number came from

Under each month's name the grid prints a small caption saying where that month's figure comes from. It is the honest provenance line for a project that mixes measured and invented data:

The captions are recomputed by the engine only when the embedded consumption series or the delivery point changes, not on every keystroke in the grid, so a month that turns from Synthetic into Manual keeps its old caption until the next download or import.

Daily power curve

This card sets when within a day the load occurs. It drives self-consumption because a load that peaks at midday overlaps solar production far better than an evening peak.

• Open days — at the top of the card, the 7-day preview of the daily power curve with a toggle button above each day's column, Monday through Sunday, in your locale's short names. A highlighted (pressed) button is an open/operating day; an unpressed button is a closure day that uses the Closed shape, and its column is hatched. Click a day to switch it. The preview smooths the two shapes into the resulting week, so you can see it before you run. Until the project records closure days, all seven days are open. Applying a typical profile sets them: most profiles close the weekend, the retail profile closes Sunday only.

• Hourly variation — a random hour-to-hour spread (0–100 %, default 5) applied to each slot on open days, so the generated curve is not perfectly smooth.

• Daily variation — a random day-to-day spread (0–100 %, default 0) that jitters whole days while preserving each month's total.

• Open and Closed shape editors — two side-by-side bar charts, one for operating days and one for closure days, each titled with the days that use it (Open · Mon–Fri). Each has 24 bars (one per hour, 0–100 %). Press a bar to set it to the height under the pointer; keep the button down and drag across the chart to paint: every bar you pass takes the height of the pointer as it crosses it. Point at a day in the preview and the chart it uses lights up; point at a chart and the buttons of its days are ringed.

• Numeric pattern grids — a collapsed panel holding the same 2 × 24 weights as plain number fields. This is the keyboard-and-screen-reader surface for the two bar editors, and the place to type an exact value.

Metered import from Enedis

For a French site with a Linky smart meter, the most accurate load is the meter's own history. pvSpline downloads it from Enedis by delivery-point identifier (the 14-digit PRM). The PRM belongs to the saved project: it is filled in by the Enedis authorisation flow, shown read-only on the Project tab, and cannot be typed here — a typed override could only point a saved project's download at a meter that project does not own.

The download control is the small download glyph on the monthly card's mode row. It appears only on a project with a delivery point, while Manual is unticked, and it needs a signed-in pvSpline cloud session: Enedis accepts no other credential, and your session token rides with that one request only.

The fetch is a job, not a button press

Pressing the button does not block the page. It queues a fetch job on the engine and returns immediately; the app polls it about once a second and shows its state next to the button as Enedis fetch: Queued, then Running, then Succeeded or Failed. While the job is in flight the Consumption icon in the rail animates, so you can leave the tab and still see that work is outstanding. The job is remembered for the browser session, so reloading the page picks the same job back up rather than losing it.

Consent before the result is applied

A successful fetch rewrites your working project, so the app only does that silently when the project is still byte-for-byte what it submitted. If you edited anything — or switched project — while the download was running, it stops and asks instead: The fetched data is ready but was not applied automatically (the working project changed, or the download failed). Applying replaces the current working project. Press Apply fetched data to take it, or simply ignore it and keep what you have.

A client with several meters

A client who authorises several delivery points signs one Enedis authorisation per meter. The first successful download of a project for such a client — before any measured series is embedded — adds the client's other meters whose authorisation is in force as Enedis source tabs, summed with the project's own meter, and says so beside the button: This client’s mandate also covers PRMs …: added as consumption sources, summed with this meter. Adding them is one step in the app's history, so an undo takes it back. Later downloads leave the source list as you made it: a meter you removed is not added again.

Every download fetches the project's own meter first, then each other meter among the enabled Enedis sources, one at a time, showing Downloading the other meters: 1 of 2 (PRM …)… while it goes and Readings downloaded for 2 other meters. once done. A meter that fails is listed under Not downloaded: with its PRM and the reason, and the others still come down — unless the session has expired, which every later meter would meet too. The status beside the button and the refusals below are those of the project's own meter: when it fails, the other meters are not asked.

When the download refuses

Overriding measured data by hand

While a measured series is embedded, the monthly grid is not what the engine bills — the meter is. The card says so: This project embeds a measured Enedis series. The engine bills THAT series, not this grid. Tick Manual to reverse that: the engine then regenerates the daily consumption from the grid and ignores the meter, and the card confirms Manual override on. Untick it to bill the measured data again. The measured series is never deleted by the override, so you can flip back and forth freely.

When your client's authorisation expires

Your client's Enedis authorisation for a delivery point is in force from the day they sign it, for the duration stated on the form they signed — twelve months by default. From the day it runs out, a download of the meter's data is refused with No Enedis authorization is in force for this PRM, unless another authorisation of your company for the same delivery point is still in force. With none left, pvSpline also removes the measured consumption from every saved version of your company's projects that name that delivery point — on a project that covers several delivery points, the series of all of them — and does the same when an authorisation is revoked before its end. The rest of each save stays as it was, and the working project, its recovery copy and any project file you exported keep their series.

A project you then reopen from your account carries no measured series, and the download that would restore it is refused. For such a project, either have your client sign a new authorisation through the Enedis consent flow (New Enedis project in the project browser on /project, shown while no project is open) and press the download glyph again, or tick Manual and bill the monthly grid, once its twelve months hold the figures you want billed. Until you do one or the other, its runs count no consumption from the meter. On a project that covers several delivery points, either way restores only the project's own delivery point: its Enedis sources still add nothing to the load.

Importing an electricity bill

A supplier bill PDF is the other way to get real numbers into the project. The importer is reached from the Consumption rates card on the Project tab (/project): set its Rate source to From a PDF bill — the rest of the card steps aside until a bill is applied — then press Choose a PDF… on the PDF bill line and pick the file. There is no separate parse step — choosing the file starts the import, and a progress bar reports reading, uploading and processing. pvSpline recognises the major French suppliers (EDF, ENGIE, TotalEnergies, Eni and others) and their tariff options.

The confirmation dialog

A successful parse opens a modal titled Parsed followed by the file's name, showing what was extracted and letting you correct it before applying:

• a read-only summary: Provider:, Tariff option:, Billing period:, the rate (Price (TTC €/kWh): for a flat bill, HP price (TTC €/kWh): and HC price (TTC €/kWh): for a split one) and Monthly consumption: — either N month(s) found on the bill or no month-by-month table on the bill;

• Import from this bill: — two checkboxes, tariffs and consumption, both ticked. They are part of the request, so unticking one re-parses the staged file under the new flags and refreshes the summary in place. While consumption is ticked and the bill carries a month table, a line says what that does to this tab: the 12 months of its grid are replaced by the bill's;

• a note stating the table's total and basis, or the caveat that only the tariff is imported — which, when the document states an estimated annual consumption, quotes that figure so you can enter it yourself;

• Correct anything the parser got wrong before applying. — editable fields for Subscribed power (kVA), Subscription (€/kVA per month) and the per-period rates in €/kWh, all seeded from the parse. Subscription opens on the all-inclusive price per kVA and per month that the import applies — the bill's monthly subscription divided by the subscribed power, or a professional bill's daily price per kVA × 30.4 — not on the monthly amount printed on the bill, and stays empty when the bill prices none. A Tempo bill offers all six colour rates instead;

• Off-peak hours on the bill: … with Update the project's HP/HC schedule timelines (both seasons), ticked by default. Ticked, applying replaces every peak-hour window, winter and summer alike, with the rest of the day around those off-peak hours: a bill printing 22:00–06:00 leaves a single 06:00–22:00 window, however many you had drawn. Untick it to keep the schedule you already have. The box has no effect while tariffs is unticked;

• a tax note: Rates read from the document’s own all-inclusive TTC column., Rates reconstructed to all-inclusive TTC: (HT + accise) × (1 + VAT)., or the warning below.

Press Apply to project to fold the values in. Cancel, press Esc or click outside the dialog to throw the parse away — nothing has been written until you apply.

How large a file may be

Every file picker in the app checks the size before reading a single byte, so an oversized file is refused straight away instead of after a long upload. A bill PDF is sent to the engine, which accepts about 25 MB per imported file.

The same ceiling applies to every file that reaches the engine, including a metered-curve or tariff CSV. Bills are almost never anywhere near it; the check exists so a mis-picked file fails with a sentence instead of a timeout.

Files imported through the cloud service also count against your monthly import allowance, set by your plan — your own on a subscription, your company's on the free plan. Once it is used up, an import is refused with Your monthly import allowance is used up, followed by how much you have stored this month; the allowance resets at the start of next month. On the free plan, an account not verified yet has no import allowance (0 MB) until it is verified (Verifying your account).

Synthetic (typical) load profiles

When you have neither meter data nor a bill, the Profile dropdown gives you a realistic starting shape. Selecting a profile fills the monthly grid, both daily shapes, the two variation knobs and the open/closed days; the Annual total scales it. The choices are:

Every profile also carries its own peak/off-peak split, so applying one to a split-rate project distributes each month between the HP and HC columns rather than dumping it all into one.

Data-centre load

A Datacenter source models an IT facility as an electrical load and sums it into the project's consumption. Its power is IT capacity × Base PUE (the cooling/overhead multiplier), shaped over the day by a utilisation schedule and — for AI clusters — a stochastic training-job process. Switch a source's Type to Datacenter to reveal three cards: Data-center parameters and AI training jobs stacked on the left, and a Daily power curve card on the right.

Data-center parameters

• IT capacity (kW) and Max utilization (%) — the nameplate IT power and the ceiling the schedule plus jobs may reach.

• Base PUE — Power Usage Effectiveness, total facility power divided by IT power (1.0 = no overhead; modern sites are roughly 1.1–1.6).

• Temperature source — where the outdoor temperature that drives cooling comes from: Automatic uses the project's fetched weather when there is any and falls back to a built-in seasonal model before the first fetch; Seasonal model always uses the built-in model; None removes the temperature coupling altogether and holds PUE at its base value.

• Free-cooling threshold (°C) — below this outdoor temperature, PUE stays at its base value; above it, PUE rises.

• PUE per °C above threshold — how much PUE climbs per degree above the free-cooling threshold.

• Slot noise and Daily noise (%) — random texture applied independently to each time slot and to whole days.

• Random seed — the same seed and parameters always reproduce the exact same series.

An estimate line at the bottom reads back the approximate annual consumption and mean utilisation implied by your settings — Estimated annual consumption: ~4 200 MWh (mean utilization 68%) — so you can size the facility before running the simulation. It is a closed-form sizing aid: it folds in the schedule, the jobs and the base PUE, but deliberately leaves out the temperature term and the noise.

AI training jobs

A data centre becomes an AI data centre when it has a training-job process; leave Compute jobs per day at 0 for a regular enterprise or cloud facility. The jobs stack step-shaped plateaus on top of the utilisation schedule:

• Compute jobs per day — the Poisson arrival rate of training jobs; above 0 makes this an AI data centre.

• Mean job duration (h) — the average job length; actual durations are drawn around it from a log-normal distribution.

• Duration spread (σ log) — the standard deviation of the log of duration; 0 means every job runs exactly the mean length.

• Job size min and Job size max (% of IT capacity) — each job's power draw is drawn uniformly between these two.

Data-center daily power curve

The Daily power curve card sets the scheduled IT utilisation as a percentage of IT capacity across the 24 hours, with Weekday IT utilization (%) and Weekend IT utilization (%) as two side-by-side 24-bar editors and a 7-day preview below. A data centre runs 24/7, so Saturday and Sunday take the weekend shape without the closed-day tint the Manual card uses.

Electric-vehicle load

An Electric vehicle source adds a vehicle that is co-simulated with the PV system: charged from surplus solar or the grid on a plug-in schedule, and — when it lends power back — discharged to cover the house. Because it participates in dispatch rather than being a fixed load, an EV source has no monthly grid and no daily curve. Its card, EV charging parameters, is written as a sentence, a picture and a verdict. The battery side of the dispatch it takes part in is covered in Storage, EV & Specialized Systems.

The session, stated as a sentence

The top of the card reads like a description of the car's day, with every highlighted word an actual control:

My Tesla Model 3 (LR) gets home at 18:00 and leaves again at 07:00.
By then it needs 10 kWh this session, charged on sunshine only.

• The vehicle token is a Model dropdown of common cars that pre-fills battery capacity, charger power and Wh/km; it also reseeds the arriving charge to half the new pack. While Custom is selected the words become a text field where you name the car — that name is the source's label, so it titles the tab too.

• The two times are 15-minute time pickers. The departure may cross midnight; an overnight 18:00–07:00 stay is the default.

• The need is a number whose unit is the mode selector next to it. Changing between kWh and % converts the value rather than reinterpreting it, so “30 kWh at departure” becomes 60 % on a 50 kWh pack.

• The strategy token is a single choice covering both solar/tariff charging and whether the car lends power back to the house.

In the km of driving mode a second line appears — It uses 175 Wh/km — ≈ 7.0 kWh/day — where the WLTP consumption converts the distance into energy and the derived figure updates live.

Two optional extras sit beneath: Weekends are different arms a separate weekend plug-in and unplug pair (09:00 and 18:00 when first switched on), and, in the km/day mode only, It also drives a different distance at weekends arms a separate weekend distance (60 km when first switched on). Both are all-or-nothing on purpose: a lone half of a weekend window is not something the engine can read.

The charge picture

Under the sentence is a drawing of the house and its roof, the grid, the wallbox and the car, with the pack shown as one bar carrying all three energy numbers: the charge it arrives with, the slice this session adds, and the slice it cannot reach. The arrows say where the kWh come from — the roof, the grid, or back out to the house when the strategy lends power back.

The picture is also a control: drag the round knob to set the charge the car arrives with, drag the flag to set the charge wanted at departure, and press the wallbox to step the charger through the common AC sizes (3.7, 7.4, 11 and 22 kW). Dragging the flag also moves the need mode to kWh in the pack by departure, because that is what the flag states.

Will it work?

Below the picture the card answers one question it can settle without running anything — whether the plug-in window is long enough for the charger to deliver what you asked for:

The numbers behind it

A collapsed The numbers behind it panel holds the three specs the sentence implies — EV battery (kWh), Charger (kW), Initial charge (kWh) — plus Consumption (Wh/km) in the modes where it is not already in the sentence. Picking Custom in the model list opens the panel, because those three numbers are exactly what “custom” means. Editing any of them returns the model selector to Custom.

A closing note states the two rules the engine applies whatever you type: the arriving charge is held at or above 20 % of the pack, and the charge leg keeps 92 % of what the wallbox delivers.

Consumption rates and grid pricing

The prices that turn kWh into euros live on the Project tab (/project), on the CONSUMPTION RATES and GRID PRICING cards. They are documented in full in The project's consumption-rate and grid-pricing cards; this section covers only the part that reaches back into this tab. Both cards start with a source selector and, under manual entry, a Granularity dropdown that shows only the fields relevant to the chosen scheme. Hidden values are kept, not discarded, but a hidden price is not billed: on GRID PRICING the level decides what is charged. One exception: until the From an hourly CSV source has a grid loaded, or Tempo (EDF) its prices filled in, the run falls back to the typed rates the CONSUMPTION RATES card hides. Two picks on CONSUMPTION RATES do rewrite what you entered, as the table below says: Flat rate and the From an hourly CSV source fold this tab's off-peak column into the visible one, and Peak / Off-peak copies its single schedule over the summer one.

The rate fields are entered in €/kWh and follow the scheme: Flat rate alone; Peak hours and Off-peak hours; or, in the seasonal scheme, Winter Peak Hours, Winter Off-Peak Hours, Summer Peak Hours and Summer Off-Peak Hours. The card's Rate source fills them all at once instead: From the catalogue, a dropdown of the rates you have favourited in The Component Catalogue, From a PDF bill, the bill importer described above, or From an hourly CSV, an 8760-value hourly price curve loaded from a file in place of the four rates — like Flat rate, it collapses the monthly grid to one column and folds the off-peak figures into it. Below the rates, in the two peak/off-peak schemes, vertical timelines define the peak-hour windows: drag a knob to retime a window, hover a printed time to type it exactly, and use the + / × buttons on each season's header to add a window or drop the last one (up to three per season).

GRID PRICING opens on a Source of its own — Manual entry, or From the catalogue, a dropdown of the grid-only tariffs you have favourited, which fills the rows in one pick. An Injection cap row sits on the same card in every mode: it summarises the current export limit and Edit schedule opens a 12 × 24 grid of caps in kW, one cell per month and hour, with Apply to all cells and Clear all shortcuts. A cell of -1 means no cap; the engine applies the cap per 5-minute slot and curtails the energy above it.

The production-versus-consumption graph

The Production vs Consumption card at the top right of the Main tab draws the two curves on the same axes, at the resolution the engine caches them: production filled in orange behind, consumption in teal in front, with dotted separators and a date label per day. A muted peak … kW readout gives the vertical scale. The series come from the engine, computed from the project's embedded weather and consumption payloads — so the card fills in as soon as those exist, without waiting for a full simulation.

Its control bar carries:

• a Week / Day span switch. Week is where it opens;

• ◂ and ▸ buttons that step by one week or one day, wrapping round at the ends of the available data, and a date field (Week of or Day) to jump straight to a date;

• Refresh, which re-asks the engine for the current window;

• Optimize consumption, a toggle that turns the graph into the comparator described below.

Switching span keeps the date anchor, so Day lands inside the week you were looking at. The graph reads the committed project, so edits on this tab's own cards show only once you have left the tab; a committed change clears the graph rather than re-querying on every keystroke — press Refresh when you want the new answer. If there is nothing to draw the card says why, for example because the project carries no consumption series yet.

Comparing day shapes

Pressing Optimize consumption overlays two more curves on the same window: an Average — the typical day for a kind of site, drawn grey and dashed because it is a statistical reference rather than a scenario — and an Optimal — a reshape of your own load at constant daily energy, moved to catch more sun or a cheaper hour. The Real measured curve and PV production stay. Four chips switch each series on and off; Real is offered only where the window actually carries a measurement, and it breaks across unmeasured stretches rather than drawing a site that consumed nothing.

Two pickers frame the comparison:

• Average from — which typical day to compare against: any of the six shipped profiles (shown as Office / commercial — typical day and so on), or This site — measured average, offered once the window holds a measurement. It opens on the office profile.

• Normalize — Native totals leaves each curve at its own daily energy, answering “was this day heavier than usual?”; Same daily total (the default) rescales the average to the measured day's energy so only the shape is left to compare, and states the factor it applied. The measured curve itself is never rescaled.

Under the plot, a Day totals (or Week totals) table has three fixed columns, Real, Average and Optimal, with a dash where a series is hidden. Its rows are Daily energy (Weekly energy over a week), Peak power, Self-consumed, Self-consumption, Coverage, Grid import, Day cost (Week cost; only once the project carries a tariff) and Energy moved. Under the From an hourly CSV source the cost is an estimate: each peak and off-peak band is priced at the curve's seasonal average, whereas a run bills the curve hour by hour. Whatever the System type, the cost credits exported kWh at the Feed-in tariff value, whether or not the run pays it.

The optimizer's own constraints sit on the last row, so the result stays explainable rather than magic:

• Objective — Maximize self-consumption or Minimize day cost. The cost objective is greyed out until the project has a tariff.

• Shiftable share — a slider capping the share of the day's energy the optimizer may move (0–40 %, default 15 %).

• Lock base load — on by default; freezes the night floor so only the flexible load above it moves.

• A readout on the right states what it actually moved: 4.2 kWh moved · 11.3 % of the day.

In the Day span, shaded bands behind the plot mark the off-peak hours as the engine's own tariff mask sees them — under Flat rate and the hourly CSV too, where they follow the peak-hour windows the rate card hides — and a note appears when the window is short of measurements or falls on a daylight-saving transition.

Field reference

Source tab strip

Monthly consumption card (Main)

Daily power curve card (Main)

Per-source header

Manual source — monthly consumption

Manual source — daily power curve

Bill import

Data-centre — parameters

Data-centre — AI training jobs

Data-centre — daily power curve

Electric vehicle

Production vs Consumption card

Day-shape comparator