Spot-hinta.fi - Yksinkertainen pörssiohjaus API ja sitä käyttävät automaatioskriptit

[Mikki]

Päivitys 14.9.2023:

Ketju on pitkä, mutta tiivistettynä: Tästä ketjun ideasta syntyi spot-hinta.fi palvelu, jolle on löytynyt aika tukeva nelinumeroinen käyttäjäkunta vuoden aikana. Palvelu on harrastepohjalta tehty, mutta tarkoitus on ylläpitää tätä pitkään ja jos into tai kyky joskus loppuu, tulee palvelinpään koodi julkiseen jakoon.

Sivusto, mistä nykyisin löytyy lisätietoa on: https://spot-hinta.fi/
Samoin Twitterissä/X:ssä voi seurata tätä: https://twitter.com/Spot_hinta_fi

Tästä se matka lähti....
-----

Tämä ketju on tarkoitettu kehittämäni pörssihinta-rajapinnan dokumentointiin. Jos vaikka joku haluaisi sitä käyttää. Tiedot rajapinta hakee Entso-E palvelusta, mutta suoraa yhteyttä rajapinnalla ei sinne ole, vaan tiedot tulee välimuistista.

Syy rajapinan tekemiseen on siinä, että en löytänyt näin yksinkertaista rajapintaa mistään, jos on kiinnostunut vain Suomen hinnoista valmiiksi pureksittuna automaatiolle sopivaan muotoon.

Rajapinnan uusi versio syntyi tänään aamukahvilla. Uudet rajapinnat ovat:

• https://api.spot-hinta.fi/Today (tämän päivän hinnat, mitä pienempi "Rank" lukema, sitä halvempi tunti)
• https://api.spot-hinta.fi/JustNow (tämän hetken hinta ja sen "Rank" päivän sisäisesti)
• https://api.spot-hinta.fi/JustNowRank (palauttaa ainoastaan "Rank" tämän hetken tunnille, ei mitään muuta)
• https://api.spot-hinta.fi/JustNowRank/{rank} (palauttaa "bad request", jos tämän hetkinen "Rank" on yli parametrina annetun arvon. Toimii myös "HEAD" requestilla jolloin rajapinta ei palauta muuta kuin otsikkotiedot).
• https://api.spot-hinta.fi/DayForward (huomisen hinnat, kun ne ilmestyy)
• https://api.spot-hinta.fi/TodayAndDayForward (yhdellä haulla tämän päivän hinnat ja huomiset jos ne on olemassa)

Jos ajastatte tietojen hakua, niin max. 1 haku per minuutti olisi toiveena, vaikka rajapinnat skaalaa. Mutta turhaa liikennettä, ja pientä lisäkustannusta tietenkin suorituksista tulee tavalla tai toisella.

Bugeista ja kehitysehdotuksista voi laittaa vaikka priva-viestiä nin ei ketju sekoitu. Tai ketjuunkin toki.

 

[ttk2]

Pyynnöstä toteutukseen alle vuorokaudessa, hyvää toimintaa @Mikki !

Tätä rajapintaa käyttäen oli hyvin nopea askarella Home Assistant:iin nykyisen hinnan ja hinnan järjestysnumeron näyttäminen:

Käytin RESTful-sensoria. Konfiguraatio configuration.yaml tiedostoon.

Ensin sensorissa määritetään haku (oletuksena HA:ssa tuo toimii 30s välein pollaavana):

sensor:
  - platform: rest
    name: "Sähkön hinta"
    resource: https://api.spot-hinta.fi/JustNow
    method: GET
    device_class: monetary
    force_update: true
    json_attributes:
      - DateTime
      - PriceWithTax
      - PriceNoTax
      - Rank
    state_class: measurement

Ja tämän jälkeen tein erilliset template sensorit vielä hinnalle ja järjestysnumerolle:

- platform: template
    sensors:
      el_price:
        friendly_name: "Sähkön hinta nyt"
        unit_of_measurement: "c/kWh"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'PriceWithTax') | float * 100 }}"
      el_price_rank:
        friendly_name: "Sähkön hinnan järjestysluku"
        value_template: "{{ state_attr('sensor.sahkon_hinta', 'Rank') | int }}"

Mitään automaatiota näiden hinnan tai järjestysluvun perusteella en vielä ehtinyt toteuttamaan, mutta se käy ihan point-and-click tyylisesti käyttöliittymästä käsin.

