Closed s-egge closed 9 months ago
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.
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_id
s as we add more buildings to the front-end.
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.
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.
See https://github.com/OSU-Sustainability-Office/automated-jobs/pull/21#issuecomment-1960520980
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.
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 themeters
table by using themeter_id
sent from the front-end, and then it queries thepacific_power_data
table with thepacific_power_meter_id
.We currently have a
meter_id
in thepacific_power_data
table, but with the data being grabbed this way we can remove it in order to prevent the need for retroactively addingmeter_id
s to thepacific_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 withnull
meter_id
s.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 https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/941442c79fc649f9bac0bf86422327c34dd8f5df/src/store/chart.module.js#L67
calls postGetData:
https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/941442c79fc649f9bac0bf86422327c34dd8f5df/src/store/chart_modifiers/line_bar/accumulated_real.js#L36
Testing
To test, change this line to
hidden: 0
in order to see all of the newly added buildings: https://github.com/OSU-Sustainability-Office/energy-dashboard/blob/941442c79fc649f9bac0bf86422327c34dd8f5df/backend/dependencies/nodejs/models/building.js#L61