For en forbruger i Danmark er strømprisen en sum af forskellige priser og afgifter, nogle faste, nogle dynamiske:
El-afgiften fastsat ved lov til 0,761 kr per kWh.
Energinet’s eltariffer: Nettarif på 0,074 kr per kWh (år 2024), og systemtarif på 0,051 kr per kWh (år 2024).
Netselskabstarif fra forsyningsselskabet (N1, Radius, etc.): denne varierer per time og per sæson for at forsøge at incentivere til at udligne forbruget så der ikke skal investeres i nye og større elkabler, og er indkodet i datasættet over tariffer og priser. Private forbrugere betaler C-tarif.
Spot-prisen: er den anden variable, og denne varierer ud fra udbud og efterspørgsel.
Moms: 25% lagt til summen af ovenstående
Dette er alle de uundgåelige priser og afgifter, der kan regnes ud udelukkende fra adressen. Derudover kommer så det “frie elmarked”, hvor der skal betales til et elselskab: typisk månedsabonnement og et tillæg til spot-prisen.
Tariffer og priser – det værste åbne datasæt?
Som om det ikke er uoverskueligt nok i sig selv, bliver vi nødt til at snakke om datasættet Datahub Price List. Der er flere åbenlyse problemer med det:
Der er flere felter man burde filtrere efter, men hvor der ikke findes en udtømmende liste over værdier, f.x. netselskab “ChargeOwner”. Det bedste man kan gøre er at downloade, hvor man så løber ind i at download kun giver 100.000 rækker – og datasættet er fuldt på over 300.000 rækker.
ChargeTypeCode er per selskab – og uden systematik. Så for hvert enkelt selskab skal man finde ud af hvilken priskode de bruger for C-tariffen. Og hvad når det ændrer sig?
ValidTo kan være udeladt og dermed et open ended interval, og prisen gælder så indtil data retroaktivt ændres. Det betyder også at man ikke kan filtrere på datoer, da prisen på 1. april kan være en række der har en ValidFrom 1. januar (eller tidligere).
Price1-24: dette er selve timetarif-priserne. Hvis en pris ikke er udfyldt gælder Price1 – hvorfor I alverden dog tilføje den ekstra kompleksitet!?!?!
For ikke at tale om tidszoner: man må antage (det er ikke dokumenteret) at alle datoer og timetal er angivet i hvad end tid der er gældende i Danmark på pågældende dato. Dette giver så problemer ved skift fra sommer-/normal-tid hvor en time gentages eller udelades: hvilken timesats bør bruges i et døgn der har 23 eller 25 timer?
Efter at have regnet de fleste af de ovenstående problemer ud, skrev jeg en API-proxy der udstiller det API man i virkeligheden vil have: givet en dato, og et elselskab (eller en adresse), returnerer den prisen time for time som et JSON dokument. Prisen er typisk tilgængelig fra kl. 13 dagen før. Som bonus får man også CO2 udledningen med, hvis den er tilgængelig (typisk kl. 15 dagen før). Det er implementeret som en ren API proxy, dvs. det er ren omskrivning af input og data og ikke andet.
Det hele er open source, men der kører en version på elprisen.somjson.dk som frit kan benyttes.
Alternativer
Der findes andre API’er der opfylder forskellige use-cases:
Min Strøm API er rigtig modent og har egen forecast model der kan forecaste 7 dage frem, før priserne er låst på Energi Data Service. Kræver en API nøgle og er uden kildekode
Strømligning API kan bruges til at udregne priser baseret på historisk forbrugsdata. Kan dog også bruges til at hente de forecastede priser. Med rate limiting, og uden kildekode.
Carnot har også et åbent API og egen forecast model. Kræver API nøgle, og er uden kildekode.
Billigkwh.dk har et åbent API til elpriser der også inkluderer de forskellige elselskabers abonnement.