Kiitos vielä tästä rajapinnan luomisesta ja avoimesta suhtautumisesta muutospyyntöihin, sekä vielä kaupanpäällisiksi erittäin nopeasta muutoksien toteutuksesta!

edit: vaihdettu yaml-esimerkin osoitteeseen "api".

 

[Mikki]

Eipä kestä. Sellaisen vielä muutoksen tässä teen, että domain muuttuu api.spot-hinta.fi muotoon. WWW-alkuinenkin toimii vielä, mutta otan sen osoitteen HTML sivujen käyttöön jossain välissä. Tuo "api" -domain toimii jo, että voit vaihtaa siihen jo.

 

[ttk2]

Mitään automaatiota näiden hinnan tai järjestysluvun perusteella en vielä ehtinyt toteuttamaan, mutta se käy ihan point-and-click tyylisesti käyttöliittymästä käsin.

Tuohon edelliseen vielä jatkoa sen verran, että tein pikaisesti käyttöliittymässä automaation, joka ohjaa lämminvesivaraajan päälle, kun on menossa jokin vuorokauden kolmesta halvimmasta tunnista. Kopioin käyttöliittymästä HA:n automaattisesti muodostaman yaml-koodin, niin näette miten automaatiot toimivat:

alias: Lämminvesivaraajan pörssisähköohjaus ON
description: Lämminvesivaraaja kytketään päälle vain vuorokauden halvimpina tunteina.
trigger:
  - platform: numeric_state
    entity_id: sensor.sahkon_hinta
    attribute: Rank
    below: "4"
condition: []
action:
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.100027461a_1
mode: single

Tuossa switch.100027461a_1 on id wifi-releelle (Sonoff 4CH R2:n yksi kanavista), joka on vielä asentamatta sähkökeskukseen. Hyvä tietysti kuivaharjoitella skenaariot ensin työpöydällä.

Vastaavasti tein OFF-automaation, kun Rank > 3.

HA:n developer tools-puolella kävin asettamassa aiemmin määritellylle "Sähkön hinta" sensorille attribuuttiin Rank arvon 3, jolloin automaatio triggeröityi ja rele meni tilaan "on". Vaihdoin arvoksi 4, jolloin rele meni tilaan "off". Toimii, joko se sähkömies tulisi kytkemään?

Potilas L1-kanava tilassa "on":

Releen olen ostanut jo pari vuotta sitten, HA oli valmiina, joten kustannukset tälle ohjaukselle toistaiseksi 0€. Sähkömieskin on omasta takaa, joten kahvilla ja pullalla selvittäneen. Tämä yksinkertaisen APIn tuleminen mukaan kuvioon sai viimein tekemään asialle jotain.

 

[Jullikka]

Tämähän on tosiaan loistava lisäys, aikaisemmin sai haettua tuntihinnat nordpool-palvelusta, mutta en jaksanut viritellä sen kummemmin tuntihintoja järjestykseen. Tällä on helppo tehdä automaatioita halvimmille tunneille, vielä kun tuota Nibeä voisi ohjata hiukan paremmin netin yli.

 

[Mikki]

No johan on nopeaa toimintaa. Älkää kuitenkaan ihan vielä ydinvoimalaa ohjatko tällä, just korjasin yhden bugin huomisiin hintoihin liittyen. Saattaapi jotain muutankin löytyä vielä

 

[Jullikka]

Tuleepahan OL3 efektiä tähänkin projektiin!

 

[ttk2]

No johan on nopeaa toimintaa. Älkää kuitenkaan ihan vielä ydinvoimalaa ohjatko tällä, just korjasin yhden bugin huomisiin hintoihin liittyen. Saattaapi jotain muutankin löytyä vielä

Laitetaan sun työtuolin alle sellainen rele kanssa ja bugin tullessa aina vähän räpsähtää takalistoon :-D Koska tietenkään kukaan ei ole koskaan tyytyväinen edes ilmaiseksi saamaansa palveluun.

Mutta jos ei nyt verkkosähkörelettä kuitenkaan, vaan joku vähän kesympi.

 

[kotte]

Saattaapi jotain muutankin löytyä vielä

Vihjeenä vain, että vajaan parin kuukauden kuluttua siirrytään talviaikaan ja periaate on, että yksi tunti tulee kahteen kertaan, kun kello peruuttaa tunnin ensimmäisellä kerralla klo 04:00. Hintahan pysyy. Keväällähän vastaava homma on tavallaan helpompi, kun yksi tunti vain kilahtaa pois. Eihän tuo muuta käytön kannalta muuta paitsi, että vuodessa on kaksi vuorokautta, joissa on muu kuin 24 tuntia (eli keväällä yhtenä 23 tuntia ja syksyllä yhtenä 25 tuntia).

 

