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

S

Sukke

Aktiivinen jäsen
Mikki sanoi:
Miltäs sinun postinumerolla ennuste näyttää tämän mun APIn kautta:

Että jotta laskeeko se paikkakuntaa paremminn sijainnin ja sitä kautta myös hakisi paremman ennusteen.
Klikkaa laajentaaksesi..

Ulkomittari näyttää nyt -6,9 (tunnin liukuva keskiarvo -7,1), sinun API -7,4 kuluvalle tunnille, yr.no koordinaateilla suoraan haettuna -7,4 ja Ilmatieteenlaitoksen ennuste -7,0.

Eli hyvin linjassa on kaikki. Yksittäisiä poikkeamia varmasti tulee, mutta jos tarkastelee vaikkapa 12/24 h keskiarvoa, tuskin isoja heittoja jää.
 
M

Mikki

Hyperaktiivi
Sellainen päivitys rajapintoihin tuli tänään, että "per IP osoite, per rajapinta" on hakumäärä rajoitettu 150 kappaleeseen tunnissa. Eli tasaisella tahdilla noin 30 sekunnin välein jos hakee yhdestä IP osoitteesta, ei vielä tule virhettä.

Jos hakumäärä ylittää 150 kappaletta yhteen rajapintaan tunnissa, niin sitten tulee HTTP 429 "Too Many Requests" palaute. Jos joku törmää tähän rajaan ja on hyvä perusteltu syy, miksi pitää tehdä enemmän hakuja, niin pistäkää privaviestiä, niin katsotaan mikä IP-osoite ja millainen raja tarvittaisiin.

 
Viimeksi muokattu:
H

Harrastelija

Vakionaama
Kodithan ovat NATin takana.
Jos yhdessä talossa on esim kaksi shellyä niin kyselyiden määrä tupautuu. APIlle näyttää siltä että yksi laite kyselee tiheään.
Vai oliko tähän jo keksitty joku ”proxy”?
 
M

Mikki

Hyperaktiivi
Harrastelija sanoi:
Kodithan ovat NATin takana.
Jos yhdessä talossa on esim kaksi shellyä niin kyselyiden määrä tupautuu. APIlle näyttää siltä että yksi laite kyselee tiheään.
Vai oliko tähän jo keksitty joku ”proxy”?
Klikkaa laajentaaksesi..
Uudet skriptit kysyy kerran tunnissa käytännössä yhtä APIa. Saa olla monta Shellyä ettei riitä tuo 150 kyselyä. :)

Suosittelen kyllä niitä uudempia muutenkin. Siistimpi koodi ja virheenkäsittelyt paremmat.

Oli pakko pistää jarrua kun yksikin tapaus oli joko vahingossa tai tarkoituksella laittanut haun sekunnin välein.
 
M

Mikki

Hyperaktiivi
Kehityksessä ja testauksessa on nyt RANK -laskennan monipuolistaminen. Ottaisin mielelläni kommentteja tähän kehitysvaiheessa jo, kun vielä on mahdollista muuttaa suuntaa/viilata eteenpäin. Tein testi-URL:n, missä asiaa voi demota.... Rank laskennassa olisi siis kolme vaihtoehtoa:

1. Vaihtoehto (nykyinen):
Rank laskenta nykyisellään, eli kaikki tunnit asetetaan järjestykseen hinnan mukaan ja sitten 'rank' numerointi:

2. Vaihtoehto (uusi):
Jyrkkä priorisointi tietyille tunneille. Rank laskenta antaisi ensin rankin "priority" tunneille ja sitten vasta muille tunneille. Ts. saadaan pakotettua pienimmät rankit priority tunneille. Use-case esimerkiksi sähköauton lataus aamuksi, maksoi mitä maksoi:

3. Vaihtoehto (uusi):
Ja sitten ns. "yösähkö"-toiminnallisuus. Eli priority-tuntien hintaa manipuloidaan ennen Rank-laskentaa erolla, mikä niillä tunneilla on muihin tunteihin nähden. Mutta muuten rank-laskenta menee normaalisti:
https://spot-hinta-testi.azurewebsites.net/Today?priorityHours=1,2,3,4,5,6,7,8&priceModifier=-2,5

