The OpenEEmeter is an open source software package that uses metered energy data to manage aggregate demand capacity across a portfolio of retail customer accounts. The software package consists of three main parts:
- an Extract-Transform-Load (ETL) toolkit for processing project, energy, and building data (https://github.com/openeemeter/etl/);
- a core calculation library (this package) that implements standardized methods (https://github.com/openeemeter/eemeter/); and
- a datastore application for storing post-ETL inputs and computed outputs (https://github.com/openeemeter/datastore/).
More information about this architecture can be found in Architecture Overview.
Core use cases¶
The OpenEEmeter has been designed specifically to provide weather-normalized energy savings measurements for a portfolio of projects using monthly billing data or interval smart meter data. The main outputs for this core use case are project and portfolio-level are:
- Gross Energy Savings
- Annualized Energy Savings
- Realization Rate (when savings predictions are available)
More information about these methods can be found in Methods Overview.
Other potential use cases¶
The OpenEEmeter can also be configured to manage energy resources across a portfolio of buildings, including potentially:
- Analytics of raw energy data
- Portfolio management
- Demand side resource management
The EEmeter requires a combination of trace data, project data, and weather data to calculate weather-normalized savings. At its most rudimentary, the EEmeter requires a trace of consumption data along with project data indicating the completion date and location of the project.
The EEmeter is configured to manage project and trace data. Trace data can be electricity, natural gas, or solar photovoltaic data of any frequency - from monthly billing data to high-frequency sensor data (see 1) Meters and Smart Meters - where does energy data come from?).
Where project and trace data originate from different database sources, a common key must be available to link projects with their respective traces.
Project data is typically a set of attributes that can be used for advanced savings analytics, but at minimum must contain a date to demarcate start and end of intervention periods.
Each project must have, at minimum:
- a unique project id
- start and end dates of known interventions
- a ZIP code (for gathering associated weather data)
- a set of associated traces
Other data can also be associated with projects, including (but not limited to):
- savings predictions
- square footage
Each trace must have, at minimum,
- a link to a project id
- a unique id of its own
- an interpretation
- a set of records
Each record within a trace must have:
- a time period (start and end dates)
- a value and assiciated units of
- a boolean “estimated” flag
The EEmeter will reject traces not meeting built-in data sufficiency requirements.
To load data into the datastore, EEMeter comes bundled with an ETL Toolkit. If you are deploying the open source software, you will need to write or customize a parser to load your data into the ETL pipeline. We rely on a python module called luigi to manage the bulk importation of data.
More on this architecture.
You may decide that you want to use EEmeter results to analyze project data that does not get parsed and uploaded into the datastore. We have made it easy to export your EEmeter results through an API or through a web interface. Other options include a direct database connection to a BI tool like Tableau or Salesforce.