Ihan shellyn käyttöliittymässä hiiren klikkauksilla
Liitteenä kuva jossa mitattu kulutus alittaa 1 kilowatin rele päällä tunnin ajan ohjaamaan vaikka lämminvesivaraajan kontaktoria huono malli mutta periaate selkiää
Spot-hinta.fi - Yksinkertainen pörssiohjaus API ja sitä käyttävät automaatioskriptit
- Viestiketjun aloittaja Mikki
- Aloituspäivämäärä
Liitteenä kuva jossa mitattu kulutus alittaa 1 kilowatin rele päällä tunnin ajan ohjaamaan vaikka lämminvesivaraajan kontaktoria huono malli mutta periaate selkiää
Tuo HomeWizardin palikka antaa kanssa 10sek välein tietoa han-portista, eli se voisi toimia ihan yhtälailla tuossa kulutustiedon lähteenä jos ei satu olemaan jo em-shellyt valmiina. Siinä on todella yksinkertainen paikallinen rest-rajapinta mistä tuolla p1-han -topicissa onkin jo puhetta.
En muista oliko tästä jo joskus puhetta, mutta API voisi ilmoittaa Rank:in lisäksi myös persentiilin (kuinka suuri osa hinnoista on yhtä suuria tai pienempiä kuin kyseinen hinta).
Jos haluaisi lämmittää puolet vuorokaudesta, niin ehto "currentPrice.Percentile <= 50" hoitaisi homman. Vastaava Rank:ia käyttävä ehto on "currentPrice.Rank <= 12".
Tuota persentiiliä voisi käyttää, oli hinnat ilmoitettu sitten tunnin tai vartin jaksoille.
Vartin jaksoja on vuorokaudessa 96 kpl, joten "persentiili" kääntyy arkikielessä melkein suoraan jaksojen lukumääräksi.
API taisi kylläkin olla jo "hakattu kiveen", mutta noin ajatuksen tasolla se voisi olla pieni lisäys johonkin tulevaan versioon.
Jos haluaisi lämmittää puolet vuorokaudesta, niin ehto "currentPrice.Percentile <= 50" hoitaisi homman. Vastaava Rank:ia käyttävä ehto on "currentPrice.Rank <= 12".
Tuota persentiiliä voisi käyttää, oli hinnat ilmoitettu sitten tunnin tai vartin jaksoille.
Vartin jaksoja on vuorokaudessa 96 kpl, joten "persentiili" kääntyy arkikielessä melkein suoraan jaksojen lukumääräksi.
API taisi kylläkin olla jo "hakattu kiveen", mutta noin ajatuksen tasolla se voisi olla pieni lisäys johonkin tulevaan versioon.
Mä olen tässä koittanut miettiä pysyykö tuon käyttäjä jotenkin säätämään niin että se osaisi toimia järkevästi laskevalla sähkönhinnalla.
Siis nyt on hieman "ongelmana" se että jos on määritellyt 4 halvinta tuntia esim LVV:lle, käytännössä varaaja suoriutuu työstään 2 tunnissa, niin se käyttää ne kaksi kalleinta tuntia, jos sähkön hinta on jokaisella tunnilla aina naksun halvempi kuin edellisellä. Lisäksi tuo tuntuu tapahtuvan aika usein pe-la välillä, kun pörssihinta yleens perjantai-iltana laskee, jolloin perjantain halvimmat tunnit asettuvat sinne iltaan, ja sitten uusi pörssipäivä lauantainen kyykkää usein selkeästi alemmas, niin sitten kun se kyykännyt hinta olisi käytössä varaja on lämmin.
Siis nyt on hieman "ongelmana" se että jos on määritellyt 4 halvinta tuntia esim LVV:lle, käytännössä varaaja suoriutuu työstään 2 tunnissa, niin se käyttää ne kaksi kalleinta tuntia, jos sähkön hinta on jokaisella tunnilla aina naksun halvempi kuin edellisellä. Lisäksi tuo tuntuu tapahtuvan aika usein pe-la välillä, kun pörssihinta yleens perjantai-iltana laskee, jolloin perjantain halvimmat tunnit asettuvat sinne iltaan, ja sitten uusi pörssipäivä lauantainen kyykkää usein selkeästi alemmas, niin sitten kun se kyykännyt hinta olisi käytössä varaja on lämmin.
Tuon takia itse sallinut vaan 3 halvinta käyttöveden tekoon, lisäksi yksi varatunti klo 12-17 välissä ja siitä joukosta se halvin, jos siis on tarvetta. Riippuu paljon varaajan koosta ja vedenlotrauksesta kuinka tuon lopulta voi toteuttaa
No nyt kun lunttasin niin 3 halvinta mullakin on LVV valittuna, mutta kyllä tuo sama pätee aina. Se hinnan laskeminen saa käytännössä sen kulutuksen aina painottumaan ensimmäiselle tunnille.
Suurempi äly vaatisi tiedon varaajan lämpötilasta tai tarkemmin ottaen tiedon kuinka pitkä aika lämmitykseen tarkasti ottaen tarvitaan. Se onnistuisi jos tietäisi 1) lämpötilan nyt 2) varaajan tilavuus 3) vastuksen teho 4) haluttu loppulämpö.
Eli oikeastaan tärkein tieto olisi varaajan lämpötila. Sitä vain helposti suurimmasta osasta varaajia ei saa.
Varaajan kanssa on lisäksi sellainen ongelma, että lämpötilakaan ei oikein kerro mitään. Pinnalla on kuumaa vettä, pohjalla kylmää, ja jollain korkeudella on harppauskerros jossa on suuri lämpötilaero lyhyellä matkalla. Pitäisi tietää ko. harppauskerroksen paikka suhteessa varaajan korkeuteen. Tai sitten voisi mitata kuuman veden kulutusta ja arvioida lämmitystarve siitä. Tietty joku viitisen lämpöanturia eri korkeuksilla antaisi jo varsin tarkan arvion.
Näinhän se on. Ja yritän itse jatkuvasti muistuttaa myös itseäni, että kun lähdetään optimoimaan niin "rajahyöty" pienenee valtavan nopeasti, mutta monimutkaisuus kasvaa jopa exponentiaalisesti.
Jos jatkuvasti tekee käyttöveden lämmityksen 3 halvimmalla tunnilla. Sitkeästi vain joka ikinen päivä, niin kaikki "poikkeustilanteet" katoaa kohinaan ja käyttövesi tulee käytännössä niin halvalla kuin se on mahdollista tehdä.
Joo. Tuo varaaja tosin ei välttämättä lämmitä kuin tunnin verran, jos vettä on mennyt vähän.
Tuo vuorokauden 3 halvinta tuntiahan tekee joskus sen että varaaja on yhtäjaksoisesti sähkössä 21-03, ja käytännössä se lämmittää 21 ja 22 tunneilla, jolloin sähkö on kalleinta.
Ei tuossa tietenkään valtavista summista ole kyse, mutta hintaoptimoinnin kannalta mutuna sanoisin että "vuorokauden" vaihtuminen klo 12 oikean 00 sijaan saisi ehkä hieman paremmin optimoitua tuon.
Sama vika, just julkistin Githubissa softan jolla saa Teslan latauksen ajastettua pörssisähköoptimoidusti. Talvella lataus hidastuu akun lämmityksen vuoksi, mutta telemetriadatasta akun sisäistä lämpötilaa ei saa. Päädyin sitten kasvattamaan latausajan arviota auton raportoiman viimeisimmän ulkolämpötilan mukaan.
Akun lämpötilan huomioonottaminen olisi mahdollista, mutta hankalaa. Pitäisi kytkeä autoon OBD2 Bluetooth dongle sekä sijoittaa latausajoituksen laskeva tietokone Bluetoothin kantaman sisälle. Auton sisäisestä CAN-väylästä tuon tiedon siis saisi.
https://github.com/ToniA/nordpool-teslamateapi (päädyin käyttämään tässä NPM-kirjastoa 'nordpool')
Akun lämpötilan huomioonottaminen olisi mahdollista, mutta hankalaa. Pitäisi kytkeä autoon OBD2 Bluetooth dongle sekä sijoittaa latausajoituksen laskeva tietokone Bluetoothin kantaman sisälle. Auton sisäisestä CAN-väylästä tuon tiedon siis saisi.
https://github.com/ToniA/nordpool-teslamateapi (päädyin käyttämään tässä NPM-kirjastoa 'nordpool')
Joo... ja 22:00 - 07:00 välisellä aikana halvimmat tunnit lähes aina löytyvät. Tuon ongelman, että illasta alkaa hinnat tippumaan voi välttää, kun hakee halvimmat tunnit tuolta yösähköajalta vuorokauden vaihtumisesta välittämättä.
Spot-hinnan Shelly skrpipteissä tuo asetus löytyy vesivaraaja, minimal ja pikakoodit skripteistä. Tai sitten rajapintakutsulla: https://api.spot-hinta.fi/JustNowRankNight?rank=3
Niin
Enpä tajunnutkaan että se toimii noin, kuvittelin että se vuorokausi vaihtuu 00 myös tuolla asetuksella.
Nysväsin joku aika sitten kotitekoisen automaation, joka löytää Teslalle halvimman yhtäjaksoisen latausjakson yön yli. Alunperin käytössä oli NPM-paketti nordpool, mutta tämä spot-hinta.fi REST API https://api.spot-hinta.fi/TodayAndDayForward tuntuu toimivan paljon luotettavammin ja nopeammin.
Tässä on siis ideana lisätä esim. Raspberry Pi:ssä pyöritettävän TeslaMate-loggerin toiminnallisuutta. Auton telemetriasta saadaan tiedot joilla voidaan arvioida tarvittava latausaika, jonka perusteella sitten löydetään halvin latauksen aloitustunti. Jos auto on kotona ja töpseli on kiinni, lähetetään ajastuskomento jolla auto aloittaa latauksen ko. kellonaikana. (02.02.2024 oli joku sähköräpsy, siitä kaksi riviä)
Gridio yms. ovat varmasti helpompia, mutta onpahan tehty itse... ks. https://play.google.com/store/apps/details?id=com.gridioapp
github.com
Tässä on siis ideana lisätä esim. Raspberry Pi:ssä pyöritettävän TeslaMate-loggerin toiminnallisuutta. Auton telemetriasta saadaan tiedot joilla voidaan arvioida tarvittava latausaika, jonka perusteella sitten löydetään halvin latauksen aloitustunti. Jos auto on kotona ja töpseli on kiinni, lähetetään ajastuskomento jolla auto aloittaa latauksen ko. kellonaikana. (02.02.2024 oli joku sähköräpsy, siitä kaksi riviä)
Gridio yms. ovat varmasti helpompia, mutta onpahan tehty itse... ks. https://play.google.com/store/apps/details?id=com.gridioapp
GitHub - ToniA/nordpool-teslamateapi: Optimize Tesla charging on Nordpool spot prices, using TeslaMateAPI
Optimize Tesla charging on Nordpool spot prices, using TeslaMateAPI - GitHub - ToniA/nordpool-teslamateapi: Optimize Tesla charging on Nordpool spot prices, using TeslaMateAPI
github.com
Shelly Plus Plug S vehkeessä toimii hyvin. Huomaa "Plus", siinä on skriprituki
Miksi se tekee tuommoista humppaa klo 05 ja klo 07 lisäksi?
Ei iso ongelma kun tietää että sieltä voi puuttua tietoja mutta ongelma on jos shelly alkaa itsenäisesti vaihtamaan sisäisen verkon ip-osoitteita tai tekee rebootteja käyttäjän tietämättä
Pumppu-Ansu
Aktiivinen jäsen
Asiasta toiseen, onko kellään kokemusta simppelistä Shelly Plus 1-releestä lattialämmityksessä? Lattialämmityskaapelin teho on 1kW. Tuon pitäisi riittää kevyesti virran puolesta, ottaa pyöreästi 4 ampeeria. Pelkkää resistiivistä kuormaa. Ei siis tarvinne erillistä relettä. Eikä häiriönpoistokonkkaa. Rele tulisi olemassaolevaan pieneen metallioviseen jakokaappiin. Matkaa wifi-tukariin alle 10m. Miten on?
Luulisin toimivan. Kokeilla voi hyvin.
Mulla on lattialämmitystä ohjaamassa. Teho menee siis suoraan releen läpi vastukselle. Lämmitettävä pita-ala on vain n 4 neliötä. Hyvin on toiminut.
Mulla on Pro 1 PM -versiot katkomassa virtoja kylpyhuoneen ja kodinhoitohuoneen lattioista. Vastukset on vajaan kilowatin tehoisia. Hyvin on pelannut nämäkin, vaikka PM -versioita on heikommiksi haukuttu.
Kiitos. Tämän sai tumpulakin minuuteissa toimintaan!
hanks
Aktiivinen jäsen
Onkohan tässä langassa vielä aprikoitu mitä tarkoittaa kun pörssisähkössä siirrytään tuntihinnoittelusta varttihinnoitteluun. Logiikka toiminee samalla tavalla kuin nytkin, jaksoja tulee vain 4 kertaa lisää.
Minulla kun mikrokontrolleri ohjaa suoraan maalämpöpumppua JustNowRank/{rank}/{price} -rajapinnalla, tuli mieleen että voisikohan kompura tykätä huonoa jos se menee päälle/pois pahimmillaan vartin välein.
Minulla kun mikrokontrolleri ohjaa suoraan maalämpöpumppua JustNowRank/{rank}/{price} -rajapinnalla, tuli mieleen että voisikohan kompura tykätä huonoa jos se menee päälle/pois pahimmillaan vartin välein.
Ainakin Boschissa voi säätää pumpun päälläololle minimiajan eli ihan jokaiseen muutokseen se ei reagoi.
Voi olla, että varttihinnoittelu ei tuo vartin välein tapahtuvaa ohjausta eli edulliset vartit ovat todennäköisesti toisten edullisten varttien vieressä, mutta voihan siinä käydä toisinkin.
Luulisin, että tulee myös ratkaisuja, joilla voi valita haluamansa tuntimäärän siten, että jaksot vähintään käyttäjän haluaman mittaisia ja lopputulos on edullisin mahdollinen. Uskoisin, että vaihtoehtoja tulee, kunhan varttihintaa alkaa tulla.
Tällä hetkellä ajatteluni on, että nykyiset rajapinnat pysyvät tuntitasolla, kuten ennenkin. Eli keskiarvo tunneista ja ne järjestykseen. En usko että oikeastaan mitään kannattaa ohjata vartin jaksolla... ei edes kontaktorien takana olevia vastuksia.
Ja lisäksi kun on tuhansia käyttäjiä, niin jatkuvuuden kannalta myös että rajapinnat ei muutu on hyvä juttu. Mutta sitten ehkä tulee uudet rajapinnat "v2", jotka ottavat huomioon varttiohjausta. En oikein osaa mielessäni speksata, että mitä se tulisi olemaan, kun ei ole haisuakaan onko varttien välillä mitään merkittäviä hintaeroja.
Yksi ongelma tässä vain on... en löydä mistään faktatietoa, että milloin esim. EntsoE kautta tulee varttihinnat. Luultavasti ensi vuoden alusta heti, mutta olisi kiva saada jostain faktatietoa aiheesta. Kiitos jos joku löytää tiedon....
Tossunkorjaaja
Aktiivinen jäsen
Ei kait tarkkaa päivää ole vielä tiedossa. Q1/2025 aikana
root
Aktiivinen jäsen
Ja jos hintoja haetaan 4 krt tunnissa vs. kerran tunnissa (toki käyttäjien omista toteutuksista riippuen), vaikuttanee se sinun Azuresta saamaan laskuun?
Eihän tuo siirrettävä data ole kuin joitain tavuja hakukerralla.. Paljon isompi taloudellinen riskihän on jokin ddos hyökkäys (en tiedä miten azure on nuo hinnoitellut).
Azuren pilvessä kun ajaa koodia "serverless" alustalla (Azure Functions), maksaa jokainen kysely vähän. Ddos hyökkäys on näissä ympäristöissä "denial of wallet" tyyppinen hyökkäys ja jonkinlainen riski kyllä. Mutta tuota riskiä voi rajata siten, että ei salli mahdotonta määrää rinnakkaisia prosesseja. Vain sen verran kuin riittää normaalin liikenteen palveluun.
Just tuossa töissä juteltiin siitä, että Azuren laskutus siirtyy enemmän ja enemmän siihen suuntaan, että tietoturva maksaa koko ajan suhteessa enemmän. Esim. yhden julkisen IP-osoitteen DDoS protection listahinta Europe West on nyt 184€ / kk. Tai sitten voi ostaa könttinä max. 100 julkisen osoitteen suojauksen 2714€ / kk, ylimenevistä 27.2€ / kk.
Pumppu-Ansu
Aktiivinen jäsen
Pari kysymystä.
Jostain syystä Shelly-Smartmonitoring.js scripti ei tuota mitään scriptin antamaan web-osoitteeseen. Sivu aukeaa, mutta sarakkeet ovat tyhjät.
Scripti on tuotu spot-hinta.fi kirjastotoiminnolla.
Scriptin alla olevaan laatikkoon kyllä tulee tapahtumat.
Olen muuttanut Common settingsiin Shellyn nimen siksi mitä se minun Shellyssä (Shelly 1 Plus) on (Ohjain 1). Samoin muutin Relaynames kohdassa "Relay A" tilalle oman Shellyn outputin nimen ("Kylpyhuone lattia"). Loput relenimet jätin sellaisenaan sinne (B, C, D).
Shellyn firmis on 1.2.2.
Toinen juttu, kuinka voisin säätää monitorointiscriptissä pelkästään nettiyhteyden tarkistusväliä? Muut tarkistukset voisi mennä alkuperäisen mukaan. Minulle riittäisi vaikka parin tunnin tarkistusväli. Turhaa liikennettä tsekata sitä vähän väliä.
Common settings-kohdassa voisi siis olla oma timeri nettitarkistukselle ja tietysti pientä viilausta scriptiin.
Ilmeisesti tuossa scriptin alussa kohta Timer.set(30000... kertoo scriptin suoritusvälin, onko tuo 30000 siis 30 sekuntia?
Itselläni olen ajastanut kotireitittimen siten että se on yöllä pois päältä, siis silloin ei nettyhteyttä Shellylläkään. Tulee tavallaan turhia bootteja. Tosin muutin vielä BootShellyInMinutes-kohtaan 60:n tilalle 600 eli 10 tuntia saa olla netti poikki ennenkuin boottaa. 10 tuntia ei haittaa yöaikaan kun hintatiedot on kuitenkin tallessa Shellyssä?
Silti tuo erillinen nettitarkastustimeri olisi kiva lisä.
Muuten Shelly pelittää hyvin, eilen asensin käyttöön ja on seurannut kiltisti pörssihintaa. Laitoin sen lämmittämään 18 halvinta tuntia, eli siis 6 kalleinta leikkaa pois.
Shelly-Minimal-Heating.js scipti pyörii ohjaamassa. Siinä on BackupHours-kohdassa kaikkiaan 15 tuntia. Tuota pitää pohtia miten käyttäytyy, jos nettiyhteyden tarkastusväli on tosi pitkä. Siis Shelly ei taida palata normi pörssihintarytmiin ennen seuraavaa nettiyhteystarkastusta?
Jostain syystä Shelly-Smartmonitoring.js scripti ei tuota mitään scriptin antamaan web-osoitteeseen. Sivu aukeaa, mutta sarakkeet ovat tyhjät.
Scripti on tuotu spot-hinta.fi kirjastotoiminnolla.
Scriptin alla olevaan laatikkoon kyllä tulee tapahtumat.
Olen muuttanut Common settingsiin Shellyn nimen siksi mitä se minun Shellyssä (Shelly 1 Plus) on (Ohjain 1). Samoin muutin Relaynames kohdassa "Relay A" tilalle oman Shellyn outputin nimen ("Kylpyhuone lattia"). Loput relenimet jätin sellaisenaan sinne (B, C, D).
Shellyn firmis on 1.2.2.
Toinen juttu, kuinka voisin säätää monitorointiscriptissä pelkästään nettiyhteyden tarkistusväliä? Muut tarkistukset voisi mennä alkuperäisen mukaan. Minulle riittäisi vaikka parin tunnin tarkistusväli. Turhaa liikennettä tsekata sitä vähän väliä.
Common settings-kohdassa voisi siis olla oma timeri nettitarkistukselle ja tietysti pientä viilausta scriptiin.
Ilmeisesti tuossa scriptin alussa kohta Timer.set(30000... kertoo scriptin suoritusvälin, onko tuo 30000 siis 30 sekuntia?
Itselläni olen ajastanut kotireitittimen siten että se on yöllä pois päältä, siis silloin ei nettyhteyttä Shellylläkään. Tulee tavallaan turhia bootteja. Tosin muutin vielä BootShellyInMinutes-kohtaan 60:n tilalle 600 eli 10 tuntia saa olla netti poikki ennenkuin boottaa. 10 tuntia ei haittaa yöaikaan kun hintatiedot on kuitenkin tallessa Shellyssä?
Silti tuo erillinen nettitarkastustimeri olisi kiva lisä.
Muuten Shelly pelittää hyvin, eilen asensin käyttöön ja on seurannut kiltisti pörssihintaa. Laitoin sen lämmittämään 18 halvinta tuntia, eli siis 6 kalleinta leikkaa pois.
Shelly-Minimal-Heating.js scipti pyörii ohjaamassa. Siinä on BackupHours-kohdassa kaikkiaan 15 tuntia. Tuota pitää pohtia miten käyttäytyy, jos nettiyhteyden tarkastusväli on tosi pitkä. Siis Shelly ei taida palata normi pörssihintarytmiin ennen seuraavaa nettiyhteystarkastusta?
Viimeksi muokattu:
Pumppu-Ansu
Aktiivinen jäsen
Mitä, siis ei talleta seuraavan päivän hintoja kun ne tulee klo 14 maissa?
Skripti ei hae ohjausta koko päivälle kerralla vaan se keskustelee serverin kanssa tunneittain miten matka jatkuu.
Tuo on aika outo tarve sulkea netti yöksi. Ei ihan tavallista.
Tuo SmartMonitoring... Olihan skripti pyörimässä? Ei ole raportoitu etteikö loki menisi talteen.