Every utility forecast team uses a temperature-sensitivity number — megawatts per degree Celsius (MW/°C) — as the planning shorthand. It's in the spreadsheet. It's in the operator's head. It's wrong — or at least, it's a single number standing in for a relationship that changes by season, by hour, by humidity, by wind, and by the size and climate of the system it's measured on. There is no universal number. The real temperature-load relationship has a change-point (the balance point where heating gives way to cooling), different slopes above and below that point, and interactions with humidity, wind, and solar radiation that the single-number shorthand can't capture.
This demo replaces the rule of thumb with a model that learns the actual relationships from data. It pulls real historical weather from your location (Open-Meteo Archive API), fetches the live 14-day forecast, generates realistic load patterns from the real weather, trains an interpretable OLS regression with change-point detection, and applies the model to produce a 14-day load forecast with operational recommendations — all in your browser.
Try It Now
The demo detects your location (via browser geolocation — allow the prompt), fetches 365 days of real hourly weather + the current 14-day forecast, generates realistic electricity load from the real weather, trains the model, and forecasts. No data leaves your browser except the weather API calls and the optional AI Q&A.
What Just Happened
The demo ran a complete Weather → Load → Risk → Recommendation pipeline:
- Ingested real weather — 365 days of hourly historical observations (temperature, humidity, precipitation, wind speed, solar radiation, pressure, weather codes) from your actual location, fetched from the free Open-Meteo Archive API. Plus the current 14-day hourly forecast from the Open-Meteo Forecast API. No API key, no synthetic weather.
- Generated realistic load — synthetic electricity demand driven by the real weather. Realistic utility patterns: diurnal cycle (13 GW overnight trough, 19 GW evening peak), 15% weekend reduction, heating response below 18°C (~0.5 GW/°C), cooling response above 18°C (~0.8 GW/°C), humidity/wind/solar effects. The load follows the real weather — if your location had a heat wave last July, the load spiked.
- Trained an interpretable model — ordinary least squares regression on 16 features: hour-of-day (cyclical), day-of-week, weekend flag, temperature, temperature², heating degree hours, cooling degree hours, humidity, wind speed, solar radiation, precipitation, pressure, lag-1h load, lag-24h load. The model also detected the change-point (the temperature where heating gives way to cooling) by sweeping 10°C–25°C in 0.5°C steps and picking the breakpoint that minimizes RMSE. The model learned the actual slopes — not a single MW/°C shorthand.
- Forecasted 14 days — applied the trained model to the real 14-day weather forecast. Produced hourly predicted load with 80% and 95% prediction intervals. Aggregated to daily peak load, identified threshold exceedances, and assigned operational risk levels (Normal / Elevated / High / Critical) based on configurable percentile thresholds.
- AI explained the forecast — the Groq AI layer answers questions like "Why is load expected to increase on Thursday?" using the model's actual learned coefficients, not assumptions. It also generates daily operational briefings: Expected Load → Main Drivers → Risk Level → Recommended Action.
What Makes This Different
| Rule-of-thumb forecasting | Interpretable model-based forecasting |
|---|---|
| Single MW/°C number — same for all seasons, all hours | Model learns separate heating and cooling slopes + the change-point where they meet |
| Temperature only — ignores humidity, wind, solar, pressure | 16 features including calendar effects, lagged load, and 7 weather variables |
| No uncertainty quantification — just a point forecast | 80% and 95% prediction intervals at every forecast hour |
| Operational thresholds are static ("if load > 18 GW, call extra crews") | Thresholds are percentile-based (P90/P95/P99 of historical peaks) — adaptive to seasonal baselines |
| Black-box ML models (if used at all) can't explain why load is forecasted high | AI uses the model's actual coefficients to explain: "Thursday's peak is +14% because temperature reaches 32°C — the model learned +0.8 GW/°C above 18°C" |
| One forecast, one number — no scenario analysis | Variable importance shows which features drive the forecast — temperature is #1, but humidity and hour-of-day matter too |
The Modeling Approach
The model is deliberately interpretable — ordinary least squares regression, not a neural network or gradient-boosted ensemble. This is a feature, not a limitation:
- OLS regression — the coefficients are directly interpretable. "+0.8 GW per °C above 18°C" means exactly that. No black-box opacity.
- Change-point detection — instead of assuming 18°C is the balance point, the model sweeps 10°C–25°C and learns the actual breakpoint from data. Different climates have different change-points.
- Calendar effects — hour-of-day, day-of-week, and weekend/weekday are encoded as features. The model learns that load drops 15% on weekends, that the evening peak is at 6pm, that the overnight trough is at 4am.
- Lagged load — yesterday's load at the same hour is a feature. This captures autocorrelation (load is sticky — today's load is correlated with yesterday's).
- Variable importance — standardized coefficients show which features matter most. Temperature is typically #1, followed by hour-of-day, then humidity. The ranking is data-driven, not assumed.
- Real load data — replace the synthetic generator with your actual SCADA/AMI load feed. The model architecture stays the same — just swap the training data source.
- Backend-less (static JSON + GitHub Pages) — the pipeline runs as a scheduled job, fetches weather + load, trains the model server-side, writes forecast JSON. The dashboard fetches the JSON. Right for daily batch forecasting.
- Your existing SQL backend — the model reads from your SCADA historian + weather data warehouse, writes the 14-day forecast to a table the operations dashboard queries. The forecast updates every hour as new weather data arrives.
- Managed warehouse + serverless API — Supabase / Neon holds the load + weather tables, a scheduled serverless function retrains the model nightly + generates the 14-day forecast. Zero ops on your side.
In production, you'd add regularized regression (Ridge/Lasso) for feature selection, GAMs for nonlinear temperature response, and optionally compare against Random Forest or XGBoost for accuracy benchmarking. But the interpretable OLS model remains the primary — because operations teams need to understand why the forecast says what it says, not just trust a number.
From Demo to Production
The demo runs entirely in your browser — real weather from Open-Meteo, realistic synthetic load, pure-JS regression, Groq AI. In production:
The model spec doesn't change between topologies. The runtime does.
The Honest Part
The load data is synthetic — generated from real weather using realistic utility coefficients (heating 0.5 GW/°C, cooling 0.8 GW/°C, etc.). The weather is 100% real from your location. In production, you'd replace the synthetic generator with your actual load feed. The model architecture, the change-point detection, the variable importance, the prediction intervals, and the AI explanation layer all stay the same.
The prediction intervals use single-step uncertainty (1.96σ × √(1 + x'⁻¹x)) rather than simulating lag-feature uncertainty propagation. For a 14-day forecast, the intervals widen in the later days — which is correct behavior, but a Kalman recursion or Monte Carlo simulation would be more precise. The UI notes this; for production, you'd integrate over the lag distribution.
The Groq AI rate limit is 10 calls per session. The model itself is trained entirely client-side — no server round-trip. The AI is used only for explanation and decision support, not for the forecast itself. The forecast is produced by the statistical model, not by the AI.
Want this wired to your real load data?
Bring your SCADA historian export or AMI load feed. We'll set up the model against your actual load + weather data, produce the 14-day forecast with operational recommendations, and show you the change-point + coefficients your data reveals — before the meeting ends.
Book a Working Session