Closed Nilogax closed 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?
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.
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:
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