[hanks]

Hieno juttu, ehdin jo aprikoida miten saisin Wemos D1 minin lukemaan tuota apia, mutta ESPeasyssä ei näytä olevan siihen mahdollisuutta. Pitänee harkita jotakin toista firmwarea.

 

[Mikki]

Hieno juttu, ehdin jo aprikoida miten saisin Wemos D1 minin lukemaan tuota apia, mutta ESPeasyssä ei näytä olevan siihen mahdollisuutta. Pitänee harkita jotakin toista firmwarea.

Eli ei saa tehtyä REST kutsua vai onko JSON parsinta ongelmana?

 

[ttk2]

Ensimmäisen yön jälkeen tarkistin kuinka hyvin APIn käyttö on toiminut. Ja onhan se!

Tässä toteutuneiden tuntien hinnan järjestysluvun historia HA:sta. Alle piirsin itse punaisella ("off") ja vihreällä ("on") mitä releen oli suunniteltu tekevän:

Ja tässä tuolla tiedolla ohjatun releen historiatieto viime yöltä:

Toimi ihan kuten pitikin.

Se, että API määrittää tuntien keskinäisen järjestyksen hinnan mukaan, on hyvä apu ja tekee tiedosta "saavutettavamman", kun tulkinnan ei tarvitse olla millään tavalla monimutkainen.

Viikonloppuna rele on toivottavasti jo paikoillaan ohjaamassa varaajaa.

 

[roots]

Sitten kun tulee 15min tasejaksot, tietääkseni -23, tarkkuus taajenee, eli 4x enemmän taulukoille pituutta.

Eihän se varmaan tuota hintaperiaatetta paljon muuta, ei siellä tunnin sisällä mikään 15min pätkä kauhiasti eroa muista.

Kait ne hinnatkin menee 15min jaksoihin, vaikkei tuosta kovin paljoa pöhinää ole näkynyt!?

 

[puuteknikko]

Sitten kun tulee 15min tasejaksot, tietääkseni -23, tarkkuus taajenee, eli 4x enemmän taulukoille pituutta.

Eihän se varmaan tuota hintaperiaatetta paljon muuta, ei siellä tunnin sisällä mikään 15min pätkä kauhiasti eroa muista.

Kait ne hinnatkin menee 15min jaksoihin, vaikkei tuosta kovin paljoa pöhinää ole näkynyt!?

Eikö tuo ollut vasta tulossa sitten joskus? Netotuspakko tulee v. 2023 alusta ja jossain vaiheessa siirtyminen varttitasolle.

 

[Mikki]

En kyllä usko että hinnat varttitasolle menee ainakaan ensivuonna. Hyvä jos nykyinen systeemi pysyy pystyssä.

Nuo rajapinnat pitäisi olla teknisesti luotettavasti toimivia. Teknisen alustan "SLA" on 99,95% kun nuo pyörivät "serverless" Azure Functions alustalla Microsoftin palvelinkeskuksessa Irlannissa. Nimipalvelut tulevat Amazon Route53 palvelun kautta.

Suurin riski lienee, että EntsoE muuttaa rajapinnan speksiä ja importtini hajoaa pidemmäksi aikaa. Varayhteys toisesta lähteestä on siksi harkinnassa. Toivotaan että homma pelaa ettei @ttk2 taloudessa nautita kylmistä suihkuista

 

[ttk2]

Sitten kun tulee 15min tasejaksot, tietääkseni -23, tarkkuus taajenee, eli 4x enemmän taulukoille pituutta.

Eihän se varmaan tuota hintaperiaatetta paljon muuta, ei siellä tunnin sisällä mikään 15min pätkä kauhiasti eroa muista.

Kait ne hinnatkin menee 15min jaksoihin, vaikkei tuosta kovin paljoa pöhinää ole näkynyt!?

Itselleni ei ainakaan tuon HA:n kanssa siitä tule mitään ongelmaa. Toteutus on sellainen, että kun halpa tunti periodi alkaa, niin varaajan lämmitys käynnistyy. Kun tulee ei-halpa periodi, niin se päättyy. Järjestysluvulla ohjaaminen: Rank <= 12 niin päälle ja muuten pois. 12 kpl 15 minuutin jaksoja vastaa kolmea tuntia vuorokaudessa.

Jos jotain, niin niistä yksittäisistä vartin jaksoista voisi löytää entistä halvemmat (keskihintana) yhteensä 3h ajalle.

Tässä tapauksessa ohjataan vastusta päälle ja pois, joten 15min periodeilla vastuksen kytkemisiä päälle tulee maksimissaan 12 vuorokaudessa. Onko tämä vastuksen kestävyydelle haitallista? Jos on, tuota voi varmasti muuttaa myös niin, että vastuksen annetaan olla päällä vähintään tunti kerrallaan.

Mikäli edelleen halutaan pitää "asiakaspää" yksinkertaisena (ja miksi ei haluttaisi, minä katson tätä nyt putkinäöllä asiakaspäästä), niin mikään ei estä ajattelemasta tällaista valmiiksi APIn puolella. Ei tämän saman APIn välttämättä, mutta tuota Rank:a käyttämällä pystyy toteuttamaan myös APIn, jonka Rank-arvot ovat esim. aina 1h yhtenäisille jaksoille (jolloin "rank" voi olla väärä termi kuvaamaan asiaa), tai miksei 3h, 6h jne. Tällöin API voi ihan hyvin vastata kysymykseen "mikä on halvin yhtenäinen N tunnin pituinen periodi seuraavan vuorokauden aikana".

Ihan vaan ajatuksena tämä voisi APIn polkuina toimia näin:

/Today/PeriodRank/1h
/Today/PeriodRank/3h
/Today/PeriodRank/6h

Tai olla kokonaan dynaaminen, eli /Today/PeriodRank/{{N}}h, jossa kutsuja voi itse määrittää N:n.

Tämä ei ollut kehitysehdotus Itse asiassa saattaa olla ihan tyhmäkin ajatus, mutta annettakoon se ryhmä-älyn pureksittavaksi kuitenkin.

EDIT: jäi sitten vielä selventämättä, että tässä minun tapauksessani taulukon pituudella ei ole mitään merkitystä. Nythän tuo taulukko on vain historiatietoa HA:sta, eli järjestysnumeron muutokset. Ohjaus tehdään kerran periodissa tilan mahdollisesti muuttuessa eikä tulevaisuudesta tai menneisyydestä välitetä lainkaan. Lämminvesivaraajan tapauksessa tähän kuuluu vielä varaajan oma termostaatti tai anturoidun lämpötilan mukaan katkaisu, joilla varmistetaan, että ei lämmitetä varaajaa koko vuorokautta, jos kaikkien tuntien hinta on sama (jolloin sitä päättymisen triggeröivää muutosta ei koskaan saavu).

 

[Mikki]

Tuskin vastukselle on 12 kytkentää minkäänlainen ongelma vuorokaudessa. Lämpöpumppujen kompressoritkin tekee samoja määriä ja enemmänkin.

Vakautan kehityksen suunnilleen tälle tasolle toistaiseksi, kun tuntuu aika toimivalta nyt tuo paketti. Jos jotain yksinkertaista rajapintaa halutaan lisää, niin sellaisen toteutus ei välttämättä ole montaa riviä koodia. Tuleva ALV lasku pitää toki toteuttaa vielä.

 

[roots]

Mielenkiinnosta katsoin Fissio.fi ja näköjään on vissiin valmisteltu sinne jo 15min jako kun tunnit jaettu 4 osaan.

 

[Mikki]

Mielenkiinnosta katsoin Fissio.fi ja näköjään on vissiin valmisteltu sinne jo 15min jako kun tunnit jaettu 4 osaan.

Voihan siihen varautua, mutta vähän insinööriajattelua kun ei vielä ole harmainta aavistustakaan milloin hinnat tulisi kuluttajille tuolla jaolla.

 

[hanks]

Eli ei saa tehtyä REST kutsua vai onko JSON parsinta ongelmana?

ESP Eesyyn on aika vasta lisätty SendToHTTP-komento, jonka tarkoitus on enemmän ohjata jotakin toista laitetta. No voisi sillä ajatella lukevan jonkun tiedonkin webin yli. Mutta

- tuo ei tue kuin salaamatonta HTTP-protokollaa
- responsea ei voi parsia ollenkaan, JustNowRank tosin ei vaatisi ihmeitä, jos vain saisi responsen käsiinsä
- JSONia tuossa ei voi kuvitellakaan

Rules — ESP Easy 2.1-beta1 documentation

espeasy.readthedocs.io

 

[Mikki]

