NILMTK is the data layer under non-intrusive load monitoring

A data layer, not a model

The README states the scope in the first line. NILMTK is the data and evaluation layer of the open source ecosystem for non-intrusive load monitoring. It converts and loads energy datasets, represents buildings and meters, prepares time windows, computes statistics and metrics, and provides classical reference algorithms. Then comes the instruction that matters for anyone arriving from the older literature, which is to use this repository when the work is about data, meters, preprocessing or metrics, and to use the companion repositories for maintained neural models or reproducible benchmark claims. That sentence is a sign of a project that has been through a governance conversation and decided where its edges are. It also explains why the repository reads as a data toolkit rather than a model zoo, and why the classical algorithms are still here, as reference implementations rather than as the recommended approach.

Four repositories, four jobs

The ecosystem table is the clearest map of the project. This repository, NILMTK core, covers dataset conversion, meter access, preprocessing and metrics. NILM Metadata covers the appliance taxonomy, synonyms, meter relationships and dataset schema. nilmtk-contrib holds disaggregation model implementation and testing, and NILMbench holds the fixed T1, T2 and T3 evaluation and the published result bundles. The division of labour is sensible, because a taxonomy that every model depends on should not live in the model repository, and an evaluation protocol that certifies results should not change when someone adds a new architecture. The ecosystem guide explains how these layers fit together, which Docker route to use and which papers to cite, and the README repeats the boundary rules further down, where changes to dataset semantics belong in NILM Metadata, new model architectures belong in nilmtk-contrib, and benchmark task definitions and published result bundles belong in NILMbench.

Installing on Python 3.11 with uv

The supported installation is narrow and deliberate. NILMTK core supports Python 3.11 and newer, and Python 3.11 is recommended for an end-to-end environment shared with nilmtk-contrib and NILMbench. The instructions assume uv, and the environment is created and the package installed in one sequence:

uv venv --python 3.11
source .venv/bin/activate
uv pip install "nilmtk @ git+https://github.com/nilmtk/nilmtk.git"
python -c "import nilmtk; print(nilmtk.__version__)"

On Windows PowerShell the environment is activated with the Activate.ps1 script instead. The DEDDIAG converter needs an optional extra, installed the same way with the deddiag suffix on the package name. The README is blunt about what not to do, saying not to combine these instructions with old Python 3.6, Anaconda channel or setup.py develop tutorials, because those routes describe earlier releases and are not the supported installation for the current repository. The converter is then worth checking, since the command line entry point lists what it can read and converts a dataset into the HDF5 form the library works with.

The datasets are not yours to redistribute

The data policy is short and unambiguous. NILMTK does not redistribute REDD, UK-DALE, REFIT or other licensed datasets, and the instruction is to download the data from its official custodian, comply with its licence and convert it locally. A converted dataset is then an HDF5 file that the library opens directly:

from nilmtk import DataSet

dataset = DataSet("redd.h5")
print(dataset.metadata)
print(dataset.buildings)

NILM Metadata is installed with core and supplies the canonical appliance taxonomy, the synonyms and the meter relationships used while loading datasets, which is why the metadata package appears as a pinned dependency in the project file rather than as something you install yourself. The practical consequence is that a replication of a published result depends on three things you have to obtain yourself, the raw dataset, the metadata and the code, and the documentation is careful to say that the original model and dataset papers should always be cited as well.

What core actually gives you

The list of what core provides is short enough to quote. Converters for public energy datasets. Lazy access to buildings, meters, appliances and time frames. Resampling, alignment, preprocessing and data-quality statistics. The standard NILM accuracy and energy metrics. The rapid experimentation API used by nilmtk-contrib. And the classical reference disaggregators and baseline utilities. The word lazy in the second point is a design decision rather than a synonym, because a dataset can be large and a researcher usually wants one building, so deferring the load is what makes an interactive session usable on a laptop. The detailed API reference is published separately, and the repository manual and notebooks live in the docs directory.

One container, on purpose

The Docker section explains a decision that looks like an omission until you read it. NILMTK core is a Python library and does not publish a separate official core image, and this is intentional. The guidance is to use the single Dockerfile from nilmtk-contrib for a general environment containing core, metadata and model code, to use NILMbench for the pinned CPU smoke and CUDA benchmark runtimes that certify leaderboard results, and not to create an image for each algorithm. The reason is given plainly, that keeping container ownership in those two places prevents four repositories from shipping drifting copies of the same environment. For a research ecosystem, that is the difference between a benchmark result and a benchmark result on a slightly different environment.

Development, citation and the state of the project

The development loop is uv based, with a clone, a sync of the dev extra, and the tests run through uv. Before a pull request the instructions are to run the narrow test for the change, the current package gate and the documentation contract, which are three commands, running the test suite, running the documentation check script and building the package. The historical core regression tests live under the package's own tests directories and the README asks that the affected files be run explicitly when changing those modules, with the work to bring those fixtures into the default gate tracked separately. The citation section is unusually thorough. If you use core dataset conversion, meter abstractions, preprocessing or metrics you cite the NILMTK paper, and there are separate papers to cite for the NILM Metadata schema and taxonomy, for the nilmtk-contrib model suite and for the NILMBench2026 protocols, runner and leaderboard results. The project is under the Apache License 2.0, the package metadata reads version 0.4.1 with a development status of Beta, the newest listed release is 0.4.2 from 2020-08-27, and the last push to the repository was on 2026-07-20.

Editorial conclusion

NILMTK fits a researcher who needs to load a public energy dataset, describe its buildings and meters, preprocess it, and score a disaggregation result with standard metrics, since that is exactly the layer this repository owns. It does not fit someone whose work is a new neural architecture, which belongs in nilmtk-contrib, and it does not fit a benchmark harness, which belongs in NILMbench. Before you install, read the ecosystem table, because the split is enforced by convention rather than by tooling, and note the release state, where the newest listed release is 0.4.2 from 2020-08-27 while the last push was on 2026-07-20 and the project metadata reads 0.4.1.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. nilmtk/nilmtk on GitHub
3. Project website
4. README
5. Releases