OpenEEmeter Documentation

Here you'll find guides, reference materials, descriptions of methods, code examples, product manuals, and installation instructions.
Methods docsRead the code


These guides are designed to help you understand how the OpenEEmeter works. Please send along your feedback.
Send feedback


The OpenEEMeter provides a consistent, replicable way to estimate site-based energy savings.

Consistent, replicable methods provide confidence in energy efficiency savings. The methods outlined below are designed to promote market transformation and innovation in the energy efficiency industry. In conjunction with available open-source code, these methods allow any public or private entity to calculate gross normalized metered savings and be confident that their results will be consistent with other third parties.

Guiding principle: openness

distributed agreement


In the next decade, energy efficiency investments will need to increase tenfold in order to meet our climate goals and energy needs. As with the solar revolution of recent years, achieving these goals will require innovation in both technology and business models. It will be essential to measure the respective impact of new approaches in a consistent, transparent way. Clear methods reduce the likelihood of implementation discrepancies and potential confusion over inputs and outputs.

Open-source code allows for collaboration and encourages stakeholders to work together to ensure transparency and replicability. The OpenEEmeter’s open-source license promotes collaboration without unduly burdening new users with restrictive implementation constraints. Much like the propagation of other open-source platforms such as the Android operating system, the OpenEEmeter lays a foundation for future innovation and deployment across the energy sector.


Constraints: consistency and replicability


Consistency means being confident that the savings calculations are using the same methods as all other savings calculations. In the case of the OpenEEmeter, each site’s savings is calculated using a consistent, weather-normalized model. There are no discretionary independent variables that change from calculation to calculation. This way, site level savings reflect the same underlying methods across programs and implementations.


Replicability means that any one analysis of gross normalized energy savings can be performed in exactly the same way by any third party. The OpenEEmeter is not a substitute for EM&V analysis with control groups that would be designed to determine Net program savings.

Rather, the OpenEEmeter is designed for a broader set of use cases, such as allowing market participants to evaluate the likely return on investment of their energy efficiency projects. It is critical to these third parties that they are able to forecast the risk associated with their investments. 

Therefore, being able to replicate the savings calculation is a crucial precondition of program participation.

Replicable and non-replicable methods
Figure 1. Replicable methods have consistent inputs.

The basic problem

The OpenEEmeter estimates building energy savings that arise after an intervention.

It does this by taking what we know about a building's energy consumption from before an intervention and comparing it to what happens afterward.

Figure 2. Baseline and reporting periods are defined by the endpoints of the project period.

The central question is: how did energy consumption change from the baseline period to the reporting period?

Figure 3. Baseline period minus reporting period consumption.

The simplest approach to finding energy savings is to subtract the reporting period consumption from the baseline period consumption to get savings.

The modifications and modeling considerations necessary to make this simple approach viable are detailed in the next sections.

Temperature response

Accurately determining baseline and reporting period consumption requires accounting for an important exogenous factor: external temperature.

While other exogenous factors affect energy consumption, we focus on temperature because it has the largest and most consistent impact and because temperature data is widely available.

Once we have included temperature data, building energy usage can usefully be broken down into two temperature-related components (a heating and a cooling component) and one weather-independent component (base load).

This makes sense intuitively given the large impact of temperature on building energy use. During cold weather conditions, a building needs to be heated to achieve a comfortable temperature; similarly, hot conditions require cooling. Other elements, such as refrigeration and lighting, remain more consistent over the course of the year and can be represented in the base load.

Figure 4. Temperature-related building energy usage
Figure 5. Building energy consumption broken into base, cooling, and heating loads.

This pattern often leads to energy consumption profiles with a strong relationship to the weather

The characteristics of the heating, cooling, and base load components vary by building and fuel type. For instance, generally only electricity (and not natural gas) is used in cooling loads.

Determining the extent of these heating, cooling, and base loads and their relationships to external weather is the essential task of the OpenEEMeter.

Energy modeling

Let's look at this data in the traditional way, with energy consumption plotted against external temperature. The basic intuition behind this model is readily visible: the more extreme the temperature, the more energy it takes to heat or cool the building to comfortable temperatures. This suggests a model like the one shown.

Figure 6. Building energy consumption plotted against external temperature.
Figure 7. Model suggested by pattern of building energy consumption.
Figure 8. OpenEEmeter candidate models.

