0.1.11

0.1.11

Bug Fix

Fix — recurring spike from offset double-counting in 4h cycles

Root cause: After importing a partial current day (e.g. 57/96 slots), last_sums[key] was set to the cumulative sum at the END of that partial data. When the next 4h cycle re-imported the same slots from CEST midnight (= 22:00 UTC), it used this inflated offset → double-counting → spike.

The 0.1.9 fix only covered the case where a complete day existed in the same chunk. If the entire chunk was partial (e.g. pending-day lookback returning today's data only), the else branch still wrote the inflated value.

Fix: The DB is now the authoritative source for the running offset before every import cycle. Before calling the fetcher, we always query statistics_during_period for the last stat before (last_import + 1 day) midnight CEST. This is identical to what the rewind already did on startup — now applied universally.

• Removed the dedicated rewind DB query (now redundant)
• Removed the pending_sum_offset path (now redundant)
• last_sums is still updated as a fallback for complete-day imports, but is no longer the primary source of truth

To fix corrupted data: reload the integration (Settings → Integrations → EKZ → Reload).