ESP Eesyyn on aika vasta lisätty SendToHTTP-komento, jonka tarkoitus on enemmän ohjata jotakin toista laitetta. No voisi sillä ajatella lukevan jonkun tiedonkin webin yli. Mutta

- tuo ei tue kuin salaamatonta HTTP-protokollaa
- responsea ei voi parsia ollenkaan, JustNowRank tosin ei vaatisi ihmeitä, jos vain saisi responsen käsiinsä
- JSONia tuossa ei voi kuvitellakaan

Rules — ESP Easy 2.1-beta1 documentation

espeasy.readthedocs.io

Hmm.... Tuossa ei ole sinänsä mitään "salaista", että HTTPS on vähän overkill ehkäpä.

Entäs jos olisi API, joka palauttaisi esim. HTTP statuksen "bad request" jos tämän hetken hinta olisi ylitse halutun "Rankin" (esim. query-parametrina se haluttu "rank")? Ei tarvitsisi lukea responsen sisältöä ollenkaan, response statusta lukuunottamatta? Pienemmäksi APIa ei enää saa

 

[hanks]

Hmm.... Tuossa ei ole sinänsä mitään "salaista", että HTTPS on vähän overkill ehkäpä.

Entäs jos olisi API, joka palauttaisi esim. HTTP statuksen "bad request" jos tämän hetken hinta olisi ylitse halutun "Rankin" (esim. query-parametrina se haluttu "rank")? Ei tarvitsisi lukea responsen sisältöä ollenkaan, response statusta lukuunottamatta? Pienemmäksi APIa ei enää saa

Tuo vois toimia kyllä.

 

[Espejot]

Mielenkiinnosta katsoin Fissio.fi ja näköjään on vissiin valmisteltu sinne jo 15min jako kun tunnit jaettu 4 osaan.

katso liitettä 80193

Saako fission alustalle missä modbuss? Ilman rekkausta sivuilla on aika vähän infoa...

 

[Mikki]

Tuo vois toimia kyllä.

Siitä sitten kokeilemaan. Laitoin pakollisen HTTPS:n pois päältä ja tein tuollaisen API:n, että voit antaa parametrina halutun alarajan "rankille" ja rajapinta palauttaa Bad Request, jos ollaan tällä hetkellä yli sen arvon.

http://www.spot-hinta.fi/JustNowRank (palauttaa "rankin" kuten ennen)
http://www.spot-hinta.fi/JustNowRank/1 (halvin tunti palauttaa "ok", muut "bad request")
http://www.spot-hinta.fi/JustNowRank/10 (10 halvinta tuntia palauttaa "ok", loput "bad request")

 

[hanks]

Kokeillaas...

on System#Boot do let,1,8 //rank timerSet,1,10 endon on Rules#Timer=1 do LogEntry,'SPOT: timer timeout event' event,get_spot_rank endon on Clock#Time=All,**:01 do LogEntry,'SPOT: 01 minute past event' event,get_spot_rank endon on get_spot_rank do LogEntry,'SPOT: sending HTTP request' SendToHTTP api.spot-hinta.fi,80,/JustNowRank/[int#1] endon on http#api.spot-hinta.fi do LogEntry,'SPOT: %eventpar% returned %eventvalue1%' if %eventvalue1%=400 gpio,4,1 LogEntry,'SPOT: EVU off' else gpio,4,0 LogEntry,'SPOT: normal operation' endif endon on rank do let,1,%eventvalue% LogEntry,'SPOT: rank = %eventvalue%' endon

Meni vähän aikaa ihmetellessä miten tuon sai toimimaan, kun tässä on logitus mitä on. Ans kattoo nyt, kuin toimii. Mulla on nyt tällainen varsin konservatiivinen 6 8 tuntia päivässä lämmitys. Kun kelit viilenee, pitänee nostaa lukua isommaksi.

Edit: mulla siis tämmöinen viritys mlp:n päässä
https://lampopumput.info/foorumi/threads/pörssisähkön-hyödyntäminen-lämmityksessä.33720/post-536922

 

[ttk2]

Pitäisikö tuo polku jotenkin versioida? Esim /v1/Today antaa näitä nykyisiä 1h resoluution vastauksia ja /V2/Today voisi toimia 15min resoluutiolla, jos se joskus hintatietoihin tulee.

Entso-E varmaan toimii vain näistä jommalla kummalla. Tuo v1 voisi deprekoitua ja alkaa antaa vaikka paluukoodin, joka kertoo ettei se ole enää käytettävissä.

