How to read half-hourly electricity data

A half-hourly data file is a year of electricity meter readings, one for every 30-minute period the site was connected. Each number is the power the site drew, or in some files the energy it used, during that half hour. Read in order the numbers show the site's demand across the whole year, which is why this single file is enough to work out the site's peak, its overnight baseload, the shape of its demand through the day, and the way that shape changes with the season.

A 24-hour day holds 48 half-hour periods, and a standard year of 365 days gives 48 times 365, which is 17,520 readings; a leap year adds a day and comes to 17,568. This is the settlement data that suppliers use to bill larger sites in Great Britain, recorded under the industry rules that Elexon administers for half-hourly settled meters. To confirm a file covers a full year, check that its first and last rows sit twelve months apart and that the row count lands near 17,520 rather than well short of it.

What one reading is

Each row of the file carries a date, a time or half-hour period number, and a value. The value comes in one of two units, and it matters which. Some files record the average power in kilowatts (kW) that the site drew during the half hour. Others record the energy in kilowatt-hours (kWh) that it used. For a 30-minute period the energy in kWh is the average power in kW divided by two, because the period is half an hour, so a steady draw of 100 kilowatts shows as 50 kilowatt-hours in an energy file. Comparing a kW value against a kWh value without converting gives a reading that is out by a factor of two.

Some files carry more than one value per period. A site with on-site generation or a battery may show import and export separately, or a net figure that can go below zero when the site exports more than it draws. Reading the sign convention correctly is the first step, because a negative number represents on-site generation being exported, which the model must treat separately from demand.

What the file as a whole tells you

The single highest reading in the year is the site's peak demand: the most power it drew in any half hour. That half-hourly peak is the main thing that drives the import capacity a connection needs, though capacity is contracted in kVA and instantaneous demand can run above the half-hourly average. It is often the number that decides whether solar and storage can reduce the capacity a site pays for.

Below the peak sits the baseload, the level the demand rarely drops below, usually seen in the overnight and weekend readings when the site is quiet. The distance between the baseload and the peak describes how variable the demand is. A site whose readings stay close together has a flat profile; one whose daytime readings sit far above its overnight minimum has a peaked profile, and the two behave very differently when solar or a battery is added.

Because every reading is stamped with its time, the file also shows when demand happens. Sort the readings by time of day and a load shape appears: the hours the site ramps up, the plateau through the working day, and the fall in the evening. Split the year into weekdays and weekends, or into months, and the seasonal pattern shows alongside it. The load factor, the average demand as a proportion of the peak, is calculated from the same numbers and summarises in one ratio how heavily the connection is used.

How the numbers connect to the bill

The time stamp on each reading is what ties the data to the electricity bill. Network charges fall in defined windows: distribution charges apply higher rates in peak bands on weekday evenings, and the forward-looking part of transmission charges reflects demand in a small number of winter peak half hours. The larger residual part of transmission charges is now a fixed capacity band that does not respond to when a site draws power. Knowing which half hour each reading falls in lets you see how much of the site's demand lands in the expensive windows, which is where reducing demand at those times lowers the bill.

The same is true of a time-of-use tariff, where the unit price changes through the day. Placing each reading against the tariff band it falls in turns the file into the actual cost of running the site, half hour by half hour, rather than an annual average, which does not show when in the day the cost falls.

What half-hourly data makes it possible to model

Solar output and battery dispatch both vary from one half hour to the next, so a feasibility study needs demand at the same resolution to line them up. With the file in hand, modelled generation can be matched against real demand in each half-hour period: how much of the solar the site would use as it is produced, how much would be left to store or export, and how much the battery could shift out of the expensive windows. An annual or monthly total cannot answer those questions, because the value of solar and storage depends on the timing of demand, which only a half-hourly file records.

Reading the file with its faults in mind

Real files are rarely perfect, and a few faults are common enough to check for first. Gaps appear where the meter failed to communicate, leaving missing periods that a model has to fill or exclude. Some readings are estimated rather than measured, and a run of suspiciously smooth values often marks an estimated stretch. The two clock-change days each year carry 46 and 50 readings rather than 48, which can shift every later time stamp if the file is read naively. Working through these before analysis keeps a data error from being read as a demand pattern.

Lupa takes a site's own half-hourly file together with its electricity invoice and turns them into a feasibility report, and the platform reads the file's peaks, load shape and tariff bands to model how solar and storage would perform against that site's real demand.