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

jmaja

Hyperaktiivi
Helppokäyttöisyydestä puheenollen. Tuossa toisessa ketjussa siis tuli ilmi ongelmia summien parsinnan kanssa ja se on kyllä pieni "käpy" kun on tosiaan mm. Javascriptin mielestä stringi, eikä float/decimal/double tms...

Siksipä tämmöisen muutoksen tekisin, meneeköhän paljon rikki olemassaolevia koodauksia? Ehkä kuitenkin nyt kuin myöheemmmin? Oikealla siis uusi muoto ja vasemmalla nykyinen. Muutos koskisi kerralla kaikkia APeja, joissa summat ovat näkyvsissä. Vastalauseita?
Eikös JavaScriptissä saa tuota muutettua floatiksi? Minä en JavaScriptiptiä käyttänyt, mutta JSON-parserista sai tuo ulos ilman hipsuja. Pitäähän tuo päivämääräkin jotenkin käsitellä.

En tiedä meneekö rikki, mutta saa ainakin helposti korjattua, jos menee.
 

jmaja

Hyperaktiivi
Ovatko muut katsoneet millaiseen keskihintasäästöön pääsevät? Sain tuon laskennan eilen tehtyä. Viimeiset 22 h:
Prices: Ave: 25.1 Compressor kWh ave: 21.8 LJAve: 22.4 LKVAve: 13.5
Electricity price ave: 25.12 min: 11.8 max: 45.4 last: 35.3

Siis pörssihinta (sisältäen vero, siirto ja marginaali) oli keskimäärin 25,1 snt/kWh ja kompressorituottoteholla painoitettu keskiarvo 21,8. Käyttöveden kompressorituottotehopainotettu keskiarvo vain 13,5 kWh.

Vähän pettymys, että noin korkea oli kuitenkin lämmönjaon kompressorituottotehopainoitettu keskiarvo. Sähköä tuossa meni 9 kWh lämmitykseen ja 1 kWh käyttöveteen. Käyttöveden COP on selkeästi alempi, mikä ei näy tuossa laskennassa eli todellinen keskihinta on hiukan parempi.
l.png
 

Mikki

Hyperaktiivi
Muutos rajapintaan on nyt tehty. Eli summat pitäisi olla oikeasti "summia", eikä "stringejä". Jos jollain hajoaa nyt haun parsinta niin tuossa syy. Luultavasti "korkeamman tason" kielissä tuo ei juuri vaikuta. Tässä esimerkki uudesta formaatista siis (ja onpas sairaan kallista sähköä näin lauantai-iltana):

1664039386472.png


Lisäksi muutin seuraavan päivän hakuja vähän nopeammaksi: huomasin että huonolla tuurilla "cachen" timeout meni niin, että haku tehtiin pahimmillaan 20min liian myöhään. Nyt klo 13:00 jälkeen cache yritetään päivittää seuraavan päivän tiedoilla parin minuutin välein kunnes tiedot on saatu.

Ja hakuja eri rajapintoihin tehtiin eilen jo yli 80 000 kertaa. Että kaipa tämöisille rajapinnoille on tarvetta.

1664039640082.png
 
Viimeksi muokattu:

Sukke

Aktiivinen jäsen
Mistä olette hakeneet sääennusteita tunneittain?

Jos yrittää arvata tulevaa lämmitystarvetta ja määrittää sallittua tuntimäärää, tarvitsi ainakin lämpötilatietoa.
 

Mikki

Hyperaktiivi
Mistä olette hakeneet sääennusteita tunneittain?

Jos yrittää arvata tulevaa lämmitystarvetta ja määrittää sallittua tuntimäärää, tarvitsi ainakin lämpötilatietoa.
Sarjassaan taas niitä asioita mitkä on aivan liian vaikeasti löydettävissä. Ei olisi vaikea tehdä vaikka postinumerolla lämpötilojen haku joka riittäisi varmaan useimmille tarkkuudeksi.
 

Käyttäjä89

Aktiivinen jäsen
Ei olisi vaikea tehdä vaikka postinumerolla lämpötilojen haku joka riittäisi varmaan useimmille tarkkuudeksi.
Olisikohan tällaiselle miten suurta tarvetta? Ilmatieteenlaitoksen kautta ainakin saisi säädatan kun sen vaan toisi saavutettavaksi hieman helpommasti. Pitäisi havaintopisteet ja postinumerot jotenkin saada mäpättyä.
 