Miltäs tämmöinen vaikuttaisi? Ja olisiko heti ajatuksia miten asian voisi tehdä paremmin/toisin?
 
Viimeksi muokattu:
heebo1974

heebo1974

Aktiivinen jäsen
Ottamatta toistaiseksi kantaa mikä kolmesta olisi paras, heitän vastakysymyksen.
Voisiko kenties kaikki ottaa mukaan ? Eli valinnan käytöstä tekee sitten käyttäjä. :)
 
M

Mikki

Hyperaktiivi
heebo1974 sanoi:
Ottamatta toistaiseksi kantaa mikä kolmesta olisi paras, heitän vastakysymyksen.
Voisiko kenties kaikki ottaa mukaan ? Eli valinnan käytöstä tekee sitten käyttäjä. :)
Klikkaa laajentaaksesi..
Tarkoitus on tosiaan siis mahdollistaa nuo kaikki ja nimenomaan antaa käyttäjälle optio valita parametreilla kuinka tuo Rank-laskenta toimii. Kysymys on lähinnä, että onko tuossa tarpeeksi optioita, tai liikaa optioita tai hulluja optioita :)
 
C

Cold

Jäsen
Itselläni ei (vielä) ole pörssisähköä, mutta yösähkö on. Tuo 3. vaihtoehto siis mahdollistaisi yö- ja päiväsähkön siirtohintojen eron huomioimisen ja vaikuttaa siksi hyvältä. Itse on virittämässä IFTTT:n kautta astianpesukoneen käynnistämistä. Pesuohjelma pyörii kerrallan 2-3 tuntia. Siihen olisi hyvä sellainen vaihtoehto, joka hakisi 2-3 peräkkäisen halvimman(keskiarvoltaan?) tunnin alkuajan. Pesuohjelmaa ei ole järkevä pysäyttää kesken vaikka hinta heiluisi.
 
P

puuteknikko

Vakionaama
Cold sanoi:
Itselläni ei (vielä) ole pörssisähköä, mutta yösähkö on. Tuo 3. vaihtoehto siis mahdollistaisi yö- ja päiväsähkön siirtohintojen eron huomioimisen ja vaikuttaa siksi hyvältä. Itse on virittämässä IFTTT:n kautta astianpesukoneen käynnistämistä. Pesuohjelma pyörii kerrallan 2-3 tuntia. Siihen olisi hyvä sellainen vaihtoehto, joka hakisi 2-3 peräkkäisen halvimman(keskiarvoltaan?) tunnin alkuajan. Pesuohjelmaa ei ole järkevä pysäyttää kesken vaikka hinta heiluisi.
Klikkaa laajentaaksesi..
Tiskarin tapauksessa kannattanee painottaa ekaa tuntia. Yleensä kulutus on suurimmillaan pesun alkuvaiheessa.
 
H

Harrastelija

Vakionaama
puuteknikko sanoi:
Tiskarin tapauksessa kannattanee painottaa ekaa tuntia.
Klikkaa laajentaaksesi..
Onko noin?
Pyykinpesukone on tietenkin eri asia mutta sehän on tutkimuksissa todettu että viherkiimassa pesu tehdään kylmällä vedellä ja pesun loppuvaiheessa muutamaksi minuutiksi lämpö nostetaan pesuohjelman mukaiseksi (eikä kunnolla siihenkään).
Voisi kuvitella että sama homma astianpesukoneessa.

Itsellä on yli 20v koneet niin ei ole noita 3 tunnin pesuohjelmia. Tunnilla (tai reilulla) selviää. Vastuksetkin on 3kW.
 
P

puuteknikko

