article

Dirk-Jan Faber (Victron Energy) avatar image
Dirk-Jan Faber (Victron Energy) posted

Node-RED: Fetch forecasted solar yield

As briefly shown during todays webinar, I've created a simple subflow that allows to easily fetch the predicted solar yield for a given location. I believe that this subflow can be very useful for determining how and when to charge your batteries.

Under the hood it uses the public API of https://forecast.solar/. That is free for 12 queries per ip per hour, but if you start using it, please consider creating a personal account.forecast-solar.pngConfiguration is straightforward:

forecast-solar-config.png

All fields are quite self explanatory and the documentation of the modules also gives more information on each field. The api key is not required, but with it you will be able to query more often.

My subflow can be found on https://flows.nodered.org/flow/d83d3224f241ec4abf6f9f119bbee9cc. In order to get the flow into Node-RED, copy the flow from the linked page and import it into Node-RED (ctrl-i).

Of course there are alternatives out there:

- https://flows.nodered.org/flow/a1907502b7256a0e4bcf408fbee93411 uses solcast for doing the same thing. But that one requires a bit more manual adjusting and a (also free) registered API account.

Node-REDsolar
59 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

I have updated the flow with an example showing how to combine different solar arrays into a single graph.


1 Like 1 ·

I've just updated the subflow to make it easy to generate a graph from it. All that is needed is to connect a line or bar chart to the second output of the subflow.
1673277033248.png

0 Likes 0 ·
1673277033248.png (38.8 KiB)
nickdb avatar image nickdb ♦♦ Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

I’ve been using the original subflow for a while now, just parsing it with a function to extract the forecast in kWh to make it easier to use for my purposes. It has been surprisingly accurate.

1 Like 1 ·
Show more comments
johnone avatar image johnone commented ·

Thanks for sharing this - obvs, forecasting is an important part of optimising self-consumption. First thing for me is exploring accuracy - yesterday's forecast accurately predicted the likely low yield today, given unrelenting rain (UK Midlands).

I have a 1770Wp free-standing, facing due south, array - will write a bit of python to collect the day's forecast at 1am (when E7 cheap rate starts) and, that evening, compare with the actual yield for the day. Will report back in a week.

Edit: sorry, should have said, going to use Solcast data as the forecasts are based on location, declination, azimuth/orientation AND weather (essential for the UK!). It seems the 'forecast solar' data is only based on location, declination, azimuth/orientation??

0 Likes 0 ·
nickdb avatar image nickdb ♦♦ johnone commented ·

It takes weather into account, there is a separate estimate they provide called "clear sky" which gives the theoretical maximum.

From their site:

Restful API for Solar production forecast data and Weather forecast data

0 Likes 0 ·
Show more comments
johnone avatar image johnone commented ·

Collecting hourly forecast.solar data in a db, but seeing big variation when doing an estimate/watthours/day/ call for my location and my little 45/0/1.77 array. In the last 3 hours:

{'2023-01-11': 3068, '2023-01-12': 829, '2023-01-13': 1472, '2023-01-14': 967}

{'2023-01-11': 2609, '2023-01-12': 824, '2023-01-13': 962, '2023-01-14': 1132}

{'2023-01-11': 1781, '2023-01-12': 946, '2023-01-13': 2230, '2023-01-14': 1051}

Yesterday the forecast for today went as high as 3303W - was wondering if I'd need sun cream, but no it's partly cloudy with rain on the way! Anyone else seeing this level of variation? Have I gotten something wrong??

0 Likes 0 ·
nickdb avatar image nickdb ♦♦ johnone commented ·
Just make sure you have all the settings right, originally what threw me was the azimuth, North was -180 instead of 0 as I had expected. Being southern hemisphere our weather patterns are a tad different. I do see it sometimes being a little optimistic but it does seems to start correcting itself.
0 Likes 0 ·
Show more comments

For the graph output there are some extra settings available:

  • Output in kWh - when checked output can be set to kWh instead of Wh
  • Show todays forecast - whether or not to include todays forecast
  • Days to forecast - the number of days to forecast (excluding today). Note that you can not get more days forecasted than your API key allows.
  • Widen graph - widen the graph to only show non-zero values


1673452480695.png

0 Likes 0 ·
1673452480695.png (77.5 KiB)
nickdb avatar image nickdb ♦♦ Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

@Dirk-Jan Faber I think there is an error with the "estimate for the period" chart output, selecting the number of days to forecast doesn't seem to have an effect.

0 Likes 0 ·
Show more comments
johnone avatar image johnone commented ·

