Frequently asked questions

You describe a location, some panels, a battery, some appliances, a building. The simulator then runs through 8,760 hours — a full year — and works out, at every hour, what the sun gives, who gets served, what is left in the battery, and what becomes of the indoor temperature.

Its real use is not the absolute figure, it is the comparison. “Are 4 kWp enough, or do I need 6?”, “what do I gain by doubling the battery?”, “what if I switch off the electric heater in the living room?” — each variant is a few clicks away and is read off the same chart.

It is not a quote, not a regulatory study, and not a promise of output. It is a tool for a first rough pass, honest about its approximations — they are all listed under “What the simulator cannot do”.

• The location, picked on a map or searched by address. The PVGIS weather year — irradiance, temperature, wind — is downloaded straight away, and the altitude filled in on its own.
• The solar arrays: peak power, azimuth, tilt, charge-controller limit, shading loss, snow-cover loss. As many as you have roof planes.
• The battery: capacity, everyday range and extended range, look-ahead horizon, weather safety margin.
• The generator or grid: power, cost per kilowatt-hour, and what it feeds — the essentials only, or everything. And the surplus sale, with its feed-in price.
• The losses: modules and wiring, inverter, battery round-trip efficiency, standby draw.
• The appliances: power, time slots, days of the week, whether they are essential, whether they run while nobody is there, and whether their heat stays inside the building.
• The occupancy calendar: the days of the year when somebody is there.
• The hot-water heat pump: the litres to bring to 60 °C on each occupied day, its four COPs, and its rank — essential or ordinary.
• The envelope, surface by surface: opaque and glazed, each with its area and its U-value; glazing also has an orientation, a solar transmittance and a shading factor.
• The general thermics of the building: ventilation and its heat-recovery rate, thermal mass, and its three temperatures — occupied set point, away set point, forced venting against overheating.
• Heating — electric radiator or air-to-water heat pump —: its power, and for the heat pump its four EN 14511 COPs.
• The thermal battery: heating appliance, volume, insulation, power, maximum temperature, radiator, months in service, location — indoors or out.
• The external heating backup — stove, boiler, heater on another supply —: its heat output and the cost of its kilowatt-hour of heat.

Every item has a switch: turned off, it keeps its settings and the calculation ignores it. That is how you compare two variants without retyping anything.

The chart stacks several panels on one shared time axis and zooms to whichever period you like; the table of figures below the panels recomputes over that same period, while the summary boxes at the top sum up the year. The month-by-month table, folded away under the chart, gives the overall picture.

Two downloads: the PDF report, which lists every setting, the summary, the monthly table and the chart for the whole year — then those for the period on screen, if it is not the year —; and the JSON export, your backup, which can be imported back unchanged.

No monthly average ever enters the calculation: everything is computed hour by hour, and only aggregated for display.

On a grid-connected system, the surplus goes out to the grid and the shortfall comes back from it: sizing is mostly a financial question. Off-grid — a cabin, a mountain hut, an isolated house — there is nobody at the other end of the wire: what is missing is really missing, and what is produced in excess is lost.

Hence the three notions the simulator keeps handling: the potential (what the panels could give), the output (what found a taker) and the lost potential (the gap, for want of battery room or of demand at the right moment).

A grid connection can still be described, but in two bounded roles: the “Generator or grid” setting — a source of last resort, served once the sun and the battery are spent and billed per kilowatt-hour — and the surplus sale, which sells what would otherwise be lost potential. What the simulator cannot represent is the ordinary grid-connected house, where the grid is the default source: here it never comes first, never charges the battery, and no tariff bends the physics.

The four chapters of the page follow the path the energy takes, and that is the right order to fill them in:

• Location and weather — the point on the map. The weather year downloads straight away, without asking anything.
• Electrical system — at least one solar array (panels sharing one orientation), then the battery and the losses.
• Use — the appliances, with their timetables, and the days someone is there.
• Building and heating — the surfaces, the windows, the heating (electric radiator or heat pump), the thermal battery. Optional: without heating the simulation is still valid.

Nothing is required beyond the location and one solar array. The message shown in place of the results always says what is missing.

Nothing is guessed from your country or your address: what decides is the header your browser sends — the one carrying its language preferences. A browser set to French gives a site in French; set to German, to Japanese, or to nothing at all, it gives English.

The language switch, at the top right of every page, overrides all of that: your choice is kept in a cookie and follows you from visit to visit, even from a browser set otherwise. The page reloads in the language you chose, losing nothing.

The translation is complete: the settings, the help bubbles, this FAQ, the error messages, the results and the PDF report — which comes out in the language of the page you export it from. The numbers, however, are written the same way in both languages: “3 539 kWh”, “60,5 °C”. This is deliberate — the same report read in either language must show the same figures.

What you write yourself — a simulation's name, an appliance's name, your description — is never translated: those are your words. The example simulations, shared by every visitor, are for that reason written in English only; change one and it becomes your copy, which you name as you please.

On your first visit the site sets an anonymous session cookie: a random number that says nothing about you. It names the folder where your simulations are kept on the server.

One consequence to keep in mind: your simulations belong to this browser, on this device. Another computer, another browser, or clearing your cookies, and they are gone for you. To take them with you, export them as JSON.

The administration area does ask for a password: it is reserved for the author of the site.

Two examples ship with the site. The first describes a small high-mountain hut at 3,000 m above the Arolla glaciers, guarded over the Christmas holidays, in February, in spring and in summer, closed in between: a south wall covered in modules, which the snow on the ground makes the winner over the roof eight months out of twelve; the shadow of the ridge at Christmas, where the generator supplies four fifths of the electricity; nearly a third of the potential lost while the hut is closed; a thermostatic gas heater keeping the core of the hut above freezing all winter, and a thermal battery sparing it one kilowatt-hour in seven. The second describes an off-grid alpine house at 2,000 m in the Queyras, occupied at weekends and during the holidays, and exercises every setting of the simulator except selling surplus — there is no grid to feed: three solar arrays — a south-facing roof, a vertical façade, and a west extension still at the planning stage —, a battery and its reserve, a heat pump for heating, a hot-water heat pump, a thermal battery, a stove as external backup, a small generator for the essentials, the building envelope, its windows, its appliances and an occupancy calendar.

They are there to be opened and tinkered with: several of their items — the electric convector, the east gable array and the bread oven of the hut; the planned array and the old resistive water heater of the house — are in fact switched off rather than deleted, ready to be turned back on to see what they change.

They show up at the top of your list, the hut then the house, labelled Example, and they do not count against your simulation quota. They stay at the top even when you create newer simulations: they are the way in, and must not slip out of sight.

You can tinker with them without worry: on your first change the simulator makes a copy of your own, and that copy is what you are editing. Nobody else sees your changes, and the original example does not move.

The “Reset” button on your copy puts the original example back, untouched and once more in its place at the top of the list — it is not called “Delete”, because it restores instead of erasing. The originals themselves cannot be deleted: only the site administrator can replace or edit them, and their version is then what everyone without a copy sees.

Deleting an appliance to see “what it would look like without” forces you to type it back in afterwards. The switch avoids that: the item stays on the sheet, greyed out, and the totals only count the active ones.

To compare two complete systems, duplicate the simulation from the home page and edit the copy: the two sheets live side by side, each with its own PDF report.

The occupancy calendar has a switch too, with a meaning of its own: turned off, it does not mean “nobody is ever there” but “somebody is always there”. Occupancy is then assumed to be continuous all year.

Latitude sets how high the sun stands at every hour of the year, longitude sets the time of solar noon, and the pair of them is what finds the weather year for the site. Latitude also decides the start of the simulated year: 1 August in the northern hemisphere, 1 January in the southern hemisphere — so that winter falls in the middle of the simulation.

The first time it opens, if you allow it, the map frames your position and already drops the marker there, place name suggested: all that is left is to adjust. An address can also be looked up by name — suggestions appear on their own, a second after you stop typing — and the marker can then be dragged on the map. There is no point aiming to the metre: the weather grid is five kilometres wide. Aiming at the right valley, on the other hand, changes everything in the mountains.

The place name is optional and follows the marker: each time the point moves, the map suggests the municipality, hamlet or locality of the new spot as OpenStreetMap knows it — even over a name already typed or saved, so that a marker dragged from one valley to another does not keep the previous name. The field stays yours: correct it after placing the point, and it will hold as long as the point does not move. It is a convenience only: the name is there to help you find the simulation in your list and at the head of the report, never for the calculation, which only looks at the coordinates.

The altitude is not typed in: the weather service returns it for the exact point, along with the year of data. In the same breath the simulator also works out the site's temperature correction, by comparing that typical year with the long-term normals for the point brought down to its altitude.

