ha-open-meteo-solar-forecast v0.1.8 fixes TypeError: unsupported operand type(s) for *: ‘NoneType’ and ‘int bug which was accidentally introduced in v0.1.5.
1 Like
Works! Thank you!
And again a question: this hour and next hour sensor gives kWh values. „Solar production forecast Estimated power production - next hour“
Gives W. Does that really make sense? Shouldn’t that be also Wh or kWh?
No, it gives the expected power at that exact instant not the energy at the 15-min interval. Just to clarify, if the current time is 11:40, and you got the “power next hour” sensor data; it would give you the nearest expected power it calculated at 12:40, which would most likely be at 12:30. When the current time is 11:46, it would give the expected power at 12:45.
So if it is 11:10 the 15m sensors tells me the watt at 11:25 right?
But then current there is no way to get the kWh estimate for the next hour from the current time on. So 11:10 and telling that we get 5kWh the next 60mins till 12:10?
No, it would would be:
- 11:00
- 11:15
- 11:30
So at 11:10 + 15m, it would be 11:25 which would give the power at 11:15 which is the nearest.
Yes there is, “Solar production forecast Estimated energy production - next hour”
1 Like
HI, sorry for asking, can you share the instructions for manual install? I copied the folder under custom component, but I don’t see the forecast information
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.