Forecast.solar uses the PVGIS backend for solar irradiation. This platform can incorporate a user-provided horizon which can be used to define shadow casted PV modules by nearby objects. This is relevant for computing good forecasts. The Forecast.solar api supports this.
Please provide a means to configure a user horizon in the Forecast.solar integration.
Would love to see the “horizon” feature implemented.
It will improve your data a lot if the sun reaches your solar panales only within specific azimuths. This is often the case for solar panales on a balcony.
I have the same usecase on a balkony, some trees, other houses and because I have solar pannels to 2 of the 3 possible directions I have shadows from the house itself which creates inaccurate forecast results for one of my modules. The damping factor for the morning/evening is not good enought to compensate that. I don’t really see it as a problem, to have a comma separated list as an parameter as long as 0 is also accepted as default value.
Sure, I did this for testing purpose. But I guess I have to somehow a) aggregate the data and b) integrate it into the energy dashboard? Is this easily possible by setting up a special kind of sensor or so?
I would also love this feature see implemented. It will probably bring more useful data to most PV owners in city area’s than the dampening feature?
It may make it difficult because you have to fill in 12 numbers for each 30degrees on the compass, but if you default these to twelve zero’s and only have an advanced option with 12 inputs, labeling something like:
Blocking height entered in 30 degree cakepies on a compass:
[xx] 0-30 degrees on compass
[xx[ 30-60 degrees on compass
[xx] 60-90degrees on compass
…
That would really be helpful in tuning the actual solar forecast for us city people with other buildings blocking part of the horizon for the PV installation.
It’s not really difficult to do. There have been to PRs to the Repo provifing this feature. So it’s an issue of the owners not wanting this feature.
For me, without it the predictions are useless for 9/12 months, as I have buildings around me. Adding the horizon provides mich more accurate predictions.
I second this. I’m currently looking for an easy way to either:
create a custom integration for forecast.solar that would allow setting the horizon or
updating the HA forecast.solar implementation
For me, it makes huge difference, like up to 50% in the winter months, since I’m surrounded by the tall trees an hill on the south and the panels are mounted to the balcony.
There’s even more to it. Forecast.solar allows you to send actual production data with the request, what could be used for “fine tuning”. The feature is only available in paid account, though.
Currently, I’m using a Rest sensor to scrap the data and it’s working beautifully. The only issue is the lack of possibility to Energy dashboard integration.
Would encourage building it into the core integration
About the horizon feature. Let me be clear that it’s not that we don’t want to add a horizon option, but that we haven’t figured out at that time, how the user should enter the horizon in the config flow.
I still hope, adding horizon came one day.
It was stopping about morning and evening damping, but this is not really a replacement.
I have 2 PV spots with shadows, one got sun in the morning up to 13:30, the other out of shadow after 12:00. Damping cannot represent reality. The accuracy is like an exact weather forecast at 14:09 in 5 weeks, useless.
An entry in the configuration.yaml is of no use either, I have 2 different forecasts with completely different horizons. This is initially not usable for predicting how consumers will switch on accordingly.
I understand your point.
Entering a simple text field with the values separated by colons is not the nicest solution.
But I would prefer this simple solution to no solution we have now.
For me it is absolutely useless now, since it overestimates my current production by factor 2 to 3.