SPP · Generation

SPP wind and solar output

Name: SPP wind and solar output
Creator: Dryos

Wind and solar output every five minutes in SPP's RTO and in RTO West — the actuals SPP publishes beside its short-term resource forecast.

spp-renewables-actualevery 5 min · 5m rows2 entities

SPP

20,874MW

2026-09-18 04:55 UTC

SWPW

459MW

2026-09-18 04:55 UTC

Read from the Dryos API and cached for an hour; the stream itself updates every 5 min.

What is in it

Every value, its unit, and what the source means by it.

Exactly what a request answers with, read from the API rather than written here.

Column	Type	Description
interval_start_utcrequired	timestamp	Start of the five-minute interval, UTC. SPP stamps the interval's end.e.g. 2026-09-14T20:45:00Z
isorequired	string	Publishing ISO.e.g. SPP
zonerequired	string	Balancing authority: SPP for the RTO, SWPW for RTO West.e.g. SPP
wind_mw	number	Actual wind output, MW.e.g. 24680.56
solar_mw	number	Actual solar output, MW.e.g. 843.41
source_published_at_utc	timestamp	When SPP published the row.
collected_at_utcrequired	timestamp	When Dryos collected this row, UTC. Stamped by the platform, not the collector.e.g. 2026-09-14T20:51:10Z

Public, read-only, no key and no sign-up. Relative times stay relative, so a URL keeps working.

The newest rows

shell

curl "https://api.dryos.ai/v1/datasets/spp-renewables-actual/query?node=SPP&limit=12"

The catalogue entry — every column, its type and the source

shell

curl "https://api.dryos.ai/v1/datasets/spp-renewables-actual"

Hourly averages for the last day

shell

curl "https://api.dryos.ai/v1/datasets/spp-renewables-actual/query?node=SPP&start=-24h&interval=1h&agg=avg"

Full parameters — bucketing, aggregation, filters and search — are on the API reference.

The same stream through the Model Context Protocol, so Claude, ChatGPT, Cursor or any MCP client can query it directly.

shell

claude mcp add --transport http dryos https://api.dryos.ai/mcp

Then ask:

What has Wind been at SPP over the last 24 hours, and when did it peak?

Setup for every client is on the MCP server page.

A change in the collector is a change in the data. Anyone reading a step in a series is owed the day it moved under them.

2026-09-17
The three-day gap from 2026-09-14 to 2026-09-17 is a collector fault, not a source one. SPP's dated files still hold it, and the runs after this read it back in oldest first.
Every run since the first raised `TypeError: Start and end cannot both be tz-aware with different timezones` while planning which files to read. Postgres hands a stored timestamp back under `Etc/UTC`, which is the same zone as pandas' `UTC` and not the same object, and a range built between the two is refused — a break that could not happen on the SQLite these were written against. SPP had published normally throughout.
2026-09-14
First collected, from SPP's marketplace portal.
Every other operator's wind and solar output was here and SPP's was not. Reconciled against the live files on 2026-09-14: schema, nulls, primary key, value bands and row counts passed.

Pulled straight from SPP Marketplace Portal · Short-Term Resource Forecast (actuals) — no reseller in between — and compared against that file before it is served.
Null means the source did not report it — never zero.
A reading lands every 5 min; the interval timestamp is the start of the interval, in UTC.
SPP publishes on US Central prevailing time, with a UTC column on every row. Every timestamp Dryos serves is UTC.