As soon as the coordinates are saved, the server downloads the weather year for the site and caches it: once per place, not once per simulation.

A typical year is not a real year: its twelve months are borrowed from different years, picked for being representative. It therefore gives a plausible “average” year, without the extremes of any one year — neither the catastrophic December nor the exceptional summer.

The annual output figure is therefore to be read as the order of magnitude of an ordinary year, not as a guarantee. A dull year will produce less.

A measured example in an Alpine valley at about 900 m: PVGIS gives a January averaging −8.3 °C, while the normals for the same point, at its altitude, sit around −2 °C. The grid cell covers the whole massif, summits included, and its temperature is the average of all that. This is not a cold year that happened to be drawn: that January is colder than the coldest of the nineteen real Januaries at the same point.

Six degrees too cold in January, seven in December: that is a third too much heating over the winter, and with it load shedding and battery cycles that would not exist. The site correction lifts the weather year by that gap — for that site, +3.7 °C on average, but from +0.5 to +7.4 °C depending on the month.

The simulator works it out itself. When it fetches the weather year, it asks Open-Meteo for thirty-year monthly averages at the same point, brought down to its altitude, and compares them month by month with the PVGIS typical year. This correction is not a setting: it is the simulation's baseline temperature, the best the tool can produce. Leaving 0 would be just as arbitrary a choice, and far more wrong in the mountains.

The gap is monthly — so much to add in January, so much in October, to recover the site's normals at its altitude —, and so is the correction: twelve gaps, January to December, applied hour by hour with a smooth passage from one to the next — interpolated between mid-months, with no step on the first day, the values placed at mid-month being adjusted so that the average of each month recovers exactly the measured gap. In the valley that was measured: +6.2 °C in January, +7.4 in December, +0.5 in October. The single figure the site card shows — “+3.7 °C on average, from +0.5 °C to +7.4 °C depending on the month” — is the average of those twelve gaps weighted by how much each month matters to the heating demand, and therefore pulled towards the cold months; that number, and it alone, is what the splitting of an old setting uses. A constant in its place left December 3.7 °C too cold and October 3.2 °C too mild.

This is not a second measurement: Open-Meteo rests on the same ERA5 reanalysis as PVGIS. What it adds is the descent to the real altitude, which PVGIS does not do — precisely what was missing.

The “additional correction” field adds to that baseline, and is only for those who can refine it further: a weather station next door, a valley floor prone to inversions, years of readings in the garden. Otherwise 0 — there is nothing to make up for. To cancel the baseline entirely, enter its opposite, but that is rarely a good idea.

Simulations saved before this calculation existed keep exactly the result they had: their baseline is empty, and their old setting stands for everything. On the first weather fetch, the correction they carried is split between the measured baseline and the fine-tuning so that the total does not move — a hand-set +5.8 becomes +3.7 of baseline and +2.1 of fine-tuning. A setting still at zero is not split: it is the default, not an intended total — the baseline applies and the fine-tuning stays at 0.

A simulation whose normals were measured before the correction became monthly only has the average: it applies as a constant, all year round — the site card then reads “+3.7 °C all year round” —, until the next weather fetch, which brings back the twelve gaps. With no measurement at all, the card reads “not measured yet”.

If Open-Meteo does not answer, the baseline stays empty: the site and its weather year are saved all the same, and the measurement is tried again on the next fetch.

The correction touches the temperature only: neither the irradiance nor the wind.

There is nothing to set. When the simulator fetches the site's temperature normals, the same request brings back thirty years of snow cover (ERA5 reanalysis, 1995-2024): a month is kept as snowy if more than half its days carry at least two centimetres of snow and if its temperature normal — which is brought down to the site's altitude — does not exceed 2 °C. The months kept appear on the site card, and the “snow on the ground” band of the chart — like the uncovered-demand band — says when they apply.

The second condition corrects a flaw in the measurement: Open-Meteo brings the temperature down to the point's altitude, but not the snow, which stays that of the grid cell — about ten kilometres wide, summits included. In an Alpine valley at 900 m, the cell counted the ground white on 98 % of April days and 63 % of May days, while the village itself was green: without this filter, those months would have reflected a sun that did not exist. With it, January, February and December remain — and, for a village at 2,000 m whose normals only climb back above 2 °C in May, November to April. The list is recomputed on every weather fetch; a simulation whose weather is already saved keeps its own until then.

In those months the ground sends back about 65 % of the sunlight instead of 20 %: the simulator applies that reflectivity to the radiation received — by the solar arrays and by the windows alike, since the glare also comes in through the glazing, and that is free heating. The effect depends mostly on tilt: next to nothing on a 30° roof, over 10 % of winter on a south-facing glazed façade, up to a quarter or a third of winter output on a vertical plane. The same months take off each array's snow-cover loss — see What is the snow-cover loss? —, and it is precisely the steep plane that gains on both counts: snow reflects well onto it and does not stay on it.

One limit worth knowing. The temperature filter rules out the shoulder months the cell sees white and the village does not; it does not make the measurement local for all that — a cold month where the valley floor is only half snow-covered still counts as snowy. And those months drive both effects at once: no reflection and no snow-cover loss outside them, both throughout them. A site with no snowy month therefore keeps its arrays' snow-cover loss exactly as entered, without ever applying it.

The weather data is stamped in universal time; the simulator shifts it by the site's time zone so that “8 am” means 8 am where you are.

Since the typical year matches no real year, it has no daylight-saving switchover dates: the simulator therefore applies winter time across all twelve months. In summer, being an hour off your watch is normal and has no effect on the totals.

The time zone fills in by itself, from the marker on the map — including when the position comes from geolocation or an address search — and it follows the marker until you correct it yourself: your value then stands. The rare half-hour zones (India, Newfoundland) are rounded to the whole hour.

Two panels facing different ways do not get the same sun at the same time: they make two arrays. Conversely, twenty panels on the same roof plane make a single array, described by its total power.

Splitting the arrays genuinely helps off-grid: one array east and one west produce less in total than a due-south one, but they spread the output across the day — so less of it is lost when the battery is already full at noon.

The summary gives the potential and the output array by array: that is where you see what each one really brings in. An array's output is its share of the hour's output, pro rata to its potential — the controller throttles every array together, and an array that made 60 % of the noon potential gets 60 % of what was produced at noon.

Multiply the number of panels by the peak power of one panel, printed on its data sheet: that is the only number to enter. Neither the area, nor the efficiency, nor the brand comes into it.

In real conditions you are almost always below it: the sun rarely exceeds 1,000 W/m² in the plane of the panels, and a hot cell gives less. A tilted array reaches its peak power only a few hours a year.

The interface spells the orientation out — “south-west”, “east” — as you adjust it: no need to count degrees in your head.

A useful rule off-grid: sizing is decided in December — June in the southern hemisphere —, the leanest month. A steep tilt (60° to 80°, or even the vertical of a façade) catches the low winter sun and the glare off the snow better, at the cost of a summer where potential would be lost anyway for want of a taker.

The effect is measured directly: change the tilt, save, and look at December on the chart.

Oversizing the panels relative to the controller is common and often deliberate: the peak lasts only a few hours a year, and the extra panels pay off in the morning, in the evening and in winter.

Clipping is counted peaks included. In an hour of broken sky, the power spikes well above its average — the gaps between clouds focus the sunlight — and a controller close to its limit clips those peaks even when the hour's average stays below. PVGIS readings are already satellite snapshots, not hourly averages: one reading an hour, 8,760 over the year, estimate the instantaneous clipping without bias, and the peaks' share is mostly in the data itself. What the simulator adds is modest: the spread that remains between the satellite pixel — five kilometres across — and the point on the roof, wider under a cumulus sky than under a stable one, clear or overcast, from each hour's diffuse share. It is a modelled estimate — the only figure in the engine not derived from physics or a measurement —, calibrated on the studies comparing minute-level to hourly time steps.

Order of magnitude measured on 5 kWp facing south, tilted at 19°, in an Alpine valley, peaks included: clipping at 4 kW costs 0.8 % of the year; at 3 kW, 7.3 %; at 2 kW, 24 %. Close to the peak power, the spikes count: a calculation on hourly averages alone would see only half the figure at 4 kW (0.4 %) — the gap fades as soon as the limit bites hard, 6.7 % and 23.6 % on averages alone.

The limit is switched on by a tick box, and the power you typed stays there when you untick it: comparing “with and without” takes two clicks, with no figure to remember or retype.

Clipping is not lost potential — that energy never existed. The summary only shows what matters about it: the producible potential clipped by the MPPT, what would genuinely have found a taker had the controller been bigger. That is the numeric answer to “is it worth replacing it?”.

The simulator cannot describe a shading mask — that would take the shape and position of whatever casts the shadow, hour by hour. But ignoring shading would be worse: it is often the largest loss on a real installation, far ahead of the choice of modules. So it is boiled down to one constant fraction, specific to each array.

Specific to each array: one roof plane may be clear while the other spends the afternoon under a fir tree. Along with the snow-cover loss, these are the only two settings of their kind that do not apply to the whole system.

• 0 to 3 % — perfectly clear site, nothing above the near horizon.
• 5 to 15 % — the ordinary case: a tree, a chimney, a neighbouring house biting into early morning or late afternoon. That is the range the suggested 10 % comes from.
• 20 to 40 % — a deep valley, a slope that cuts off the winter sun, tall vegetation close by.

It applies to the potential as much as to the output — shade does not spare the modules just because the battery is empty — and before the controller clips, as in reality. It is not the same thing as the module losses, which apply to the whole system: the two add up.

This is deliberately crude. Real shading is seasonal and only bites at certain hours; a single value cannot say that. It lowers the whole day without changing its shape — take it as an annual average, not as a shading study. For winter, the snow-cover loss separately says what snow lying on the modules costs, and over the snowy months alone.

It is the winter counterpart of the shading loss: the same shape of setting — a constant fraction, specific to each array — but taken off in the snowy months only, instead of all year. The simulator cannot tell when the layer holds and when it slides off: that would take hourly snowfall, the tilt, the state of the glass surface and the temperature of the modules, which thaw from underneath as soon as they produce a little.

It is the site's months of snow on the ground that trigger the loss — the same ones that make the white ground reflect, measured from the normals (see Is snow on the ground taken into account?). Outside them the setting takes nothing off; with no snowy month at all it never takes anything off, and the form says so. The two effects of snow therefore live in the same month without contradiction: the ground sends sunlight up onto the modules, the layer lying on top blinds them.

• 0 % — a vertical plane or nearly so: snow does not stay on it. That is the great advantage of a façade in the mountains, along with December's low sun.
• 5 to 15 % — a proper roof pitch, 30° and up, smooth glass, well exposed: the layer slides off a few days after each fall. That is the range the suggested 10 % comes from.
• 20 to 40 % — a shallow plane, under 25°, or framed modules whose frame holds the layer at the bottom; a very snowy site where falls follow one another.

Like shading, it applies to the potential as much as to the output, and before the controller clips. It is specific to each array: on the same building, the roof loses and the vertical wall loses nothing — which is exactly what both examples show, the Queyras house and the hut above Arolla alike.

It is crude in the same way as shading, and a little more so: the real loss is concentrated in the few days after each fall, and nil in between. A single value does not say that — it lowers the snowy months uniformly. And the trigger is snow on the ground of the grid cell, filtered by temperature: it says the winter is snowy, not when the falls happened.

The gross capacity is the one the manufacturer states (5 kWh, say). It is the only place in the simulator where kilowatt-hours are typed in: everywhere else it is watts and watt-hours.

The usable capacity follows from it: what can really be drawn between the limits you set. A battery is never emptied to zero without damage.

The battery has its own switch, like the heating or the thermal battery: turned off, it keeps all its settings but the simulation runs with no storage — anything not consumed at that very instant becomes lost potential again. That is how you measure what it brings.

A lithium battery wears out mostly at the extremes: sitting at 100 % for a long time or dropping to 5 % costs cycles. Working between 20 and 80 % spares it.

But sticking to it in December would mean letting the heating go short while the battery still has something left. So the simulator opens the extended range in the one case where it helps: stress — the total demand of the coming days, heating included — its thermostat's demand, free heat deducted, see the reserve —, exceeds what the everyday range can cover: even full to its everyday ceiling, the battery would not be enough. The extended range then opens both ways: charging up to the total demand, discharging for every appliance down to the essentials' reserve. Outside stress, the everyday range holds.

The summary counts the hours spent under stress and outside the everyday range: a good sign of a system cut too fine. The battery panel draws both limits of the range as dotted grey lines — you can see at a glance when the charge leaves it.

Three priorities, in order: as little shortfall as possible on the essential appliances; use as much of the solar potential as possible; serve the essentials, then the other appliances, then the heating. The reserve is the tool of the first.

A fixed threshold — “cut the heating below 40 %” — locks energy away in every season, including the evening before a bright day when it will be of no use. The reserve does the same job as tightly as possible: it knows what the essentials will consume and what the sun will give over the chosen horizon.

For the heating, what the reserve and stress anticipate is the thermostat's demand as it would be if the appliance were always served — sun through the windows, heat from the appliances, external backup and forced venting included —, and not the building's raw theoretical demand, heat loss against the set point. The difference is large: on a mountain-pasture house, the raw demand announced 3,800 kWh of heating to keep ahead where the thermostat would ask for under 600. Counting the raw figure opened stress one hour in two, July included, and had the everyday range you set ignored; with the real demand, stress no longer opens from May to July, and the everyday range holds outside genuine cold spells.

In practice: the reserve rises the day before a dull spell and falls back as soon as a sunny day is in sight. In summer it is nil. It is read hour by hour on the battery panel, as a dotted line labelled “Reserve floor for essential appliances”: ordinary appliances and the heating do not go below that line, the essentials do.

The order of service never changes: essentials first, then the ordinary appliances in list order, then the heating, then charging the battery, then — last of all — the heating of the thermal battery. Serving comes before storing: whatever the reserve does not require to be kept goes to the appliances and then to the heating.

The simulator knows the year in advance: left unchecked, it would know exactly how much to keep, which no real controller does. The weather safety margin lowers the expected sun inside the reserve calculation: the reserve is therefore the one you would need if the sky gave less than promised.

It never touches the output of the current hour: it only makes the sharing-out cautious. At 0 %, the forecast is perfect; at 100 %, the look-ahead counts on no sun at all.

30 % by default, because the look-ahead peers two or three days out, and at that range a sunshine forecast is commonly off by about that third — more so in the mountains, where the sky changes from one valley to the next. A controller keeping less would be betting its reserve on the weather. Simulations set before this change keep the margin they had.

What the look-ahead counts for the heating is its thermostat's demand as it would be if the appliance were always served — sun through the windows, heat from the appliances, external backup and forced venting included —, and not the building's raw theoretical demand. See “What is the reserve” for what that changes.

With a look-ahead of 0 days there is no reserve at all: ordinary appliances and the heating go down to the everyday floor, the essentials have the band below it, and nothing is set aside for tomorrow.

The “Generator or grid” setting stands for either a generator or a grid connection: to the calculation they are one and the same backup source, served as a last resort and billed per kWh. Three settings: the power in watts — the most it delivers, and it will never fill more than that; 3,000 W by default, the size of the usual portable set —, the cost per kilowatt-hour produced, fuel and maintenance included — or the grid tariff —, and what it feeds.

• Essential loads only — the most common use: you wheel the set out for an hour to save a freezer, then put it away. This is the default.
• Every load, heating included — it additionally serves the ordinary appliances and then the heating, in the same order as the rest of the system: the generator changes the energy available, never the priorities.

The generator never charges the battery, and never feeds the heating of the thermal battery. The first because running an engine to fill a store you will then empty would pay the losses twice; the second because it only eats surplus — what would otherwise be lost — and a generator produces none: it gives exactly what is asked of it.

Its current does not pass through the converter: a generator produces AC that is usable directly, where the sun and the battery go through the inverter. Its kilowatt-hours are therefore neither in the potential nor in the output, which speak only of solar, and what it served is not counted as unmet.

The cost per kWh has no influence whatsoever on the simulation: it only puts a figure, in the results table and in the report, on what the generator will have cost over the period. One franc — one euro — per kilowatt-hour is the order of magnitude of a small petrol set: about ten times the grid tariff, and that is precisely what justifies keeping it for the essentials.

When its power is not enough, it serves the essentials first, then whatever fits entirely in what is left: an ordinary appliance is all or nothing, as everywhere else. An 800 W set that has already given 500 W to the essentials will not start a 1,500 W washing machine; the heating, which modulates, would take the remaining 300 W.

Do not confuse it with the external heating backup: they are two distinct things. The generator supplies electricity to the appliances — and to the radiator, if set to “everything” — in the system's order of service. The external backup supplies heat, last of all, when the radiator and the thermal battery were not enough: a stove, a boiler, a heater on another supply. Both are priced per kWh, each at its own rate.

Like the solar arrays, the battery or the heating, the generator has a switch: turned off, it keeps all its settings and the calculation ignores it. That is the intended way to measure what it brings — save it, switch it off, compare the two summaries.

