Frog 1 bad data January 2018

[kathrynparadis]

For the whole month of January in Frog 1 of the FrogUHM database, there was bad data for the Whole building net egauge appliance (purpose_id: 84, 85) in the system. We had the absolute value of the data values, and no way to revert it to the original value. This happened due to an improper configuring of the Egauge by the electrician (not scrap-util's fault).

Eileen took the data out of the readings table (so we don't have January data for that egauge in the database), however in the egauge_5min_avg_view2 view she took the Webctrl whole building data, and averaged it to 5 minute readings to "replace" the egauge data for just that view (which we will eventually use in our 'dashboard ___' views). (Our 'dashboard ____' views have so far been used to give data to Sara for use in her report.)

[kathrynparadis]

Sara recently asked us to check this again because the whole building data was bad for the same time period.

Eileen's "Notes on Data" document with her notes for the Frog buildings from the same day as my previous post on this Github issue do not match. Her notes say that the Whole building net (purpose_id: 40, 50, 96, and 109) data was bad, while my previous post says Whole building net egauge (purpose_id: 84, 85) data was bad due to improper configuring of the Egauge.

It seems that the data for both Whole building net egauge (purpose_id: 84, 85), and Whole building net (purpose_id: 40, 50, 96, and 109) are bad from the sources (Egaurd & Webctrl).

Sara will not be using data before PV installation (Jan 22) for her analysis since we don't have whole building data for before then.