Mikki

Hyperaktiivi
Olisikohan tällaiselle miten suurta tarvetta? Ilmatieteenlaitoksen kautta ainakin saisi säädatan kun sen vaan toisi saavutettavaksi hieman helpommasti. Pitäisi havaintopisteet ja postinumerot jotenkin saada mäpättyä.
Pää meinaa heti räjähtää kun katsoo FMI avointa dataa. Näissä julkisissa rajaoinnoissa on se iso ongelma että niissä ei huomioida aivan yksinkertaisimpia tapauksia vaan rajapintoihin oksennetaan massiiviset määrät dataa.

Kannatan sinänsä sitä että tarjotaan paljon dataa. Mutta jos ei ole rajapinnoissa yksinkertaista lämpötilaennusteen hakua helpolla sijaintitiedolla niin on se ihme homma. Loppujen lopuksi tuo lienee tärkeinpiä tietoja yhdessä sen kanssa että sataako vai ei.
 

Käyttäjä89

Aktiivinen jäsen
Joo, hankalaksi tuo menee, mutta kaippa se olisi tehtävissä. Katsotaan jos tuota ehtisi tutkimaan tässä ensi viikon aikana



<StoredQueryDescription id="fmi::forecast::harmonie::surface::point::timevaluepair">
<Title>Harmonie Surface Point Weather Forecast as time value pairs</Title>
<Abstract> The stored query can be used to fetch Harmonie surface level weather forecast in time value pair format. The model data covers the geographical area of Scandinavia. New forecast dataset will come available every 6 hours. Location need to be specified as place or geoid or latlon query parameters. By default data will be returned 50 hours from the request time. </Abstract>
<Parameter name="starttime" type="dateTime">
<Title>Begin of time interval</Title>
<Abstract> Parameter specifies the begin of time interval in ISO 8601 format (for example 2012-02-27T00:00:00Z). </Abstract>
</Parameter>
<Parameter name="endtime" type="dateTime">
<Title>End of time interval</Title>
<Abstract> Parameter specifies the end of time interval in ISO 8601 format (for example 2012-02-27T00:00:00Z). </Abstract>
</Parameter>
<Parameter name="timestep" type="int">
<Title>The time step of data in minutes</Title>
<Abstract> The time step of data in minutes. Notice that timestep is calculated from start of the ongoing hour or day. </Abstract>
</Parameter>
<Parameter name="parameters" type="NameList">
<Title>Parameters to return</Title>
<Abstract> Comma separated list of meteorological parameters to return. </Abstract>
</Parameter>
<Parameter name="place" type="xsi:string">
<Title>The location for which to provide data</Title>
<Abstract> The location for which to provide forecast. Region can be given after location name separated by comma (for example Kumpula,Kolari). </Abstract>
</Parameter>
<Parameter name="latlon" type="gml:pos">
<Title>Location coordinates to return data.</Title>
<Abstract> Location coordinates to return data (lat,lon). For example 61.2,21 </Abstract>
</Parameter>
<Parameter name="geoid" type="int">
<Title>Geoid of the location for which to return data.</Title>
<Abstract> Geoid of the location for which to return data. (ID from geonames.org) </Abstract>
</Parameter>
<Parameter name="fmisid" type="int">
<Title>FMI observation station identifier.</Title>
<Abstract> Identifier of the observation station. </Abstract>
</Parameter>
<Parameter name="wmo" type="int">
<Title>WMO code of the location for which to return data.</Title>
<Abstract> WMO code of the location for which to return data. </Abstract>
</Parameter>
<QueryExpressionText xmlns:wfs_001="http://inspire.ec.europa.eu/schemas/omso/3.0" xsi:schemaLocation="http://inspire.ec.europa.eu/schemas/omso/3.0 https://inspire.ec.europa.eu/schemas/omso/3.0/SpecialisedObservations.xsd" returnFeatureTypes="wfs_001:pointTimeSeriesObservation" language="urn:eek:gc:def:queryLanguage:OGC-WFS::WFS_QueryExpression" isPrivate="true"/>
</StoredQueryDescription>
 

Mikki

Hyperaktiivi

VesA

In Memoriam
Mutta en ymmärrä miksei perushakuja saa tehtyä näin

