BJReplay / PowerwallService

This windows service can log data from a local Powerwall to a local database and / or an azure database, can control pre-charging during off-peak, and can upload data to PVOutput.
9 stars 0 forks source link

SolCast HTTP Error #1

Closed spoonwzd closed 6 years ago

spoonwzd commented 6 years ago

Hi,

First time setup; SolCast not working for me - I get a HTTP 400 bad request event:

The remote server returned an error: (400) Bad Request.

at System.Net.HttpWebRequest.GetResponse() at PowerwallService.PowerwallService.GetSolCastResult[JSONType]()

...and then...

Object reference not set to an instance of an object.

at PowerwallService.PowerwallService.GetForecasts()

API key / longitude / lattitude / systemcapacity / tilt / azimuth / installdate all correctly defined in the .config

Advice welcome!

BJReplay commented 6 years ago

Can you share the relevant snippet from your config file (excluding the key)?

You can test the call in your browser as shown below.

The Solcast API is pretty good at reporting why a call doesn't work (for example, I substituted in 4850kW for capacity (instead of 4850)

https://api.solcast.com.au/pv_power/forecasts?longitude=140.9&latitude=-34.2&capacity=4850kW&tilt=0&azimuth=0&install_date=20150419&api_key=INSERT_YOUR_API_KEY

and it returned

SerializationException | capacity | '4850kW' is an Invalid value for 'capacity'

But I haven't captured the detailed response in the exception handler. It's only a few lines of code, so I'll add that tonight to capture the detailed response and log that to the event log, but at first guess it is a badly formed parameter.

spoonwzd commented 6 years ago

Sure, which snippet do you want? :)

      <setting name="SolcastAPIKey" serializeAs="String">
        <!--Obtain and API key from solcast.com.au and put it here to obtain forecasts for your solar system-->
        <value>narp</value>
      </setting>
      <setting name="PVSystemLongitude" serializeAs="String">
        <!--Put your longitude here - use google maps to work it out-->
        <value>50.719087</value>
      </setting>
      <setting name="PVSystemLattitude" serializeAs="String">
        <!--Put your lattitude here - use google maps to work it out-->
        <value>-3.488382</value>
      </setting>
      <setting name="PVSystemCapacity" serializeAs="String">
        <!--Put your PV system capacity here-->
        <value>3.68</value>
      </setting>
      <setting name="PVSystemTilt" serializeAs="String">
        <!--Put your PV system tilt or elevation here-->
        <value>30</value>
      </setting>
      <setting name="PVSystemAzimuth" serializeAs="String">
        <!--Put your PV system azimuth here (what compass direction does it face? 0 for north, 90 for east, 270 for west, and so on-->
        <value>130</value>
      </setting>
      <setting name="PVSystemInstallDate" serializeAs="String">
        <!--Put your PV system install date here in yyyy-MM-dd format - this allows solcast to take into account aging in the forecast-->
        <value>2018-02-18</value>
      </setting>
spoonwzd commented 6 years ago

Message from Anthony:

You haven't put a Solcast API key value in (changing it from TODO to narp is not going to work...)

narp Read the documentation (Powerwall Service.pdf) and set up correctly (specifically "An API account at solcast.com.au" on p5) ------------- I have in my config, I’ve just anonymised the key when publicly posting 😊
spoonwzd commented 6 years ago

https://api.solcast.com.au/pv_power/forecasts?longitude=50.719087&latitude=-3.488382&capacity=3.68&tilt=0&azimuth=130&install_date=20180218&api_key=MY_API_KEY

Yields good results

spoonwzd commented 6 years ago

If I manually update the SolcastAddress line in the .config with the specific data instead of relying on the defined variables, ie:

<value>https://api.solcast.com.au/pv_power/forecasts?longitude=50.719087&amp;latitude=-3.488382&amp;capacity=3.68&amp;tilt=0&amp;azimuth=130&amp;install_date=20180218&amp;api_key=MY_API_KEY&amp;format=json</value>

...then the event log reports success:

Three Day Forecast

Date: 4/4/2018 12:00:00 AM Total: 8.343851 Morning: 0
Date: 4/5/2018 12:00:00 AM Total: 19.00828 Morning: 8.890236
Date: 4/6/2018 12:00:00 AM Total: 18.94926 Morning: 8.911198
BJReplay commented 6 years ago

Parameters look reasonable - but specify the capacity in watts, not kW (so you should have 3680 as the capacity).

Given it gets the forecast with the actual address in the config at least you've got a workaround.

My last guess before attempting to debug with my API key is that it might have been the API key wasn't specified correctly.

spoonwzd commented 6 years ago

Thanks, I've updated the config for watts.

I 100% guarantee you that the API key is identical to the line I have manually defined vs the SolcastAPIKey string value. In fact, I actually copied it from there into the other string. Promise. :)

BJReplay commented 6 years ago

I've now changed it to log the response on an exception, so if you can reproduce it, we'll have the detailed response.

BJReplay commented 6 years ago

https://github.com/BJReplay/PowerwallService/blob/master/PowerwallService.exe now logs the response if there is an error calling solcast. No other changes.

spoonwzd commented 6 years ago

Stopped service, replaced exe, uncommented the original code and commented out my line....

...and it now works?!

Three Day Forecast

Date: 04/04/2018 00:00:00 Total: 5578.506 Morning: 0
Date: 05/04/2018 00:00:00 Total: 17131.13 Morning: 6556.296
Date: 06/04/2018 00:00:00 Total: 17008.39 Morning: 6577.941
spoonwzd commented 6 years ago

