search

SEED-platform / seed

Standard Energy Efficiency Data (SEED) Platform™ is a web-based application that helps organizations easily manage data on the energy performance of large groups of buildings.
Other
107 stars 55 forks source link

ESPM Custom Report Template -- add importing of monthly energy data #1736

Closed RDmitchell closed 2 years ago

RDmitchell commented 5 years ago

Expected Behavior

The ESPM Custom Report Template now includes the option to specify monthly electric and gas consumption. This data is reported on a 2nd tab in the downloaded Custom Report Template data.

We need to add the capability to import this monthly data, both importing "by hand" and importing via the ESPM login functionality in SEED.

Here are some screen shots from a power point from ESPM (the PPT is also included in the gdrive folder for this issue) image This is the format of the 2nd tab There is one record per month, so 12 records per year for one PM Property ID. I believe we dealt with this again in the CMU code, but we will probably want to revisit how we store and represent this data. image

The sample file is also included in the gdrive folder for this issue

Actual Behavior

We used to have a similar functionality in the CMU version where we could upload an ESPM spreadsheet with a 2nd tab with meter data, but we have disabled that functionality.

Steps to Reproduce

N/A

Instance Information

N/A

RDmitchell commented 5 years ago

@adrian-lara / @nllong -- this is another flavor of how to get meter data from ESPM

I'm thinking we don't support this yet?

RDmitchell commented 5 years ago

@nllong / @adrian-lara -- tested with sample file I generated from the ESPM test account, and the program does not currently support this format (2 tabs).

So I will move this out of test and put it in the To Do column of the June 2019 project.

adrian-lara commented 5 years ago

@RDmitchell This is the format that the app was originally set up to receive. The last we checked, this no longer exported from ESPM itself. Did that change?

RDmitchell commented 5 years ago

@adrian-lara / @nllong -- sigh ...

I guess somehow I didn't see this issue, although it looks like it was in the Test column of the (presumably) June 2019 project. If when I started testing this, I had looked at this issue, I would have immediately known where to look for this style of meter data, and might not have sidetracked us on the other option for getting meter data.

So yes, I guess this is a 2nd way to get the monthly meter data. And I am guessing that we need to support this file as well as the other spreadsheet file.

Not to take away the fault from me not realizing that this was the issue I should test against, I think it would be good when something is ready for testing, that it is clear to me what the "spec" is that I am testing against. For some reason, in this case, I didn't realize this was the issue I should have been looking at for testing, and so I basically started over in ESPM to figure out how to get meter data, forgetting that this was an option.

I'm not sure how to prevent this is in the future, but possibly making sure that when a feature is implemented, that there is something, an issue or a doc, that says, "this is what was implemented (referencing the issue / doc) and this is how to test it. "

Now the decision is whether or not to take the time to implement this second option (or maybe it's the first option). It is true that most of the SEED users use the report template to get their data, so this method is probably going to be preferred by the users.

Sorry that I led you down the wrong path into changing what was the correct implementation in the first place. I just hope that we can figure out a way to prevent this from happening in the future. :<

adrian-lara commented 5 years ago

@RDmitchell No worries - these things happen! 😄

In regards to how this could have been prevented, I agree that basing work on a written document/issue is a great path to take. Though I will say that specifically for this case, looking back, we collectively didn't realize that more research/information was needed on the capabilities of ESPM and how users typically export meters. I think when we started, we all felt good about the general understanding of how ESPM produced meter data, so we proceeded with that.

But actually, I think this ended up working out for the better. It seems that these report templates do some aggregation/summarizing/combining of actual meters. In a very notable case, Electric - Grid, Electric - Solar, and Electric - Wind are all separate Meter Types in ESPM, but in these custom report templates, they get lumped together to a column called "Electricity Use (kBtu)". When we only knew about these custom report templates, we thought that the generic "Electricity" was an actual meter type from ESPM as opposed to a summary/aggregation of the 3 actual ESPM electric types. Knowing that this is an aggregation is key in keeping ESPM and SEED meters as apples-to-apples as possible. To go even further, even when knowing this is a summary column, upon receiving this report with "Electricity Use (kBtu)", we would have no way of knowing how to split the readings into the actual electricity meters.

Ultimately, with the understanding that these custom report templates do some generalizations that hide the actual underlying meters of ESPM, I think supporting these formats would be either very difficult or impossible without creating large inconsistencies between meters within SEED and ESPM.

RDmitchell commented 5 years ago

@adrian-lara -- right, this makes sense. We will keep the existing import of the ESPM portfolio spreadsheet which breaks out the energy by meters, and then at some point later, we can possibly (?) include the monthly energy data from the Custom Report Template.

RDmitchell commented 5 years ago

@nllong -- this is the issue that I think we should add to the FY 2020 list of features, as this is the way that most cities using ESPM are going to get monthly data. I found out today from one city that the building owners don't even share their detailed meter data with the city, so this aggregated data is the only method for the city to get more detailed information about the building energy use.

The trick will be deciding whether to include it in the existing meter functionality, which may not make sense because it doesn't break the data down by meter. On the other hand, the meter functionality does have the ability to aggregate the data by month and by year, so maybe this aggregated monthly data could somehow be incorporated into that aspect of the meter functionality ?? Not sure.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity within 60 days. It will be closed if no further activity occurs. Thank you for your contributions.

github-actions[bot] commented 2 years ago

This issue has been closed automatically. If this still affects you please re-open this issue with a comment or contact us so we can look into resolving it.