Niiden teko on jätetty sille joka haluaa jotenkin esittää siitä oman valikoimansa, noistahan rakennellaan ties mitä maatalous-spesiaaleja jne. Olen apia käyttänyt muutama vuosi sitten kun laskeskelin jollekin palstalaiselle muutaman vuoden datasta minkämoinen tuuli/aurinko/akkukokoelma pitäisi mittarit pyörimässä yli pimeän ajan. Eise lopulta niin ihmeellistä ollut ja jotennii muistelen että datan sai pyytää muunakin kuin xml:nä. Yhdellä curlilla sen datan sieltä sai.
 

Mikki

Hyperaktiivi
Joo, hyvä puoli FMI datassa on että se on aidosti avointa. Siis ei tarvi rekisteröityä eikä tarvi mitään avaimia. pointsit siitä.
 

Käyttäjä89

Aktiivinen jäsen
Vielä kun saisi postinumerot ja niille kuuluvat koordinaatit ja paikkanimet jostain niin tuo kyllä olisi ihan tehtävissä. Vaihtoehtona olisi joku GeoNameID, mutta ei kait tuolla väliä ole.
Tämän perusteella sitten voisi rustailla rajapinnan joka palauttaa muutaman päivän aikajänteen jossa on kellonaikojen mukaan lämpötilat.
Mutta tarvitaanko tässä miten suurta tarkkuutta? Onko sama tunti / varttijaottelu edes tarpeen vai riittääkö että palauttaa päivän keskilämpötilan.
 

VesA

In Memoriam
Kaikkien asuinrakannusten koordinaatit ovat jo jossain kannassa .. ehkä sen jostain löytää ja paikkakuntien koordinaatit wikissä ja ties missä.
 

Käyttäjä89

Aktiivinen jäsen
Postilta saa kaikki postinumerot ja Geonames.org saa sitten näille postinumeroille koordinaatit
Suoria osoitteitakin vastaavat koordinaatit löytyy avoimen datan kautta, mutta datamäärä alkaa sitten jo paisumaan eikä olla enää yksinkertaisuuden äärellä teknisessä mielessä.

Vastaavia listauksia näkyy toteutetun: https://kartta.com/postinumerohaku/postinumerot-kartalla/

Voisin tästä ottaa itselleni sellaisen pienen harrastusprojektin. Jos ei joku muu ehdi sitten ensin jolla on enempi kiire. Ajatuksena voisi tosiaan olla että yksinkertaisella haulla saisi ennusteen tulevalle lämpötilalle ja sen kautta sitten voisi lämmitystarvetta kWh arvolla arvioida tai jotain
 
Viimeksi muokattu:

hanks

Aktiivinen jäsen
Mlp:ssä integraali kertoo jotakin lämmitystarpeesta. Päivällä jos ei lämmitetä, integraali painuu miinukselle useita satoja asteminuutteja, ja yöllä maksetaan velkaa kun pörssisähkö on halvempaa. Kun kelit viilenee päivällä otetaan velkaa enemmän ja yöllä pumppu tekee pitkiä käyntijaksoja.

Toistaiseksi on saanut rank=8 alle menevillä tunneilla kuitattua velat, kohta ei enää välttämättä riitä. Ylitehoinen 10 kW pumppu auttaa tässä.

Meinaan vaan että ainakin itselleni tuo asteminuuttihomma riittää, ei tarvitse ennustaa tulevaa säätä. Tosin vähän jälkijättöistähän tuo on.
 

jmaja

Hyperaktiivi
Toistaiseksi on saanut rank=8 alle menevillä tunneilla kuitattua velat, kohta ei enää välttämättä riitä. Ylitehoinen 10 kW pumppu auttaa tässä.
Miten tuossa käy vastusten kanssa? Eikö suuri velka pistä vastukset päälle? Niiden totaaliesto on hiukan kyseenalaista, jos sattuu tulemaan joku häiriö kompurapuolelle.

Näillä mietteillä itse päädyin säätämään pörssisähkön mukaan sisälämpötilaa (vaikuttaa suoraan menolämpöön Boschissa, kun anturia ei ole) enkä estämään käyntiä kokonaan. Tuo on riittänyt viimeiaikoina pääsemään n. 20% alle pörssisähkön keskihinnan. Halvimmilla tunneilla olisi päässyt parempaan, mutta varmasti silloin myös sisälämpötila vaihtelee enemmän.

Voisin tietysti minäkin kokeilla suurempia muutoksia pörssisähkön mukaan, jolloin kulutus painottuisi enemmän halvempiin tunteihin.
 

hanks