Set to everything, it often makes the demand and the solar output go down, which is surprising. It is not a mistake: the building no longer cools down, so the thermostat has no backlog to catch up and asks for less; and because it asks for less, part of the sun no longer finds a taker and becomes lost potential again. The generator does not make the panels produce more — it steps in when they cannot.

Under the chart, a band shows its running hours: it only appears if a generator is declared. The results table gives it a section below the battery's — energy delivered, running hours, cost. The PDF report repeats both exactly.

Like the battery, the sale does not exist until it has been filled in — most off-grid systems have no feed-in contract. One setting: the resale price per kilowatt-hour, 0.011 .- suggested, the order of magnitude of a bottom-end feed-in tariff. Once saved, the sale is on — you do not fill in a feed-in price in order not to sell.

What is sold is exactly the surplus: the potential that neither the appliances, nor the battery, nor the thermal battery took — what, without a contract, would be lost potential. MPPT clipping, never produced, is never sold.

Selling changes nothing in the physics: not one more watt for the appliances, the battery or the heating. It switches the vocabulary — output shows as self-consumed, lost potential as exported — and puts a revenue against those kilowatt-hours, that is all.

The price only puts figures on it: a Sale to the grid box at the head of the year's summary gives the share of the potential exported, the matching energy out of the total potential, then the revenue and the tariff; the results table has its section of the same name, the monthly table gains a revenue column, the “Exported” panel's tooltip prices the hour under the cursor, and the PDF report repeats all of it exactly.

Like everything else, the sale has a switch: turned off, it keeps its price and the calculation ignores it — the results speak of output and lost potential again. That is the intended way to compare the two readings.

• Modules and wiring — DC wiring, mismatch between panels, soiling, manufacturing tolerance, ageing. 8 % is a reasonable value.
• Converter — to deliver 100 Wh to the appliances, a little more has to be drawn from the source. 5 % by default, a recent inverter-charger spending the year at partial load.
• Battery — the value is a round-trip efficiency, split half on charging, half on discharging. 5 % by default, the round trip of today's lithium iron phosphate; allow more like 10 % for lead-acid or an older lithium pack.
• Standby draw — what the controller, the converter and the electronics pull permanently, whether the appliances are on or off; 20 W by default, a 4 to 5 kVA inverter-charger. It counts as an essential: left unpowered, it goes into the essential shortfall, after the appliances.

Twenty watts of standby draw look negligible: over 8,760 hours they add up to 175 kWh, often more than any single appliance on the list. It is the first thing to look at on a small system.

Do not put the PVGIS calculator's 14 % of “system losses” here: that flat figure covers the converter and part of the storage, which have their own items. Counting them twice would skew the sizing.

For an appliance running continuously — a fridge, a router —, take its average draw rather than its peak power: a 150 W fridge running a third of the time is well described as 50 W over 24 hours.

For an occasional appliance — a washing machine —, give its real power over the slot where it runs, and the days concerned.

Several slots are allowed in the same day (6–9 am and 6–11 pm, say), as long as they do not overlap. An ordinary appliance is served all or nothing: it is never half fed.

The appliance draws its power for the whole slot, on each ticked day: 120 W from 6 pm to midnight makes 720 Wh per day concerned. The total under the rows adds up the slot hours, so you can check at a glance what you have just described.

A slot whose end comes before its start — 10 pm to 6 am — is split at midnight: it applies in two pieces, 10 pm–midnight and midnight–6 am, on the same ticked day. The ticked day is what rules, not the night straddling two dates.

The ticked days combine with the occupancy calendar: on a ticked day when nobody is there, only the appliances marked “standby” run. The ticked days say when the appliance *would* run; occupancy says whether someone is there for it.

No day ticked is not a valid setting: an appliance that never runs is switched off with its toggle, which keeps all its settings for comparison.

The essentials are what the reserve protects: the simulator permanently keeps enough to feed them over the coming days. An ordinary appliance only draws above that reserve.

What the essentials go without has its own indicator, the shortfall: the real shortage, the one the system tries first to bring to zero. A non-zero essential shortfall in midwinter — December, or June in the southern hemisphere — means the sizing does not hold.

Marking everything “essential” amounts to prioritising nothing: the reserve becomes huge, the heating gets nothing left, and the comparison stops meaning much.

Typical examples: the freezer, the alarm, the circulation pump, the router. Everything else stops when the place is empty.

Ticking “standby” therefore forces “essential”: what must run while nobody is watching is a priority all the more. The interface does it for you.

Do not confuse standby (an occupancy state, decided by the calendar) with load shedding (the energy ran short). The two are independent and can happen together.

It is the setting that changes the results most on a holiday home: heating a chalet to 19 °C all year or for six weeks only are two entirely different things.

The calendar has a switch of its own, with a meaning worth remembering: turned off, it does not mean “nobody ever” but “somebody always”. Occupancy is then assumed continuous, and the days you ticked wait, doing nothing, until you turn it back on — they stay editable in the meantime, like the settings of any switched-off item.

Unlike the other loads, you enter neither a power nor time slots: the day's heat follows from the litres — from 10 °C, the mains cold water approximated constant, to 60 °C, the usual sanitary set point, i.e. 58 Wh per litre —, and each hour's electricity is that heat, spread over the day, divided by the COP of the moment. Reckon 40 to 60 litres per person per day.

The COP comes from the four EN 14511 points of the data sheet, 60 °C water column — markedly lower than a heating heat pump's, the temperature gap to climb is larger. The values suggested by default (about 1.8 / 2.4 / 2.9 / 3.3) are those of a good current heat-pump water heater. Between the points, the same interpolation as the heating heat pump, from the hour's outdoor temperature: cold days cost more.

Essential or ordinary, your choice: essential, it is served with priority and the battery keeps its reserve for it; ordinary, it goes last in the appliance list and can be shed. The results line “of which hot-water heat pump” gives the electricity served and its share of its demand: below 100 %, the appliance was shed by that much. Either way it never runs in standby: nobody draws hot water in an empty house, and on days with nobody there the appliance sleeps.

The model's approximations: the cold water is assumed at 10 °C all year round; the preparation is spread evenly over the day — a real appliance timed to the sunny hours will do better; the COP follows the outdoor air — a water heater on extract air or in a cellar would depend on indoor air instead; and its tank's standing losses are not counted separately — pad the litres slightly to cover them.

Do not stack it with a hand-entered “water heater” load or with the thermal battery: the latter is a heat store for the building, fed by surplus only — the hot-water heat pump is a domestic hot-water demand, served like an appliance.

When the box is ticked, the power of the appliance actually served adds to the heating in warming the building. A shed appliance heats nothing.

This is no detail: on a mountain house with 2 MWh of appliances, ticking everything removes a third of the heating called for, and three hundred hours spent below the set point.

That heat is not counted twice: it is the same electricity, seen from the heat side. It is already in the consumption.

The box comes ticked for a new appliance — by far the most common case. Appliances saved before this setting existed stay unticked, so their simulation does not change on its own: the box is then yours to tick.

The heating is served last: it gets what is left once the appliances are fed, and the building is warmed by that alone. This is deliberate — a room at 17 °C is better than a freezer thawing out.

An appliance, or the heating, that the reserve will not let through is shed: its demand is counted, it is not served. The summary therefore separates the demand — everything called for, shed loads included — from what was delivered. The gap, on the essentials, is the shortfall, counted separately — that is the indicator that matters, and the hour is then marked shortfall, in red, on the state band, ahead of load shedding.

If there is a generator or grid, this is where it steps in, right at the end: what it picks up is neither shed nor unmet, since it was in fact served. An hour where the generator covers the whole shortage is therefore not marked “load shedding”.

The U-value measures the insulation: the lower, the better. Orders of magnitude: 2.0 for an old uninsulated wall, 0.5 for decent insulation, 0.15 for high-performance new build. 1.5 for double glazing, 0.8 for triple.

The sum of the areas multiplied by their U-values gives the building's conduction, in watts per degree. That is the number that decides the heating. The interface also shows the average U-value, which judges the overall insulation regardless of size.

Entering it surface by surface rather than as one total lets you see what each surface costs, and what insulating it would save: set the roof U-value to 0.15 and read December again.

An empty envelope — or one whose surfaces are all switched off — is a building that is not described: the heating, the thermal battery and the external backup are then ignored, and the interface says so. Do not forget the floor and the roof.

A glazed surface is described exactly like a solar array — area, azimuth, and its slope, called verticality here: 90° for a façade window, 0° for a flat rooflight — because it is the same solar geometry.

The transmittance (solar heat gain coefficient) is the share of the incoming energy that ends up as heat in the room: about 75 % for clear double glazing, 50 % for coated triple glazing, over 80 % for single glazing.