Nykyisellä toteutuksella nämä meidän asiakaspään hienot toteutukset jatkaisivat toimimista, mutta tuntien sijaan takaisin tulisikin niitä vartin siivuja ja automaatio ei sitä välttämättä tajuaisi. Parempi olisi tajuta ja saada virhekoodi kuin olettaa ja toimia väärin? Ehkä vähän mielipidekysymyskin.

 

[Mikki]

Ihan hyvä ajatus versiointi. Mutta saapi nähdä lähdetäänkö tuohon 15min juttuun oikeasti vuosiin. Edes nykyistä systeemiä ei osata käyttää kulutuksen ohjaukseen.

EntsoE APIssa on jo paikka resoluutiolle. Siinä taitaa olla nyt arvo "60M". Periaatteessa nuo kellonajat pitää jo nyt laskea itse että koodini logiikka muuttuisi helposti 15min pätkiinkin.

Sinänsä mikäänhän ei varsinaisesti muutu jos vain kyselee "Rank"n perusteella edelleen "käynnistyslupaa". Samalla Rank arvolla lämmitettäisiin edelleen sama kertamäärä mutta neljäsosa aikaa. Sen huomaisi ainakin nopeasti talvella

 

[hanks]

Siitä sitten kokeilemaan. Laitoin pakollisen HTTPS:n pois päältä ja tein tuollaisen API:n, että voit antaa parametrina halutun alarajan "rankille" ja rajapinta palauttaa Bad Request, jos ollaan tällä hetkellä yli sen arvon.

http://www.spot-hinta.fi/JustNowRank (palauttaa "rankin" kuten ennen)
http://www.spot-hinta.fi/JustNowRank/1 (halvin tunti palauttaa "ok", muut "bad request")
http://www.spot-hinta.fi/JustNowRank/10 (10 halvinta tuntia palauttaa "ok", loput "bad request")

Eka yön kokeilu, laitoin 8 ’rankilla’, eli pumppu sai käydä 8 halvinta tuntia. Käyttöveden lämmitys alkoi heti klo 23 edellisenä päivänä kun viimeinen tunti oli edellisen päivän 6. halvin. Lattialämmitys lähti käyntiin puoli yhden maissa, kun integraali painui -250:een. Kolme lämmityssykliä teki yön aikana, ennen kuin tuli kielto päälle. Alkoi ulkolämpötilakin nousta, niin että tarvekin loppui (integraali nousee lopussa ylöspäin ilman lämmitystä).

Iso kiitos Mikille apista!

 

[Espejot]

@Mikki Katsoin että EntsoE on rajapinta valminna datan hakuun. En tutkinut asiaa sen enmpää mutta vaatiko rajapinnan hyväksikäyttö rekisteröinnin?

Edit: löysinkin tiedon ihan itse. "Registered users can also download data tables and graphs and customise their own dashboard and data views. Registration is simple, free and open to all."

 

[Mikki]

@Mikki Katsoin että EntsoE on rajapinta valminna datan hakuun. En tutkinut asiaa sen enmpää mutta vaatiko rajapinnan hyväksikäyttö rekisteröinnin?

Edit: löysinkin tiedon ihan itse. "Registered users can also download data tables and graphs and customise their own dashboard and data views. Registration is simple, free and open to all."

Rajapintaan vielä pitää anoa pääsy sähköpostilla. Rest kutsu vaatii dynaamisen parametroinnin (aikarajaus) ja paluuna tulee XML tiedosto josta pitää parsia tiedot. Ihan tehtävissä oleva juttu mutta on se köytånnössä satoja rivejä koodia.

Rajapinta on suht nopea ollakseen virkaköpien palvelu. Mutta ei siihen rajapintaan ole suoraan tarkoitus kytkeä mitään IOT laitteita. Siinä on rajat monta kutsua saa tehdä.

Joten lisää koodia tietojen cachetusta varten sitten.

 

[VesA]

@Mikki Katsoin että EntsoE on rajapinta valminna datan hakuun. En tutkinut asiaa sen enmpää mutta vaatiko rajapinnan hyväksikäyttö rekisteröinnin?

Edit: löysinkin tiedon ihan itse. "Registered users can also download data tables and graphs and customise their own dashboard and data views. Registration is simple, free and open to all."