Quick update on accuracy/reliability of forecast data. It's a good time to gauge accuracy as in the UK this morning there's a bog-standard Atlantic jet-stream produced weather system which has been accurately forecast - over the last 3-4 days - to arrive overnight. Currently, in the Midlands at 52 deg North it's overcast but clearing. Given yields over the last few weeks - with max sun altitude of 15deg, now 16 deg in mid-January - harvesting 1kW today looks very optimistic. Following data gathered by python script into a db:
Time of forecast / yield-for-the-day forecast for 1.77kWp free-standing, south facing array
Solcast
21:02 2448W
00:02 2783W
03:02 2794W
06:02 977W
forecast.solar
21:02 4196W
00:02 5112W
03:02 4129W
06:02 1501W

EDIT: actual yield for today: 960Wh (Pmax 1076W). Snowing at midday. Yes, Solcast was very accurate at 6:02 - of course, though, that's way too late for deciding whether or not to fully charge the battery in cheap rate period. 6:02 is more of an observation than a forecast!

0 Likes 0 ·
nickdb avatar image nickdb ♦♦ johnone commented ·

I found it tends to overestimate, so I lowered the panel size slightly to where I was more confident in the forecast.

0 Likes 0 ·
Show more comments
johnone avatar image johnone commented ·

Another big clue to the inaccuracy - today is sunny (not cloudless, and started out misty). Max sun altitude for my location (52 deg N) today is 17 deg. Expected max yield for the 1.77kWp array is around 2.5kWh. Forecasts:
Solcast
21:02 6785Wh
00:02 7066Wh
03:02 7124Wh
06:02 6416Wh

forecast.solar

21:02 6398Wh
00:02 6417Wh
03:02 5905Wh
06:02 5645Wh

You'd have thought they would use the easily available 'clear-sky irradiance' data as a baseline, then factor in the weather. Here's a January daily 'average daily irradiance' graph for my location from PVGIS.

Clearly, 6-7kWh for my 1.77kWp array is simply not anywhere near possible in January - why don't the APIs use PVGIS data?

pvgis-irradiaion-jan-52n.jpg

0 Likes 0 ·
krafty avatar image krafty johnone commented ·

I gave up fiddling about with 'forecast.solar' etc a while ago... I just tried it again (for today) and their forecast was out by 5 x.


Now I simply pull the (free) 3-hour cloud cover figures from openweathermap at 5am, average them, add ~20 and set that as my SOC target to hit before the cheap juice ends at 7am.


Last year, I had the various forecasts all feeding their (wildly!) varying figures into a db for a while for comparison. The method above emerged the clear winner. :D

0 Likes 0 ·
fish avatar image fish commented ·

Dirk Thanks for the ideas, I've now got your bit and a Solcast one averaging and setting the charge levels each night for my kit dependant on the forecasts. It also emails the figures used each day... Cheers

0 Likes 0 ·
joolster avatar image joolster fish commented ·

Hi all,

What's your current best view regarding long term accuracy for solcast and forecast.solar?

From my calculations (and just for the last 3 days), it looks like both are +/- 30% (approx) on the real production values, and typically their forecast is optimistic.

Does this correlate with what you've been seeing?

If this is true then a sensible ESS off-peak charging scenario would be to take the solar forecast numbers, factor down to 75%, and subtract this from target SOC (obviously converting between kwh, battery capacity etc) and charge to this level off peak - this would minimise solar 'waste' (export to grid), maximise off-peak (lower cost charging) etc

What do you think?

Thx, Julian

0 Likes 0 ·
tomcat avatar image tomcat commented ·

Hi, thanks for sharing.

Im relativly new to node red. Ist there a way to get the estimated production from doing the request to the end of the day?

If not I want to suggest it :)

Why im asking is, I try to consume as most as possible with different loads directly wihout touching the battery but still want to get the battery full at the end of the day.

So I need to know when to stop direct consumpten to get enough to get the battery full.

I know I could charge the battery first and start direct consumption after its full but my heat pump has high load from 4-6kw/h and Im running it whern sun deliveres enough to not touch the battery and in most cases the battery is not full when this period starts. I hope you understand what im trying to say achieve :D

0 Likes 0 ·
ronski avatar image ronski tomcat commented ·

I'm also very new to Node Red, and JSON, but I have done a bit of programming in the past so starting to pick it up.

What you're asking could be done, but it would be very inaccurate, mine is currently predicting 28.1kWh for today, it's 5pm and I've generated 41.23kWh so far - the weathers been great, pretty much as per the weather forecast, so not even a difficult day to predict.

I've logged a weeks worth of predicted values from the night before, and actual values generated, and they range from 20% to 50% more than estimated. I believe I have everything set correctly as well.

For me it's just an indication, a guide as such, but from Tuesday my game plan changes as I've moved to Octopus Flux.

0 Likes 0 ·
Show more comments

Article

Contributors

dfaber contributed to this article