The shading is what a roof overhang, a balcony, a tree or the terrain intercepts before the glass, as a percentage. A single value, constant all year.

What the sun brings beyond what is needed is not lost for nothing: it is vented away, under the name “venting against overheating” — the window you open on a bright spring day.

Do not confuse a window's U-value — what it lets escape — with its transmittance — what the sun gets through. The two are independent, and triple glazing improves the first while degrading the second.

An order of magnitude for ventilation: the regulatory air change rate is around 0.5 volumes per hour. For 200 m³ of living space, that is 100 m³/h.

The recovery rate says how much of the outgoing air's heat a heat-recovery ventilation unit gives back to the fresh air. 0 % for a single-flow system, a vent or a window left ajar; 70 to 90 % for a heat-recovery unit with an exchanger — the value is on the unit's data sheet, take that rather than the advertising —; 95 % at most. The ventilation heat loss is multiplied by (1 − rate): at 75 %, 100 m³/h costs only a quarter. Ventilation stays off in standby, exchanger or not: an empty dwelling has no air to renew, and switching it off is the first thing anyone does when closing the house for the week.

Thermal mass decides how fast the house cools once the heating stops. A heavy stone house keeps its warmth for hours; a light timber chalet loses it in one. It matters a great deal off-grid: a large mass lets you take in the midday sun and give it back in the evening.

The block finally carries the building's three temperatures: the occupied set point (20 °C by default), the away set point (5 °C, just above freezing) and the forced venting (24 °C) — the threshold above which you air the place against overheating. They describe the place, not the appliance: heating and thermal battery both aim at them. Each has its own entry in this FAQ.

The heating demand is met first by what costs nothing — sun through the windows, heat from the appliances —, then by the direct heating — radiator or heat pump, fed by the system or by the generator —, then by the thermal battery's water. The external backup comes last of all: it only gives what is still missing to hold the set point, up to its rated heat output. A stove is not lit while electricity and hot water are enough.

Three settings, like the generator: the power — the most heat it can give back, 5,000 W by default, an ordinary stove —, the cost per kilowatt-hour of heat — wood, pellets, gas, oil or the grid tariff —, and the switch. Turned off, it keeps its settings and the calculation ignores it: that is the intended way to measure what it brings — save it, switch it off, compare the two summaries.

Its heat enters the calculation: the indoor temperature, the hours below set point and the direct heating demand all take it into account, as for the tank's radiator. A backup with enough output holds the set point; one that is too weak runs flat out, and what is still missing is the uncovered demand — the building then falls below the set point. That uncovered demand has its own entry in this FAQ.

What the backup gives is paid for: the heating boxes turn amber, “rescued”, as soon as it has heated — just as when the generator powers the radiator. The set point held, but thanks to heat you buy, and the solar system alone would not have been enough. A green here would be falsely reassuring.

The backup gives back heat, not electricity: its kilowatt-hours enter neither the demand, nor the shortfall, nor the load shedding — it rescues no appliance, it heats the building. It charges nothing, does not pass through the converter, and only counts once the building is described — envelope and general thermics —, like the heating and the thermal battery.

It can be read wherever the heating can: in orange on the “Heating” panel of the chart, in the “External heating backup” box of the summary — share of the demand, heat, expense, hours —, in the table of figures below the chart and in the “Backup” and “Backup cost” columns of the month-by-month table. The PDF report carries all of it.

The currency is not specified: “.-” stands for the unit of yours — euro, franc, whatever it is. Enter the price per kilowatt-hour of heat delivered, as it comes out of your bill: 617 backup kWh at 0.12 .- per kilowatt-hour make “74.04 .-”. For a stove, that is the price of the wood or pellets brought down to the useful kilowatt-hour; for a heater on the grid, the electricity tariff.

This setting has no influence whatsoever on the simulation: the physics, the order of service and the reserve know nothing of prices. It only puts a figure, in the summary and the PDF report, on what the backup cost — and therefore on what one more panel or one more battery would save.

The suggested value, 0.21 .-, is an ordinary electricity tariff. Zero is a price like any other — wood you do not pay for shows as 0.00 .-. The cost only appears while the backup is on: switched off, it gave nothing, and cost nothing.

The heating demand is met first by what costs nothing — sun through the windows, heat from the appliances —, then by the direct heating, the thermal battery's water and the external backup, with heat stored earlier closing the account — the heat from earlier gains, sun or appliances, which had carried the building above its set point and which it gives back afterwards: not a source, a shift in time. The uncovered demand is what is left after all that: the share of the demand that nothing described has covered.

It is only counted during the hours spent below the set point: it is the kilowatt-hour counterpart of those hours, and it is zero when comfort was never lacking. An hour counts as covered as soon as the set point holds there, even if little heat arrived — the mass of the building is then giving back what it had taken.

When it is not zero, it says what is missing. Without an external backup, add one — the “External heating backup” section, below the general thermics — and the simulator will heat with it, pricing what that costs. With a backup, raise its heat output, or the heating's, or the insulation. It is the one heating figure that must read zero, and the outline of its box turns red as soon as it does not.

It can be read as the gap on the “Heating” panel of the chart — between the top of the stack and the dotted demand line —, on the “Heating demand not covered” band, in the summary box and in the “Not covered” column of the month-by-month table. It is what the simulator used to call the “theoretical external backup”: the measure of what was missing, which never heated.

The heating only counts once the building is described: the envelope (at least one active wall or window) and the general thermics (ventilation, thermal mass, building temperatures), switched on as well. Without them a thermal simulation would be wrong and reassuring — filling in the heating therefore launches nothing while they are missing, and the block says so. The temperature set points are set in the general thermics: they describe the place, not the appliance.

The appliance is chosen in the direct heating block: an electric radiator — one watt of electricity gives one watt of heat — or an air-to-water heat pump, which gives several thanks to its COP. Everything else — thermostat, set points, order of service — is identical for both; the heat pump has its own entry in this FAQ.

The thermostat asks for a power — the one needed to hold the set point — but does not always get it. The summary separates what was asked for from what was delivered, and counts the hours spent below the set point.

The heating has no cut-off threshold of its own: the essentials' reserve is what bounds it, as tightly as possible. There is no “cut the heating below X %” setting to look for.

Unlike the appliances, the heating modulates: it takes whatever is left, even partially.

The demand to hold the set point is the building's heat loss at the set point, hour by hour: what would have to be supplied never to fall below it. The results table breaks it down free heat first, each contribution bounded by what the previous ones left: sun through the windows, heat from the appliances, water from the thermal battery — its radiator, plus the leaks from its insulation if it stands in the heated volume —, then the heating appliance, electric radiator or heat pump.

Then the external backup — stove, boiler, heater on another supply —, called upon last of all if it is described and on, and heat stored earlier, which closes the account: an hour counts as covered as soon as the set point is held there, even if little heat arrived — the mass of the building is then giving back what earlier gains, sun or appliances, had given it above the set point. It is not a source, only a shift in time: that heat was already counted in the hour it came in. The uncovered demand is therefore only counted during the hours spent below the set point, of which it is the kilowatt-hour counterpart; all the lines add up to the demand.

That uncovered demand has no heat: indoor temperatures unfold with the gap — which is what lets it say something. To fill it, describe an external backup: the simulator will heat with it, and price what that costs.

The direct heating demand is what the appliance asks for, not to be confused with the building's demand: after a shed hour the building has cooled, and the appliance asks in addition for enough to warm it back up. The share of that demand which is met is its service rate, comparable to that of the appliances. These lines — demand, supplied, share of the building's demand, hours of direct heating — only appear when the appliance is on: switched off, the thermal battery and the external backup heat without it.

The power you enter is the heat delivered — the one on the rating plate, at the nominal A7/W35 point —, not the electricity absorbed. It is what the thermostat compares to the building's demand, as for the radiator; the electricity drawn follows from it hour by hour, and it alone weighs on the panels and the battery.

The four COPs are copied from the machine's EN 14511 data sheet, 35 °C water column. The values suggested by default are those of a good current air-to-water heat pump — about 2.8 / 3.6 / 4.7 / 5.6 —: a sound starting point, not a substitute for your appliance's sheet.

Between two points, the COP is linearly interpolated from the hour's outdoor temperature. Below −7 °C it is extended along the first slope, never dropping below 1 — at worst the machine is worth its backup resistance element — nor exceeding the A−7 point: some data sheets put A−7 a hair above A+2 (defrosting penalises humid air), and extending that slope would make the COP grow with the cold. Above +12 °C it is capped at the A12 point: it would keep rising in reality, but the heating demand dies out at those temperatures.