siinä rekisteröinnissä - siis APIn käyttöön - on sellainen jekku, että vaikka tunnuksen teko laskee sinut samantien sisälle, niin siitä ei tartu tieto vielä kaikkiin paikkkoihin - ja APIn enablointi ei onnistu. Eli pitää logata ulos ja takaisin sisään ainakin kerran.

 

[VesA]

Rajapintaan vielä pitää anoa pääsy sähköpostilla. Rest kutsu vaatii dynaamisen parametroinnin (aikarajaus) ja paluuna tulee XML tiedosto josta pitää parsia tiedot. Ihan tehtävissä oleva juttu mutta on se köytånnössä satoja rivejä koodia.

Rajapinta on suht nopea ollakseen virkaköpien palvelu. Mutta ei siihen rajapintaan ole suoraan tarkoitus kytkeä mitään IOT laitteita. Siinä on rajat monta kutsua saa tehdä.

Joten lisää koodia tietojen cachetusta varten sitten.

GITHUBissa sitä valmista entsokoodia on - niillä voi sitten tehdä vaikka mitä muutakin kuin hakea tuntihintoja, joka taas ei välttämättä tee asiaa ainakaan selkeämmäksi

 

[Mikki]

GITHUBissa sitä valmista entsokoodia on - niillä voi sitten tehdä vaikka mitä muutakin kuin hakea tuntihintoja, joka taas ei välttämättä tee asiaa ainakaan selkeämmäksi

Se rajapinta on huikean laaja. Siis oikeasti mielettömän iso. Ja katsoin vähän mallitoteutuksia ja päätin koodata kösin Rest kutsun ja tuloksen parsinnan. Nuo kirjastot on painajaisia seurattavaksi että mikä muuttuu ja milloin.

Ja kuten todettua nuo mun rajapinnat toimii suoraan yksinkertaisilla laitteilla ilman käytännössä koodausta. Se on just se syy miksi nuo ajattelin tehdä.

 

[Mikki]

@hanks : kysymys tuosta ESP Eesyn httpstä. Saisiko tuossa kohtaa missä räpsyrät relettä tehtyä uuden http kutsun?

Nimittäin Shellyn älypistokkeeseen on http rajapinta jolla saisi virran päälle ja pois.

Shelly Cloud

shop.shelly.cloud

Jos tuon ESP easyn saisi paketoituna jotenkin fiksusti niin aika helppo, edullinen ja toimiva pörssipistorasia voisi syntyä.

 

[tet]

Ihan hyvä ajatus versiointi. Mutta saapi nähdä lähdetäänkö tuohon 15min juttuun oikeasti vuosiin. Edes nykyistä systeemiä ei osata käyttää kulutuksen ohjaukseen.

Varttitaseeseen siirrytään ensi toukokuussa, ja siitä eteenpäin mm. datahubin tiedot ovat vartin jaksolla. Sitä en osaa sanoa, aikovatko sähkön vähittäismyyjät summailla noita vartteja edelleen neljä kappaletta samaan pakettiin pörssiasiakkaidensa laskutuksessa. Vahvasti epäilen että eivät aio, vaan varttiin mennään myös kuluttajatasolla.

https://www.fingrid.fi/globalassets/dokumentit/fi/sahkomarkkinat/varttitaseen-kayttoonotto-suomessa-22.5.2023-paivitetty-4.82022.pdf

 

[Mikki]

Varttitaseeseen siirrytään ensi toukokuussa, ja siitä eteenpäin mm. datahubin tiedot ovat vartin jaksolla. Sitä en osaa sanoa, aikovatko sähkön vähittäismyyjät summailla noita vartteja edelleen neljä kappaletta samaan pakettiin pörssiasiakkaidensa laskutuksessa. Vahvasti epäilen että eivät aio, vaan varttiin mennään myös kuluttajatasolla.

https://www.fingrid.fi/globalassets/dokumentit/fi/sahkomarkkinat/varttitaseen-kayttoonotto-suomessa-22.5.2023-paivitetty-4.82022.pdf

Joo näemmä. Mutta eipä tuossa rajapinnassa sinänsä mikään muutu. Ei vain ala tasatunnein pelkästään uusi hinta.

Mutta lämpöpumppuja ei kannattane ajaa noin lyhyttä pätkää että joku fiksu tapa olisi hakea esim halvimmat puolituntiset ja antaa niille rankit. Tai halvimmat tunnit ja niille rankit vaikkei tunti olisi kellon mukainen tasatunti.

