more Dumping options and time shifting

[brych92]

Hi, is it possible to add 2 more dumping interval, to more precisely adjust production in the morning, an not to cut near noon production?
Like I need to reduce forecast in the morning, cause i leave near mountain and in the morning i loose some 1-2 hour, but if I will use morning dump, it also cut near noon forecast.

and also it looks like forecast shifted 1 hour in the future(most probably because "summer time" in my country)

without dumping

with morning dumping 0.6:

[WildEchoWanderer]

I have quite similar problem with a chimney shadow wandering over my panels in the late evening and i would appreciate more damping options.

The Problem i see here is the change in sun elevation. This results in different times for the shift in shadow and damping.

[thecem]

The only way to do this, is the horizon function, but this must be delivered by the api, since the azimuth is needed.

[rany2]

We will also need to calculate the GTI on our end instead of relying on Open-Meteo. It's a big overhaul.

[thecem]

Is open-meteo delivering the azimuth of the sun ? If not is there a way to do this?

[brych92]

We will also need to calculate the GTI on our end instead of relying on Open-Meteo. It's a big overhaul.

Does dumping rely on open-meteo API, or it is calculated on site?

[rany2]

We will also need to calculate the GTI on our end instead of relying on Open-Meteo. It's a big overhaul.

Does dumping rely on open-meteo API, or it is calculated on site?

Currently dampening does not rely on open-meteo API. We only make use of the sunrise and sunset times provided to determine by how much to dampen.

[WildEchoWanderer]

could this be done with dividing morning in equal parts?
as example:
( noon - sunrise ) / 4 ?

with a "dividing"-variable it could also be sliced into user-defined time slices or hardcode a max value of 12.
maybe like this:

dividing_variable = 12
morning_slices = ( noon - sunset ) / dividing_variable
morning_slice_1 = sunset + 1 * morning_slices
morning_slice_2 = sunset + 2 * morning_slices
...

[Oldie-driver]

The only way to do this, is the horizon function, but this must be delivered by the api, since the azimuth is needed.

I need even horizon. I have 2 PV spots with different horizon. In practice it's like a switch, sun there or not. Damping cannot reflect this.

[javolek]

I also have a shadow from a tree wandering across my Panels and I see a precise dumping configuration quite an endeavour.

I'm wondering if it would be possible to use a simple kind of Statistics to provide more precise forecast taking a local conditions into account. The Idea ist to take the forecast provided by open-meteo and compare it on hourly basis with the actual data provided by the PV-Inverter. The integration can then persist the differences for each hour for a configurable period of time - i.e. month - and use suitable statistic function to calculate expected differences for each hour on a day in the future. Especially for local conditions that do not change or change only slightly over the time, like horizon or tree shadow, this would provide remarkable improvement of the forecast without the need to do a complicated dumping configuration. Only one sensor would be necessary to configure to provide the actual PV-data to the integration.