Vakionaama
Harrastelija sanoi:
Onko noin?
Pyykinpesukone on tietenkin eri asia mutta sehän on tutkimuksissa todettu että viherkiimassa pesu tehdään kylmällä vedellä ja pesun loppuvaiheessa muutamaksi minuutiksi lämpö nostetaan pesuohjelman mukaiseksi (eikä kunnolla siihenkään).
Voisi kuvitella että sama homma astianpesukoneessa.

Itsellä on yli 20v koneet niin ei ole noita 3 tunnin pesuohjelmia. Tunnilla (tai reilulla) selviää. Vastuksetkin on 3kW.
Klikkaa laajentaaksesi..
Näin se on ainakin viitisen vuotta vanhassa Mielessä, kylmävesiliitännässä kiinni. Satuin juuri tänään pyöräyttämään automaattiohjelman läpi, se nostaa lämmöt pesun alussa kohdalleen ja suurin kulutus syntyykin ekan 20-30 minuutin aikana riippuen siitä, päättääkö kone vaihtaa vedet kertaalleen ennen kuin pesuaine otetaan käyttöön.

1672399989534.png
 
M

Mikki

Hyperaktiivi
Cold sanoi:
Itselläni ei (vielä) ole pörssisähköä, mutta yösähkö on. Tuo 3. vaihtoehto siis mahdollistaisi yö- ja päiväsähkön siirtohintojen eron huomioimisen ja vaikuttaa siksi hyvältä. Itse on virittämässä IFTTT:n kautta astianpesukoneen käynnistämistä. Pesuohjelma pyörii kerrallan 2-3 tuntia. Siihen olisi hyvä sellainen vaihtoehto, joka hakisi 2-3 peräkkäisen halvimman(keskiarvoltaan?) tunnin alkuajan. Pesuohjelmaa ei ole järkevä pysäyttää kesken vaikka hinta heiluisi.
Klikkaa laajentaaksesi..

Tämä rajapinta palauttaa kolmen tiedossa olevan halvimman tunnin alku- ja loppuajat:

Jos olet koodari, niin koodaile siihen IFTTT:hen integraatio näihin rajapintoihin, että on helppoa ottaa käyttöön IFTTT käyttäjille jotka ei ole koodareita. :)
 
Viimeksi muokattu:
haraldh

haraldh

Vakionaama
puuteknikko sanoi:
Näin se on ainakin viitisen vuotta vanhassa Mielessä, kylmävesiliitännässä kiinni. Satuin juuri tänään pyöräyttämään automaattiohjelman läpi, se nostaa lämmöt pesun alussa kohdalleen ja suurin kulutus syntyykin ekan 20-30 minuutin aikana riippuen siitä, päättääkö kone vaihtaa vedet kertaalleen ennen kuin pesuaine otetaan käyttöön.

katso liitettä 83472
Klikkaa laajentaaksesi..
Mistä saat noin hienoa käppyrää?
 
C

Cold

Jäsen
No toihan ratkaisi asian! Tiskikone käyttää ihan lopussa aika paljon energiaa kuivaukseen, joku zeoliittizydeemi. Joo olen 'tosi koodari' ;)ensimmäisen kerran rupesin ihmettelemään JavaScript:iä viime kuussa! Tosiasiassa en tiedä oikein mitään, mutta se IFTTT tuntuu onnistuvat (if) WebHook + (then) Home Connect (pesukone on Bosch) virityksellä.
 
S

Sammypiru

Vakionaama
Rele päällä vuorokauden xx (esim. 12h) halvimman tunnin ajan + tunteina joiden hinta on xx (12h) halvimman tunnin keskiarvo + YY% (esim. 10%)
XX ja YY itse säädettävissä.

Eli esimerkkitapauksessa jos 12 tunnin keskiarvo olisi 22 senttiä, niin huoletta myös tunnit jotka ovat 24,2 senttiä tai alle saisivat olla käynnissä jos niitä on.
 
N

Niksula