Aktiivinen jäsen
Miten tuossa käy vastusten kanssa? Eikö suuri velka pistä vastukset päälle? Niiden totaaliesto on hiukan kyseenalaista, jos sattuu tulemaan joku häiriö kompurapuolelle.
Totta, toistaiseksi olen ajellut ilman vastuksia. Pitää keksiä jotakin muuta talvella varsinkin jos ei ole kotosalla. Thermiassa on lisälämmölle toinen integraali A2, jonka alin arvo voi olla -990 asteminuuttia. Eli aika alas voi mennä. Sitten on vielä asetus "VIIVE EVUN JÄLKEEN - Aika minuutteina. Ilmaisee kuinka monta minuuttia pitää kulua EVUn jälkeen ennen kuin lisälämmön saa aktivoida." tuon maksimiarvo on 120 minuuttia. Tuo EVU (tulee saksankielen sanasta Elektrizitätsversorgungsunternehmen) on juuri se tila, jota ohjaan.

Voisin kokeilla miten tuo pelaa kun kelit vähän vielä kylmenee.
 
Viimeksi muokattu:

Mikki

Hyperaktiivi
Vaikka tämä ei nyt pörssihintaan enää liity, niin ärsytti kun en löytänyt APIa, josta hakee postinumerolle koordinaatit. Oli vähän kimurantti päättää miten sen laskisi, mutta tämmöinen siitä nyt sitten tuli parin tunnin koodauksella:


Koordinaatit per postinumero on laskettu kolmen miljoonan rakennustiedon pohjalta ja laskemalla suurinpiirteinen keskiarvopiste kullekkin alueelle. Aika sumea logiikka, mutta suhteellisen järkeviä koordinaatteja tuli ainakin tiheämmin asutuille alueille. Pohjois-Suomen suuremmille alueille toki se on epätarkempi.
 
Viimeksi muokattu:

Mikki

Hyperaktiivi
Nyt aivan testimielessä yhdistin laskemani postialueen koordinaatit YR.NO lämpötilaennusteeseen. Rajapinta on nyt aivan testimielessä tehty, että älkää rakentako sen päälle mitään. Mutta palautetta voi antaa ja ideoita.

Tässä näin: https://api.spot-hinta.fi/PostalCodeTemperatures/00100

Laitoin rajapintakuvaukseen myös nämä kaksi uutta rajapintaa ja maininnalla että on "BETA" tasoa... ei todennäköisesti jää ihan tämmöiseksi.
 

Mikki

Hyperaktiivi
Kai tuo voisi antaa pidemmälle ennusteen, jos sitä vaikka jotenkin haluaisi käyttää optimointiin?

Edit: Saako tuolta samalla jonkinlaisen aurinkoenergiaennusteen?

Noniin... versio 0.2 olisi nyt tulilla: https://api.spot-hinta.fi/PostalCodeTemperatures/00120

- Pidemmälle säätilaennuste
- Mukana ennuste pilvisyydestä (oli lähin mitä aurinkoenergiaennusteesta löysin)
- Sademäärä millimetreinä

Poistin responsesta ne postinumeroalueen koordinaatit, redundanttia tietoa. Mietin seuraavaksi, että miten yhdistäisin ainakin lämpötilan tuohon /Today ja /TodayAndTomorrow rajapintoihin. Tai sitten erillään edelleen....
 

Sukke

Aktiivinen jäsen
Tuulennopeus voisi olla yhtenä tietona mukana. Muistelen lukeneeni, että sillä on jonkinlainen vaikutus lämmitystarpeeseen.

Tein toteutuneista lämpötiloista ja kWh:n spot-hinnoista pienen harjoituksen noin vuoden ajalta. Laskeskelin lämpötilojen perusteella lämmitystarpeen, jonka jälkeen määritettiin vuorokaudessa sallitut lämmitystunnit halvimmasta lähtien. Vertailukohtana oli lämmityksen jakautuminen tuntikohtaiseen tasaiseen lämmitykseen. Taustalla arvio tulevan MLP:n tehontarpeesta eri lämpötiloissa. Täällä tulee optimointia toivottavasti helpottamaan "liian" syvä kaivo ja "ylimitoitettu" pumppu.

Lopputuloksena oli, että tuntioptimoinnilla kWh:n keskihinta oli noin 40 % alempi kuin tasaisella lämmityksellä. Vastaavasti tuntioptimoinnilla keskihinta jäi noin 25 % alemmaksi kuin keskimääräinen kWh:n hinta ilman mitään kulutuspainotusta. Toivottavasti laskelmat meni suunnilleen oikein.

