BJReplay / ha-solcast-solar

Solcast Integration for Home Assistant
Apache License 2.0
165 stars 32 forks source link

Forecasts not responding to changed dampening factors #44

Closed Nilogax closed 3 months ago

Nilogax commented 3 months ago

In previous versions any change to dampening factors was very quickly reflected in all solcast forecast data, but latest versions don't seem to behave in the same way.

To Reproduce Steps to reproduce the behavior:

  1. Note current solcast PV forecast totals for today, day 2 etc and current dampening settings
  2. In Developer Tools call solcast_solar.set_dampening with 24 zeroes, or reset all dampening factors to zero via the integration UI
  3. Expected behaviour is that all forecast data should be set to zero, but for me they remain unchanged (I have also try varying a single hourly dampening factor rather than the full zero option, but again there's no effect)
  4. Call set dampening or use the UI again to restore prior dampening settings

Logs don't seem to help much as it just records the service call with no extra info.

Noticed in 4.0.31 and 4.0.30, tried 4.0.27 which seemed to behave as expected

Nilogax commented 3 months ago

Had a bit of time to explore this today and think I may have identified the source of the issue, but I'm not sure if my simple fix is valid.

In the update from 4.0.27 I found this commit:

https://github.com/BJReplay/ha-solcast-solar/commit/181ea1c4f6d952e2e58031ba874eaf8999386b44

Specifically I edited my local copy of init.py and undid the change at 292:293/291:300 so I'm assuming the code to detect if an item has been changed wasn't detecting changes to the dampening settings. Not sure if this the actual cause or how to correct the new code, but for now it seems the forecasts (and calls to query_forecast_data) are responding to dampening changes again.

Could someone who actually knows what they're doing take a look please?

autoSteve commented 3 months ago

That was part of the change made to incorporate the "lost" Oziee v4.0.23 changes. I'm beginning to wish they had remained lost.

Maybe Oziee didn't think through the broader impact.

I already have one merge and a draft release prepared covering another of these lost v4.0.23 changes that broke long term statistics for forecast history, which will likely be released unless a reason can be found not to. (Have you lost forecast LTS, @Nilogax?)

So I throw the floor open to opinion.

Should this modification to only reload on config change also be reverted? At the very least the potantial for impact needs to be further investigated by someone.