Hantera effektkomponent som beror på lokalisering i elnätet

[mattiaspalmqvist]

I framtiden kan det bli aktuellt med tariffer för olika lokala områden i elnätet. Genom att ha en komponenttyp "localized" eller liknande i powerPrice så kan vi hantera det med hjälp av en ny endpoint där du skickar in ditt mpid och priset för din lokala del.

[mattiaspalmqvist]

Lösningsförslag:

{
  "id": "c174eb50-7cee-4027-b280-c3d23dda558e",
  "name": "Dynamic hour price winter",
  "description": "During winter season every single hour has it's own price level. Every day the price levels are updated. The average power during one hour is mulitplied with the hour price to calculate the cost.",
  "type": "dynamic",
  "reference": "dynamic",
  "price": null,
  "pricesUrl": "https://www.thegridcompany.se/api/prices",
  "validPeriod": {
    "fromIncluding": "2024-10-01",
    "toExcluding": "2025-04-01"
  },
  "peakIdentificationSettings": null,
  "recurringPeriods": []
},
{
  "id": "ff7ba4a2-0b1b-463f-82a9-6e93681c7a67",
  "name": "Localized price component",
  "description": "Power price component that depends on the localization in the grid. Get prices by calling the prices endpoint with this components ID.",
  "type": "localized",
  "reference": "localized",
  "price": null,
  "pricesUrl": "https://www.thegridcompany.se/api/prices",
  "validPeriod": {
    "fromIncluding": "2024-10-01",
    "toExcluding": "2025-04-01"
  },
  "peakIdentificationSettings": null,
  "recurringPeriods": []
}

För att få priserna så behöver prices-endpointen anropas med componentId (alltså GUID för den priskomponent som innehåller pricesUrl). När man får en pricesUrl i svaret istället för ett price-objekt så innebär det att man ska anropa url istället eftersom man inte får något statiskt pris i svaret.

[mattiaspalmqvist]

Jag tänkte först att MPID ska skickas med i anropet till api/prices, men det bör räcka med componentId även för "localized" eftersom det går att skapa flera olika localized components i backend och göra länkningen mellan MPID och korrekt localized component i backend. Då skickas korrekt localized component med i svaret när man frågar om tariff för ett specifikt MPID.

[larwa99]

Jag tycker det skaver lite om det är så att den tariff vi svarar med för en viss mpid inte är en generell tariffdefinition utan innehåller en component som varierar utifrån vilken mpid man skickat. Det skulle innebära att vi behöver ha ett unikt "id" för alla lokaliseringsvarianter av varje typ av tariff/avtal. Jag skulle hellre se att vi har en och samma lokaliseringskomponent om det ingår i tariffen/avtalet och sedan en separat endpoint /api/locations som ger en mappning mellan mpid och ett "locationId" som sedan används för att få ett lokaliserat pris genom anrop till /api/prices. Endpoint /api/locations behöver troligen bara anropas som del av onboarding och sparas undan.

Alternativt, om vi vill byta ut befintligt API skulle /api/mappings kunna ersätta /api/Tariffs/ForMeteringPoints och bara ger olika mpid-specifika mappningar (tariffId och locationId) och inte som nu inkludera själva tariffdefinitionen.