Luulen siis että nämä rajapinnat pysyy kuten on "raakatiedon" tasolla. Ja sitten joku /SmartRank/60 tai /SmartRank/30 kertoisi olisiko tämä hetki halvimman X tunnin tai puolituntisen sisällä jos haluaa ajaa lömmitystä pidempään kuin 15min

 

[tet]

Vihjeenä vain, että vajaan parin kuukauden kuluttua siirrytään talviaikaan ja periaate on, että yksi tunti tulee kahteen kertaan, kun kello peruuttaa tunnin ensimmäisellä kerralla klo 04:00. Hintahan pysyy. Keväällähän vastaava homma on tavallaan helpompi, kun yksi tunti vain kilahtaa pois. Eihän tuo muuta käytön kannalta muuta paitsi, että vuodessa on kaksi vuorokautta, joissa on muu kuin 24 tuntia (eli keväällä yhtenä 23 tuntia ja syksyllä yhtenä 25 tuntia).

Ei taida mennä ihan yllä esitetyllä tavalla tuo kellonsiirto. Kyllä ne tunnit käsitellään kaikki ominaan, eli homma toimii pohjimmiltaan UTC-ajassa. Ainakin Entso-E:n hintahistoria kertoo, että viime syksynä 31.10 oli hintadatassa 25 tuntia, ja klo 3 alkavilla kahdella peräkkäisellä tunnilla oli hieman eri hinta: 60,06 € ja 60,03 €.

Mutta eihän tuossa mitään ongelmaa pitäisi syntyä, kunhan käsittelee aina aikaleimoja UTC-ajassa kuten pitää. Joka käyttiksestä ja korkeamman tason ohjelmointikielestä löytyy kyllä kirjastofunktiot ajan konvertoimiseen. Periaatteessa API:n pitäisi siis antaa ajat ulos UTC-aikana, jotta tiedon käyttäjä tietää varmasti mistä ajanhetkestä on kyse. Jos antaa ulos paikallisaikaleimoja, niin sitten mukana pitää olla myös UTC-offset (meillä siis +02:00 tai +03:00). Nyt näyttää API antavan oikeaoppisesti ISO 8601-aikaleimat, hyvä hyvä. Vielä perään tuo aikavyöhyketieto, niin kesäaikakin hoituu oikein. Toki sitten API ei enää ole ihan niin läpisimppeli kuin nyt.

 

[Mikki]

Voisin kyllä lisätä sen offsetin. Se kyllä kuuluu aikaleimaan joka ei ole UTC ajassa. Standardeja on hyvä noudattaa piirulleen.

 

[roots]

Joo näemmä. Mutta eipä tuossa rajapinnassa sinänsä mikään muutu. Ei vain ala tasatunnein pelkästään uusi hinta.

Mutta lämpöpumppuja ei kannattane ajaa noin lyhyttä pätkää että joku fiksu tapa olisi hakea esim halvimmat puolituntiset ja antaa niille rankit. Tai halvimmat tunnit ja niille rankit vaikkei tunti olisi kellon mukainen tasatunti.

Luulen siis että nämä rajapinnat pysyy kuten on "raakatiedon" tasolla. Ja sitten joku /SmartRank/60 tai /SmartRank/30 kertoisi olisiko tämä hetki halvimman X tunnin tai puolituntisen sisällä jos haluaa ajaa lömmitystä pidempään kuin 15min

Kyllä varttijako on jo kauan ollut aikataulutettuna.

Lämpöpumput ei tarvii pätkimiseen mennä, ne voi myös vaihtaa pelkistään nopeutta, jos pysytään pysäytysrajojen sisällä. Ehkä ne nyt ei vielä nykyään ole kovin hyvillä valmiuksilla tämmöseen muuttuvaan säätöön, tuo varmaan kehittyy.

Ehkä juu rajapintaa turha jalostaa liian pitkälle, soveltamiset pysayköön lukijan päässä.

 

[Mikki]

Kyllä varttijako on jo kauan ollut aikataulutettuna.

Lämpöpumput ei tarvii pätkimiseen mennä, ne voi myös vaihtaa pelkistään nopeutta, jos pysytään pysäytysrajojen sisällä. Ehkä ne nyt ei vielä nykyään ole kovin hyvillä valmiuksilla tämmöseen muuttuvaan säätöön, tuo varmaan kehittyy.

Ehkä juu rajapintaa turha jalostaa liian pitkälle, soveltamiset pysayköön lukijan päässä.

Kuluttajien osalta ei taida yksikään firma kertonut miten käy.

Ja onko mittarit kaikilla varttimittaukseen kykeneviä?