Otin huvikseni tuulennopeuden mukaan lämmitystarpeeseen kertoimella 1+tuulennopeus (m/s)/100. Oikeata dataa ei ollut, satunnaista tuulennopeutta vain. Eikä myöskään mitään käsitystä vaikutuksista...
 

jmaja

Hyperaktiivi
Lopputuloksena oli, että tuntioptimoinnilla kWh:n keskihinta oli noin 40 % alempi kuin tasaisella lämmityksellä. Vastaavasti tuntioptimoinnilla keskihinta jäi noin 25 % alemmaksi kuin keskimääräinen kWh:n hinta ilman mitään kulutuspainotusta.
Avaatko tarkemmin mikä ero noissa kahdessa on? Onko ero laskettu pelkästä pörssihinnasta vai onko mukana myös marginaali, siirtohinta ja sähkövero?

Laskitko myös miten tuo vaikuttaa sisälämpötilan tasaisuuteen ja COPiin? Mihin lämpö varataan?
 

Sukke

Aktiivinen jäsen
Avaatko tarkemmin mikä ero noissa kahdessa on? Onko ero laskettu pelkästä pörssihinnasta vai onko mukana myös marginaali, siirtohinta ja sähkövero?

Laskitko myös miten tuo vaikuttaa sisälämpötilan tasaisuuteen ja COPiin? Mihin lämpö varataan?

Ero näissä kahdessa on se, että keskimääräinen spot-hinta on laskettu painottamattomana keskiarvona tarkastelujakson kaikista tunneista. Tasaisella lämmityksellä toteutunut keskimääräinen tuntihinta on edellistä suurempi, koska hinnassa painottuu lämmityskauden kulutus ja siten todennäköisesti korkeammat tuntihinnat. Optimoidun tuntihinnan ero tasaiseen lämmitykseen on kyllä epäilyttävän suuri... En ole kyllä katsonut ihan kaikkia yksityiskohtia vaan raapasin laskelman aika nopeasti kasaan. Täytyy tarkastaa laskelma, kunhan lapsiperhearki suo sopivan hetken.

Mukavuustekijöitä, kuten sisälämpötilaa tai lattian lämpötilaa COPista puhumattakaan en ole edes yrittänyt simuloida eli tosielämän reunaehdot tuosta puuttuvat. Lämmön on ajateltu varautuvan lattian betonilaattaan ja muihin rakenteisiin. Aika monen vuorokauden osalta lämmitys ajoittuu kokonaan yöhön eli iltaisin voi olla vähän viileämpää. Jos lämpötilaero kasvaa liian isoksi, ajattelin, että sallittujen tuntien määrää manipuloidaan tällöin sopivasti.

Käsittääkseni spot-hinta oli verollinen. Siirtoja en ottanut huomioon, kun ostoenergian määrä on molemmissa sama vuorokausi ja siten koko tarkastelun tasolla.

Tämä oli siis ihan puhdas ja aika suoraviivainen excel-harjoitus ja tuskin vastaa todellisuutta. Perusajatuksena, että pumppu saa tuotettua tarvittavan lämmön joko a) maksimiteholla sallittuina tunteina tai b) tasaisesti lämmittämällä läpi vuorokauden. Sallittujen tuntien määrä on arvioitu laskennallisen tehontarpeen perusteella - olikohan tuossa laskelmassa suurin määrä tarvittavia ja siten sallittuja tunteja luokkaa 16 h / vuorokausi. Sallittujen tuntien keskiarvo ja mediaani olivat luokkaa 8 h / vrk. Lämpimät päivät pitäisi käsitellä nykyistä paremmin, mutta niistä tulevat kulutukset on kokonaisuudessa pientä.

Tuossa myös systeemi toimi siten täydellisesti, että koko tarvittava lämpö saatiin a-tapauksessa tuotettua sallituilla tunneilla ja muilla tunneilla ei ollut lämmityksestä aiheutuvaa kulutusta lainkaan.
 

jmaja

Hyperaktiivi
Siirtoja en ottanut huomioon, kun ostoenergian määrä on molemmissa sama vuorokausi ja siten koko tarkastelun tasolla.
Nuo kuitenkin vaikuttavat oleellisesti laskettuun prosentuaaliseen säästöön, kun sekä halvat että kalliit tunnit kallistuvat samalla kiinteällä osuudella.
 

