REFIT Electrical Load Measurements (Cleaned)

A smart meter tells you the house drew 523 watts. It never tells you whether the fridge compressor cycled or the washing machine hit its heating element. The project behind it - Personalised Retrofit Decision Support Tools for Existing and New Owner Occupied Houses, an EPSRC-funded collaboration among Loughborough University, the University of Strathclyde and the University of East Anglia - was built to close exactly that gap in occupied UK homes, and the cleaned release is its usable form: 20 households in Loughborough monitored from October 2013 to June 2015 at a nominal 8-second interval, each home carrying whole-house aggregate power plus up to nine individually metered appliance circuits, all in plain watts.

The "cleaned" in the name is pulling its weight. Its published procedure merged duplicate timestamps, clamped appliance-monitor readings above the 4,000 W sensor limit to zero, assigned each monitor to a single appliance wherever the wiring allowed, forward-filled gaps shorter than two minutes and zeroed longer ones - then stamped every affected row with an Issues flag recording what happened. Raw logger dumps make you reconstruct all of that yourself; here it arrives already done, with an audit trail.

The result became a reference corpus for non-intrusive load monitoring: a frozen, fully documented, peer-reviewed benchmark (Murray, Stankovic and Stankovic published the study in Scientific Data) against which disaggregation models get trained and compared. On Datadory's quality rubric it scores 9 out of 10 - field definitions verified, sample rows shipped, coverage documented down to the individual house.

Rows verified during the August 2026 research pass, exactly as they land in your warehouse - one row per 8-second reading tick, thirteen columns wide.

Time                | Unix       | Aggregate | Appliance1 | Appliance2 | Appliance3 | Appliance4 | Appliance5 | Appliance6 | Appliance7 | Appliance8 | Appliance9 | Issues
2013-10-09 13:06:17 | 1381323977 | 523       | 74         | 0          | 69         | 0          | 0          | 0          | 0          | 0          | 1          | 0
2013-10-09 13:06:31 | 1381323991 | 526       | 75         | 0          | 69         | 0          | 0          | 0          | 0          | 0          | 1          | 0

Read the pair as a two-frame movie of one October afternoon. Fourteen seconds separate the rows - the nominal 8-second cadence drifting a little, precisely the kind of jitter the cleaning pipeline tolerates rather than discards. Whole-house draw sits at 523 W and ticks up to 526 W. Slot 1 holds a steady 74-75 W and slot 3 a steady 69 W: baselines, not cycles. Slot 9 idles at a single watt. Slots 2 and 4 through 8 read zero because nothing on those circuits ran during this window - and that absence is signal, since you now know those appliances were off at 13:06 on 9 October 2013.

Issues reads 0 on both rows: the cleaner found nothing to touch. Wherever it intervenes - a gap bridged, a duplicate merged, a spike past the 4,000 W sensor limit clamped to zero - the flag turns non-zero, so quality filtering becomes a WHERE clause instead of an archaeology project.

Thirteen columns, four jobs. Two timekeepers: Time in YYYY-MM-DD HH:MM:SS local UK time, and Unix epoch seconds for anyone who refuses to parse timestamps twice. Ten measurement channels: the Aggregate whole-house figure plus Appliance1 through Appliance9, one wattage per individually metered circuit. One auditor: Issues, the cleaning pipeline's flag. Every definition below is verified against the source card, and every example is lifted from the shipped rows.

One honest caveat: slot numbers are sockets, not names. Which circuit behind the consumer unit became Appliance3 in a given house is fixed per house in the companion mapping workbook, and the cleaning step assigned each monitor to a single appliance wherever possible. Pull that mapping alongside the measurements and the columns stop being anonymous integers and start being dishwashers, tumble dryers and kettles.

Geography: Loughborough, United Kingdom - twenty occupied houses in a single East Midlands town. Depth over breadth: one climate, one housing stock, one utility context, so cross-house comparison stays clean and confounders stay few. What the panel gives up in national representativeness it returns as a controlled setting for method work.

Temporal: October 2013 through June 2015, roughly twenty months of continuous monitoring per home - two full winters plus the shoulder seasons between them, which matters, because heating-season behaviour is where UK household load gets interesting. The campaign is complete and the corpus is fixed: nothing you calibrate on this year shifts next year.

Granularity: a nominal 8-second interval per house, split into one aggregate channel plus up to nine appliance channels, each reported in watts. House 1 alone runs to roughly 1.66 million rows. That cadence is fast enough to catch compressor cycling, kettle elements and washer drum motors, slow enough to keep the whole twenty-home corpus manageable on commodity hardware.

API, files, or your warehouse. Daily, weekly, or hourly.

• Non-intrusive load monitoring (NILM) - supervised disaggregation needs labelled truth, and up to nine metered circuits per home at 8-second cadence are exactly that; train on some houses, test on the rest, and report numbers directly comparable with the published literature because everyone benchmarked on the same corpus.
• Appliance engineering and benchmarking - duty cycles, standby draw and startup signatures for real white goods in occupied homes rather than lab benches, segmented household by household instead of averaged into a fiction.
• Demand response and flexibility modelling - measured baselines make shiftable load quantifiable: simulate what interrupting or shifting a cycle actually saves, in watts and minutes, instead of estimating from surveys.
• Smart-home automation and anomaly detection - reference curves for a household's normal rhythm give anomaly thresholds an empirical floor, and the Issues flag keeps sensor artefacts from masquerading as events.
• Retrofit and efficiency research - the project existed to power retrofit decision support, and aggregate-plus-appliance decomposition shows precisely where efficiency investment lands in a real dwelling.
• Reproducible academic work - a frozen, peer-reviewed benchmark with a stable citation, so methods sections survive reviewers asking for a rerun.

ML engineers and data scientists get labelled ground truth at a resolution that still supports event detection, with a per-row quality flag keeping dirty rows out of training. Academics and students inherit a benchmark their reviewers already recognise - published in Scientific Data and cited across the NILM literature. Appliance product managers and engineers see category-level duty cycles straight from real kitchens and utility rooms. Energy consultants and retrofit assessors get decomposition evidence for where savings hide in ordinary dwellings. Smart-home and energy-app builders prototype against realistic household rhythms before ever touching a customer's consumer unit. Climate-tech investors and analysts sizing residential-flexibility markets get measured load shapes rather than vendor slide decks.

Three things worth knowing upfront. First, this is a deep slice, not a wide one: twenty homes in one town between October 2013 and June 2015. Treat it as a laboratory for methods and appliance physics, and reach for broader panels when you need population-level claims.

Second, budget for scale honestly. Twenty headered tables approaching half a gigabyte compressed and several gigabytes once parsed, with the largest single house at roughly 1.66 million rows - trivial for a notebook, hopeless for a spreadsheet, decisive if your tooling assumes everything fits in memory.

Third, resolve slot identities before you model. The numeric appliance columns mean something different in every house until the per-house mapping is applied; request it with the measurements and your features arrive named. And keep the Issues column in scope - filtering on it first is the difference between clean training data and a debugging afternoon.