And now after changing my azimuth to 220 and restarting the service...

The remote server returned an error: (400) Bad Request.

   at System.Net.HttpWebRequest.GetResponse()
   at PowerwallService.PowerwallService.GetSolCastResult[JSONType]()

I don't get this inconsistent behavior...!

spoonwzd commented 6 years ago

Ok, inconsistency possibly due to the fact I was editing the file remotely. Editing the config locally, I get consistent results.

I also have no additional event logs regarding the HTTP request failure...

spoonwzd commented 6 years ago

Sorry, but this is still an issue.

Things are currently working because I have manually defined the SolcastAddress string without using any of the variables. I've just not progressed this as we've had other priorities...

spoonwzd commented 6 years ago

Sussed it.

The definition of PVSystemAzimuth is incorrect. It needs to read:

<!--Put your PV system azimuth here (what compass direction does it face?) -180 for North, -90 for East, 0 for South, 90 for West -->

AnthonyBe commented 6 years ago

Hmmm... you're in Northern Hemisphere right? The azimuth was working just fine for me in Southern Hemisphere.. I wonder if Solcast have some weird quirk with their system relating to hemisphere?

spoonwzd commented 6 years ago

If your azimuth is somewhere between 0-180 you won't have noticed an issue, however it's likely your PV forecast is more inaccurate as a result.

My East / West systems are 130° & 310° which I averaged to 220°. If you try plumbing this into SolCast, it spits out an error detailing the issue:

image

AnthonyBe commented 6 years ago

Right. Mine are a mix of NE and NW so just averaged mine as North, i.e. 0.

AnthonyBe commented 6 years ago

Actually, that just got me thinking..

Rather than averaging them, would it be better to define them as 2 separate 'systems' (can't recall if this service has the bility to do this or not) so as to get more accurate predictions?

E.g. in my case, while my entire system is 6930W, more accurately my system has 2 banks of panels:

  1. 1980W facing NE

  2. 4950W facing NNW

If the system could treat these independently, it should make predictions a lot more accurate shouldn't it?

spoonwzd commented 6 years ago

As your two systems aren't identical then averaging them is going to give you results that are a bit skewed I think.

You're right of course - ideally you would define systems separately along with their appropriate azimuth / tilt / etc - this would make prediction much more relevant for unbalanced strings like yours.

@BJReplay did confirm this was not a feature of SolCast, but I think it could still be implemented by querying the API for both systems separately and then merging the results. Of course, coding this is harder then coming up with the idea and I'e been tying him up with other issues! :)

I'm still comparing daily estimates to my generation stats to see if I can find a sweet spot for the PV size. While my systems are identical 3.54kW East/West (ish) facing, averaging the azimuth is still not ideal even for me and I've had to increase the defined inverter size to compensate.

Then there's the fact that SolCast isn't probably the best choice of source data for my location on the planet. Their web site states, "Our data is global, with increased detail and update frequency in satellite coverage areas - currently Australia, North and Central America and East Asia." So not me then!

I found the following tool useful for establishing panel orientation: http://tools.solmetric.com/Tools/roofazimuthtool

spoonwzd commented 6 years ago

So I thought I'd try and make sense of a way to work out the expected PV generation of my East / West panels, but I'm afraid I'm left even more confused.

Tomorrow's forecast using an average azimuth of +40 (220°) and inverter limit set at 3680 (max inverter limit), I have an estimate of 10286 (370 morning)

If I measure just my South East panel azimuth -50 (130°) and inverter limit set to 3540 (max East PV string output), I have an estimate of 11929 (3511 morning).

If I measure just my North East panel azimuth 130 (310°) and inverter limit set to 3540 (max West PV string output), I have an estimate of 19369 (418 morning).

The actual local weather forecast for the day is a cloudy one, with a small chance of sun in the afternoon - which is similar to today. Today I generated around 10kWh.

So on the face of it, averaging the azimuth gives the most accurate estimate in theory, but not for the morning. If anything, just the South-East array provides more convincing results for morning generation. Averaging the results of the individual strings paints a very different picture.

Can anyone help me understand what's going on here? Does the tilt angle for a East facing roof need to be different like the azimuth is? Despite extensive searching online I'm unable to find a clear answer.

spoonwzd commented 6 years ago

I've asked the question on the Solcast community forums. Let's see if anyone there has some advice...

spoonwzd commented 6 years ago

The response was "I have two solar arrays too and managed to get a suitable generation prediction by making a separate API call for each array then combine the two results by adding them together. You can then cap the resultant output at any given time point to be no more than your inverter’s max output"

As this takes us considerably off-topic from the original post, I shall close this and open a feature request as it seems my generation estimates don't stand a chance of being close to correct as it stands, and the original problem was identified as a configuration description issue.

spoonwzd commented 6 years ago

Seems I was previous incorrect about how Solcast handle their azimuth. From their FAQ:

The angle (degrees) from true north that the PV system is facing, if tilted. Must be between -180 and 180. An azimuth of 0 means the system is facing true north. Positive values are anticlockwise, so azimuth=-90 for an east-facing system, and azimuth=135 for a southwest-facing system. Default value is 0 (north-facing) in the southern hemisphere, 180 (south-facing) in the northern hemisphere.

@BJReplay please can you update the documentation / readme / etc.