Vaizki

Tulokas
Käyttöehdoissa käsittääkseni kielletään automaattinen poiminta tuolta, mutta kyllä sitä varmaan monikin (ainakin kotikutoinen) järjestelmä silti tekee.
Saisihan ne varmaan tuolta nopeammin. Mutta käyttötarkoitus näissä apeissa ei ole olla mahdollisimman reaaliaikaiset, vaan mahdollisimman helpot. Entso-E myös henkisesti on "transparency platform" ja siksi mieluiten sitä käytän.

En ole lakimies enkä yleinen ankeuttaja MUTTA.. :hmm: Nordpoolin sivuilta tiedon kerääminen on tosiaan kielletty ja silti sitä tehdään, tämän tuntuu kaikki ymmärtävän. Mutta myös Entso-E transparency platformin data on vain käyttäjän (api avaimen haltijan) omaan käyttöön ja sitä ei saa levittää eteenpäin. Osa Entso-E datasta on CC-BY 4.0 lisenssillä, siitä on ihan taulukko ja "syy" miksi näin on, yleensä viitaten eri direktiiveihin. Mutta spot-alueiden day-ahead hintatiedot eivät ole mukana.

Näin ollen sen datan "reuse" eli eteenpäin levittäminen tai sen pohjalta tuotetun sekundäärisen datan levittäminen vaatii sopimuksen Nordpoolin kanssa. Ja nämähän on melko kalliita, jollain 5000e + alv pääsee alkuun mutta muistaakseni silläkään ei saa vielä levittää edes omille asiakkailleen. Kaikissa lisensseissä on suljettu kohderyhmä ja yleensä ne käyttäjät pitää jopa yksilöidä eli kertoa Nordpoolille täsmälleen kelle dataa annetaan. Entso-E varmaan kertoo myös. Sellaista lisenssiä jossa dataa levitettäisiin avoimesta API rajapinnasta ei ole olemassakaan.

Fingridin tuntihinta-applikaatio on laajin lisensoitu käyttö ja sekin saa vain visualisoida trendin sekä kertoa tarkemmin yhden datapisteen kerrallaan. Heidän FAQ:ssakin lukee että saman tiedon esittäminen webissä ei olisi mahdollista lisenssiehtojen vuoksi.

Minullakin on oma entso-e toteutus joka tuottaa suoraan APIsta Shelly-yhteensopivia cron-stringejä on/off ohjaukseen, itseasiassa 15min resoluutiolla. Mutta en ole kehdannut laittaa sitä jakoon koska ylläoleva. Olen myös ohjelmistoalan yrittäjä ja en kaipaa tälläisestä kakkaa niskaani.

Pitäisihän tälläisen datan olla ilmaisesti ja helposti jaossa kun EU samaan aikaan velvoittaa jäsenmaita säästämään sähköä kriittisinä tunteina jotta saadaan kulutuspiikit ja hinnat laskuun. Mutta se on kaupallisen toimijan omaisuutta joten tie tähän kulkenee (hitaaaaaasti) EU:n kautta.
 

Mikki

Hyperaktiivi
Ihan tottahan turiset @Vaizki. Mutta tosiaan katsotaan älähtääkö joku: ei ole tosiaan mitään järkeä, että timestamp+veroton hinta olisi jotenkin salaista tietoa energiakriisin keskellä. Varsinkin kun joka tuutista niitä hintoja työnnetään näkyville ja kannustetaan siirtämään kulutusta halvoille hinnoille. Ja toisaalta olisi hullua, että kaikkien pitäisi jumpata suhteellisen "vaikeiden" rajapintojen kanssa kulutusjouston rakentamiseksi omaan käyttöönsä ja vain "periaatteen vuoksi".

YR.NO taas oikein kannustaa käyttämään säätietietoa, kunhan ei kuormita niiden palvelimia liikaa.

Olen tuonne Swaggeriin laittanut, että voi laittaa foorumin yksityisviestien kautta viestiä jos joku kokee tarpeelliseksi ottaa yhteyttä.
Ja tosiaan jos tulisi joku show niin julkaisen kyllä koodit jossain ja ohjeet miten Azureen saa omat rajapinnat.
 
Viimeksi muokattu:

Sukke

Aktiivinen jäsen
Nuo kuitenkin vaikuttavat oleellisesti laskettuun prosentuaaliseen säästöön, kun sekä halvat että kalliit tunnit kallistuvat samalla kiinteällä osuudella.

