core icon indicating copy to clipboard operation
core copied to clipboard

New eveing dampening of forecast solar does no seem to be working

Open sargonas opened this issue 9 months ago • 8 comments

The problem

Forecast.Solar was documented to have been updated in 2023.9 with the ability to set separate dampening levels for both morning and evening, instead of the previous one universal offset. However, no matter what adjustments I try, I cannot seem to get an evening setting to actually affect the forecast graph. Any changes to the morning setting are reflected upon the next update quite obviously, but no values I have tested insofar for evening have changed the projection in any noticeable way.

I've ever gone to far as to take screen shots and try changing it everywhere form .25 all the way up to 5.0 in .5 increments, stacked the images, and all of them were identical.

What version of Home Assistant Core has the issue?

2023.9.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Forecast.Solar

Link to integration documentation on our website

https://www.home-assistant.io/integrations/forecast_solar

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

sargonas avatar Sep 19 '23 06:09 sargonas

Hey there @klaasnicolaas, @frenck, mind taking a look at this issue as it has been labeled with an integration (forecast_solar) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of forecast_solar can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Renames the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign forecast_solar Removes the current integration label and assignees on the issue, add the integration domain after the command.

(message by CodeOwnersMention)


forecast_solar documentation forecast_solar source (message by IssueLinks)

home-assistant[bot] avatar Sep 19 '23 06:09 home-assistant[bot]

Checking in on this one since it's been about 11 days? Just trying to get a sense on if I am doing something wrong, or if it is not working as expected.

sargonas avatar Sep 28 '23 18:09 sargonas

You could also compare by downloading different diagnostics from the integration and see what data comes in, perhaps the difference is minimal and otherwise you could also try using Postman to retrieve data directly with the API and see if that also differs.

This way you could investigate a bit and rule out what the cause is and whether there really is a problem.

./Klaas

klaasnicolaas avatar Oct 19 '23 09:10 klaasnicolaas

I have run a direct API call against forecast.solar for a given day without damping, and then again with morning/evening values of .25 and 1 respectively, and the result was as expected, with the hourly kWh estimates changing by the damping to the expected variations.

I then looked at the values for the same day in HA as provided by the integration, which was configured with the same damping values of .25 morning and 1 evening, and the hourly kWh estimates were not the same as the direct API call with very similar (but not exactly the same) morning values with the evening values being wildly different, seemingly skewing further and further away from the expected values the further one went in the day by hour.

sargonas avatar Oct 20 '23 07:10 sargonas

bumping this issue as I did as suggested and compared the results between the integration in HA and the FS website directly, and as determined above the HA integration is not reporting accurate values compared to the FS website API.

Unfortunately, that is the limitations of my skill set and knowledge in this area, as to what the is skewing the results between the API, integration, and rendering in the Energy panel, I'll need to defer to the experts who built this.

sargonas avatar Jan 11 '24 19:01 sargonas

At the moment I don't see anything strange in the code that could explain this. When I have time I'll look at it again.

./Klaas

klaasnicolaas avatar Jan 11 '24 19:01 klaasnicolaas

Thanks!

It's not game breaking so not urgent, I simply wanted to make sure this didn't fall off any radars and got a look when possible. Much appreciated!

sargonas avatar Jan 11 '24 19:01 sargonas

I'm seeing this too.

cirrusflyer avatar Jan 14 '24 21:01 cirrusflyer

I m seeing this as well. Br

nils-82 avatar Jan 27 '24 18:01 nils-82

It looks like the lib is setting ?damping=0 by default for all requests, in addition to any optional damping_evening, damping_morning from specified by the integration options.

https://github.com/home-assistant-libs/forecast_solar/blob/171deff67b95e80605806e3db4800e4a01ceddb6/forecast_solar/init.py#L36

Setting damping_morning = 1 and damping_evening= 1 in integration options will give the request:

https://api.forecast.solar/estimate/51.15/10.45/20/0/12.34?damping=0&damping_morning=1&damping_evening=1

From the looks of the docs above does not seem like a supported parameter format.

https://doc.forecast.solar/damping

According to the docs the supported request format is either:

?damping=<factor morning>[,<factor evening]

OR

?damping_morning=<factor morning>&damping_evening=<factor evening>

bj00rn avatar Mar 20 '24 13:03 bj00rn

This lines up with what my digging has uncovered as well.

sargonas avatar Apr 12 '24 23:04 sargonas

We've had a discussion about this in the past with the creator of the API. His answer at the time was that if you send damping_morning, damping_evening and damping as parameters, the morning/evening will be leading in the request.

./Klaas

klaasnicolaas avatar Apr 12 '24 23:04 klaasnicolaas

Interesting. So then I take it that it is safe to assume this is not the source of the inconsistency then, and we need to look elsewhere?

On Fri, Apr 12, 2024 at 4:31 PM Klaas Schoute @.***> wrote:

We've had a discussion about this in the past with the creator of the API. His answer at the time was that if you send damping_morning, damping_evening and damping as parameters, the morning/evening will be leading in the request.

./Klaas

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/100576#issuecomment-2052693054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALDF23WHGIUKYYDTS3KYDY5BVFTAVCNFSM6AAAAAA45YXMF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJSGY4TGMBVGQ . You are receiving this because you authored the thread.Message ID: @.***>

sargonas avatar Apr 12 '24 23:04 sargonas

What I was thinking about is that in Home Assistant we process the damping values as float, so 0,25. But the API wants a dot notation, so 0.25 and that might cause problems 🤷🏻‍♂️ In any case, worth checking to rule out some things.

./Klaas

klaasnicolaas avatar Apr 12 '24 23:04 klaasnicolaas

What I was thinking about is that in Home Assistant we process the damping values as float, so 0,25. But the API wants a dot notation, so 0.25 and that might cause problems 🤷🏻‍♂️ In any case, worth checking to rule out some things.

./Klaas

Seems unlikely though. Float.__str__() is culture invariant methinks.

>>> dampning_evening = 0.25
>>> f"dampning_evenning={dampning_evening}"
'dampning_evenning=0.25'
>>> 

bj00rn avatar May 02 '24 09:05 bj00rn