Closed spoonwzd closed 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)
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.
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>
Message from Anthony:
You haven't put a Solcast API key value in (changing it from TODO to narp is not going to work...)
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&latitude=-3.488382&capacity=3.68&tilt=0&azimuth=130&install_date=20180218&api_key=MY_API_KEY&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
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.
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. :)
I've now changed it to log the response on an exception, so if you can reproduce it, we'll have the detailed response.
https://github.com/BJReplay/PowerwallService/blob/master/PowerwallService.exe now logs the response if there is an error calling solcast. No other changes.
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
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...!
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...
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...
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 -->
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?
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:
Right. Mine are a mix of NE and NW so just averaged mine as North, i.e. 0.
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:
1980W facing NE
4950W facing NNW
If the system could treat these independently, it should make predictions a lot more accurate shouldn't it?
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
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.
I've asked the question on the Solcast community forums. Let's see if anyone there has some advice...
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.
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.
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!