search

NREL / OpenOA

This library provides a framework for assessing wind plant performance using operational assessment (OA) methodologies that consume time series data from wind plants. The goal of the project is to provide an open source implementation of common data structures, analysis methods, and utility functions relevant to wind plant OA.
https://openoa.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
183 stars 62 forks source link

Create a Greenbyte API data connection #280

Open charlie9578 opened 7 months ago

charlie9578 commented 7 months ago

I'd like to include a method to use data from Greenbyte's API in OpenOA, so that companies using this secondary SCADA platform are able to simply enter their API key, select their site, and run the analysis. It might be nice to develop a series of IO modules to support other data systems too. Does this sound reasonable?

RHammond2 commented 7 months ago

After chatting in bit more detail and thinking on this @charlie9578 I think this is a really great idea that could help demonstrate how to solve workflow issues for others as well.

My initial thought is to set up something akin to the from_enter method, but I'm not sure this would work if we have to modify the Greenbyte API. I think we could another utils module that can host these methods, so PlantData can have a from_xx method for each that acts as a thin wrapper.

@ejsimley I'm curious on your thoughts here.

ejsimley commented 7 months ago

I think this is a great idea, and it probably makes sense to add a utils module for Greenbyte (and potentially other data platforms) to import data. We would need to work closely with you @charlie9578, or someone else who uses Greenbyte, to develop and test this feature. If you're interested, we could come up with a plan.

charlie9578 commented 6 months ago

I'm interested, and happy to develop this feature... but I think worth discussing how best to make it work.

My initial feeling is that including it in the utils would be a good option, as it could support development of a selection of connectors to different systems. To an extent this and issue #279 could be considered two sides of the same coin when it comes to integrating new datasets, just one is for open data and the other closed.

RHammond2 commented 6 months ago

I agree, @charlie9578, this is certainly related to #279, though I'd propose taking a piecemeal approach since each API is going to differ quite a bit. Do you happen to have a working example? I'd lean towards utils with a thin wrapper in the PlantData class like is done with the ENTR connector. Though I feel that each is going to require its own Python API client, so it might be useful to have a package within the utilities, like utils/apis or utils/connectors or similar, and have separate modules for each external API connection to avoid unnecessary package requirements for the varying use cases.