The water is assumed to stay at 35 °C — underfloor heating or very-low-temperature radiators. Ordinary radiators call for hotter water: enter the COPs from the W45 or W55 column of the sheet, which are lower. Other simplifications: the heat output is assumed constant — a real machine loses capacity in deep cold —, and defrost cycles are not simulated separately, the standardised COPs already include them.

In the results, the heating's consumption stays electricity — it is what compares to the panels and the battery — while the coverage of the demand counts the heat delivered. The summary shows both, and the average COP actually achieved over the year: a little below the plate figure, because the machine mostly runs when it is cold.

They are set in the building's general thermics, not in the heating block: they are temperatures of the place. The heating appliance — radiator or heat pump — and the thermal battery's water radiator aim at the same set point, and switching the heating off to compare two variants does not move the comfort aimed at.

Lowering the away set point is the most effective lever on a holiday home, and the easiest to try: set 5 °C, save, and compare the annual heating consumption.

The set points apply as soon as the heating, the thermal battery or the external backup is declared and on: a stove or a thermal battery needs a temperature to aim at, even with no radiator or heat pump. With none of the three, nothing heats: the building freely follows the outside, and no hour is counted “below the set point”.

The third temperature, “forced venting above”, is the threshold where you air the place against overheating — 24 °C by default, an absolute independent of the set points. See the dedicated overheating entry.

Like the heating, the thermal battery only counts once the building is described — envelope and general thermics filled in: without them, its heat would have no building to go to. Filling it in launches nothing while they are missing, and the block says so.

Six settings: the appliance that heats the water — electric element or heat pump, see A heat pump for the thermal battery —, the volume in litres, the insulation thickness in millimetres, the power in watts — that of the heat put into the water —, the maximum water temperature — 90 °C by default: heating stops when it is reached, so it is what bounds how much the tank can store —, and the radiator performance in W/K — what it passes to the room per degree of difference between the water and the air.

The heating of the water is served last of all, after the appliances, the heating and the battery charging: it only takes what had no taker at all. It can therefore never make a shortage worse.

The water radiator supplements the heating appliance — electric radiator or heat pump —, or replaces it if that is switched off, in proportion to the difference between the water and the indoor air — and never below 5 °C, see Below 5 °C the thermal battery gives nothing back. The losses through the insulation, on the other hand, depend on where the tank stands: see A thermal battery outdoors is not the same tank.

It is the right way to recover part of the lost potential of summer and of bright winter days, without adding battery capacity.

The model is exactly the direct heating's, applied at the other end of the installation: four standardised EN 14511 points — the COP measured at −7, +2, +7 and +12 °C of outdoor air —, interpolated at the hour's temperature, extended below −7 °C without ever dropping under 1, capped at the A12 point above +12 °C. See How is the heat pump modelled? for the interpolation itself, which is the same here.

The power you enter is the heat put into the water, not the electricity absorbed — as for the direct heating. It is what bounds the filling of the tank; the electricity taken from the surplus follows from it hour by hour by dividing by the COP. The summary and the report give both: the surplus taken in — electricity, the figure that compares to the panels — and the heat stored, with the average COP actually achieved over the period.

Nothing else changes. The heating of the water is still served last of all and only absorbs the surplus: a heat pump can no more make a shortage worse than an element can. The insulation losses, the water radiator, the months of service and the location are set and computed identically — the water only knows joules, and what put them there is no concern of its own.

The COPs suggested by default are those of a machine preparing 60 °C water — lower than the underfloor-heating ones, the temperature gap to bridge being wider. Copy the column of the data sheet closest to the maximum temperature you set: that is what the machine has to reach. And an off-the-shelf air-to-water heat pump hardly goes past 55 to 65 °C — the 90 °C default suits an element, not a pump: the form says so.

The machine is assumed to draw on the outdoor air, the one from the weather year, wherever the thermal battery stands. A pump on indoor air would cool the very room it ends up heating: that is another model, and the simulator does not offer it.

The water radiator only works above 5 °C. The rule has two halves, and holds whatever the settings: below that temperature it gives nothing — even if the building is colder still —; above it, it never gives more than what brings the water down to the floor by the end of the hour. The thermal battery is never drawn lower.

It is first of all what a real installation does. Water approaching zero gives nothing useful back — a few watts per degree on emitters designed for hot water — and puts the whole loop at risk, as it almost always runs through unheated spaces. You stop it well before, at the usual frost-protection temperature: the one the building's default standby set point already carries.

Above all, the simulator cannot describe ice. Water is a single capacity there — 1.163 Wh per litre and per degree —, with no latent heat and no change of state: the 93 Wh per litre you have to take out to freeze one litre of water, eighty degrees of that same capacity, do not exist in the model. Without the floor, a thermal battery standing outdoors, or in a building itself below zero, went on heating the place with water at −10 °C: a wrong answer, and a reassuring one.

The floor does not stop the water from cooling: the insulation keeps leaking towards whatever surrounds the tank, and the water can fall below 5 °C on its own — it only rises again with the next surplus. What it no longer does is heat the building. The capacity given by the block and by the report is likewise counted from 5 °C as soon as the set point is lower: the degrees underneath cannot be recovered. You meet the case where heating is set to frost protection — a hut closed for the winter — or with a thermal battery outdoors; in a home held at 20 °C, the floor is never reached.

Ticked, the thermal battery sits in the indoor air: its insulation leaks against the indoor temperature, and what escapes is not lost — it is a heat gain for the building, like an appliance giving off heat.

Unticked, the thermal battery is outdoors: its insulation leaks against the outdoor temperature, the one from the weather year, hour by hour. In winter the gap between water and air is far wider than it would be in a living room — a 500-litre tank under 80 mm of foam loses about 47 W with its water at 60 °C in a room at 20, and close to 71 W outdoors at 0 °C. And that heat comes back to nobody.

The consequence goes beyond the extra leakage: an exposed thermal battery no longer holds its temperature. It falls back between two hours of sun, so its radiator rarely has anything to give, and the heating appliance has to make up the difference. Over a cold year, the gap between the two settings runs into hundreds of kilowatt-hours of heating — often the argument for bringing the tank indoors, or insulating it far better.

There is no third option. A cellar, a pantry or an adjoining plant room are halfway houses: colder than the living room, far milder than outdoors. The simulator offers no such intermediate case, so unticking amounts to assuming the worst. For a thermal battery in a cellar, the two settings bracket reality: tick for the optimistic bound, untick for the pessimistic one, and read the gap as your uncertainty.

The radiator does not change: it always gives to the building, and it is the difference between the water and the indoor air that drives it, wherever the tank stands. When the water falls back to the level of the room, it gives nothing more — it never cools the room down —, and it stops at 5 °C in any case: see Below 5 °C the thermal battery gives nothing back, the rule an exposed tank meets first.

Outside its months of service the thermal battery sleeps — valves shut —, but its temperature keeps being computed: the water cools towards whatever surrounds it — the room, or the outdoors if that is where it stands. Physics does not stop because the valves are closed.

An empty list is legitimate: the thermal battery stays declared, with all its settings, but never works. It is one way of comparing it with its own absence.

A good choice: tick the months where, without the thermal battery, the heating would not hold the set point or the battery would have to open its extended range — and the month before each of them, so the tank enters them full. The rest of the year, let it sleep: its heating would take potential nobody misses, and its insulation would heat a building that is not asking for it.

When the battery is full and everybody has been served, the controller throttles the panels: the output parts company with the potential. This is not a fault, it is how an off-grid system normally works — and in summer it is even desirable.

All three words speak of solar only. A generator's or the grid's kilowatt-hours are therefore nowhere in them: they have their own section in the summary, with their running hours and their cost.

On the chart, the solid line is the output, the dotted line the potential, and the hatched area between them the lost potential. Lost potential says nothing about the controllers' clipping: what the controller did not let through never enters the potential. The summary counts it separately, by what it cost: the producible potential clipped by the MPPT, the share of the clipping that would have found a taker.

In the table, the potential and the output are both broken down array by array. The simulator cannot tell which array's watt was throttled — the controller closes on every array at once —: each array's output is therefore its share of the hour's output, pro rata to its potential within that hour. Hour by hour, not on the totals: a west-facing array, the only one producing in the evening when nothing is throttled any more, keeps all of its evening output. The arrays add up to the output.

A lot of lost potential in winter, on the other hand, is a signal: there is sun left that nobody takes, often for want of storage or of a thermal battery.

With the surplus sale on, the vocabulary switches: output shows as self-consumed and lost potential as exported — the surplus goes to the grid instead of being throttled. Same quantities, different fate: the potential itself keeps its name.