Tulokas
Cold sanoi:
No toihan ratkaisi asian! Tiskikone käyttää ihan lopussa aika paljon energiaa kuivaukseen, joku zeoliittizydeemi. Joo olen 'tosi koodari' ;)ensimmäisen kerran rupesin ihmettelemään JavaScript:iä viime kuussa! Tosiasiassa en tiedä oikein mitään, mutta se IFTTT tuntuu onnistuvat (if) WebHook + (then) Home Connect (pesukone on Bosch) virityksellä.
Klikkaa laajentaaksesi..
Itseasiassa zeoliitti-kuivaussysteemillä olevat koneet käyttää eniten sähköä ohjelman alussa, kun pesuvesi ja astiat lämmitetään. Sen jälkeen lämmitystä ei juurikaan tarvita kuin tarvittaessa, halutun lämpötilan ylläpitoon. Koneessa on myös lämmönvaihdin joka esilämmittää sisään otettavan puhtaan veden. Kuivausvaiheessa puhallin kierrättää ilmaa koneen sisällä zeoliitin läpi, joka sitoo kosteutta ja kostuessaan luovuttaa lämpöä (=kuivaa ja lämmintä ilmaa puhalletaan takaisin astioille).
 
M

Mikki

Hyperaktiivi
Nyt on sitten Shelly skriptit päivitetty, että ne tukevat "priorityHours" ja "priceModifier" parametreja. Siis tiivistetysti näillä voi hoitaa "yösiirtohinnan" kompensaation hintoihin TAI sitten priorisoida esimerkiksi yötunteja, niin että ne tunnit saavat varmasti pienimmät 'rankit'.

Skriptit löytyy täältä kuten aina: https://github.com/Spot-hinta-fi/Shelly

Ei mitenkään "pakollinen" päivitys, jos ei ole tarvetta näille uusille parametreille.
 
S

Sukke

Aktiivinen jäsen
Sukke sanoi:
Tällä hetkellä ohjaan ensimmäisissä kokeilussa yhtä lamppua HAn kautta, kun ei vielä muuta ohjattava ole - eikä tosin osaamistakaan. Täytyy pikkuhiljaa tehdä tuosta vähän edistyneempi, kun tulee kaikki tutuksi.
Klikkaa laajentaaksesi..

Tämän kokeilun osalta katkaisin napanuoran spot-hinta.fi rank-kyselyyn ja siirryin käyttämään HA:n sensorin tarjoilemaa rank-tietoa. Lamppu edelleen kirkkauden ja värilämpötilan osalta rank-ohjauksessa, kuten se on syyskuusta lähtien ollut.

Sain myös vihdoin tehtyä tuntitietojen hakuun liipaisimen hakuyritysten aloittamiselle ja tauolle, kun hinnat ovat riittävän pitkälle ajalle taas tiedossa. Uskalsin tosin samassa yhteydessä tihentää hakuyrityksiä noin 10 minuuttiin.

Monenlaista ideaa täältä on kyllä saanut.
 
M

Mikki

Hyperaktiivi
Olisiko vinkkiä, mistä löytäisi pohjoismaiden (Ruotsi, Norja, Tanska) ja baltianmaiden (Viro, Latvia, Liettua) sähkön verotuksen, mitä kuluttajat maksavat verottoman pörssihinnan päälle? Siis kuten Suomessa ALV.

Tässä on pienessä tutkinnassa, josko saisin "Region" parametrin tehtyä jolla voisi vaihtaa hinta-aluetta API kutsuissa. Yllättävää kyllä, mutta on tullut kyselyitä muistakin maista ja harmiteltu kun ei ole vastaavaa olemassa. Shellyjen kautta näitä kyselyjä tulee, kun varmaan nuo skriptit löytyy google-hauilla.
 
M

mobbe

Vakionaama
Mikki sanoi:
Olisiko vinkkiä, mistä löytäisi pohjoismaiden (Ruotsi, Norja, Tanska) ja baltianmaiden (Viro, Latvia, Liettua) sähkön verotuksen, mitä kuluttajat maksavat verottoman pörssihinnan päälle? Siis kuten Suomessa ALV.

