I warmly appreciate the implementation of solar forecast in VRM. It is a nice feature that allows a better planning of various aspects. Since I was using an own Solcast account before Victron’s implementation, I have the ability to compare.
In the past I observed already that Victron’s numbers were mostly 10% to 30% too optimistic, whereas native Solcast forecast had in most cases a deviation smaller than 5%. This circumstance is not anything to complain. However in current weather condition the VRM forecast shows 350% of Solcast projection. Reality confirms that native Solcast forecast is again quite close.
Solcast shows predicts the low PV production already since more than 36 hours, whereas VRM as of now still predicts 350% of reality.
Since Victron uses the same source (Solcast) for VRM implementation (as I think to remember in relevant announcement), I would appreciate if Victron team could invest some time in improvement measures.
Current screeshot of native Solcast forecast (was nearly identically yesterday afternoon):
Since I was spending yesterday some time in own home automation development and was wondering about next day’s numbers, I logged in into Solcast to get confirmation.
This is something I have been raising for some time. In my case it under-estimates and then tries to correct itself throughout the day, see-sawing as it goes along.
In this chart I compare forecast vs actual, recording the PV that is expected from any moment in time. It is typically off by 30% or more, in poor weather, this delta is much greater, even though the actual irradiance data seems much more accurate, so the issue is the modelling on VRM.
Evening Update:
The Prediction of 34.5 kWh Solar was in Fact a yield of 14.2 kWh.
This needs to be improved, mainly for the Operability of DESS. It has a hard time sticking to a schedule anyway - If the forecast is that far off, the whole schedule may be insufficent as well.
@Barbara : Last 9 days I recorded VRM and native Solcast forecasts and PV results, where I like to share my findings. My post please shall be not considered as criticism, but as collaboration to support.
During first 6 days VRM forecast was steadily predicting essentially lower than native Solcast. Last 3 days it became closer. Since my panels are in a 15° angle only, I would actually expected the oppositive, since VRM does not use more config details for Solcast. Maybe you have an explanation for that issue?
When we look to forecast details (I recorded a 24 hours rolling forecast), I had to observe that VRM showed during 6 out of 9 days a peak, which couldn’t be explained by native Solcast forecast. Mostlikely that peak has major influence on weak forecast quality, since it typically occurs between ~10:00 and ~15:00.
In a few cases the VRM forecast even exceeded the Solcast-max-forecast (90% level). That should be actually not the case.
There a several patterns providing indication that VRM forecast seems to be delayed by 2 hours. Since Solcast delivers in UTC time, maybe the translation in CET is not performed for VRM. Since VRM-API provides time also in UNIX-time, I would expect according to UNIX time definition the same interpretation.
Could you please check and explain?
Similar problems still here on my ESS with PV. I had been using Solcast for over 2 years and it provided ‘good enough’ forecasts for me to model the overnight target SoC so as not to feed back PV to the grid during the following day (I just look at tomorrows forecast for this model). I recently migrated to the VRM predictions since I have a winter shading problem that I hoped the VRM PV model would handle. That seemed to be OK for the low PV generation numbers involved at the time. We’re just going through a few sunny days here and I have had to revert back to using the Solcast forecast directly since VRM PV forecast is now consistently about 50% lower than the Solcast forecast (which is much more accurate).
So, echoing the topic title, this is a very nice feature but please can it be improved?
Colin
Since anybody from community admin team deleted my previous forecast related to VRM based forecast, I have to submiit a new thread ;-(
In that former thread I indicated the low VRM solar forecast stabilty, which makes a dynamic battery usage quite difficult (just to remind, I added a diagram showing the VRM behavior.)
During recent months I recorded solar forecasts from VRM and the native one from Solcast. Below I add 2 graphs.
First graph shows VRM and native Solcast related solar forecast recorded at noon of previous day and compares it to actual outcome.
Second graph recorded both forecasts at midnight and compares it to actual outcome.
Please consider that at midnight the forecast should be actually already quite reliable, but is actually too late to control battery usage.
Forecast at noon day before versus acutal outcome: Forecast hits out of 39 days: Solcast 24 (62% reliability) versus VRM 10 (26% reliability)
Hi grua,
In order to use the native Solcast forecast, you have to create a “Home PV” account at Solcast and to retrieve results via their API. Of course I do that in nodered. You have just to evaluate the returned json forecast object:
VRM forecast I call via VRM API objects also in nodered.
During the period I used in my comparison the weather was not impacted by fog or high fog. In November and December we effectively had. During that time the comparison would have been not fair and meaningful.
In one of former threads it was mentioned that VRM forecast actually uses Solcast. This can be also underpinned by curves showing often analog behaviors at same time (whereas VRM ignores UTC timing - also mentioned in my deleted post).
Since anybody from community admin team deleted my previous forecast related to VRM based forecast, I have to submiit a new thread ;-(
In that former thread I indicated the low VRM solar forecast stabilty, which makes a dynamic battery usage quite difficult (just to remind, I added a diagram showing the VRM behavior.)
During recent months I recorded solar forecasts from VRM and the native one from Solcast. Below I add 2 graphs.
First graph shows VRM and native Solcast related solar forecast recorded at noon of previous day and compares it to actual outcome.
Second graph recorded both forecasts at midnight and compares it to actual outcome.
Please consider that at midnight the forecast should be actually already quite reliable, but is actually too late to control battery usage.
Forecast at noon day before versus acutal outcome: Forecast hits out of 39 days: Solcast 24 (62% reliability) versus VRM 10 (26% reliability)
You can publicly share the 5 or 6 digits in the vrm url between installation and dashboard. No one can use that. Just don’t share the GX serial number.
This isn’t a new topic, I have pushed for improvements for some time.
If you look at my data from today you can see how off it is and how it recalculates.
Yet the actual irradiance data isn’t as far out, so VRM is calculating it wrong. The weighting it uses resists shorter term changes.
We are using the Solcast irradiance forecast, so the irradiance forecast you see in VRM is 1:1 that of Solcast.
We take this irradiance forecast and add some more factors to model the solar yield forecast. So as we build on the Solcast data and add more varying factors, the solar yield forecast is less accurate than the irradiance forecast, that’s very logical.
In the screenshot below the green graph is the Solcast deviation from actual solar irradiance, and the purple line is VRM’s deviation from actual solar yield. You can see that both follow the same trend, meaning that also Solcast struggles with changes in weather. As solar yield has more factors to account for than only irradiance, the impact of an inaccurate day is bigger in VRM compared to only solar irradiance data.
What we do to correct for that is - besides continuously retraining the model so it understands the impact of weather changes - is that when the algorithmic model deviates too much on a day or hour, we switch to a more simplistic mathematical model, which just takes solar irradiance forecast and adds a ‘rule of thumb’ calculation of what solar yield could be.
As DESS re-schedules every 15 minutes, even deviations from solar forecast will be corrected in terms of the best strategy to save money.
We are working on a page that explains solar forecast and how Dynamic ESS performs with it, so hopefully that clarifies it a bit.