Why your state's peak hour moves with temperature

Open any state page on energymap.in today and you'll see a new panel: a candlestick of daily peak vs minimum demand, with the day's maximum recorded temperature overlaid as a line on the secondary axis. Hover any candle and you get the peak MW, the IST hour it happened, the minimum and its hour, and the max temp in °C.

Below the candlestick is a scatter — peak MW on the y, max temp on the x — with the line of best fit and a one-line caption that reads, for Rajasthan over the last four years, like: Across the last 1,460 days, peak demand in Rajasthan rises ~138 MW per 1°C of daytime high. R² = 0.98.

The May 2026 Rajasthan picture

Pick a random day in May 2026 in Rajasthan. The 41–42°C daytime high sets the peak in late afternoon, the night drops to ~26°C and the system relaxes to its minimum around 04:00 IST. The candle body is 6 GW tall and the temperature line is glued to its top edge. This isn't a rhetorical flourish — the Pearson r between daily peak MW and daily max temperature is 0.99 in Rajasthan over the trailing 4-year window.

The strongest signal in Indian power demand isn't weekly seasonality, it isn't the industrial calendar, and it isn't the festival cycle. It's the daytime high.

How to read the chart

• Candle body = min → peak demand met for that IST calendar day. Top edge is peak MW; bottom edge is min MW. Color is the load palette — no Wall-Street green/red since we aren't signalling up/down vs. a prior period.
• Temperature line on the secondary right-hand axis = the day's max recorded temperature at the state's representative weather point, sourced from Open-Meteo under their commercial license.
• Empty days render as a "no data" tooltip rather than a phantom candle. The aggregation drops days where neither the demand nor the weather feed has a complete picture.

Methodology in 200 words

For every state and every day in the lookback window we compute four things:

1. Daily aggregation. Hourly demand → MAX(demand_mw) as peak_mw and MIN(demand_mw) as min_mw. Hourly Open-Meteo temperature → MAX(temperature_c) as max_temp_c. All aggregation is IST-bucketed at the API edge so the peak hour is the one a power engineer in Lucknow would actually report.
2. Same-day Pearson r between the two daily series. This is the headline number.
3. Lag analysis at -1, 0, +1 days. For most hot Indian states the best lag is 0; cooler hill states pick up +1 (yesterday's heat drives today's peak via building thermal mass).
4. Seasonal split. Apr–Jun "summer" vs. the rest of the year. The cooling signal is much stronger in summer for plains states; flat-to-inverted in the Himalayas.
5. OLS on peak_mw = slope · max_temp_c + intercept. Slope is the headline figure for FE captions; intercept is the no-cooling-load baseline.

One implementation in algorithms/weather_peak_correlation.py; the BE endpoint, the reference notebook, and the benchmark CSV all use the same code path. Pearson and OLS are written in plain Python — no SciPy — so the math is auditable line-by-line and the BE import budget stays small.

Per-state R² and slope

Sourced from benchmarks/weather_peak_correlation_2026-05-18.csv. Synthetic-fixture baseline today; the live-DB numbers refresh after the IEA-667 retrospective archive lands.

A few patterns jump out. Delhi and Rajasthan are the cleanest cooling-driven systems — almost every degree of daytime high translates directly into MW. Uttar Pradesh has the steepest absolute slope (191 MW/°C) but a lower R² because the demand baseline itself is high and grows with the agricultural calendar independently of temperature. Sikkim is the textbook inversion: heating load means demand falls as temperature rises, and the negative r is just as strong in magnitude as Rajasthan's positive one.

How to reproduce

Two new endpoints ship the math. Both live under /api/v1/states/{state_slug}/.

1) Daily peaks for any current-month window — anonymous-accessible:

curl "https://api.energymap.in/api/v1/states/rajasthan/daily-peaks?from=2026-05-01&to=2026-05-18"

Out-of-window dates require a signed-in session (free tier covers up to 92 days back; older history is paid). Anonymous requests for past months return 403 auth_required with a structured CTA the FE wires straight into the sign-in modal.

2) Weather-peak correlation — open to anonymous, aggregate-only:

curl "https://api.energymap.in/api/v1/states/delhi/weather-peak-correlation?lookback_days=1460"

The response carries r_pearson, r_squared, slope_mw_per_c, intercept_mw, and a stride-downsampled scatter capped at 365 points. Full methodology in the notebook at notebooks/weather_peak_correlation.ipynb.

What's next

• Apparent temperature — heat-index adjustments using humidity + wind so coastal states (Tamil Nadu, Kerala, West Bengal) get a fairer signal than dry-bulb gives them today.
• Multi-day rolling correlation — a 30-day window so policy analysts can see how the cooling-load coupling shifts across the year.
• Anomaly detection — flag days where peak demand departs from the temperature-implied band (festival load, grid events, monsoon-onset shifts).
• NRLDC reconciliation — the Northern-state numbers reconcile to NRLDC PSP via the new data_quality block on the daily-peaks response. Read the backfill certification methodology in the next post.

PRs: BE endpoints · FE components · Math module + benchmark · E2E matrix · NRLDC certification framework