Tässä on pienessä tutkinnassa, josko saisin "Region" parametrin tehtyä jolla voisi vaihtaa hinta-aluetta API kutsuissa. Yllättävää kyllä, mutta on tullut kyselyitä muistakin maista ja harmiteltu kun ei ole vastaavaa olemassa. Shellyjen kautta näitä kyselyjä tulee, kun varmaan nuo skriptit löytyy google-hauilla.
Klikkaa laajentaaksesi..
sähkön tuntihinnat paikallinen verotus sisältäen euroopassa saa tuolla https://www.peakhours.eu/

tänään 10-00-11.00 suomessa tunti on 10,81 ja samaan aikaan vaikka latviassa 12,82 veroineen paikallisessa valuutassa/kwh
 
R

roots

Hyperaktiivi
Eikös sen veron voi vaikka lisätä kyselyyn tai kysellä verottomana?
Sitten paikallisesti lisätä vero jos sitä veroa yleensä edes tarvii kun se on kuitenkin vakio kerroin kaiketi joka maassa (paitsi nyt juuri poikkeustilanteessa).
 
M

Mikki

Hyperaktiivi
Tein pienen Youtube-nauhoituksen, että miltä näyttää skriptin asennus Shellyyn uuden URL:n avulla. Tämä vähän konkretisoi niille, jotka eivät ole Shellyä käyttänyt, että mistä puhutaan. :)

Videolla siis asennetaan skripti. Otetaan rele käyttöön, asetetaan 3 halvinta tuntia rele päälle ja aina kun hinta on alle 5 senttiä.

 
T

Temez

Aktiivinen jäsen
Mikki sanoi:
Ja jälleen uusia ominaisuuksia rajapintoihin. Samalla tarkkailkaa jos huomaatte jotain ongelmia, kun taustalla on tehty aika suuria muutoksia. Jos jotain on lipsahtanut testien läpi, niin korjataan pian toki:

Klikkaa laajentaaksesi..
Palauttikohan vanha versio ajettaessa esim. kello 12:00 (eli vain nykyisen päivän hinnat tiedossa) endpointista /TodayAndDayForward JSONissa viimeisessä elementissä kellonajalle 23:00 vai 0:00?
Oma HA-instanssini ladannut dataa kello 14:08:11 tänään 15.11.2023 ja silloin ei vielä kai ollut dataa saatavilla seuraavalle päivälle, mutta HA:n mukaan JSON arrayn viimeinen elementti olisi sisältänyt datasisällön:
Rank: 1
DateTime: '2023-01-16T00:00:00+02:00'
PriceNoTax: 0.0324
PriceWithTax: 0.0356
Klikkaa laajentaaksesi..
Tällä voi olla vähän vaikutusta tuohon spotprices2ha HA-systeemiin, kun olin rajannut haut tapahtumaan vain, jos tiedossa on hintoja vain 24kpl, mutta nyt tulikin 25kpl.
 
M

Mikki

Hyperaktiivi
Temez sanoi:
Palauttikohan vanha versio ajettaessa esim. kello 12:00 (eli vain nykyisen päivän hinnat tiedossa) endpointista /TodayAndDayForward JSONissa viimeisessä elementissä kellonajalle 23:00 vai 0:00?
Oma HA-instanssini ladannut dataa kello 14:08:11 tänään 15.11.2023 ja silloin ei vielä kai ollut dataa saatavilla seuraavalle päivälle, mutta HA:n mukaan JSON arrayn viimeinen elementti olisi sisältänyt datasisällön:

Tällä voi olla vähän vaikutusta tuohon spotprices2ha HA-systeemiin, kun olin rajannut haut tapahtumaan vain, jos tiedossa on hintoja vain 24kpl, mutta nyt tulikin 25kpl.
Klikkaa laajentaaksesi..

Hmm... hyvä huomio. Refactoroin koodia ja näemmä tosiaan tuossa kohtaa on tahaton muutos. Edellisessä versiossa oli tuo viimeinen tunti tiputettu pois, joka menee siis Suomen aikavyökykkeelle huomiselle. Mutta siis kun kysytään TodayAndDayForward, niin nyt se sitten palauttikin sen ensimmäisen tunnin huomiselta.

