weather_forecast_cache (solcast)

[GeoDerp]

Changes

• New runtime parameter created weather_forecast_cache, for caching results of a weather forecast to Pickle file: (Only supports Solcast as of now)

  curl -i -H 'Content-Type:application/json' -X POST -d '{"weather_forecast_cache":true}' http://localhost:5000/action/dayahead-optim

  Example: Ran in the morning with day-ahead to store current days forecast data.
• New push action for running forecast separately, try to cache result to Pickle file: (Only supports Solcast as of now)

  curl -i -H 'Content-Type:application/json' -X POST -d {} http://localhost:5000/action/forecast-cache

  Example: Run a couple of times throughout the day to update cached forecast data with the current Solcast data.
• EMHASS will check to see if there is a weather_forecast_data pickle file. If so, forecast will use the file instead of sending a POST request (Only supports Solcast as of now)
• Added custom header for Solcast POST requests, following Solcast CTO's guidelines
• Adjusted Solcast error handling

Pprogress

• Test
• Add documentation
• Adjust naming conventions
• Check error handling
  • File exists but no data
  • User runs forecast but data has expired
  • Other weather forecasts (optional)
• Add tests (optional?)

[GeoDerp]

It should be noted we have been given permission by Solcast to use their API via the EMHASS application. We have also been given some conditions to follow with the use of the Solcast API for EMHASS:

"The only endpoints that are permitted under this use are the rooftop_sites/* urls from https://docs.solcast.com.au/#f60d61ac-d11e-412e-b47b-af8844cea252"

• As EMHASS uses the https://api.solcast.com.au/rooftop_sites/solcast_rooftop_id/forecasts url, i don't believe any modification is needed.

"Use a custom User-Agent string in the HTTP requests that you are making so we can attribute traffic that is coming from your service/platform."

• A 'User-Agent': 'EMHASS' header has been implemented into this PR to adhere.

"To the extent that you can control how the users access the API, spread out the request times (e.g. by adding a random number of minutes) so that all the requests from your platform don't flood the API at the same time."

• Due to the nature of EMHASS, I dought that many users will be calling the Solcast API at any one time.
• However, we may need to watch for this, if the EMHASS user space grows, or if a scheduling feature is considered down the track.

The Solcast results should only be seen by the holder of the API key

• This PR converts the cache data into a pickle file, making a it little more difficult for users copy and past the Solcast output.
  However, in the end of the day its up to each EMHASS user to agree to the Solcast terms of service.

"If the number of users grows significantly or starts to cause problems that impact our ability to deliver the data to paying customers, Solcast reserves the right to revoke this permission."

• If EMHASS becomes a more enterprise grade product, I hope that EMHASS works more closely with Solcast. May be cool to work with Solcast to gain analytics on how many people use Solcast with EMHASS down the track.

A big thank you goes to the team over at Solcast for allowing us the permission to use the API. Its companies like them that can help the community to lower the carbon footprint and power costs.

[GeoDerp]

@davidusb-geek , we are currently running this Solcast PR at home without any issues. Haven't done a thorough test but feel free to pull it in. I could also make some unittests for the PR if requested.

[GeoDerp]

The last few commits added:

• more error reporting
• cache file will delete automatically if it detects the stored timestamps in the file is too old (while running an optimization)
• added weather_forecast_cache_only runtime parameter. when passed this will force the optimization to only use previously cached data. Otherwise it will produce an error.