But not all buildings line up  exactly with this model. Given this reality, the EEmeter runs data against all four of the following models.  It then scores the results, and chooses the best fit. For more information on the fitting procedure and the exact model construction, see our additional documentation.

For more information on why these four are the models used, see model comparison in the additional documentation.

Additional Documentation [pdf]

Models are evaluated on how well they estimate the observed energy data. Model error is a summary of the divergence between the observed data and the fitted model. The model fitting process is applied independently to the energy data observed in the baseline period and the reporting period.

Figure 9. Model errors for (potentially different) reporting and baseline models.

Energy savings types

There are a few different ways to look at energy savings. The technique you use depends largely upon the question you want to ask. The two most common questions are:

  1. How much has energy consumption decreased since completion of the project?
  2. How do energy savings for this project compare to other similar projects in a typical year?

Gross savings

Figure 10. Gross normalized metered savings represents savings observed since project completion.

We call the first quantity "total gross normalized metered savings". This is the total savings during the reporting period achieved by applying the baseline model to the observed reporting period weather data.

Annualized savings

Figure 11. Annualized weather normalized savings represents as might be observed in a "typical" meteorological year.

We call the second quantity "annualized weather normalized savings". This is expected annual savings not over any observed period, but over a “normal” weather year. The “normal” weather year is an idealized, hypothetical year which is constructed by drawing from observed weather data.This effectively “normalizes” the data by removing some weather uncertainty, and allowing for comparison across projects.

Data preparation

To enable replicability, the OpenEEmeter carefully defines the types of appropriate data used as inputs. The two types of data the OpenEEmeter takes as input are 1) energy data, and 2) project data.

Trace data

In the OpenEEmeter, energy data are stored as “traces”. A trace is a single-dimensional time series of measurements tracked by a single physical meter or smart meter. For instance, many projects are broken into two traces: one natural gas trace, and one electricity trace. This is not a strict requirement, as the number of gas and electricity meters varies from building to building.

Traces are time-series collections of fuel consumption records. Records are identified by start date and, by convention, assumed to continue until the next occurring start date. The final end point and missing data are indicated with null values. Estimated records are indicated with a boolean value.

Figure 12. A single project can have multiple traces, each of which is a single time-series of energy measurement.
Data sufficiency requirements

Project data

The OpenEEmeter accepts only a few special fields of project data. These special fields are

  1. ZIP code
  2. Project start date
  3. Project end date

Additional diverse project data, including building data, measure and intervention data, or contractor data can be associated with OpenEEmeter results after analysis. We refer to this additional data as “project metadata”.

The ZIP code (1) is used for matching the project to nearby weather stations in the same climate zone

The project dates (2), (3) define the project period, which is used for splitting traces into baseline and reporting periods. All traces which correspond to the same project use the same project dates.

Figure 13. Weather station mapping by climate zone.
More about ZCTAs

Data sufficiency requirements

Data sufficiency requirements must be met for each part (baseline and reporting) of each trace (gas and/or electric). If data sufficiency requirements are not met for a particular modeling step, the OpenEEmeter will not compute the results that depend on that modeling step, although it will proceed to calculate all other possible outputs.

The data sufficiency requirements for individual traces are as follows:

For a baseline period:

  1. At least twelve contiguous months of data immediately preceding project
  2. Each month must have at least 50% non-null data

For a reporting period:

  1. At least twelve contiguous months of data immediately following project
  2. Each month must have at least 50% non-null data
Figure 14. Data sufficiency requirements for each trace.


After weather stations have been matched and models have been selected, the OpenEEmeter reports a series of outputs. These outputs include:

  1. Software version
  2. Data sufficiency status
  3. Matched weather station ID
  4. Fetched temperature data
  5. Model fits
  6. Meter derivatives (computed outputs)

Meter derivatives are the official high quality "savings" outputs of the OpenEEmeter and can be used in pay for performance programs, charting, and ad-hoc analysis. These include predicted and observed savings or usage values over baseline, reporting, and normal year periods in time series and as single-value summaries.

How the software works

The core open source software package primarily takes a single serialized input and returns a single serialized output. The input and output formats are all that is needed to run a meter. Both the input and output are structured as JSON, a machine- and human-readable format that is supported by almost every programming language. This helps facilitate taking OpenEEmeter inputs and outputs and using them as part of larger systems. The software is implemented in python and available on github.

Figure 15. Software inputs and outputs.

We welcome your feedback.

Was this guide useful to you? Was there anything that needed more explanation or that seemed incorrect? Please let us know.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form