Open-Meteo Solar Forecast

Share your Projects! Custom Integrations
22

that’s what the log says:

Unexpected error fetching open_meteo_solar_forecast data

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 315, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/open_meteo_solar_forecast/coordinator.py", line 57, in _async_update_data
    return await self.forecast.estimate()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/open_meteo_solar_forecast/open_meteo_solar_forecast.py", line 149, in estimate
    data = await self._request(
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/open_meteo_solar_forecast/open_meteo_solar_forecast.py", line 116, in _request
    raise OpenMeteoSolarForecastRatelimitError("Rate limit exceeded")
open_meteo_solar_forecast.exceptions.OpenMeteoSolarForecastRatelimitError: Rate limit exceeded
23

Might be because you’re behind NAT then, that stinks.

24

orientation of our panels is south-east - this should be -160 degrees in SolCast coordinates (0 being north, -90 east, -180 south), right?

200 in “your” coordinates, if I understand the info note correctly, however, is south-west (180 is south plus 20 degrees further west), right?

25

no idea - I was also surprised why this happened because I am only using this integration since yesterday…

26

Yep, that’s correct.

27

This morning it started working again and the predictions are much closer to those by SolCast. For today the forecasts differ by 3.2kWh (Solcast: 52.5kWh), for tomorrow by 13.2kWh (Solcast: 98.3kWh) - in both cases Open Meteo is still underestimating.

28

Tried that here for my setup, but without the cloud data from Open-Meteo, it overestimates extremely (almost double) for me. The previous version with the cloud data worked just fine. :man_shrugging:

29

maybe add an option for different calculation method like solcast does

1000036896
10000368961080×1023 87.5 KB

30

Thanks, I’ve also noticed that the cloud cover compensation code seemed to work fine for me. I just need to figure out how to best make use of it and when to trigger it.

31

I’ll see what I could do about this. Personally I like the Kasten-Czeplak model because it’s simple and effective (works really well when you’re using clear sky approximation), but the biggest issue is that Open-Meteo sometimes accounts for cloud cover properly and having Open-Meteo’s compensation interacting with my own causes massive underestimation.

It’s pretty interesting that people seem to be interested in this :slight_smile:

32

I’ve been watching the forecast for a few days and it worked fine together with the cloud data. Not perfect, not 100%, but we must not forget that it is a forecast and that it is based on other forecast data. That makes it impossible to be 100% accurate.

Also, some regional weather conditions make things complicated. Therefore, I don’t think it’s a good idea to change or adjust the calculation immediately in case of deviations. Instead, you should observe the whole thing over a longer period of time. If you expect a 100% production forecast, you should realise that the weather data required for this is never 100% accurate. Forecasts are forecasts, sometimes they can be like looking into a crystal ball. This also applies to SolCast and other services. Sometimes one is better, sometimes the other …

33

Thanks, that’s my mindset as well but it seems pretty bad for it to be off by that much so I was more willing to revert it. I’ll come up with something more suitable maybe in the weekends, I have some ideas. This is just a side project for me (obviously).

Of course, this is FOSS so you could contribute as well if you have some ideas on how to best approach this issue.

34

I think the original approach, which took cloud density into account, was very good and I currently see no need to improve or change the whole thing in any other way.

I looked at the cloud data provided by Open-Meteo and ran a few tests myself. Perhaps the mid and low cloud density should somehow be put in relation to each other, or perhaps an average value should be calculated from both and then used to calculate the production. But I haven’t tested that yet, it’s just an idea …

It would be helpful to have more information about which cloud cover at which altitude has the greatest influence on production. Then you could play around with the different data from different altitudes …

35

I have forgotten one thing that has not made sense to me so far: the efficiency_factor in the calculation is not particularly clear to me, especially when to adjust it and in which direction … ??? Is there any information here?

36

I’ve tried to account for cloud low and mid before in my experimentation and I found that using mid or high leads to results that are too pessimistic. What I ended up doing was averaging the two values and taking the maximum of the two, both approaches were too pessimistic and there was never an instance where it worked well.

Only taking cloud low worked okayish in my case, and I think it could very well be dependent on location (i.e., available solar radiation data) which is why it seems to be working poorly for some.

1 Like
37

Efficiency factor is to account for DC wire loss and also the efficiency of the inverter/panels. I recommend you start with 0.93

38

Yes, that may be correct.

You could possibly include the Open-Meteo sunshine_duration value. All radiation above 120 W/m2 is considered sunshine there. So if we have a high cloud density, but at the same time a high sunshine duration, then a reduction in the cloud density might make sense. However, it is unclear to me how this can be mathematically correlated.

39

I’d assume that the sunshine duration is reflected in the average radiation that Open-Meteo returns, so it didn’t seem worth investigating but I might be wrong.

40

That is true, but shouldn’t the cloud cover values then also be part of the calculation of the Open-Meteo irradiation values?

Actually, that should be the case, so that the cloud cover could be ignored for the production forecast. But this then leads (at least for me) to exorbitant forecast values and only the consideration of the cloudiness values brings the whole thing back to normal values (which might be a simple coincidence, though)

If I look at a graph on Open-Meteo with all the available cloud cover values for the current day, as well as the radiation values, then I can’t see any connection, i.e. I don’t see any higher radiation values with lower cloud cover, the curves don’t seem to be connected to each other … that doesn’t make the whole thing easy

41

Here’s what I mean: no visible connection between low-clouds and irradiance.

iScreen Shoter - Safari - 240603151647
iScreen Shoter - Safari - 2406031516472639×779 168 KB