Documentation
What is worth knowing before your first project
The system gives a good answer when the input is sound and the steps run in the right order. This page describes both — plus what the most common warnings actually mean.
Quick start — one page
What you will need, what order to work in, what the numbers mean. Printable, so it can sit on your desk next to your first project.
Open →
User manual
Screen by screen, field by field: signing in, locations, data, calculation, optimization, reports, MEKH filing, energy community.
Open →
A short guided tour also starts inside the application the first time you sign in. It can be restarted any time with the ❓ Tour button in the header.
The concept that matters most: the T-curve is grid draw
The consumption curve you load shows how much energy you took from the grid — not how much you consumed in total. If you have solar, the two are not the same: energy that went from the panels straight into self-consumption never passed through the meter.
The system is built on this: from measured grid draw and modelled solar production it reconstructs total consumption. Load a curve that already contains total consumption and the result will be wrong — the effect of the solar system would be counted twice.
1 · Data preparation
What the consumption file should look like
| Format | .xlsx, .xls or .csv |
|---|---|
| Resolution | Hourly or finer (15 or 30 minutes). Finer data is summed per hour. |
| Period | A full calendar year is best. A shorter period loads too, but annual figures and payback only make sense from a full year. |
| Date column | One column whose header contains date, time, stamp, datum or idő. Without such a header the system tries to recognise the date from the values in the first row. |
| Value column | In kWh. With several numeric columns the system adds them together. |
| Decimal mark | Comma and point are both fine. Semicolon-delimited, header-less supplier exports are handled too. |
⚠ One trap worth knowing about
If the system finds no date column at all, it assumes the data is 15-minute and merges every four rows into one hour. If your file is actually hourly or half-hourly, this silently produces a wrong result — four or two times the real consumption.
So after loading, always read the import summary: the system states how many raw rows became how many hourly rows, and names the detected granularity (“15-min”, “30-min” or “Raw (hourly)”). If a year of data gave you 8 760 hourly rows (8 784 in a leap year), you are on the right track.
What else you can load — but do not have to
- Inverter export log — makes the solar self-consumption/feed-in split rest on measurement rather than estimation. This adds the most to the reliability of the result.
- Battery state-of-charge and discharge log — for the actual behaviour of an existing battery.
- Hourly prices — for a stock-priced contract.
- Pre-install consumption — if the solar system went up during the measurement year.
2 · Workflow
What order to work in
The steps build on each other: several calculations use data that an earlier step wrote. Keeping the order prevents half of the common mistakes.
Create a location
Name, address, then coordinates — from the built-in geocoder or by clicking the map. Without coordinates there is no weather or solar data.
Prices and tariff
Electricity price (fixed or stock), feed-in price, gas or district-heating price if you have such a demand. You can also pick from the tariff catalogue.
Load the consumption curve
On the T-curve page. After the import, check the row count and the detected granularity.
Fetch the weather
On the location page, with the measurement year. The building calculation requires this step — without outdoor temperature there is nothing to distribute the heating and cooling demand along.
Add existing systems
Solar (then “Fetch and calculate hourly data”) and battery. This is when hourly solar production enters the data table.
Energy demands
Technological heat, hot water, building heating and cooling. Run “Calculate hourly data” on each — that is what writes the hourly columns.
Energy flow (EFC)
This is where the picture comes together: self-consumption, feed-in, battery behaviour, annual cost and self-sufficiency.
Planned developments
Add the developments you want to examine, then run the optimizer or evaluate them one by one.
Report
The system analysis report, and — if your plan includes them — the MEKH filing and the ESG chapters.
3 · Concepts
What the indicators mean exactly
| T-curve | Measured grid draw in hourly resolution. Not the same as total consumption. |
|---|---|
| Total consumption | The site's actual energy need: grid draw + the solar energy that went into self-consumption + the part covered from the battery. |
| Self-sufficiency (%) | 1 − (grid draw − feed-in) / total consumption. An annual net balance in which feed-in counts as a credit — so 100% means you generate as much as you consume over the year, not that you run off-grid. |
| Confidence (%) | How far the result rests on measured data rather than modelling. A low value is not an error — it says the result would be sharper with more data uploaded. |
| Dispatch | The hourly simulation of energy allocation: which source covers the demand in each hour (solar, battery, grid), and what goes back to the grid. |
| NPV / IRR | Net present value and internal rate of return, with the discount rate and lifetime you set. The report also states payback in discounted terms. |
| COP / EER | Heat-pump heating and cooling efficiency. The system does not use a single average — it computes them as a function of outdoor temperature, hour by hour. |
4 · Troubleshooting
The most common warnings
The system deliberately tells you when something is missing rather than quietly estimating. The following are not errors but tasks.
“Enable at least one distribution” — the demand calculation will not start
The annual demand has to be distributed across the hours of the year, and that needs at least one distribution: monthly, weekly or daily. Switch at least one on in the demand card — monthly is usually enough, and it is on by default.
“Download the outdoor temperature first” — the building calculation stops
Distributing heating and cooling demand depends on outdoor temperature. Go to the location page, enter the measurement year and run the weather fetch. This is done once per location.
“T-Curve data not found” — the EFC will not run
No consumption curve is loaded for this location, or the import was not saved into the data table. Go to the T-curve page, load the file, and wait for the confirmation with the row count.
“solar split is MODELED (no export data)” — the solar split is estimated
No inverter export log is uploaded, so the system splits solar production into self-consumption and feed-in on a rule basis. The result is usable, but self-consumption is typically overestimated. If your inverter has an export log, upload it — this adds the most to accuracy.
“stock pricing selected but no hourly prices linked”
You set stock pricing for the location, but no hourly price table is uploaded, so the calculation uses the fixed price for every hour. Either upload hourly prices or switch the location to fixed pricing.
The optimizer says the development is not worth it
That is not an error, it is a result. If every cell of the matrix is more expensive than the starting point, then for this consumption profile and these prices the development is not economically justified. It is worth checking the capital cost, the lifetime and the discount rate — but often this simply is the right answer.
The area breakdown differs from the annual balance
In the MEKH filing the area breakdown is computed from the card settings, while the annual balance comes from the hourly columns. If the two differ by more than 2%, the system warns you: one of the demands has not had “Calculate hourly data” run. Run them all and the two figures converge.
Did not find what you were looking for?
Write to us — we extend the documentation based on real questions.