Meter Data: if data spans month, program reports No Data for Interval == Month

[RDmitchell]

Expected Behavior

Imported monthly ESPM meter data. Expected to see monthly data for both filters Exact and Monthly

This is not a high priority for now, as the data can always be displayed by setting Interval to Exact. This should not delay the release of the Meter Data feature.

Actual Behavior

Clicked on Filter = Month and program reported no data. Clicked on Filter = Exact and program displayed monthly data

This is because the monthly data spans more than one month. So for now the program doesn't try to figure out how to aggregate it over individual months.

Steps to Reproduce

• Import monthly ESPM data

• Default Interval = Exact displays the monthly data

• Setting Interval = Month, program displays "No Data"

Instance Information

Instance: dev1 (NREL) SHA: e120119f

[RDmitchell]

It might be good to add this to the FY 2020 list, ie, implement an algorithm that pro-rates the energy usage between the spanned months, so that the user can see the monthly aggregated data in a reasonable way.

I believe ESPM is doing this in their Custom Report Template when they show aggregated monthly energy data (not by meter, but aggregated across all meters), so we might want to implement a similar algorithm, so that SEED would give the same aggregated result as ESPM (?? Not sure this is necessary but something to think about).

[nllong]

@adrian-lara Can we have this default to exact if there is no monthly data roll up available? Else, default to monthly?

[adrian-lara]

@RDmitchell and @nllong the handling of generating Monthly (or Annual) Interval data has changed from the time when this issue was created.

Currently, SEED does the following for these intervals: The start time and end time must be fully contained within a month for the program to report an entry for a specific month (when Interval == Month). The caveat here is an end time of one month could be the very beginning of next month. For example, August 1 00:00:00 is an acceptable/readable end time for an entry contained within the month of July.

Currently, this means that the example presented in the initial comment is no longer "a problem"

Given this information, do we still we want to implement some kind of default interval or pro-rating logic? Defaulting the interval could definitely be done in an "all-or-nothing" type of way - either all the data can be completely shown by month or exact times are shown on page load. The pro-rating could be complicated given the current algorithm used to provide aggregated interval data.

[RDmitchell]

Maybe we should move this to the December project, and ponder what to do about it. ESPM has some logic they use for pro-rating, and we could decide to implement that, or we could come up with some other solution.

[nllong]

@RDmitchell -- sounds good. let's move to December.

[adrian-lara]

@RDmitchell @nllong Hoping to revisit this conversation and potentially start working on any proposed changes. Let me know if you two would like to discuss on a call, otherwise feel free to respond here with your thoughts/questions, etc.

[RDmitchell]

@nllong -- do we want to query someone at EPA/Portfolio Manager to determine what their algorithms are for this, so that the 2 programs get the same result for the same data? Not sure if it's possible, but might be worth an email?

[github-actions[bot]]

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]]

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.