Open-Meteo Solar Forecast

wh_period is actually a bit different, it takes the average over a 15 minute period and then provides an estimate for Wh over an hour. The reason why I’m not returning data at 15 minute intervals for both is for compatibility with the old Solcast integration.

1 Like

Do we need it to be backwards compatible with Solcast integration? Thanks!

I don’t care, I was under the impression that people want the hourly data to do things they did with Solcast integration but if it doesn’t matter I could just… not do that.

Besides the ApexCharts thing, is there another use for these sensor attributes? If I return 15min data for wh_period, will it cause breakages?

I could do something like wh_period_15min, wh_period_hourly, watts. watts is unchanged and the change in wh_period is obvious from the name. Thoughts?

What a great job by Rany - thanks to him we are nearly there with a complete (and better) Solcast replacement !
Unfortunately, I have east/west PV arrays, so at the moment I have to use 2 instances of Open-Meteo solar forecasts.
I would like these combined into ONE display on the Apexcharts graph.
I am a complete novice when it comes to Javascript - anyone happy to supply the data generator code for the addition of the 2 arrays ?
Thanks

1 Like

I’m planning to provide some option to handle this configuration. The biggest hurdle for this is the config flow system in Home Assistant. I think in the worst case, I could allow it via configuration.yaml easily.

2 Likes

Would be okay for me :slight_smile: if the other option takes more time.

1 Like

Not even sure how to do it with config flow, I think it’s not even possible without ugly hacks like delimiting values by commas as that’s what other integrations seem to resort to.

if you can, can you directly implement it in such a way that n arrays are supported?

You mean in such a way that the config flow always give you the option to support a fixed amount of PV arrays instead of a dynamic amount? For example, if lat/lon is unset for array 2 and 3; then it’s clear that 1 array in use. It all feels really hacky :confused:

I meant that you don’t implement support for two separate arrays now and in a few weeks somebody shows up who needs support for three. Not sure how difficult/possible this is but if the integration directly supported more than 2 arrays that would be nice.

I have to say personally, however, that I don’t see a problem with having two instances of the integration/devices setup. Other integrations do it the same way - I find this consistent and clean.

If people need aggregated data/predictions they can always create themselves a template sensor and do whatever they need/want in it.

The issue is only with the peak time/power sensors where you cannot (at least not in a very clear/obvious way, I personally have no idea how but it is probably possible) make a template sensor; that’s why I’m convinced that this should be done.

Sounds to me like just adding up the predictions and detecting the new peak (max). Done. Or do I misunderstand?

This sounds like a great solution to me. Thanks!

1 Like

Yes, but how could you do this using a template sensor? It seems to me that is not possible or at least very difficult.

Up to you of course. Hacky integration - that is prone to not work at any time if HA APIs/rules change - or users have to learn templating :wink:

An approach could also be to suggest/trigger changes or modifications to the HA template functionality that are required for these calculations (if this is really not possible with the current functionality - no idea). This way all integrations would benefit.

1 Like

Hello,
I would also appreciate being able to sum up the values of 4 arrays.

Besides that I run into an error message during every afternoon “rate limit exceeded”.

The forecast is then gone until the following day.

Is there any possibility to limit the polls per hour if that is the problem?

Thanks and kind regards

P1t

1 Like

I ran into the same issue but the rate limit is very generous. The reason for this message is most likely that you have received a dynamic IP from which many requests have already been made in the past. New IP address → error gone.

Technically you would have to do the same thing in Jinja or PY.

I’m assuming the array has the same number of elements with the same date values.

Then you would have to go through all the elements and add them together to get the total energy.
The largest value in the array is the new peak time.

Might be a bit difficult with jinja. Not an expert with jinja not my favorite DSL.

1 Like

Jinja is the worst, I wish Home Assistant just let you use python code for the templates. It’s really simple to do in my python, would hardly take me a few minutes. Instead they enjoy treating you like toddlers…

Even the default Python integration service HA provides is extremely restrictive.

(I get why they do it like that, though)