ED.UNIT.RANGE

Time series of generation for a single production unit. ENTSO-E A73 publishes at native 15-min cadence. Aggregation is controlled by agg: 0=native, 5min/10min/15min, 1=hourly, 2=daily (default), 3=monthly, 4=quarterly, 5=semiannual, 6=annual, 7=total. agg=0/RAW returns the real 15-min grid (96 slots a day, reconstructed from the run-length document) and agg=7/T returns a single total value — same semantics as ED.RANGE.

**Unit (unit parameter):** by default each bucket holds the mean power in MW over the bucket, weighted by how long each published value was in force. That is the right number for capacity-factor and dispatch analysis but it is NOT the energy generated — "annual generation 800 MW" does not mean 800 MWh, it means 800 MW × 8760 h ≈ 7 TWh. Pass unit="MWh" for the energy delivered in each bucket: the integral of the same curve, so it agrees with the MW figure by construction. The unit_generation table is 100% MW-stored, so unit="MWh" always works — there is no already-MWh edge case (unlike prices or pre-MWh metrics in ED.RANGE).

**How the 15-min data is read (important).** ENTSO-E publishes A73 with curveType A03 — run-length encoded. A position missing from the document means *"the same value as the previous point"*, not zero and not "no data": a plant sitting at 985 MW all day may publish two points, not 96. EnergyData stores the document exactly as published and expands it at read time — every point is weighted by how long it was in force, so MW and MWh are two views of the same curve and can no longer contradict each other. Averaging the stored points as if they were equal samples over-reports MW by up to +777 % on a CCGT; the older per-hour-average-then-sum route under-reported MWh by up to 74 % because it dropped hours that published no point. If you pull per-plant data from another provider, check which of the three you get.

**coverage_pct.** The REST response carries a coverage_pct (0-1) for the whole window plus a coverage array per bucket: the share of each period actually backed by published data. A value is carried forward only to the end of its own UTC day's publication — never across midnight, never backwards, never past the point where that day's data stops — so an ingest gap stays a gap with a low coverage_pct instead of turning into a plausible-looking number, and a bucket with nothing behind it is omitted rather than filled. Expect 1.000 for recent data; about 0.958 between 2025-05-31 and 2026-04-12 (hour 23 UTC was not collected) and about 0.240 before 2025-05-31 (an upstream resolution bug compressed each day into its first ~6 hours). Windows spanning those periods are still affected — coverage_pct is how you spot it.

**Calendar-bucket edge.** With agg=2/D and coarser, a value in force across civil midnight is credited entirely to the bucket it started in (about 1 % of intervals). It is immaterial for plants that run around the clock and visible only for units that switch off overnight; agg=1/H and agg=0/RAW are unaffected. If you need calendar-day energy at settlement precision, aggregate the hourly series yourself.

A window with no data returns #N/A, never 0: a zero here would read as "the plant produced nothing", which is a different — and false — statement.