Prosentteihin toki vaikuttaa, muttei absoluuttiseen säästöön. Huomasin pienen virheen tuossa koko vuoden keskimääräisen spot-hinnat laskemisessa - vertailuhinta oli liian pieni eli laskennallinen säästöprosentti jopa kasvoi edellä esitetyistä. Toisaalta tämä johti siihen, että tasaisesti tehty lämmityksen keskimääräinen hinta on melkein sama kuin koko tarkastelun spot-keskiarvo eli eron noiden kahden välillä poistui ja jäi optimoituun verrattuna noin luokkaan 40 % (ilman siirtoa) molemmissa tapauksissa. Siirron kanssa (sis. kaiken) ero reilut 30 %.

Teen jossain vaiheessa paremman tarkastuksen laskentaan ja laitan tarvittaessa päivitettyjä tietoja.

@Mikki annetaanko keskustelun rönsyillä näihin optimointeihin vai haluatko pitää tämän enemmän API-keskusteluna?
 

Vaizki

Tulokas
Tässä yksi parannusehdotus.. Shelly Pro ja Plus laitteet ainakin tukevat suoraan cron-muotoista "schedule" asetusta ja oma implementaationi tästä tuottaa näitä scheduleita APIsta jolloin laitteen täytyy vain kerran päivässä hakea se ja toimii sen jälkeen itsenäisesti ilman internettiä.
Tässä esimerkki tältä päivältä (tai no minun härvelini tarkastelee aina 18:00 - 17:59 välistä aikaa eikä 00:00-23:59) ja eri tuntimäärille (vartin tarkkuudella):

Koodi:
-- 0.25 hours --
27.9. 03:45 --> 27.9. 04:00
{'on': ['30 45 3 27 9 *'], 'off': ['30 59 3 27 9 *']}
24h avg: 13.59 snt/kWh  0.25h avg: 1.27 snt/kWh
-- 3.00 hours --
27.9. 02:00 --> 27.9. 05:00
{'on': ['30 0 2 27 9 *'], 'off': ['30 59 4 27 9 *']}
24h avg: 13.59 snt/kWh  3.00h avg: 1.29 snt/kWh
-- 4.00 hours --
27.9. 01:00 --> 27.9. 05:00
{'on': ['30 0 1 27 9 *'], 'off': ['30 59 4 27 9 *']}
24h avg: 13.59 snt/kWh  4.00h avg: 1.31 snt/kWh
-- 6.00 hours --
27.9. 00:00 --> 27.9. 06:00
{'on': ['30 0 0 27 9 *'], 'off': ['30 59 5 27 9 *']}
24h avg: 13.59 snt/kWh  6.00h avg: 1.43 snt/kWh

Tässä siis kun laite tietää montako tuntia sen pitäisi olla päällä niin se saa halvimman sekoituksen 15min aikaikkunoita jotta tuo toteutuu seuraavan jakson aikana. Aikaikkunat annetaan kahtena schedulena, on ja off ja niissä on säädettävä turvamarginaali (esimerkissä 30 sekuntia). Aikojen ei tarvitse olla yhtenäisiä eli välillä tulee 2 tai kolmekin on + off schedulea että saadaan paras tulos.

Jos vastaavan saisi tähän APIin niin voisin yrittää viimeistellä & pistää jakoon Shelly koodia joka pingaa tämän.

Edit: Linkki Shellyn dokumentaatioon Schedulesta.
 

Mikki

Hyperaktiivi
Tuokin on hyvä tieto Shellystä, että sille voi antaa tuollaisen cronin. Mutta ehkä kaikista yksinkertaisin on standalone-ohjaus Shellyn skriptauksella. Ei tarvita mitään ohjaavaa laitetta lähettämään niitä tietoja Shellylle. Vai näetkö siinä jotain erityisiä riskejä?

Vai tarkoititko, että Shellyllä ajetaan skriptiä, joka asettaa itselleen nuo Cronit? Kiitos ideasta kuitenkin... täytyypä tuumia.
 
Viimeksi muokattu:

Vaizki

Tulokas
Vai tarkoititko, että Shellyllä ajetaan skriptiä, joka asettaa itselleen nuo Cronit? Kiitos ideasta kuitenkin... täytyypä tuumia.
Juuri näin. Eli yksi schedule joka hakee muut schedulet. Scheduleja saa olla 20 yhdessä laitteessa eli "varaa" on. Minulla on nyt tuo Shelly irti mutta laitan sen kiinni ja katson tuon scriptin valmiiksi + githubiin niin käytännössä sen voisi kuka vaan vaan copy-pasteta shellyynsä.

Ymmärrän ettei ehkä ole tosi-harrastajien suosima tapa tehdä juttuja mutta oma alkuperäinen ideani oli tehdä se simppelein mahdollinen ja halvin jonka kuka vaan voisi ottaa käyttöön heti. Tietty jos tämä spotti-API olisi githubissa niin voisin forkata ja tehdä PR:n :)
 

Sukke

Aktiivinen jäsen
Tässä yksi parannusehdotus.. Shelly Pro ja Plus laitteet ainakin tukevat suoraan cron-muotoista "schedule" asetusta ja oma implementaationi tästä tuottaa näitä scheduleita APIsta jolloin laitteen täytyy vain kerran päivässä hakea se ja toimii sen jälkeen itsenäisesti ilman internettiä.
Tässä esimerkki tältä päivältä (tai no minun härvelini tarkastelee aina 18:00 - 17:59 välistä aikaa eikä 00:00-23:59) ja eri tuntimäärille (vartin tarkkuudella):

Koodi:
-- 0.25 hours --
27.9. 03:45 --> 27.9. 04:00
{'on': ['30 45 3 27 9 *'], 'off': ['30 59 3 27 9 *']}
24h avg: 13.59 snt/kWh  0.25h avg: 1.27 snt/kWh
-- 3.00 hours --
27.9. 02:00 --> 27.9. 05:00
{'on': ['30 0 2 27 9 *'], 'off': ['30 59 4 27 9 *']}
24h avg: 13.59 snt/kWh  3.00h avg: 1.29 snt/kWh
-- 4.00 hours --
27.9. 01:00 --> 27.9. 05:00
{'on': ['30 0 1 27 9 *'], 'off': ['30 59 4 27 9 *']}
24h avg: 13.59 snt/kWh  4.00h avg: 1.31 snt/kWh
-- 6.00 hours --
27.9. 00:00 --> 27.9. 06:00
{'on': ['30 0 0 27 9 *'], 'off': ['30 59 5 27 9 *']}
24h avg: 13.59 snt/kWh  6.00h avg: 1.43 snt/kWh

Tässä siis kun laite tietää montako tuntia sen pitäisi olla päällä niin se saa halvimman sekoituksen 15min aikaikkunoita jotta tuo toteutuu seuraavan jakson aikana. Aikaikkunat annetaan kahtena schedulena, on ja off ja niissä on säädettävä turvamarginaali (esimerkissä 30 sekuntia). Aikojen ei tarvitse olla yhtenäisiä eli välillä tulee 2 tai kolmekin on + off schedulea että saadaan paras tulos.

Jos vastaavan saisi tähän APIin niin voisin yrittää viimeistellä & pistää jakoon Shelly koodia joka pingaa tämän.

Edit: Linkki Shellyn dokumentaatioon Schedulesta.

Tuntia lyhyempi tarkastelujakso käynyt itselläkin mielessä. Esim tuntihinnat siten, että alkava tunti aina 15 minuutin välein tarkasteluun. Pitäisi vain osata rajata päällekkäiset tunnit pois. Tai jos olisi 15 minuutin tarkastelu, pitäisi saada pumppujen ohjaukseen määritettyä jokin minimipituus.

API-kyselyhän voisi olla muotoa tarvittava tuntimäärä, aikaikkunan minimipituus. Palautus sitten sallitut 15 minuutin jaksot minimikäyntiaika huomioiden. Samalla tulisi valmius 15 minuutin tasejaksoihin @Mikki ;)

Tällöin hieman kalliimpikin tunti voisi olla osittain mukana, jos sen sisältävä aikaikkuna mahtuu kuitenkin optimiin?
 

seppos

Jäsen
Tarkoitus on Shellyllä ohjata lämminvesivaraaja ja lattialämmitystä.
Konduktoria ja laitteita säästääkseni olen päätynyt, että käytän peräkkäisiä tunteja ainakin lämminvesivaraajaan.

Olisiko apua saatavilla joka palauttaisi annetun parametrin mukaiset halvimmat peräkkäiset tunnit?
Tyyliin
/TodayCheapestSequential/{hours}

Voisin pyytää esim päivän kolme halvinta. Ei tarvitsisi Shellyllä scriptata...
 
Back
Ylös Bottom