That’s the Open-Meteo integration, there’s another one called “Open-Meteo Solar Forecast”.
1 Like
Hi. Looking at the API and the parameters for azimuth are 0 -South, -90 East, 90 West.
How does the Python API translate the 0, 90, 180, 270 values? I cant see anything in the main class?
EDIT ok I found the line azimuth=entry.options[CONF_AZIMUTH] - 180
1 Like
It just subtracts 180: ha-open-meteo-solar-forecast/custom_components/open_meteo_solar_forecast/coordinator.py at aad945d8ca1f88048a4dd3d6f4c5fef21e7b0771 · rany2/ha-open-meteo-solar-forecast · GitHub
1 Like
@rany Would it be possible to set a regular version for the integration and make regular releases? With that hacs would show an update. Currently it does not. I do need to know that you pushed something new and need to manually re-install.
HACS does work fine for me. It’s just that it doesn’t poll the repository frequently. Take a look at Updates | HACS.
To force it to update from HACS, check the “Manually trigger updates” section.
Even with updating your repo manually within hacs it is not showing an update.
I guess you need to implement and use the releases function of GitHub. you can check my integration how it is done there: GitHub - dm82m/hass-Deltasol-KM2: Custom component for retrieving sensor information from Resol KM1/KM2, DL2/DL3, VBus/LAN, VBus/USB
1 Like
It works. You are so fast, incredible. And thanks!
1 Like
Can we make cloud cover an on/off option? I live in the Lakes and it’s claiming I’ll see 38KWh today, Solax shows 28KWh (which is more realistic). We have a lot of clouds 
Bit confused by this - my azimuth in Solcast is -130, if I put in 130 and you take off 180 that’s -50 which isn’t correct?
I also stumbled over the logic to just substract the 180.
My “360-azimuth” is 164 (which is south with a slight east turn). If you substract 180 we’ll end up with -16 which actually means north, doesnt it?
Ihave checked this withSolcast WebUI:
I believe in this example -164 would be the correct value forthe “180-azimuth” logic
I read from your post cloud cover is not compensated for enough where you live. The weird thing is, in my case the predictions seem quite good, but underestimate a lot when cloudy. Then my solar panels are producting way more, and the prediction is way too bleak. I was thinking they may not take into account that clouds disperse light too.
I also notice in the estimate in the morning is better then wgen time passes (and more actual weather data is known).
dont understand your questions, within the configuration interface of the integration you just set your azimut value:
in my case: south, so 180
the integration substracts -180 so asks the meteo api for value 0:
so everything is correct. just set your CORRECT azimut and dont do any substractions, as these are done in the integration.
and most importantly: this plugin here uses open meteo api and NOT solcast. it has nothing to do with solcast!
I get that, so if I put in 130 - the integration subtracts 180 and gives -50 which is wrong though? My actual azimuth is technically -130. Subtracting 180 only works if you are facing South with this logic.
If your azimuth is negative, just add 360. So if it was -130 (0=North), then just add 360 it would be 230.
So I made a mistake when entering some details. Apologies for going down this rabbit hole. Doing the comparison now and its much closer.
Daily Meteo 33.84
Daily Solcast 34,3
1 Like
