How this monitor works
The Ireland Energy Transition Monitor is a public-interest dashboard. It gathers public electricity data, turns it into local JSON files, checks whether the numbers are coherent, and presents the result as a readable story about Ireland’s electricity transition.
1. What question is the monitor asking?
The monitor asks whether Ireland is moving fast enough toward the 2030 renewable-electricity benchmark. It also asks how new electricity demand, especially from data centres and electric vehicles, could make the catch-up task harder.
The key idea is simple: the target is about a share, not just a fixed amount of electricity.
If total demand grows, Ireland needs more renewable electricity just to hold the same percentage.
2. Why live grid data and annual RES-E data are not the same thing
Shows what is happening now or recently: generation, wind, solar, interconnection, thermal/other generation, and CO₂ intensity where available.
Shows annual renewable-electricity progress against the 2030 benchmark. This is slower, policy-facing, and better for accountability.
A windy hour can look excellent while the annual transition remains off track. That is why the dashboard keeps live electricity conditions and annual target progress separate.
3. How the data pipeline works
The browser does not scrape public websites directly. Instead, Python scripts harvest or build data files first. The webpage reads local JSON.
This makes the dashboard easier to archive, inspect, and reproduce. It also means the dashboard can keep working even when a public source needs a fallback or caveat.
4. What the scrapers do
The scripts in ops/ collect, normalise, or generate data. Some scripts harvest current electricity
values. Others build derived layers such as the target tracker, demand-pressure scenarios, daily history, or source metadata.
The scraper layer is deliberately separate from the display layer. The public page reads prepared JSON rather than scraping live sources in the user’s browser.
5. Why some numbers are withheld or caveated
Energy data can be incomplete, delayed, or internally inconsistent. If a number looks precise but does not reconcile, the responsible choice is to withhold or label it.
| Case | Dashboard response |
|---|---|
| Generation mix does not add up coherently | Fail validation or withhold affected output |
| Solar is zero at night | Do not fail; this can be normal |
| Demand does not balance with generation and interconnection | Withhold demand card and show caveat |
| Other renewables remainder is unusually high | Warn; likely component/source uncertainty |
6. What the demand-pressure scenarios mean
Data centres and electric vehicles can increase electricity demand. That does not move the official 80% RES-E target. It changes how much renewable electricity is needed to reach that target.
The model asks: if extra demand arrives, and if that demand is not neutralised by additional renewable generation, how much wider could the visible gap to 80% become?
The low, central, and high pathways are scenario assumptions. They are not official forecasts.
7. How to read the final gap-widening chart
The final chart keeps the y-axis as RES-E percentage. The green target line stays fixed. The projected trend line moves lower if unneutralised demand pressure is added.
Higher demand pressure therefore means a wider visible gap, not a moving target.
8. Measured, forecast, modelled, scenario, fallback
| Label | Meaning |
|---|---|
| Measured | Observed or reported historical value. |
| Forecast | Near-term published or source-based expectation. |
| Modelled | Calculated from transparent assumptions. |
| Scenario | Conditional pathway used to stress-test a possible future. |
| Fallback | Placeholder or schematic value used when primary data are unavailable. |
9. State of the art
Most live grid dashboards show the present. Official annual statistics show retrospective progress. Scenario studies examine possible futures. This monitor connects those layers in one static civic dashboard: current conditions, annual accountability, caveats, and demand-pressure stress testing.
10. Intended further work
- Add stronger source provenance to generated JSON values.
- Replace scenario assumptions with official or traceable projections where available.
- Document each harvester and fallback pathway.
- Add tests for generated files and validation rules.
- Prepare a clean archival release with citation metadata for Zenodo.
11. Where the deeper documentation lives
The public explainer is this page. The Zenodo-facing technical overview is the project README: