Discovering eensight

[victorbsrd]

Hello @hebes-io ! I've recently being interested in your work, and I spend 2/3 hours looking at the code, doc and playing with it.

Unfortunatly I'm a bit stucked right now:

• the current doc of the book is not working. The Design-Principles.ipynb assumes there is a "preprocessed" folder for building B01 for instance. But it doesn't exists in the data you provide. (clone this repo and try to run the notebook, you'll be able to reproduce the error)
• Ok not, big deal, I tried to run "run preprocess" to create it. But there is little documentation about it; how to use "store-uri" ? All my attemps felt into "No partition dataset" error, and it's hard to debug.

Could you please have a look at this ? Thank you :), happy to go further into details.

[hebes-io]

Thank you for reaching out victorbsrd.

Overall, the best way to understand where the eensight tool reads and writes its files and models is by looking at its catalogue.

The first pipeline should always be the preprocess one, unless a preprocess folder is already there. It is easier if you first run the commands with the --no-tracking flag so that you do not need to keep track of the IDs that correspond to each run (IDs are added to the paths where the generated artifacts are saved).

The preprocess pipeline operates on the input data. You will see in the catalogue that the input features should be located at an {{ input_uri }}/{{ namespace }}/features folder and the labels at an {{ input_uri }}/{{ namespace }}/labels folder. In this case, you need to pass to the CLI the --input-uri argument (as well as the --namespace one, since each pipeline does different things for different namespaces).

Alternatively, the input features can be located in an {{ store_uri }}/{{ site_id }}/01_raw/{{ namespace }}/features folder and the labels at an {{ store_uri }}/{{ site_id }}/01_raw/{{ namespace }}/labels one. The --store-uri argument will also define where all the generated models and files will be saved (if you go through the catalogue, you will see that all artifacts are stored in paths that start with {{ store_uri }}/{{ site_id }}).

It is a bit opinionated, but this structure is meant to support the application of the tool on a large number of buildings (each building having its own site_id).

The predict pipeline assumes that the artifacts from the preprocess pipeline are already available, and the evaluate and adjust pipelines that the artifacts of the predict pipeline have been generated.

I hope this helps.

[victorbsrd]

Thank you for your answer:

• 1) if you allow, I will add few lines to the documentation, with your answer and working notebook so that any other newcomer won't fall into the same issue
• 2) Reading your answer I realized I read to fast the doc, features should be in {{ **store_uri** }}/{{ site_id }}/01_raw/{{ namespace }}/features, but I read {{ **input_uri** }}/{{ site_id }}/01_raw/{{ namespace }}/features. This fixed it's running now !

I'll continue to explore, many thanks !

[victorbsrd]

Hello again :) very interesting work. The documentation of the model is well explained.

Two questions : 1) Technical one: you documented approach to quanitfy energy savings from events that either impacts impact variable (retrofit) or mapping variable (covid). But if my understanding is correct, it is exclusive right ?

• what happens in the case we have a retrofit + a conjectural event (for instance, gas crisis in europe, leading to "energy soberty") happens ? If we consider the impact variable approach, retrofit gains will be over estimated because it will take into account energy soberty. If we consider mapping approach, the retrofit gains will be close to 0, as everything will be accounted as a change in occupancy density levels ?

  2) Business one:

• Your work is quite advanced. I saw some work build on your approach, to launch services (here). What are top applications in the fields for this kind of work according to you ? Both at short and long term.

Happy to connect

[hebes-io]

Hello victorbsrd.

Let me start with a brief description on how eensight came about. eensight was developed to support an ambition to bring the Pay-for-Performance (P4P) concept for energy efficiency from the US to Europe. The main idea behind P4P is that if there is an organization that provides grants/subsidies for energy efficiency upgrades in buildings, it can choose to provide these financial incentives based on actual impact (actual savings) instead of just matching (part of) the incurred costs for the upgrades.

The SENSEI project was mainly about discussing with different public authorities in Europe to see if the P4P concept is relevant to them. One of the issues that was consistently raised is what happens if something changes in a building so that there is a detectable change in energy consumption but it cannot/should not be attributed to the upgrade. The most interesting ideas for solving this problem can be found in IPMVP's Manual on Non Routine Adjustments. There is a detailed presentation of the manual here. The manual is conceptual in the sense that it does not provide actual implementations of the methods it proposes. eensight is an implementation of the chaining method for adjustments (you can find details about the chaining concept in the documents at the bottom of this page: https://facilityenergysolutions.com/publications).

In P4P, a program administrator issues a Request for Participation that is addressed to companies and commercial collaborations that have the expertise and capacity to reach consumers and install energy efficiency measures (these companies are often referred to as aggregators because they aggregate a lot of small-scale projects together). As a result, a P4P program "sees" a large portfolio of buildings, where usually the only available data is whole-building energy consumption and outdoor temperature. Given this data, eensight does a good job in identifying what changes in energy consumption to attribute to an efficiency upgrade; it is not hard to come up with cases where the model will have a hard time doing so accurately, but still it beats any alternatives when you have limited data sources.

A challenge that will always exist when you do have limited data sources is that you cannot deal with, for instance, changes in a heating system's efficiency and systematic changes in the way it is used (occupancy levels and the internal heat gains that they generate) at the same time. If there is a period where a retrofit and a conjectural event do not overlap, you can identify their impact, but if they always overlap, one will always mask the effects of the other. This is not the case if you have additional data sources, such as meters exclusively for the HVAC systems. We have been developing M&V methods for such cases, but eensight is meant for P4P applications where the availability of additional data sources is not common.

Let's connect through Linkedin. I am here.

My wishes for a happy and productive 2024!