Spot-hinta.fi - Yksinkertainen pörssiohjaus API ja sitä käyttävät automaatioskriptit
- Keskustelun aloittaja Mikki
- Aloitettu
Mun oma mielipiteeni on, että minkä tahansa systeemin pitäisi käsitellä vain ja ainoastaan ajanhetkiä, esim. unixin epoch (joka laskee lineaarisesti sekunteja 00:00:00 UTC 1 January 1970 eteenpäin). Vasta siinä kun ollaan vuorovaikutuksessa ihmisen kanssa ko. ajanhetki pitäisi muuttaa paikalliseksi ajaksi.
Sellainen ihmeellisyys on kyllä mietityttänyt, että miksi esim. MongoDB:ssä ei ole erillistä tietotyyppiä pelkälle päivämäärälle... Esimerkkinä syntymäaika, joka yleensä tallennetaan ilman kellonaikaa. Sen pitäisi olla universaalisti sama päivämäärä, riippumatta paikallisesta aikavyöhykkeestä. Näin ei käy, jos vain yksinkertaisesti käytetään datetime-tyyppistä tallennusta ja laitetaan kellonajaksi 00:00, siis tilanteessa jossa käyttöä on useammalla aikavyöhykkeellä eikä erikseen huomata huomioida sitä että ko. tieto on pelkkä paljas päivämäärä.
Sellainen ihmeellisyys on kyllä mietityttänyt, että miksi esim. MongoDB:ssä ei ole erillistä tietotyyppiä pelkälle päivämäärälle... Esimerkkinä syntymäaika, joka yleensä tallennetaan ilman kellonaikaa. Sen pitäisi olla universaalisti sama päivämäärä, riippumatta paikallisesta aikavyöhykkeestä. Näin ei käy, jos vain yksinkertaisesti käytetään datetime-tyyppistä tallennusta ja laitetaan kellonajaksi 00:00, siis tilanteessa jossa käyttöä on useammalla aikavyöhykkeellä eikä erikseen huomata huomioida sitä että ko. tieto on pelkkä paljas päivämäärä.
Olen periaatteessa samaa mieltä, mutta ei tuossa API:ssa kyllä mitään ongelmaa ole. Siinähän on aikavyöhyketieto mukana, joten aikaleiman konvertointi vaikkapa unix timestampiksi onnistuu kyllä ihan standardikirjastoilla. Itse koodailen paljon PHP:lla, ja sen DateTime-luojan konstruktori osaa kyllä hoitaa oikean ajan kun sille syöttää ajan tuossa ISO8601-muodossa jossa se API:sta tulee.
Olennaistahan aikalaskelmissa on tietää, onko lähtötiedot annettu paikallisajassa ja miten ja tällöin ei pelkkä kellonaika riitä, vaan myös päivämäärä ja periaatteessa maakin, minkä ajan mukaan eletään. Tuon kun muuttaa UTC-ajaksi laskelmiin ja tulokset tarvittaessa takaisin paikallisajaksi (mikä paikka sitten milloinkin sattuu olemaan), niin oikeinhan menee. Noiden standardien etuna on, että kuljettavat mukanaan tarvittavat identifikaatiotiedot, joita täydellisissä muunnoksissa tarvitaan, jos mielitään välttyä sekaannusmahdollisuuksilta.
Muunnoksethan tietävät myös historiassa tapahtuneet muutokset, eli esimerkiksi Suomessa 1980 käyttöön otetun kesäajan ja matkan varrella tapahtuneet muutokset, joista aikahyöhykesiirtymät ja uusien aikavyöhyketunnusten/-standardien käyttöönotto ovat merkittävimmät (jokin UTC+2:00 ei vielä sano ollenkaan riittävästi ilman päiväystä mutta myös maa pitäisi tietää, koska muutokset ovat menneet eri kolkilla eri tahtiin). Muunnokset on myös aika ajoin päivitettävä, jos esimerkiksi EU:ssa joskus luovutaan käyttämästä kesäaikaa (mikä ainakin omasta mielestäni olisi sikäli hölmöä, että siitä aiheutuu arvaamatonta harmia ja sotkua kuten vuosituhannen vaihteen ongelmista aikoinaan, sillä joka ikisessä mahdollisessa kohdassa on kuitenkin jossakin kiireen ja yksinkertaisuuden takia luistettu; kaikki olennaiset kunnolla tehdyt itsestään kesä- ja talviaikavaihdon tekevät kellot ja nykyisetkin ohjelmistot osaavat jatkaa nykytyylillä vaikka maailman tappiin ilman ongelmia). Toki jossakin (tai monessakin paikassa) voi olla vielä vanhoja lyhyitä (32-bit) epoch-laskureita, jotka aiheuttavat joskus vuosikymmenen, parin kuluttua ongelmia. Päivitetyt taitavat toimia siihen asti, että aurinko on jo laajennuttuaan korventanut Maan ja Marsin seudut asuinkelvottomiseksi ainakin Jupiterin liepeille asti.
Muunnoksethan tietävät myös historiassa tapahtuneet muutokset, eli esimerkiksi Suomessa 1980 käyttöön otetun kesäajan ja matkan varrella tapahtuneet muutokset, joista aikahyöhykesiirtymät ja uusien aikavyöhyketunnusten/-standardien käyttöönotto ovat merkittävimmät (jokin UTC+2:00 ei vielä sano ollenkaan riittävästi ilman päiväystä mutta myös maa pitäisi tietää, koska muutokset ovat menneet eri kolkilla eri tahtiin). Muunnokset on myös aika ajoin päivitettävä, jos esimerkiksi EU:ssa joskus luovutaan käyttämästä kesäaikaa (mikä ainakin omasta mielestäni olisi sikäli hölmöä, että siitä aiheutuu arvaamatonta harmia ja sotkua kuten vuosituhannen vaihteen ongelmista aikoinaan, sillä joka ikisessä mahdollisessa kohdassa on kuitenkin jossakin kiireen ja yksinkertaisuuden takia luistettu; kaikki olennaiset kunnolla tehdyt itsestään kesä- ja talviaikavaihdon tekevät kellot ja nykyisetkin ohjelmistot osaavat jatkaa nykytyylillä vaikka maailman tappiin ilman ongelmia). Toki jossakin (tai monessakin paikassa) voi olla vielä vanhoja lyhyitä (32-bit) epoch-laskureita, jotka aiheuttavat joskus vuosikymmenen, parin kuluttua ongelmia. Päivitetyt taitavat toimia siihen asti, että aurinko on jo laajennuttuaan korventanut Maan ja Marsin seudut asuinkelvottomiseksi ainakin Jupiterin liepeille asti.
Voisihan vielä lisätä, että UTC-aikaan on joinakin vuosina lisätty "karkaussekunteja" maapallon pyörimisen hidastumisesta johtuen (maan pyöriminen nimittäin linkoaa Kuuta vähitellen kauemmas vuorivesikitkojen ym. takia). Joissakin tarkoissa laskelmissa pitäisi UTC-ajankin kohdalla ottaa moinen huomioon (vuosien pituudet voivat sekunteina heitellä yhden sekunnin verran).
Kannattaa muuten lukea vaikkapa Wikipedian artikkeli tuosta Leap second -aiheesta (https://en.wikipedia.org/wiki/Leap_second). Vaikka aihe saattaa aluksi tuntua turhanpäiväiseltä hiusten halkomiselta, se ei sitä nykyisessä GPS-maailmassa suinkaan ole (karkaussekunnit ovat toistaiseksi tauolla, koska ei ole yksimielisyyttä, miten pitäisi vastaisuudessa toimia ja ongelmat ovat jo aiheuttaneet harmia ja alkavat vähitellen hypätä silmille).
Toki näin, jos käsitellään jotain ajankohtia kauempana historiassa. Sähkön spot-hinnan tapauksessa noilla ei ole merkitystä, järjestelmä on pysynyt samana koko Nord Poolin olemassaolon ajan. Tässä tapauksessa siis tuon UTC-offsetin pitäisi riittää vallan mainiosti. Mutta olet oikeassa siinä, että aikavyöhykkeen nimi on olennainen tieto, jos tarvitsee käsitellä vaikkapa vuosikymmenien mittaisia aikajaksoja, joiden aikana kesäaikasäännöt ovat voineet muuttua.
Mikäköhän härö eilen 4.12.2023 kello 19 mahtoi olla? Mulla on Smart Heating käytössä, ja siinä määrittely "HeatingHours_MinTemperature: -4". Eilen oli kuitenkin katkaissut lämmityksen yhden tunnin ajaksi -16°C ulkolämpötilassa.
yr.no säätiedot hikkaa? Tämän sijainti on Kaarina, postinumero 20780. Shellyn konsolilogia ei ole tallessa.
yr.no säätiedot hikkaa? Tämän sijainti on Kaarina, postinumero 20780. Shellyn konsolilogia ei ole tallessa.
- Keskustelun aloittaja
- #1 371
Tuolla taisi tosiaan olla YR.no pässä joku ongelma, kun palautti virhettä ehkä tunnin ajan. Tästä viisastuneena olen tekemässä varalähdettä lämpötilaennusteelle Azure Maps Weather API:n kautta (käytännössä AccuWeather). Sitä käytettäisiin korvikkeena jos YR.no:sta ei saada hintoja.
Suomalaiset rajapinnat on muuten käsittämättömän paljon vaikeampia teknisesti kuin mitkään ulkomaiset. Ja hinnat esim. Forecalla aivan taivaissa vrt. ulkomaiset sääennustajat.
Suomalaisessa sovelluskehityksessä on kyllä jotain mielestäni vialla, kun keskimäärin esim. rajapinnoissa ihan helpoimmankin peruskäyttötapauksen tekeminen voi olla eeppisen vaikean teknisen jargonin takana.
- Keskustelun aloittaja
- #1 373
Hmm... Onhan Shellyn kello oikeassa? Raportille aikaleima tulee sieltä. Ohjaus menee palvelimen kellon kautta.
Jep on oikeassa. Kyseessä kylppärin lattialämmitys ja iltapäivän Shellyn raportointi osuu yhteen suihkussa käyntiin
kayttajatunnus
Aktiivinen jäsen
Täytyy sanoa, että oma lämmitysjärjestelmä kyllä kaipaisi kovemmille pakkasille sitä, että voisi määritellä kuinka pitkä tauko lämmityksessä maksimissaan on. MLP masiina on hieman alitehoinen tähän taloon ja jos laatta pääsee viilenemään liikaa, ei se meinaa saada vajausta enää kiinni.
En tiedä miten käytännössä voisi toteuttaa mutta muuttuja x, joka on maksimi tauko lämmityksen eston välissä ja y, joka on pakkasraja tälle. Meneeköhän jo liian monimutkaiseksi nykyisten toiminnallisuuksien kanssa?
Muutoin skripti on toiminut kovemmillakin pakkasilla kuten kuuluu. Lämmitysjärjestelmä asettaa pieniä haasteita, kun nopeasti viiletessä ei meinaa pysyä perässä mutta nämä on onneksi helposti ratkaistavissa kun ottaa vain skriptin pois päältä ja antaa koneen käydä jatkuvasti.
En tiedä miten käytännössä voisi toteuttaa mutta muuttuja x, joka on maksimi tauko lämmityksen eston välissä ja y, joka on pakkasraja tälle. Meneeköhän jo liian monimutkaiseksi nykyisten toiminnallisuuksien kanssa?
Muutoin skripti on toiminut kovemmillakin pakkasilla kuten kuuluu. Lämmitysjärjestelmä asettaa pieniä haasteita, kun nopeasti viiletessä ei meinaa pysyä perässä mutta nämä on onneksi helposti ratkaistavissa kun ottaa vain skriptin pois päältä ja antaa koneen käydä jatkuvasti.
- Keskustelun aloittaja
- #1 376
Oliko sinulla tuo SmartHeating skripti käytössä? Jyrkemmällä käyrällä esim -10C ja -20C välillä toki pienenee tauot ja jos etelärannikolla on, niin ei ne kovat pakkaspäivät kovin yleisiä ole, että välttämättä hirmuisesti haittaisi jos ajetaan selvästi reilummin tunteja silloin?
Jos haluat niin voit heittää vaikka paremetrisi s-postilla info @ spot-hinta.fi niin voin katsoa keksinkö jotain parannusehdotusta parametreihin.
Jos haluat niin voit heittää vaikka paremetrisi s-postilla info @ spot-hinta.fi niin voin katsoa keksinkö jotain parannusehdotusta parametreihin.
kayttajatunnus
Aktiivinen jäsen
Joo SmartHeating käytössä. Tänäänkin on rank 20 näillä pakkasilla ja kaikki neljä tuntia osuvat peräkkäin.
Laitoin skriptin "käyrää" ihan reippaasti ylöspäin ja -11 asteessa jo sallitaan lämmitys koko ajan.
Ei tämä tosiaan iso ongelma ole ja pääsääntöisesti toimii juuri kuten pitää. Keskeltä päivää on sallittu pari tuntia mutta se ei tässä vaiheessa enää oikein auta kun alkaa ei-lämmitettäviä tunteja olla niin vähän.
Koodi:
HeatingHours_MaxTemperature: 50, // Stop heating at this temperature (zero hours in all degrees above this)
HeatingHours_Plus30: 3, // Number of heating hours at +30C
HeatingHours_Plus20: 3, // Number of heating hours at +20C
HeatingHours_Plus10: 8, // Number of heating hours at +10C
HeatingHours_Zero: 14, // Number of heating hours at 0C
HeatingHours_Minus10: 23, // Number of heating hours at -10C
HeatingHours_Minus20: 24, // Number of heating hours at -20C
HeatingHours_Minus30: 24, // Number of heating hours at -30C
HeatingHours_MinTemperature: -11, // Temperature where heating is always on (24 hours in all degrees below this)
// Minimum hours period (mainly for a daytime to avoid too long heating pauses)
MinimumHoursPeriod_IsActive: true, // Set to true, if you want to define minimum hours period
MinimumHoursPeriod_TemperatureStart: 10, // Minimum hours are active only below this temperature
MinimumHoursPeriod_PriceAllowed: 50, // Minimum hour price limit. Skip hours that more expensive than this. Note! This can reduce minimum period hours.
MinimumHoursPeriod_Hours: [10, 11, 12, 13, 14, 15, 16], // List hours (0...23) for minimum hours period.
MinimumHoursPeriod_NumberOfHours: 2, // How many hours at minimum must be put to this period. Note! Price limit can reduce this number.Minulla on Shelly Pro 1 ohjaamassa talon lattialämmityksiä Shelly Rank and Price scriptillä. Toimintaa pitäisi olla valvomassa Shelly-SmartMonitoring scripti. Kaikki on toiminut loistavasti jo useamman kuukauden. Tänään huomasin ensimmäisen ongelman. Jostakin syystä Shelly Rank and Price oli stopannut kokonaan eilen ja kämppä oli jäänyt lämmittämättä tänään. Normaalisti Shelly poimii lämmitykseen päivän 7 halvinta tuntia ja yölle on 5 backup tuntia varuilta, jos ei satu saamaan hintatietoja. Osaako joku kertoa tai veikata miksi Rank and Price on stopannut ja miksi päällä oleva Smart Monitoring ei startannut automaattisesti käyntiin uudelleen? Olenko ymmärtänyt oikein, että Smart Monitoringin pitäisi startata tuo, jos parametrit on asetettu oikein.
- Keskustelun aloittaja
- #1 379
Kyllä SmartMonitoring käynnistää skriptin uudestaan, kunhan skriptin numero mitä valvotaan on oikein. Ja jos skriptimonitorointi on päälle asetettuna. Skriptin numeron näkee selaimen URL:sta kun skripti on auki.
SmartMonitoring kannattaa testata että on toiminnassa siten, että stoppaa käsin sen valvottavan skriptin ja katsoo että lähtee parin minuutin sisällä uudestaan päälle.
Onhan Shellyssä skriptien kohdalla tuo liukukytkin päällä mikä on ympäröity punaisella? Se on typerästi käyttöliittymässä ilman selitystä, mutta se siis tarkoittaa että skripti käynnistyy jos Shelly uudelleenkäynnistyy jostain syystä.
Viimeksi muokattu:
Ongelma ratkesi. Kaikki muu oli kunnossa, mutta valvottavan scriptin numero oli pielessä. Kun on vain yksi scripti valvottavana, olin tietämättömyyttäni asettanut valvonnan alle scriptin numero 1, joka on oletusarvona koodissa. Tämä ohje ratkaisi ongelman:"Skriptin numeron näkee selaimen URL:sta kun skripti on auki." Valvoa pitikin numeroa 3 vaikka ei ole kuin yksi valvottava. 1-->3 muutoksen jälkeen stoppasin Rank and Pricen käsin ja se starttasi takaisin päälle minuutin parin kuluttua valvontascriptin avulla itsekseen.
Iso kiitos Mikki avustasi!
Iso kiitos Mikki avustasi!
SikariSibelius
Jäsen
Tähän liittyen, onko kenelläkään kokemusta niben etäohjauksesta käyttäen nibe uplinkkiä?
Mietiskelin, jos käyttäisi tätä rajapintaa hyödyksi ja hoitaisi ohjauksen uplinkin kautta.
E: tulipa mielenkiinnosta ostettua etäohjaus, että pääsi tutkimaan. Sieltä näköjään saa muokattua estoja ja lisättyä ohjelmointeja. Pitääpä viritellä automaatiota, jolla voisin tehdä vähän vastaavanlaisia ohjauksia, mitä tässä on tehty shellyllä.
Mietiskelin, jos käyttäisi tätä rajapintaa hyödyksi ja hoitaisi ohjauksen uplinkin kautta.
E: tulipa mielenkiinnosta ostettua etäohjaus, että pääsi tutkimaan. Sieltä näköjään saa muokattua estoja ja lisättyä ohjelmointeja. Pitääpä viritellä automaatiota, jolla voisin tehdä vähän vastaavanlaisia ohjauksia, mitä tässä on tehty shellyllä.
Viimeksi muokattu:
Nuo kaikki samat löytyy myös sieltä pumpun valikosta mitä etäohjauksella pystyt uplinkin kautta tekemään.
Uplinkiin on kyllä jonkinlainen rajoitettu API olemassa, mitä nyt nopeasti tutkailin niin pystyy lähinnä ohjaamaan lämpökäyrän siirtymää ja käyttöveden tilaa.
Nibessä pitäisi olla tuon uplinkin kautta jonkinlainen mahdollisuus IFTTT:lle, niin ehkä spot-hintaa saisi sen kautta hyödynnettyä?
SikariSibelius
Jäsen
Tutkin kanssa sitä APIa ja se tosiaan vaikutti todella riisutulta. Kuten tuohon editoinkin, niin sieltä uplinkin kautta saa kaiken tarvittavan tehtyä.
Näin alkuun ajattelin e2e testi frameworkillä viritellä tuon spot-hintaan reagoinnin ja laittaa sen ajastetusta awsään pyörimään.
Hyvänä puolena tuossa on se, että voin laittaa jonkin oletus konfiguraation viikon muille päiville, jos netti sattuisi olemaan muutaman päivän poikki.
Itse ohjaan aux-liitännöillä, se toimii niin, että jos ohjaus ei pelaa niin pumppu toimii normiasetuksilla. Aux sitten ohjaa käyttöveden säästötilaan, kompressorin eston ja lämpökäyrän korotuksen pörssihinnan ja ulkolämpöennusteen mukaan. Mutta se menee jo osin tämän ketjun aiheen ohi, kun en käytä spot-hintaa.
Gebwellin (Siemensin) pumppu Aries 12 ja kallis pörssiohjaus loppuu nyt tammikuussa, tuli otettua kun oltiin protossa mukana 2022 syksynä. Pumppu on jo nyt Home Assistantin / NodeRedin perässä siten, että pystyn ModBusTCP:n kautta pumppua ohjaamaan ja hakemaan tietoja.
Rehellisyyden nimessä, en ole kokonaan ketjua lukenut. Ilmeisesti porukka on käyttänyt Shellyä paljolti ohjauksessa laiteille, mutta itsellä olisi tarkoitus tehdä tuohon ohjaus modbusin kautta suoraan koneelle. Tuota Gebwellin logiikkaa en täysin tiedä, miten se tuota pörssiohjausta tekee, lattiapiirin menolämpöön se vaikuttaa +- tyyppisesti, mutta mitä muuta se ohjaa niin pitää nyt vielä lokittaa tuota dataa koneesta kun vielä on tuo palvelu.
Lähinnä vuorokauden kalliimpien tuntien esto ja halvimpien kevyt buustaus suunnitelmissa, toki pakkasrajan mukaan (näin se karkiasti menee tuo valmistajankin)
Onko muita vastaavan jutun äärellä ollut?
Rehellisyyden nimessä, en ole kokonaan ketjua lukenut. Ilmeisesti porukka on käyttänyt Shellyä paljolti ohjauksessa laiteille, mutta itsellä olisi tarkoitus tehdä tuohon ohjaus modbusin kautta suoraan koneelle. Tuota Gebwellin logiikkaa en täysin tiedä, miten se tuota pörssiohjausta tekee, lattiapiirin menolämpöön se vaikuttaa +- tyyppisesti, mutta mitä muuta se ohjaa niin pitää nyt vielä lokittaa tuota dataa koneesta kun vielä on tuo palvelu.
Lähinnä vuorokauden kalliimpien tuntien esto ja halvimpien kevyt buustaus suunnitelmissa, toki pakkasrajan mukaan (näin se karkiasti menee tuo valmistajankin)
Onko muita vastaavan jutun äärellä ollut?
- Keskustelun aloittaja
- #1 386
Shelly-skripteihin liittyvää kehitystä jälleen.... Nyt on valmiina testaukseen uusi suomenkielinen lämminvesivaraaja skripti. Tämä skripti pyrkii jälleen uudeksi lyhyimmäksi pörssiohjauskriptiksi, mitä on nähty.
Löytyy täältä:
Ominaisuutena on yritys todelliseen yksinkertaisuuteen. Eli valitset vain kuinka monta halvinta tuntia lämmitetään yöllä (22:00 - 06:59) ja kuinka monta tuntia iltapäivällä (12:00-19:59). Tarkoitus on, että tämä mukailee normaalia elämänrytmiä ja iltapäivän "tehostus" on tarkoitettu suurempiin lämmitystarpeisiin, kun kerran vuorokaudessa lämmitys ei riitä.
Testata saa ja palautetta antaa.
Löytyy täältä:
Ominaisuutena on yritys todelliseen yksinkertaisuuteen. Eli valitset vain kuinka monta halvinta tuntia lämmitetään yöllä (22:00 - 06:59) ja kuinka monta tuntia iltapäivällä (12:00-19:59). Tarkoitus on, että tämä mukailee normaalia elämänrytmiä ja iltapäivän "tehostus" on tarkoitettu suurempiin lämmitystarpeisiin, kun kerran vuorokaudessa lämmitys ei riitä.
Testata saa ja palautetta antaa.
Käytännössä joku +8 C riittää varmasti siihen ettei maanvaraisessa laatassa tai sen alla olevat putket jäädy mutta onhan se aika raikkaan makuinen sitten suihkussa käydessä. Kodinhoitohuoneessa toki voi olettaa liikuttavan sukat jalassa niin siellä tuskin tulee ongelmaa.
Miten lämmönjako ja -tuotto on toteutettu eli säästyykö tässä oikeasti sähköä vai siirtyykö lämmitys vain toiseen huoneeseen?
Joku asumisterveys(?)ohje ohjeistaa että pesutilojen tulisi olla lämpimämmät kuin asuintilat. Jos ovat kylmemmät, kastepiste on niissä tiloissa sille runsaalle kosteudelle jota tiloista nimensäkin mukaan jo tulee. Toisaalta onko tämä huono asia koska siellä ne vesieristeet ja enemmän kosteutta kestävät pinnat/ rakenteet ovat.
Ehkä tuolla ohjeella että olisivat lämpimämmät tavoitellaan parempaa kuivumista.
Ajastetusti itse menen ja tilojen ollessa toisessa päässä taloa ulkoseiniä vasten on tiloissa välillä +16 ja lattia silti vaikka +23 (kun ulkona sen -30 tuulien kera). Lattiaa en ole uskaltanut kovin viileäksi päästää vaan tavoite että tila kuivuisi suihkuläträyksen jälkeenkin.
Ilmanvaihto tietenkin olennaista mutta sen me kaikki varmaankin tiedämme jo
Kuivumisen kannalta kesäaika ja alkusyksy ovat oleellisia. Talvella ilma on joka tapauksessa niin kuivaa, että kosteuskin häipyy normaalin ilmanvaihdon myötä.
On toinen juttu, että kylmäsillat voivat muodostaa pesutiloihin talvisaikaan realisoituvia kosteusriskejä. Noita ei kuitenkaan saa tyypillisesti hallintaan nostamalla pesutilan lämpötilaa, vaan kyse on rakennevirheestä, joka olisi syytä korjata ja jollei muuten, niin parantamalla lämpöeristystä ja vaihtamalla materiaaleja kosteutta kestäviksi.
Kiitoksia, olipa lyhyt ja selkeä skripti! Testasin sitä ja se toimii hyvin paitsi, että skripti noukkii aina vuorokauden ensimmäisen tunnin, oli hinta mikä hyvänsä. Minulla oli valittuna yö aikaan 3 tuntia, jotka menivät ihan oikein halvimmille tunneille (kuten myös iltapäivätunnit). Kuitenkin yö tunteja tuli 4 tuo haamutunti (00-01) mukaan lukien? En keksinyt syytä ongelmaan.
Kaikki muut skriptit ovat toimineet moitteettomasti, vaikka kyllähän sitä testatessa toki probleemeihin törmää, mutta ne ovat aina olleet itse aiheutettuja säätöjen kanssa sählätessä.
Käytössä Shelly Pro 2PM rele ja päivitykset ajan tasalla.
Liitteet
- Keskustelun aloittaja
- #1 392
Pitikin laittaa tänne että tuo bugi on korjattu tänään. Pitää valitettavasti vain päivittää skripti kun vika oli siinä.
Löytyy kirjaston kautta. Tai täältä:
Shelly/Scripts/Shelly-Vesivaraaja.js at main · Spot-hinta-fi/Shelly
Shelly smart relay scripts to utilize api.spot-hinta.fi API's - Spot-hinta-fi/Shelly
github.com
Toistan varmaan itseäni mutta aloin miettimään miksi tuo price modifier ylipäätään on pitänyt sotkea priority hours parametreihin ? price modifierillahan voisi olla oma price modifier hours lista joiden hintaa muokataan esim. yötunnit. Silloin voisi käyttää hinnan muokkausta ja priority tunteja yhtäaikaa, nyt joutuu valitsemaan kumpia käyttää, molempia ei voi. tämä tarve tuli vastaan muutama päivä sitten kun halvimmat tunnit olikin poikkeuksellisesti päivällä, jäi lattiamassa lämmittämättä kun niitä ei voinut priorisoida. Yleensä ei ongelmaa mutta tuo olis selvä parannus.
- Keskustelun aloittaja
- #1 394
Täytyy tuumia... Ideassasi on hyvät perustelut. Tuo kohta kieltämättä vaivaa vähän itseäkin.
vois olla yhtenäinen käytäntö että aina kun jotain muokkausta tehdään parametrillä esim price, booster, jne. niin sillä olis aina parina tuntilista johon ko. muokkauksen halutaan vaikuttavan
Shellyjen käyttäjät ehkä jo tietävät tämän erinomaisen action toiminnon jossa mm. voi käskeä suoraan lähiverkkoon liitettyä toista shellyä .Tässä ohjataan seis http://192.168.33.4/relay/0?turn=off ja tässä ohjaus myös seis http://192.168.33.4/relay/0?turn=off&timer=200 mutta vasta 200 sekunnin viiveen kuluttua.
Pörssisähkön tai aurinkosähkön ohjauksiin ProEm tuotteiden kanssa täydellinen ja luotettava ja kaikki ilman ulkopuolisia automaatiojärjestelmiä tai sitä kuuluisaa HA
korjaus:200 sekunnin ajaksi rele tai kanava off
Pörssisähkön tai aurinkosähkön ohjauksiin ProEm tuotteiden kanssa täydellinen ja luotettava ja kaikki ilman ulkopuolisia automaatiojärjestelmiä tai sitä kuuluisaa HA
korjaus:200 sekunnin ajaksi rele tai kanava off
Viimeksi muokattu:
Menee vähän ohi aiheen, mutta toisaalta voi spot-hinnan kanssakin tuoda mukaan yksinkertaista kuormanhallintaa. Eli jos omistaa han-portillisen mittarin, niin voi hyödyntää esimerkiksi tuota homewizardinkin palikkaa shellyn skriptillä siten, että käskyttää esim tietyn tehorajan ylittyessä vaiheita pois päältä.
Pro Em-shellyillä voi halvoilla tunneilla tai aurinkosähköllä flip-toiminnolla tankata vaikka watti kerrallaan varaajaa tai akkua kun ehdot täyttyy (tarpeeksi halpaa tai koko talon energiankulutus on riittävästi miinuksella )
Käytän api-kutsua https://api.spot-hinta.fi/TodayAndDayForward hintojen hakemiseen, ja olen hyvin kiitollinen, että tuollainen helppo API on olemassa.
Olisi kuitenkin pari kehitystoivetta:
1: palautettava json ei sisällä viimeistä julkaistua tuntihintaa. Esim. nyt viimeinen rekordi on:
Ymmärrän, että tuolle tunnille ei vielä voi antaa rank:iä, mutta voisiko sen silti palauttaa (esim. rank:illä -1 tms)
2: hinnat eivät ole viimeisiä desimaaleja myöten oikein. Esim. tuon yllä olevan tunnin hinta on nordpoolspotin (https://www.nordpoolgroup.com/en/Market-data1/Dayahead/Area-Prices/ALL1/Hourly/?view=table) mukaan -0,01 EUR/Mwh (alv 0%), mikä tarkoittaa -0,001 c/KWh (alv 0%) ja -0,00124 c/kWh (alv 24%). Vaikka nuo viimeiset desimaalit eivät sähkölaskussa näykään, ottaisin silti mielelläni tarkat arvot. Vaikka niin, että nykyisten kenttien lisäksi tulisi tuo alviton EUR/MWh hinta, josta voi sitten itse laskea haluamallaan tarkkuudella.
e: löysin toisen, tarkoituksiini paremmin soveltuvan APIn ja siirtynen käyttämään sitä.
Olisi kuitenkin pari kehitystoivetta:
1: palautettava json ei sisällä viimeistä julkaistua tuntihintaa. Esim. nyt viimeinen rekordi on:
vaikka viimeinen julkaistu hinta on tuntia myöhempi (-0,31 EUR/MWh alv 0%)
Ymmärrän, että tuolle tunnille ei vielä voi antaa rank:iä, mutta voisiko sen silti palauttaa (esim. rank:illä -1 tms)
2: hinnat eivät ole viimeisiä desimaaleja myöten oikein. Esim. tuon yllä olevan tunnin hinta on nordpoolspotin (https://www.nordpoolgroup.com/en/Market-data1/Dayahead/Area-Prices/ALL1/Hourly/?view=table) mukaan -0,01 EUR/Mwh (alv 0%), mikä tarkoittaa -0,001 c/KWh (alv 0%) ja -0,00124 c/kWh (alv 24%). Vaikka nuo viimeiset desimaalit eivät sähkölaskussa näykään, ottaisin silti mielelläni tarkat arvot. Vaikka niin, että nykyisten kenttien lisäksi tulisi tuo alviton EUR/MWh hinta, josta voi sitten itse laskea haluamallaan tarkkuudella.
e: löysin toisen, tarkoituksiini paremmin soveltuvan APIn ja siirtynen käyttämään sitä.
Viimeksi muokattu:
Avaatko enemmän tuota flip toimintaa, miten tuo tapahtuu ?