Clipping as a whole is not a loss: what the controller would have let through at noon, battery full and appliances served, would have become lost potential — it is missing to nobody, and the summary does not name it. What it names is the producible potential clipped by the MPPT: the share of the clipping that would have found a taker, appliances, battery or thermal battery — potential the controller held back although it would have been produced.

That share cannot be read hour by hour: energy clipped at noon could have charged the battery and served in the evening. So the simulator replays the whole year with no controller limit at all and compares the two outputs, hour after hour. When the unlimited year delivers *less* in a given hour — its battery was already full from the noon surplus —, that difference is taken off the winning hours before it: the energy had only been moved. What remains is positive in every hour, and adds up over a month, a week or the year.

Like the whole clipping, it is counted peaks included: PVGIS readings are satellite snapshots, which already carry the spikes of a broken sky, and the spread the simulator adds only covers the gap between the satellite pixel and the point on the roof — see “What is the controller limit, and clipping?” for orders of magnitude.

On the chart, the lost-potential panel stacks the two: grey ink for what found no taker, amber for the producible potential clipped by the MPPT. They nearly exclude each other — clipping only has a taker when nothing is lost —, and the colour tells the cause. In the summary, it is set against the potential, like lost potential: “3 % of the potential” is what a bigger controller would have added. Below that total, one line per array says what each one would have produced on top, set against its own potential: the array that clips is the one that loses, and that is where you see which controller is too small for its array. The lines only appear if something was actually clipped.

With the surplus sale on, the question no longer arises: the grid takes everything, and the whole clipping would have been exported or self-consumed. The “Producible potential clipped by the MPPT” line is then the whole clipping, and the amber area of the chart takes it up.

• Essential shortfall — the shortage in the strict sense: the essential appliances, and the system's own electronics — its standby draw —, that went unpowered. Target: zero.
• Hours below set point — the comfort you went without, and by how many degrees.
• Lost potential — “exported” if you sell the surplus —: available energy the system did not take for itself: room for a thermal battery, for moving an appliance, or for fewer panels.
• Hours under stress — those where the battery's everyday range was not enough: that is where the wear happens.

The boxes at the top sum up the year; the table of figures below the chart covers the period on screen: frame December and it recomputes over December. That is the month which decides an off-grid sizing — June in the southern hemisphere, where the chart offers the same shortcut.

• Potential and output — the share of the potential actually delivered, with both energies: what was produced, out of what the arrays would give with an unlimited battery. Low in summer is normal; low in December is an opportunity.
• Shortfall on essential loads — the share of their demand that went unmet, and the matching energy. The demand counts the essential appliances and the system's own electronics — its standby draw, which has to run for anything to run —; the appliances are served first, the electronics next, and what went short is counted to the watt on both. What the system supplied, what the generator supplied and the shortfall add up exactly to that demand, and all three shares are set against it. It is the one figure that must read zero: the box is outlined in green as long as it does, in red as soon as it does not. In between, amber: nothing went unmet, but it was the generator — or the grid — that filled the gap, and the box then breaks the demand down between what the system served and what the generator supplied. The system alone would not have held; a green here would be falsely reassuring.
• Generator or grid — when it is on: the share of the total demand it supplied, the energy, and the expense at the set kWh price. The box passes no judgement — the amber of the shortfall and heating boxes already says what that rescue means.
• External heating backup — when it is on: the share of the demand it covered, its heat, the expense at the set kWh price, its hours, and — if its heat output was not enough — what is still uncovered. Without a backup, the box becomes Heating demand not covered: the share of the demand nothing covered, in kilowatt-hours and in hours. Like the shortfall box, it knows amber: nothing is missing, but it was the generator — or the grid — that powered the radiator, or the external backup that heated, and the box then breaks the heating's electricity down between the system and the generator.
• Heating demand covered — the share of the demand to hold the set point that something covered, and its breakdown by source: sun through the windows, heat from the appliances, water from the thermal battery, electric radiator or heat pump, external backup, heat stored earlier, not covered. Heat stored earlier is not a source: it is the heat from earlier gains — sun, appliances — which had carried the building above its set point, and which it gives back afterwards. The shares add up to the demand. The box follows the same judge as its neighbour, amber included: a demand covered thanks to the generator — or the backup — is not a green.

The outline of the three boxes that pass judgement — shortfall, backup or not covered, demand covered — answers before the figure does: green when it is sufficient (nothing went unmet), red when energy fell short. The two heating boxes turn together: they are the two faces of the same gap. The potential box stays neutral — a little-used potential is neither good nor bad. The PDF report uses the same code.

These boxes sum up the whole year. To read one period — December, a week in January —, frame it on the chart: the table of figures below the panels follows the window on screen, and box by box the same quantities are found there.

Zoom with the wheel or by dragging out a range; the overview at the top places the window within the year. On hover, every panel opens its tooltip at once, on the same hour and aligned under the cursor: you read in one glance what the output, the battery, the heating and the temperature were at that precise moment.

A coloured band gives the state of each hour: normal, standby, load shedding, and shortfall — in red — when an essential appliance went short of energy; the most serious state wins. Further bands give running hours: those of the generator or grid, those where the heating demand was not covered, and the months when the site's ground is snow-covered — the measured reflection then applies to the panels and the windows. Each only appears if it has something to say — no generator declared, no band; no heating demand, no uncovered-demand band; no measured snow, no snow band. On the battery panel, the dotted line is the reserve — the floor that ordinary appliances and the heating do not cross.

Each panel has its own vertical scale, recomputed over the displayed window alone: consumption is counted in hundreds of watts where the potential is counted in thousands, and a winter month flattened by the July peak would teach nothing. Two panels are therefore not compared by height, but by shape and by figures.

On a wide window each point covers several hours: the peaks are shaved off by the averaging. The same instant therefore does not have the same height at every zoom level — this is not an inconsistency.

A well-oriented window sometimes brings in more than the set point asks for: a bright March day with the shutters open warms the room beyond what you want. In reality you open a window; in the model the excess heat is vented, and the solar gains panel draws it as a dashed line.

The threshold is set in the building's general thermics — “forced venting above”, 24 °C by default. It is an absolute, independent of the set points: nobody airs the place at 22 °C because the thermostat reads 18. Nothing is vented while the building stays below it, and nothing can cool it below the outdoor temperature: in a heat wave it simply follows the outside.

It reads like a loss, but it rarely is one: that heat would have served nobody, and it costs nothing since it is free. Large venting in the middle of winter, however, points to oversized glazing or to too little thermal mass to take in the middle of the day and give it back in the evening.

It is counted separately from the useful gains, which are what the heating did not have to supply. In the table of figures it is read under the heat entering through the windows — “of which vented against overheating”, with the share of those gains it represents.

The simulator does not return averages: it returns every hour of every series — potential, output, consumption, shortfall, state of charge, temperatures. That is what makes it possible to zoom into three days of December without recomputing anything, and that is what weighs at the far end.

Two signs tell you it is working: a page skeleton while a simulation opens, and a thin bar at the top of the screen while a setting is being saved — because each save restarts the whole calculation and sends the whole year back.

If the wait feels long, it is mostly so on a slow connection: it is a transfer, not a computation. The PDF report is far lighter — the chart is already drawn in it.

The simulated year does not follow the civil calendar: it starts on 1 August in the northern hemisphere, on 1 January in the southern hemisphere, and the table follows that order. This is deliberate — it puts the slide into winter in the middle, with no break at the critical moment.

The starting date is no whim: it puts the slide into winter in the middle of the simulation, with the battery starting at its everyday ceiling. It is 1 August in the north and, the austral winter falling in June, 1 January in the south — the equator counts as south. Starting in mid-winter would cut in two the only season that decides the sizing.

The building does not reach the first step without a past. The typical year loops: the hours before the start are the last of the simulated year — late July in the north, late December in the south —, and the simulator plays those last two weeks before the first step — from the outdoor temperature, with the sun through the windows, the heat from the appliances, the heating and the backup as the thermostat would ask for them — so as to reach the first step in the state the building is really in. Starting from the first step's outdoor temperature, as it used to, invented no heat but called for some: on a mountain-pasture house, climbing from 12 to 19 °C on the morning of 1 August cost 37 kWh, almost all of it stove, for a house that then lives at 23 °C all month. The thermal battery's water, for its part, starts at the temperature of the air around it — the building primed that way if it stands inside, the outdoors otherwise.

There is no monthly average anywhere: everything is computed hour by hour, then aggregated for display.

The site's latitude settles it, nothing else: north of the equator the year starts on 1 August; exactly on the equator and south of it, on 1 January. Dragging the marker from one hemisphere to the other therefore reorders the whole simulated year.

