← Back to Solar Dashboard

Solar Buffer Estimation — Recommendations

The buffer estimation architecture is sound — the three-tier fallback, period segmentation, and source transparency are well-designed. The dominant accuracy problem is evening load variance (±8 kWh, 3× range), which overwhelms all other error sources. The fastest wins: resume data collection, add day-of-week baselines, and fix the one-line kWh bug.

✅ Strengths

Three-tier fallback chain (live 1h → 7-day historical → hardcoded constants) — ensures the system always produces a result even with sparse data
Sub-period time segmentation (evening/overnight/morning) correctly models Melbourne's pattern of high evening load, low overnight baseload, ramping morning load
Morning solar offset correctly subtracts expected solar from morning energy need — critical in July where sunrise is ~7:40am
Historical data confirms assumptions — overnight IS ~0.2 kW, morning IS 1.5–2.7 kW range, evening shows expected 3× variance
5-minute polling (load_readings) provides decent live resolution
Source transparencydataSource label shows user whether each period uses 1h live, N-day historical, or constant
Fast & simple — pure arithmetic, no heavy computation, suitable for 5-second polling

⚠️ Weaknesses

Evening load variance is the #1 problem CRITICAL
3× variance between light/heavy evenings (8 kWh vs 26 kWh over 10h). Flat average overestimates by ~15 kWh on light evenings — 35% of battery! Causes false SHORTFALL warnings on quiet nights.
_last_hour_avg kWh calculation bug MEDIUM
kwh = avg_kw × len(hours) uses count of distinct hours, not actual time span. Overestimates kWh by 10–20% for overnight periods.
Morning solar offset too coarse MEDIUM
Computed over 6–10am, but solar doesn't start until ~8:15am in Melbourne July. No fallback defaults to 0, inflating morning cost estimate.
23:00 misclassified as "evening" LOW
Load at 23:00 is ~1 kW (overnight-level) but counted as evening. Inflates evening estimate by ~1 kWh on light nights.
No day-of-week awareness
Weekend vs weekday patterns differ, especially mornings. Averages treat all days equally.
No afternoon solar offset
At 2–4pm, solar still generates but model assumes battery supplies everything. Overestimates evening need by 1–3 kWh.
Only 5 days of historical data
Hourly data collection paused Jul 12. The "7-day" window returns just 5 days — statistically noisy averages.
Fixed buffer threshold
10% (4.2 kWh) regardless of estimation uncertainty. Too thin on high-variance evenings, overly conservative for overnight-only windows.

📋 Recommendations — Priority Order

FixAccuracy GainEffortRationale
1 Resume hourly_data collection +30% over 30 days Low More data = better everything. Single highest-leverage action.
2 Day-of-week filtered baselines ±4 → ±2 kWh evening Low Halves evening variance, the dominant error source.
3 Fix _last_hour_avg kWh bug ±0.5 kWh One line Eliminates systematic 10–20% overestimate in rolling estimates.
4 Split evening: early (14–20) / late (20–24) ±2–3 kWh Low Clear load cliff at ~20:00 (1.85 kW → 0.88 kW).
5 Blend live + historical (weighted α) Smoother, less jumpy Medium Better UX, fewer false alarms at period transitions.
6 Sunrise-aware solar offset ±0.5 kWh morning Low Prevents over-crediting solar in 6–8am dead zone.
7 Dynamic buffer threshold (σ-based) Better SAFE/TIGHT calls Low Makes classifications meaningful given estimation uncertainty.
8 Afternoon solar offset ±1–3 kWh at 2–4pm Low-Med Only matters for 2 hours of the day.

⚖️ Design Assessment

✅ Pros

  • Zero-dependency — all self-contained JS + Python
  • Graceful degradation — always works, even with no data
  • Fast — simple arithmetic for 5-second polling
  • Interpretable — each component clearly labeled in UI
  • Source transparency — user can debug mentally
  • Appropriate complexity for 5 days of data

❌ Cons

  • Evening variance swamps all other errors
  • Averages hide extremes — underperforms on outlier days
  • No feedback loop — doesn't learn from mistakes
  • Historical data stale — only 5 days, collector paused
  • Single constant per period ignores intra-period ramps
  • No weather awareness — cloudy vs sunny mornings

🔧 Suggested Implementation Order

  1. P8 + P2 (immediate) — Resume hourly collection + fix the one-line kWh bug. Trivial fixes with outsized impact.
  2. P1 + P4 (next) — Day-of-week baselines + split evening early/late. Backend SQL changes that compound for accuracy.
  3. P3 + P5 (refinement) — Weighted blending + sunrise-aware solar offset. Frontend refinements for polish.
  4. P6 + P7 (nice-to-have) — Afternoon solar offset + dynamic thresholds. Minor gains for specific windows.