The result for wh_days appears to be getting thrown off by timezone offsets.
This surfaced in seeing very low values for the "tomorrow" production estimate in Home Assistant. On digging into it, an example query using ForecastSolar for my location, with my kwp/declination/azimuth info, for example, gave me 919 and 59 Wh, whereas doing a standard curl against the forecast.solar API with the same values gave me 1049 and 1076 Wh.
Looking at it further, it appears that the values for the "tomorrow" wh_days values are actually the sum of the wh_period values for the day after tomorrow, where there are 3 period values showing in that bucket.
Effectively, the values in the watts and wh_period dictionaries were calculated against UTC rather than the local timezone, even though the api_timezone does correctly show my local timezone. The wh_days values, then, end up adding up incorrect values.
When querying the API directly just with curl, the returned watt_hours_day values account for timezones correctly.
It looks like this might be because time in the query params is being explicitly and statically set to utc, rather than either (a) letting the forecast.solar API handle it implicitly or (b) setting it explicitly from the locally determined timezone:
|
params = {"time": "utc", "damping": str(self.damping)} |
The result for wh_days appears to be getting thrown off by timezone offsets.
This surfaced in seeing very low values for the "tomorrow" production estimate in Home Assistant. On digging into it, an example query using
ForecastSolarfor my location, with my kwp/declination/azimuth info, for example, gave me 919 and 59 Wh, whereas doing a standard curl against the forecast.solar API with the same values gave me 1049 and 1076 Wh.Looking at it further, it appears that the values for the "tomorrow" wh_days values are actually the sum of the wh_period values for the day after tomorrow, where there are 3 period values showing in that bucket.
Effectively, the values in the
wattsandwh_perioddictionaries were calculated against UTC rather than the local timezone, even though theapi_timezonedoes correctly show my local timezone. The wh_days values, then, end up adding up incorrect values.When querying the API directly just with curl, the returned
watt_hours_dayvalues account for timezones correctly.It looks like this might be because
timein the query params is being explicitly and statically set to utc, rather than either (a) letting the forecast.solar API handle it implicitly or (b) setting it explicitly from the locally determined timezone:forecast_solar/src/forecast_solar/forecast_solar.py
Line 198 in c95b5ec