Add pacific power meters

[s-egge]

No description provided.

[s-egge]

Upload

The data upload for Pacific Power mimics the way that the Solar Meters are uploaded, and is differentiated by the meter_type sent in the upload request.

Download

The pacific_power_meter_id is first requested from the meters table by using the meter_id sent from the front-end, and then it queries the pacific_power_data table with the pacific_power_meter_id.

We currently have a meter_id in the pacific_power_data table, but with the data being grabbed this way we can remove it in order to prevent the need for retroactively adding meter_ids to the pacific_power_data table in the future as we add more meters to the front-end, since the table currently stores all data for meters from the Pacific Power website that have daily data, so there are rows with null meter_ids.

Download Issue

There is still an issue with the data on the front-end. It is being sent correctly from the back-end, but is incorrect after chart.module.js

energy-dashboard/src/store/chart.module.js

Line 67 in 941442c

await chartModifier.postGetData(chartData, reqPayload, this, store)

calls postGetData:

energy-dashboard/src/store/chart_modifiers/line_bar/accumulated_real.js

Line 36 in 941442c

async postGetData (chartData, payload, store, module) {

Testing

To test, change this line to hidden: 0 in order to see all of the newly added buildings:

energy-dashboard/backend/dependencies/nodejs/models/building.js

Line 61 in 941442c

hidden: this.hidden

[s-egge]

Download

The bug above was because the accumulated_real chart modifier expected accumulated energy data every 15 minutes, but Pacific Power meters provide daily non-accumulated energy data. They behave similarly to the Solar Array meters, which use the energy_change chart modifier. In order to avoid duplicating the logic, I added a check in the chart.module.js file that will check if the first meter in the meterGroup is a Pacific Power meter, and if so it will send the data through the energy_change chart modifier without actually changing the point type in the chart data, which would cause issues elsewhere were accumulated_real is expected.

The way that it's checked to be a Pacific Power meter may need work, as I wasn't able to check the meter itself but only the first meter in the meterGroup, but this is working as intended for the moment.

The first image is with actual data from the database, there are days missing due to the webscraper not being automated to run daily right now, so the second picture has 30 days of daily dummy data to demonstrate the chart modifier is working as intended.

Upload

To grab Pacific Power meter data, the download logic will first query the meter table in order to retrieve the Pacific Power meter ID, and then use that to pull the data from the pacific_power_data table. The meter_id is now no longer needed in the PP data table, so I removed the check in both the webscraper and in the upload, as well as removing it from the table. This will prevent us from needing to manually update the table with meter_ids as we add more buildings to the front-end.

[solderq35]

Added offset to make time of day consistent with other daily meters

Rest of PR looks fine to me. I'm not sure why accumulated_real shows non-existent data as "zero" on the frontend (check Memorial Union), while energy_change just skips over the missing data point. But for now I don't think it's a big deal.

[solderq35]

The way that it's checked to be a Pacific Power meter may need work, as I wasn't able to check the meter itself but only the first meter in the meterGroup, but this is working as intended for the moment.

Should be fine, I think it's safe to assume that all Pacific Power meters will not mix with other types of meters in a meter group.

[solderq35]

See OSU-Sustainability-Office/automated-jobs#21 (comment)

I think the PR as it is now is good to go, but it might be a good idea to look into a better way of handling missing data (pacific power site doesn't show yesterday's data yet) in the future.