Both dates play the same role: putting the slide into winter — December in the north, June in the south — in the middle of the simulation, with no break at the critical moment, the battery starting at its everyday ceiling, the building and the thermal battery from a late-summer state — the last two weeks of the simulated year are played before the start for that. Starting in mid-winter would cut in two the only season that decides the sizing.

Every display follows that same order: the months of the results table and of the occupancy calendar, the bounds shown above the chart, the PDF report — and the chart shortcuts, “December” and its November – January quarter in the north, “June” and May – July in the south.

The first simulated day is by convention a Monday — 1 August in the north, 1 January in the south. Since the PVGIS typical year is stitched from months of different years, it has no real calendar: the weekends of the occupancy calendar follow this convention.

The sky is not uniformly bright: part of the diffuse radiation comes from the halo around the sun and follows the same geometry as the direct beam. A simpler model, assuming a uniform sky, underestimates a south-facing plane by 5 to 10 %.

To this are added ground reflection — an albedo of 0.2, raised to 0.65 for the months ticked under the site's “snow on the ground” — and the reflection loss off the glass when the sun arrives at an angle: 3 to 4.5 % over the year facing south, more facing east and west.

The sun's position has been checked against an independent algorithm, to within 0.1–0.5°, and against the known landmarks: elevation at the solstices, due-south azimuth at solar noon, the southern-hemisphere case.

A panel gives less when it is hot, but also when the light is weak: 5 to 8 % less at 200 W/m², more below that. It is this second effect that a plain temperature coefficient ignores — and that leads to overestimating annual output by 5 to 7 %.

The simulator therefore uses the function published by PVGIS (Huld et al., 2010) for crystalline silicon, which equals exactly 1 under test conditions.

Three goals, in this order: as little shortfall as possible on the essentials, then use as much of the potential as possible, then respect the order of service. The battery wear constraint is added on top through the two ranges.

Serving comes before storing: whatever the reserve does not require to be kept goes to the appliances, then to the heating. An ordinary appliance is all or nothing; the heating modulates and takes what is left. The hot-water heat pump follows the same rule at the place its setting gives it: essential, it is folded into the essentials; ordinary, it goes last in the appliance list, just before the heating — the automaton waits its turn behind the appliances you ranked yourself.

The generator or grid only comes in after that, and only if a gap remains: it picks up the essentials first, then — if it is set to “everything” — the ordinary loads and the heating, in that same order. It does not charge the battery and does not feed the tank's heating.

Three flows enter the balance: what escapes through the surfaces and the ventilation, what the sun brings in through the windows, and what the appliances, the heating and the thermal battery give off indoors.

The thermostat decides on the temperature at the start of the hour: it anticipates neither the sun about to come in nor the heat from the appliances. That is how a real thermostat behaves.

The external heating backup, if it is described and on, is the fourth flow, called upon last of all: its heat enters like the others. Whatever nothing covered — the uncovered demand — has no heat: the temperature unfolds with the gap, and that is what allows the hours below set point to mean something.

For an off-grid sizing, good practice is to keep a margin on the worst month rather than to aim at the annual total as tightly as possible.

The correction is monthly — twelve gaps, smoothed between mid-months —, and therefore follows the season: in the valley that was measured, +6.2 °C in January, +7.4 in December, +0.5 in October. What it does not follow is the day: within one month, a valley-floor inversion or a mild spell keep their own gap, and one number per month cannot say that. The figure shown on the site card is the average of those gaps, weighted towards the heating months — a summary, not what the engine applies; a simulation whose normals predate this monthly calculation only has that average, applied as a constant until the next fetch.

The normals used to measure it come from the same reanalysis PVGIS uses; what they add is the descent to the real altitude, not a second observation. A nearby weather station, if you know of one, remains a better judge — that is what the additional correction is for, which adds to the baseline.

The wind is not corrected at all. It only comes into the module temperature, whose effect on annual output stays modest.

On flat ground the error is small, and often nil: it is in the mountains, where the altitude of the point departs from that of its grid cell, that the correction is warranted.

What a constant fraction lacks is the when: real shading depends on the season and on the hour. A roof overhang hides the summer sun and lets the winter one through; a hillside cuts off December's sun and not June's. The simulator lowers the whole day uniformly — roughly the right annual energy, at the wrong time.

This matters because off-grid everything is decided over a few winter weeks: shading that only bites in that season is underestimated by an annual average, while summer shading is overestimated — it often costs nothing, the potential being already lost for want of a taker.

The far horizon mask — the terrain — is properly accounted for, hour by hour: it comes with the PVGIS data. The percentage you enter therefore only concerns what is close by.

The simulator will therefore say nothing about a cold north-facing bedroom or a living room overheated by its picture window: it gives the average temperature of the volume.

In the same way, soiling and ageing of the panels are covered by a flat loss figure, not computed day by day — and so is the snow that covers them, as a percentage taken off the snowy months alone, never from the snowfalls themselves: see “What is the snow-cover loss?”.

Checked on a mountain site at about 900 m, with two arrays of different orientations: the in-plane irradiance is within 1–1.5 % of PVGIS, and the annual output within 2–3 %.

Against that, a rough surface U-value, a guessed thermal mass or optimistic appliance timetables will move the result by 20 % without difficulty. That is where the care belongs.

This is neither a regulatory calculation, nor a detailed design study, nor a commitment: the results are indicative, and the simulator is provided without any warranty.

A simulation is a file on the server, kept in the folder your anonymous cookie names. Nobody else can reach it, and there is nothing for you to install.

The flip side: from another device or another browser you will not see your simulations. That is what the JSON export is for.

The home page always shows your count, in the form “1 / 3”. Beyond that, creation is refused with a message saying so.

To make room without losing anything: export the simulation as JSON, delete it, and import it back the day you need it.

The site is open to all and needs no account: keeping every visitor's simulations for ever would make no sense. The purge runs on its own and erases whatever has not been touched for 3 days.

If you want to keep a piece of work, export it as JSON: that is the only way to hold on to it beyond that deadline, and it can be imported back unchanged.

The button is on each simulation's card on the home page, and next to the results on a simulation's own page. It stays available even when the calculation cannot run: it only carries the settings.

The file is readable text: it can be opened, archived, sent by email.

The file is fully re-checked on import: a damaged or tampered-with file is refused with a message, never loaded halfway.

An import counts towards your quota. If the name already exists, “(copie)” — the literal suffix the tool writes, whatever the display language — is appended so as not to cause confusion.

The “Export as PDF” button is next to the results. The file is built on the fly and downloaded directly: no intermediate page, no print preview.

The chart appears twice, on full landscape pages: first the whole year, always — that is the scale at which a sizing is judged, and the report must stay readable for whoever receives it without knowing what you were looking at —, then the period on screen in the simulator, with its own figures below the plot. Frame December before exporting and you will get the year and December.

Items that are switched off appear in the report, marked as such: knowing what was set aside is part of reading it. A simulation that cannot be computed still produces its settings report.

Every report carries the date and time it was exported — at the head, and at the foot of each page along with that page's number. The file name carries them too: “My-simulation-2026-08-29_16-15.pdf”. That is what lets you produce two reports of the same simulation with one setting changed in between and still know, once they are printed or filed side by side, which is the more recent. The report comes out in the language of the page you export it from.

The shared examples are the exception: they do not belong to you, so their cards carry no delete button. Your own copy carries “Reset” instead — it is erased and the original example takes its place again.

The simulations you enter — location, equipment, consumption — are kept on the server for the time given above, then erased. Nothing in them is tied to your identity.

Your choice of language is kept in a cookie of its own, so the site does not fall back to English on every page. Without that cookie, the language set in your browser decides, and English by default.

Audience measurement (Google Analytics, loaded through Google Tag Manager) is only written into the page after you accept on the banner — before that there is nothing to load, not even idling. Google's consent mode is used as it prescribes: everything denied by default, then audience measurement alone granted. Advertising signals stay denied permanently: no profiling, no targeted advertising.

The question is asked before any use of the site: a banner puts it at the foot of the screen, and until it is answered the site stays fully visible — it can be read and scrolled — but nothing responds to you: no link, no button, no form, on every page and for the whole visit. Declining leaves the site, and is not remembered: the question is asked again next time. One page stays usable before deciding, “Privacy”, because it is what the choice rests on.

The “Privacy” page, linked at the foot of every page, sets out the cookies, the audience measurement and your rights under the GDPR.

Nothing guarantees the site will stay online: it may change, be restricted or stop without notice. Your simulations are deleted automatically after a few days; export whatever you care about.

The figures produced are indicative. A sizing, an investment or any choice bearing on safety must be checked elsewhere, with a professional; whoever makes it remains solely responsible for it.

The calculation engine — solar physics, building thermics, battery management —, the chart and the PDF report generator are written specifically for this site.