Taidan korjata tuon takaisin ennalleen. Se yksi irtotunti on vähän sekoittava.
 
Viimeksi muokattu:
T

Temez

Aktiivinen jäsen
Mikki sanoi:
Hmm... hyvä huomio. Refactoroin koodia ja näemmä tosiaan tuossa kohtaa on tahaton muutos. Edellisessä versiossa oli tuo viimeinen tunti tiputettu pois, joka menee siis Suomen aikavyökykkeelle huomiselle.

Mutta siis kun kysytään TodayAndDayForward, niin nyt se sitten palauttikin sen ensimmäisen tunnin huomiselta.
Mitenköhän on, pitäisikö muuttaa takaisin, että jos huomisia tunteja on vain yksi, niin ei palauteta sitä?
Klikkaa laajentaaksesi..
Jos se näppärästi onnistuu, niin auttaisi noita HA-lisäosan käyttäjiä, jotka eivät keksi päivittää lisäosaa syystä tai toisesta. Heillä muuten jää tuo datalataus jumiin.

Ajattelin kyllä ottaa jatkossa tämänkin tilanteen huomioon tuolla HA-lisäosan puolella, kun tämä vastaava tilannehan tulee viimeistään seuraavan kerran talviaikaan siirryttäessä, kun tulee ylimääräinen tunti.

Ei oikeastaan ole minulle väliä, että kummin haluat tehdä. HA-lisäosaan teen joka tapauksessa tässä muutoksen, joten parasta varmaan mennä sen mukaan, että mikä API:n ja yleisesti sen käyttäjien kannalta mielestäsi parasta.
 
M

Mikki

Hyperaktiivi
Temez sanoi:
Ei oikeastaan ole minulle väliä, että kummin haluat tehdä. HA-lisäosaan teen joka tapauksessa tässä muutoksen, joten parasta varmaan mennä sen mukaan, että mikä API:n ja yleisesti sen käyttäjien kannalta mielestäsi parasta.
Klikkaa laajentaaksesi..

Tuo on nyt korjattu. Eli kun vuorokausi vaihtuu niin ei enää se ensimmäinen tunti tiistailta pitäisi tulla. Kiitoksia havainnosta.
Yksi asia mitä koodaamisessa inhoan on päivämäärät ja aikavyöhykkeet :)
 
T

Temez

Aktiivinen jäsen
Mikki sanoi:
Tuo on nyt korjattu.
Klikkaa laajentaaksesi..
Hienoa, kiitos! Ja tätä ratkaisuhaaraa tukeva ajatus tuli vielä mieleen: API palautti silloin sen "ylimääräisen tunnin" Rankiksi 1, mikä toki juuri sillä hetkellä on oikein, mutta todennäköisesti ei ole sitten, kun koko vuorokauden hinnat tiedossa. Siksikin ihan miellyttävää, ettei tunnin Rank voisi vaihtua yhtäkkiä ladatessa dataa eri aikaan. Aika pikkujuttu, mutta on mielestäni hyvin linjassa tekemäsi korjauksen kanssa.
 
M

Mikki

Hyperaktiivi
Pieni päivitys vielä Shelly-skripteihin ja myös "check" rajapintoihin. Eli "AllowedDays" parametri. Jos tämän parametrin antaa, voi sillä määritellä minä päivinä suoritus sallitaan ja minä päivinä rajapinnat palauttaa tylysti "400" koko päivän.

Käyttötapauksena esitettiin esimerkiksi, että ollaan työn vuoksi pois viikolla säännölliset päivät. Tai että varaajaa lämmitetään jossain erityisemmässä paikassa vain viikonloppuisin. Ehkä jotain muitankin skenaarioita tälle voisi keksiä.

Mutta rajapinnoissa tuo nyt on ja myös Shelly-skripteihin lisätty.
 
Sinun on kirjauduttava sisään tai rekisteröityä kirjoittaaksesi tänne.
Back
Ylös Bottom