HomeAssistant ja sähköpörssiohjaus

[kurre orava]

Millä tavoin ja keinoin olette toteuttaneet omialla tahoillanne vuorokauden halpojen tuntien hyödyntämistä HA:n ja pörssisähkösovelluksen avulla?

Itse käytän tietysti tuota SHF Max Price jolla rajaan pois kalleimmat tunnit, hintaraja kun ylittyy niin Niben kompressori estetään ja Multiheaterin anturit huijataan jotta sekin menee tauolle. Tuon lisäksi olen vuorokauden 6 edullisimmille tunneille määritellyt säännön joka nostaa Niben pyyntiä pari pykälää.

Mutta tuntuu että yhä tuosta jää paljon potentiaalia hyödyntämättä ja homma toimii ontuen. Niben asteminuuttisäätö asettaa tietty omat rajoituksensa mutta sitäkin saa toki tarvittaessa peukaloitua. Lähinnä hakusessa olisi joku tapa millä varmistaa sen että kalliiden tuntien alkaessa varaaja olisi ladattuna eikä melkein tyhjänä niin kun herkästi käy jos varaajaa on lähdetty lataamaan halpojen tuntien alussa.

Mielestäni tuossa on kyllä kaikki työkalut koossa tuon aikaansaamiseen mutta ehkä en osaa vaan tehdä sellaista sääntöä jonka tuon homman toteuttaisi.

Muoks: saisiko tuohon ympättyä jonkinlaisen trendinhaistelijan eli voisi määritellä vaikkapa "mikäli sähkön hinta on alle Xc/kWh ja trendi X tunnin sisällä on nouseva" niin pyyntiä lisää? Ehkä tuossa olisi tarve lisäksi määritellä nouseeko ramppi millä jyrkkyydellä kun käytännössähän aina on joko laskua tai nousua tuntien välillä?

 

[aurinko_anu]

Millä tavoin ja keinoin olette toteuttaneet omialla tahoillanne vuorokauden halpojen tuntien hyödyntämistä HA:n ja pörssisähkösovelluksen avulla?

Itse käytän tietysti tuota SHF Max Price jolla rajaan pois kalleimmat tunnit, hintaraja kun ylittyy niin Niben kompressori estetään ja Multiheaterin anturit huijataan jotta sekin menee tauolle. Tuon lisäksi olen vuorokauden 6 edullisimmille tunneille määritellyt säännön joka nostaa Niben pyyntiä pari pykälää.

Mutta tuntuu että yhä tuosta jää paljon potentiaalia hyödyntämättä ja homma toimii ontuen. Niben asteminuuttisäätö asettaa tietty omat rajoituksensa mutta sitäkin saa toki tarvittaessa peukaloitua. Lähinnä hakusessa olisi joku tapa millä varmistaa sen että kalliiden tuntien alkaessa varaaja olisi ladattuna eikä melkein tyhjänä niin kun herkästi käy jos varaajaa on lähdetty lataamaan halpojen tuntien alussa.

Mielestäni tuossa on kyllä kaikki työkalut koossa tuon aikaansaamiseen mutta ehkä en osaa vaan tehdä sellaista sääntöä jonka tuon homman toteuttaisi.

Vasta kehitteillä, eli tarvikkeet tilattu, mutta suunnitelma on samankaltainen. Pakkaa mutkistamassa itellä on vielä aurinkopaneelit lisänä.

Tuo sun lähestymistapa kuulostaa hyvältä. Niben SR-kytkimeen signaali shelly dc:llä, joka estää pumpun käynnin kun liian kallista sähköä.

Sitten jos pörssisähköstä saa alle 2 senttiä / kwh ja aurinkopaneleista tuotto ylittää kulutuksen, niin tilapäinen luksus päälle vesivaraajaan jolloin tekee sähkön vastuksella eikä pumpulla. Näin siksi koska ostosähkön hinta menisi aina vähintään 4-kertaiseksi. Pitää vielä ratkaista miten reaaliajassa arvioin tuon ylituoton tuntitasolla netotettuna.

Tällä pääsee jo pitkälle.

 

[Temez]

Millä tavoin ja keinoin olette toteuttaneet omialla tahoillanne vuorokauden halpojen tuntien hyödyntämistä HA:n ja pörssisähkösovelluksen avulla?

Tuossa kesällä herättelin tämmöistä ketjua, mutta taisi olla väärä vuodenaika lämmitysjutuille kesällä:

Foorumilaisten automaatioalgoritmit lämmityksen hintaoptimointiin?

Tätä vastaavaa keskustelua lienee jo monessa muussa ketjussa, mutta on hautautunut esim. muun HomeAssistant-keskustelun sekaan jne. Ajattelin, että voisi olla hyvä jakaa softariippumattomasti kokemuksia siitä, että millaisilla ja miten monimutkaisilla logiikoilla ohjaatte esim. lämmityskuormia...

lampopumput.info

Jos tuonne kerättäisiin ajatuksia? Tosin ketjun ajatus oli olla "merkkiriippumaton" eli ettei siitä tule HA-ketju tai jokin muu vastaava. Mutta toisaalta ei kai etenkin olemassa olevista toteutuksista keskustelu haitanne - onhan ne jollain tekniikalla/ohjelmalla tehty ja taustalla jokin algoritmi.

Itsellä on tämmöinen systeemi (jota jo esittelinkin aiemmin muistaakseni): FMI:ltä lämpötila- ja (auringon) säteilyennuste. Kun seuraavan vuorokauden hinnat tulevat, niin lasketaan lämmitystarve tunneittain suhteessa haluttuun sisälämpötilaan, josta miinustetaan auringon säteilyn tuoma energia. Keskimääräisestä sisälämpötilasta (useita kotiautomaatioon liitettyjä mittareita) katsotaan laskentahetkellä, että ollaanko paljon yli/ali tavoitelämpötilan. Tämä miinustetaan/plussataan sitten lämmitystarpeeseen (mikä huomioi saunanlämmityksestä taloon huokuvaa lisälämpöä). Sitten lämmitystarve katetaan per lämmitin aina halvimmalla mahdollisella (PILP, suorasähkö, varaavien takkojen poltto). Laskenta tapahtuu yhden Template-sensorin takana. Tuloksista saa piirrettyä seuraavanlaisen graafin, jossa oranssi mitattu lämpötila, liila FMI:n lämpötilaennuste (joka tuntuu aina heittävän 1-2 astetta), punainen säteilyennuste, sininen taas energiankulutus per tunti. Keltaiset palkit PILP-lämmitystä ja vihreät suorasähköä.

Varaavien takkojen palkkeja kuvassa ei toki vielä tässä vaiheessa vuotta näy, kun pistin niillekin hinnan per kWh, jotta tulisi oikeasti kustannusoptimoitua kokonaisuutta. Jos tulee lämmiteltyä takkoja fiiliksen vuoksi vaikkei "olisi tarvetta", niin sitten keskimääräinen lämpötila sisällä nousee -> seuraavan lämmitystarpeen arvioinnin yhteydessä lämmitystarve alempi.

Ohjattavana laitteena minulla on vanha Nibe 410P (, jossa nostan/lasken relevirityksellä laitteen näkemää sisälämpötilaa. Näin saan (suhteellisen karkeasti) ohjattua kulutusta. Kun haluan pelkän poistoilmalämpöpumpun pyörivän, niin vastukset kielletty releellä ja säädän sisälämpötilafeikkausta ylös/alas niin, ettei pumppu mene pois päältä, mutta toisaalta ei kattilan lämpötilakaan laske liian alas. Mittailen kattilan alalaidan lämpötilaa ja pyrin pitämään sen tietyssä haarukassa.

Sisälämpötila-anturin feikkaus tuo lisäksi sellaisen failsafe-ominaisuuden, että jos releitä ohjaava laite menee rikki tai sekoaa, niin ei mene -20 pakkasilla kaikki jäähän. NTC-lämpötila-anturi sitten tekee korjausta jossain kohdin, jotta mökki ei mene pakkaselle vaikka pois kotoa ollessa.

Lämmitystarpeen arviointiin keräsin juuri ennen lämmityskautta (jotta pumpun COP:tä ei tarvitse huomioida käyrän sovituksessa) dataa ulkolämpötilasta, sisälämpötilasta, talossa olevien ihmisten lukumäärästä, auringon säteilytehosta sekä sähkönkulutuksesta. Sovitin dataan käyrän ja sain ulos seuraavat parametrit: paljonko ihmiset lämmittävät keskimäärin, paljonko talon lämpökapasiteetti on (eli montako astetta kWh nostaa sisälämpötilaa) ja miten auringon säteily noin keskimäärin lämmittää taloa (tässä tosin pitäisi varmaan lisätä vielä jokin vuodenaikakerroin, kun puut varjostavat taloa eri tavalla eri vuodenaikoina vaikka säteilyteho W/m2 olisikin sama). Näitä parametreja sitten käytetään tuossa lämmöntarpeen laskennassa. Alla sovituksesta kuva, jossa vihreä ja oranssi mitattuja ja vihreä on sovitettu käyrä.

EDIT: Niin, todettakoon vielä, että tämä on itsellä semmoisessa "kehittyy pikkuhiljaa ehtiessä" -moodissa eikä ole testattu vielä kunnolla, kun kylmät ajat vielä tulossa. Ei ollut ajossa 22-23 talvella tämmöistä. Eli tuskin on vielä kaikki palikat ihan viimeisillä paikoillaan.

 

[Temez]

Lähinnä hakusessa olisi joku tapa millä varmistaa sen että kalliiden tuntien alkaessa varaaja olisi ladattuna eikä melkein tyhjänä niin kun herkästi käy jos varaajaa on lähdetty lataamaan halpojen tuntien alussa.

Niin eli ongelmana sinulla on se, että esim. 3 halvinta tuntia ei riitäkään saavuttamaan haluttua loppulämpötilaa?

Jos saat tietoosi varaajan lämpötilan ja tiedät koon, niin siitä pitäisi pystyä laskemaan tarvittava energiamäärä. Sitten tuolla minun tapaisella systeemillä noukkisi kyseisen energiamäärän lämmittimen näkökulmasta halvimmilla tunneilla (kuten itse teen). Tästä tulee "ohjaustaulukko", jota vasten voi sitten tehdä automaatioita. Myös sellaisia, että "jos lämmitystunti alkaa 20min päästä, ala tekemään jotain" (eikös asteminuuttijutuissa pidä tehdä jotain tämän suuntaista?) En ole itse tutustunut asteminuuttisysteemeihin, mutta kai se tosiaan niillä onnistuu jollain tarkkuudella.

 

[kurre orava]

Niin eli ongelmana sinulla on se, että esim. 3 halvinta tuntia ei riitäkään saavuttamaan haluttua loppulämpötilaa?

Jos saat tietoosi varaajan lämpötilan ja tiedät koon, niin siitä pitäisi pystyä laskemaan tarvittava energiamäärä. Sitten tuolla minun tapaisella systeemillä noukkisi kyseisen energiamäärän lämmittimen näkökulmasta halvimmilla tunneilla (kuten itse teen). Tästä tulee "ohjaustaulukko", jota vasten voi sitten tehdä automaatioita. Myös sellaisia, että "jos lämmitystunti alkaa 20min päästä, ala tekemään jotain" (eikös asteminuuttijutuissa pidä tehdä jotain tämän suuntaista?) En ole itse tutustunut asteminuuttisysteemeihin, mutta kai se tosiaan niillä onnistuu jollain tarkkuudella.

Omasta järjestelmästä puuttuu lähinnä "äly" eli tuo ennakoiva osa mikä sinulla tuossa on aika vahvana. Saisin kyllä kolmen halvimman tunnin aikana nykyisen varaajan komeasti täyteen mutta käytännössä tuo kuitenkin ontuu niin kun jo aiemmin totesin. Varaaja ei riitä näin välikeleilläkään koko vuorokaudeksi eikä ole ollut tarkoituskaan riittää mutta monesti käy niin että illalla kun sähkö halpenee niin logiikka nykymuodossaan lataa varaajan täyteen koska sen "horisontti" ulottuu vain klo 24:ään. Seuraava vuorokausi on taas uus tsäänssi niin kun Masa olisi konsanaan sanonut. Ja jos tuon vuorokauden halvimmat tunnit tulevat heti aamuyöstä niin voi olla et jäävät kokonaan hyödyntämättä. Kalliin sähkön aikana ei tehdä lämpöä ellei sisälämpötila putoa alle 21,5C.

Niben oma "smart adationkaan" ei ole kovin viisas, ei tiedä onko kymppi paljon tai vähän eli sellaisena vuorokautena kun keskihinta on vaikka alle sentin niin kannattaisi tietty lämmittää hyötysuhteen ehdoilla. Mutta sellaisena vuorokautena taas kun hinnat heittelehtivät muutamasta sentistä viiteenkymmeneen senttiin niin täytyisi saada automatisoitua se että varaaja ajetaan täyteen oikeaan aikaan juuri ennen kun hinta kipuaa pilviin. Ja tässä yhtenä työkaluna voisi olla se et ennen kun hinnat nousevat käydään nykimässä asteminuutit sopivasti pakkaselle jotta saadaan tuo lataus alkuun. En vaan ole vielä hoksannut millä tuon tekisin.

Varaajassa on kyllä lämpötilamittaukset (2kpl) mutta 800 litraan ei nyt mahdottomia varata. Kunhan saan sen Ovalin mukaan puskuriksi niin siinä on kuution verran lisää vettä, silloin saa jo hiukan varattua vaikkei nyt lataisi ja purkaisi kun joku 7-8 astetta maksimissaan.

 

[tk-]

Omasta järjestelmästä puuttuu lähinnä "äly" eli tuo ennakoiva osa mikä sinulla tuossa on aika vahvana. Saisin kyllä kolmen halvimman tunnin aikana nykyisen varaajan komeasti täyteen mutta käytännössä tuo kuitenkin ontuu niin kun jo aiemmin totesin. Varaaja ei riitä näin välikeleilläkään koko vuorokaudeksi eikä ole ollut tarkoituskaan riittää mutta monesti käy niin että illalla kun sähkö halpenee niin logiikka nykymuodossaan lataa varaajan täyteen koska sen "horisontti" ulottuu vain klo 24:ään. Seuraava vuorokausi on taas uus tsäänssi niin kun Masa olisi konsanaan sanonut. Ja jos tuon vuorokauden halvimmat tunnit tulevat heti aamuyöstä niin voi olla et jäävät kokonaan hyödyntämättä. Kalliin sähkön aikana ei tehdä lämpöä ellei sisälämpötila putoa alle 21,5C.

Niben oma "smart adationkaan" ei ole kovin viisas, ei tiedä onko kymppi paljon tai vähän eli sellaisena vuorokautena kun keskihinta on vaikka alle sentin niin kannattaisi tietty lämmittää hyötysuhteen ehdoilla. Mutta sellaisena vuorokautena taas kun hinnat heittelehtivät muutamasta sentistä viiteenkymmeneen senttiin niin täytyisi saada automatisoitua se että varaaja ajetaan täyteen oikeaan aikaan juuri ennen kun hinta kipuaa pilviin. Ja tässä yhtenä työkaluna voisi olla se et ennen kun hinnat nousevat käydään nykimässä asteminuutit sopivasti pakkaselle jotta saadaan tuo lataus alkuun. En vaan ole vielä hoksannut millä tuon tekisin.

Varaajassa on kyllä lämpötilamittaukset (2kpl) mutta 800 litraan ei nyt mahdottomia varata. Kunhan saan sen Ovalin mukaan puskuriksi niin siinä on kuution verran lisää vettä, silloin saa jo hiukan varattua vaikkei nyt lataisi ja purkaisi kun joku 7-8 astetta maksimissaan.

Lämmönjako näyttelee tässä kokonaisuudessa isoa roolia. Jos on betoniin lattialämmitys ja se on säädetty oikein, niin sinne saa kyllä uppoamaan lämpöenergiaa reilusti. Sitten taas jos on radiaattorit seinässä, niin tarvitaankin jo ihan eri tavalla vesitilavuutta.

Toki molemmissa on tärkeintä, että huonetermostaatit ei ole missään sotkemassa kokonaisuutta. Eli kierto pitää olla kokoajan kaikkialla auki.

 

[kurre orava]

Lämmönjako näyttelee tässä kokonaisuudessa isoa roolia. Jos on betoniin lattialämmitys ja se on säädetty oikein, niin sinne saa kyllä uppoamaan lämpöenergiaa reilusti. Sitten taas jos on radiaattorit seinässä, niin tarvitaankin jo ihan eri tavalla vesitilavuutta.

Toki molemmissa on tärkeintä, että huonetermostaatit ei ole missään sotkemassa kokonaisuutta. Eli kierto pitää olla kokoajan kaikkialla auki.

No, täällä on noita molempia. Lattioihin saa ajettua ongelmitta energiaa varastoon ja voi tuota sisälämpötilaakin nostaa hiukan ennakolta. Termareita ei ole kummassakaan vaan Ouman shunttaa lämpöä noihin.

Mutta täytyisi keksiä se mekanismi joka oivaltaa että nyt, hyvän sään eli halvan sähkön aikana lämmitetään varastoon koska kohta hinta nousee.

 

[Temez]

No olisiko tyhmä idea apusensorilla etsiä halvin 0-X tunnin pätkä vaikka 6h välein seuraavan 12h pätkälle? Haettava tuntimäärä voisi olla vaikkapa jotenkin seuraavan 12h keskimääräiseen ulkolämpötilaan perustuva.

Tuolla saisi aikaan sen, että katsottaisiin vähän matkaa tulevaisuuteen, mutta kuitenkin päivitettäisiin arviota suhteellisen usein, koska varaaja ei ole iso. Eli tässä alla olevassa muuttaisi triggerin ajankohtaa ja start/stop/hours-arvoja sopiviksi (hours ehkä dynaaminen).

template:
  - trigger:
    - platform: time_pattern
        hours: /6
    sensor:
    - name: "Heating"
      availability: '{{ has_value("sensor.shf_data") }}'
      state: 'OK'
      attributes:
       data: >
        {% set start = now() - timedelta(hours=1) %} {# Alku #}
        {% set stop = start + timedelta(hours=12) %} {# Loppu #}
        {% set hours = 5 %} {# Tähän ehkä jokin dynaamisuus? #}
        {% set data = state_attr("sensor.shf_data", "data") | selectattr("Timestamp", "ge", start | as_timestamp) | selectattr("Timestamp", "lt", stop | as_timestamp) | sort(attribute="TotalPrice") %}
        {{ data[0:hours] }}

Ja sitten tämmöinen automaatiotriggeri tyypiltään Template, jolla "lämmitys päälle":

{{ state_attr('sensor.heating', 'data') | selectattr("Timestamp", "eq", now().replace(minute=0, second=0, microsecond=0) | as_timestamp) | list | length > 0}}

Tällä "lämmitys pois päältä":

{{ state_attr('sensor.heating', 'data') | selectattr("Timestamp", "eq", now().replace(minute=0, second=0, microsecond=0) | as_timestamp) | list | length == 0}}

Disclaimer: testaamatonta koodia.

 

[Temez]

Eli tässä alla olevassa muuttaisi triggerin ajankohtaa ja start/stop/hours-arvoja sopiviksi (hours ehkä dynaaminen).

Ja varmaan stop-ajankohtaa voisi sitten koettaa vähän arpoa ulkolämpötilan mukaan? Jos ulkona on +10, niin etsitään halvimmat tunnit 24h ajalta. Jos taas ulkona on -10, niin etsitään halvimmat tunnit seuraavan 12h ajalta jne.

Kunhan tässä heittelen ajatuksia, että tuota voisi suhteellisen pienellä koodauksella viritellä moneen eri suuntaan.

 

[Jullikka]

Eiköpä se jollain opilla löydy tuosta SHF Average price hours sensorin kautta. Eli jos sitä sensorin arvoa muutetaan oletetun lämmitystarpeen mukaan (ulkolämpötila vs. sisälämpötila) ja lämpötilapyyntiä lasketaan/nostetaan oletetun tulevan hinnan mukaisesti verrattuna vallitsevaan hintaan. Tähän toki samalla pitää sotkea eri lämmityslaitteiden hyötysuhteet, joten koodi monimutkaistuu merkittävästi.

 

[tk-]

No, täällä on noita molempia. Lattioihin saa ajettua ongelmitta energiaa varastoon ja voi tuota sisälämpötilaakin nostaa hiukan ennakolta. Termareita ei ole kummassakaan vaan Ouman shunttaa lämpöä noihin.

Mutta täytyisi keksiä se mekanismi joka oivaltaa että nyt, hyvän sään eli halvan sähkön aikana lämmitetään varastoon koska kohta hinta nousee.

Ei kai tuossa auta kun katsoa seuraavan ”lämmitysjakson” keskihinta, ja jos se on kalliimpi niin ylilämmitetään enemmän? Tai toisinpäin jos halvempi?

Tuohon Pörssärin tulevaan logiikkaan on tulossa juuri tuon tyyppistä reagointia, eli minkäkokoisiin blokkeihin väliltä 3-24h se lämmitys vuorokaudessa käyttäjän toiveesta jaetaankaan, niin seuraavan blokin keskihinnan perusteella joko lisätään tai vähennetään lämmitystunteja siihen edelliseen. Ja samaa tehtäisiin myös jos seuraavan blokin keskilämpö muuttuu tarpeeksi. Nuo parametrit on vähän vielä auki miten ne muotoutuu, mutta kunhan saadaan valmiiksi niin avaan tänne sitä vielä tarkemmin.

 

[kurre orava]

Ja varmaan stop-ajankohtaa voisi sitten koettaa vähän arpoa ulkolämpötilan mukaan? Jos ulkona on +10, niin etsitään halvimmat tunnit 24h ajalta. Jos taas ulkona on -10, niin etsitään halvimmat tunnit seuraavan 12h ajalta jne.

Kunhan tässä heittelen ajatuksia, että tuota voisi suhteellisen pienellä koodauksella viritellä moneen eri suuntaan.

Kiitos!

Uskon ihan samalla lailla ettei tuohon mitään monimutkaista koodia tarvita mutta kun itse on todistetusti imbesilli softapuolella niin ei tahdo taipua se vähänkään. Leikkaa ja liimaa sentään sujuu minultakin

 

[kurre orava]

Ei kai tuossa auta kun katsoa seuraavan ”lämmitysjakson” keskihinta, ja jos se on kalliimpi niin ylilämmitetään enemmän? Tai toisinpäin jos halvempi?

Tuohon Pörssärin tulevaan logiikkaan on tulossa juuri tuon tyyppistä reagointia, eli minkäkokoisiin blokkeihin väliltä 3-24h se lämmitys vuorokaudessa käyttäjän toiveesta jaetaankaan, niin seuraavan blokin keskihinnan perusteella joko lisätään tai vähennetään lämmitystunteja siihen edelliseen. Ja samaa tehtäisiin myös jos seuraavan blokin keskilämpö muuttuu tarpeeksi. Nuo parametrit on vähän vielä auki miten ne muotoutuu, mutta kunhan saadaan valmiiksi niin avaan tänne sitä vielä tarkemmin.

Jotain tämäntapaista itselläkin oli mielessä mutta en osannut pukea ajatukset sanoiksi noin selkeästi. Jos tuohon saisi mukaan vielä samojen jaksojen lämpötilaennusteet niin uskon että sillä pääsisi jo aika pitkälle.

 

[tk-]

Jotain tämäntapaista itselläkin oli mielessä mutta en osannut pukea ajatukset sanoiksi noin selkeästi. Jos tuohon saisi mukaan vielä samojen jaksojen lämpötilaennusteet niin uskon että sillä pääsisi jo aika pitkälle.

Niin meinaat, että vielä hienosäätää tuulisuuden ja auringon perusteella?

 

[kurre orava]

Niin meinaat, että vielä hienosäätää tuulisuuden ja auringon perusteella?

No, enemmän tuo oli ikään kun itselleni muistiinpano siitä että ainakin ulkolämpötila täytyisi saada lopulliseen yhtälöön mukaan. Teillä tuo taitaa kuulua siihen jo ennestään. Toki esimerkiksi aurinko vaikuttaa meillä paljonkin siihen kuinka paljon lisä lämmitystä talo tarvitsee mutta eiköhän riittävä tarkkuus tulisi jo ihan lämpötilaennusteen avulla.

 

[tk-]

No, enemmän tuo oli ikään kun itselleni muistiinpano siitä että ainakin ulkolämpötila täytyisi saada lopulliseen yhtälöön mukaan. Teillä tuo taitaa kuulua siihen jo ennestään. Toki esimerkiksi aurinko vaikuttaa meillä paljonkin siihen kuinka paljon lisä lämmitystä talo tarvitsee mutta eiköhän riittävä tarkkuus tulisi jo ihan lämpötilaennusteen avulla.

Niin aivan! Luulin sen tuossa jo maininneeni niin sillä ihmettelin. Ha:ssa onko jopa oletuksena se yr.no -sääennuste, niin siitä saa kyllä sen jakson lämpötilakin aina sitten tietoon.

 

[jämä67]

Hienoa, että on herätty tekemään uusia virityksiä vielä ennen lämmityskautta! Asentelin kanssa temezin uusimman version eilen ja hienosti näyttää pelaavan. Vähän hankaluuksia oli uuden ominaisuuden, halpojen tuntien haun käyttöönotossa githubin ohjeilla, mutta kun selasin foorumin viestejä taaksepäin, niin kyllä se sitten selkeni minullekkin.

Hienosti tosin se vanhakin käytännössä palasi, eikä minulla ollut edes ongelmia sen apex chartin kanssa. Se voi vaikuttaa, että minulla oli hinnassa mukana siirto ja vero, joten ei ikinä käynyt pakkasella. Vähän kipuja aiheutti jossain kohtaa se HA päivitys, mutta siihenkin löytyi foorumin tietäjiltä nopeasti apu. Tästä viisastuneena täytyy jättää HA päivitykset tekemättä pahimpien talvikuukausien aikana.

 

[Temez]

Automaatio päätti, että aamulta ja iltapäivältä leikataan lämmitykset pois joiltakin tunneilta. Nyt jänskätään, että paljonko sisälämpötila heiluu, kun lämpöä koetetaan ensi yön aikana puskea taloon rakenteisiin väkipakolla (vihreät palkit). Päivällä PILP sitten koettaa välillä vähän tukea lämmitystä.

Innostunut fiilis siis, kun nyt alkaa tulla niitä hetkiä, että koodausharrastus sekä talon lämpökapasiteettien jne. mallinnus saattavat oikeasti kantaa hedelmää. EDIT: ettei siis ole pelkäksi ajanhukaksi mennyt

 

[Ninnannunna]

Automaatio päätti, että aamulta ja iltapäivältä leikataan lämmitykset pois joiltakin tunneilta. Nyt jänskätään, että paljonko sisälämpötila heiluu, kun lämpöä koetetaan ensi yön aikana puskea taloon rakenteisiin väkipakolla (vihreät palkit). Päivällä PILP sitten koettaa välillä vähän tukea lämmitystä.

Innostunut fiilis siis, kun nyt alkaa tulla niitä hetkiä, että koodausharrastus sekä talon lämpökapasiteettien jne. mallinnus saattavat oikeasti kantaa hedelmää. EDIT: ettei siis ole pelkäksi ajanhukaksi mennyt
katso liitettä 88937

Minkälainen logiikka sulla tuossa on taustalla?

 

[Temez]

Minkälainen logiikka sulla tuossa on taustalla?

Tarkemmin avattu tässä viestissä: https://lampopumput.info/foorumi/th...a-sähköpörssiohjaus.34446/page-17#post-598891

Mutta lyhyesti: ulkolämpötila- ja säteilyennusteet FMI:ltä, joista lasketaan arvioitu energiantarve tunneittain + staattinen energiantuotto hupisähkölaitteista (suhteellisen tasainen osuus läpi vuoden) ja ihmisten tuottama energia. Hintatiedot SHF/spotprices2ha-paketilla.Template-sensorissa lasketaan hinta per tuotettu kWh (huomioiden siis COP) taulukkoon per lämmitin (minulla tällä hetkellä PILP, suorasähkö, varaavat takat). Sitten tuosta taulukosta valitaan niin monta halvinta lämmitintuntia (voi siis olla eri lämmittimiä), että ennustettu energiantarve täytetään.

 

[ederopaa]

Heips! Lyhyesti kiireisille; uusi beta-versio tarjolla: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft

Tässä olisi nyt isolta osalta uudelleenkirjoitettu "Beta-versio" pitkän hiljaiselon jälkeen (siviilielämä vaatinut paljon, joten ei ole näihin harrastuksiin oikein ehtinyt). En vielä työntänyt tätä tuonne Github master-haaraan, sillä ajattelin kysäistä hiukan ajatuksia/kommentteja, että vaikuttaako hyvältä teidän mielestänne: https://github.com/T3m3z/spotprices2ha/tree/v0.2.0-draft

Pakettia on kirjoitettu nyt suurelta osin uusiksi, jotta toimisi paremmin (ainakin toivottavasti) esim. talviajan alkaessa. Vähemmän ainakin virheitä tulee logille nyt. Käytön puolesta pitäisi olla aika vähän vaihtunut. Ehkä jotain kuvaajien koodeja joutuu tekemään uudestaan, sillä en ihan 100% taaksepäin yhteensopivuutta voi taata.

Suurin muutos on se, että jatkossa voit kysellä scriptillä kysymyksen "anna halvin 2h yhtäjaksoinen pätkä tänään kello 15 ja 22". Samalla katosi vanha "SHF Cheapest Period Start", jotta ei ole päällekkäisiä ominaisuuksia.

Pikaohjeet tämän käyttöön:
1. Luo uusi aloitusajankohdan helpperi: Settings->Devices&Services->Helpers->Create Helper->"Date and/or time" + valitse "Time".
2. Tee uusi automaatio tämän esimerkin pohjalta (https://github.com/T3m3z/spotprices2ha/blob/v0.2.0-draft/example-of-cheapest-period-automation.yaml). Vaihda entity_id-riville kohdassa 1 luodun helperin ID. määrittele "start", "end" ja "hours"-riveille halutut arvot (today_at('15:00') voi esimerkiksi olla hyvä, lisäesimerkkejä täältä: https://www.home-assistant.io/docs/configuration/templating/#time). Määrittele itse, että milloin tämä automaatio ajetaan eli milloin laskenta tapahtuu.
3. Käytä kohdassa 1 luotua helperiä jonkin automaation triggerinä:
katso liitettä 88282

Olen ohjaillut auton latausta 0.1.11 versiolla hyödyntäen SHF cheapest period start. Kun päivitin 0.2.1 versioon ja yritin noudattaa gitin ja näitä ohjeita, niin ei oikein onnistu. Löytyykö vielä joku tarkempi kuvaus mitä kaikkea pitää tehdä? Helpperin tein ja uuden automaation, jne... mutta ei oikein löydä tunteja...ja "SHF Cheapest period start" on harmaana. Varoituksessa lukee "input_datetime ei enää tarjoa tätä kohdetta. Jos kohde ei ole enää käytössä, poista se asetuksista."

Edit: Hieman vastailen itselleni. Laitoin tosiaan tuonne scriptiin start- ja stop-ajat. Helpperiin tulee aloitusaika. Varsinainen latausautomaatio laukeaa kun aikahelperin aika koittaa.

 

[Temez]

Edit: Hieman vastailen itselleni. Laitoin tosiaan tuonne scriptiin start- ja stop-ajat. Helpperiin tulee aloitusaika. Varsinainen latausautomaatio laukeaa kun aikahelperin aika koittaa.

Saitko siis toimimaan vai jäikö vielä ongelmia? Koetan kuitenkin tähän alle kuvata vähän ohjeen tynkää kuvankaappauksin.

1. Helperin luonti: Settings -> Devices & Services -> Helpers -> Button: Create Helper -> Date and/or time
   
   
2. Halvimman ajan laskenta: Settings -> Automations & scenes -> Button: Create automation -> Create new automation
   1. Ylälaidasta kolme pistettä -> Edit in YAML
   2. Kopioi kenttään täältä esimerkkikoodi: https://github.com/T3m3z/spotprices2ha/blob/main/example-of-cheapest-period-automation.yaml
   3. Ylälaidasta kolme pistettä -> Edit in visual editor. Pitäisi näyttää tältä:
      
      
      
   4. Vaihda haluamasi triggeri tilalle.
   5. Muuta ensimmäistä scriptiä niin, että siinä on haluamasi alkuajankohta (huom! kannattaa miettiä suhteessa triggeriin), loppuajankohta ja tuntimäärä.
      1. Tämä esimerkiksi kello 16:55 triggeröitynä hakisi halvimman 2h jakson 17-21 väliltä.
         
         
      2. Tämä taas hakee halvimman pätkän seuraavan 12h ajalta aloittaen seuraavasta tasatunnista:
         
      3. Timedeltaa voi myös yhdistellä today_at-pätkiin. Tällä saa halvimman 3h pätkän alkaen seuraavasta tasatunnista huomiseen kello 18 asti. Huom! Jos huomisen hintoja ei ole saatavilla, niin sitten koodi palauttaa halvimman 3h pätkän saatavilla olevasta datasta.
         
   6. Lopuksi korvaa viimeisessä kohdassa haluamasi helper target -> entity_id -kohtaan. Tässä esimerkissä HomeAssistant ehdottaa oikeaa entity_id:tä, kun alkaa kirjoittamaan input_datetime.wash...
      
   7. Tallenna/save
3. Nyt on helper olemassa ja automaatio, joka tietyn triggerin kohdatessaan laskee halutun pituisen pätkän alkuajankohdan. Viimeinen osuus on jonkin toimenpiteen käynnistys toisella automaatiolla. Sen voi tehdä näin:
   

Tässä siis nyt kuvankaappauksin vähän ohjeentynkää. Toivottavasti saat toimimaan.

Tässä oli vähän ajatuksena, että näin tehtynä voit tehdä erilaisia helpereitä eri tarkoituksiin vaikka 10kpl etkä ole sidottu yhteen. Ja toisaalta jokainen voi määrittää halutun ajanjakson, jolta hinta haetaan. Jotkut haluavat sen olevan vuorokausi alkaen keskiyöstä, toinen vuorokausi alkaen kello15, kolmas taas 6h välein jne. riippuen käyttötarkoituksesta.

 

[ederopaa]

Saitko siis toimimaan vai jäikö vielä ongelmia? Koetan kuitenkin tähän alle kuvata vähän ohjeen tynkää kuvankaappauksin.

1. Helperin luonti: Settings -> Devices & Services -> Helpers -> Button: Create Helper -> Date and/or time
   katso liitettä 88983
2. Halvimman ajan laskenta: Settings -> Automations & scenes -> Button: Create automation -> Create new automation
   1. Ylälaidasta kolme pistettä -> Edit in YAML
   2. Kopioi kenttään täältä esimerkkikoodi: https://github.com/T3m3z/spotprices2ha/blob/main/example-of-cheapest-period-automation.yaml
   3. Ylälaidasta kolme pistettä -> Edit in visual editor. Pitäisi näyttää tältä:katso liitettä 88984
      
   4. Vaihda haluamasi triggeri tilalle.
   5. Muuta ensimmäistä scriptiä niin, että siinä on haluamasi alkuajankohta (huom! kannattaa miettiä suhteessa triggeriin), loppuajankohta ja tuntimäärä.
      1. Tämä esimerkiksi kello 16:55 triggeröitynä hakisi halvimman 2h jakson 17-21 väliltä.
         katso liitettä 88985
      2. Tämä taas hakee halvimman pätkän seuraavan 12h ajalta aloittaen seuraavasta tasatunnista:katso liitettä 88986
      3. Timedeltaa voi myös yhdistellä today_at-pätkiin. Tällä saa halvimman 3h pätkän alkaen seuraavasta tasatunnista huomiseen kello 18 asti. Huom! Jos huomisen hintoja ei ole saatavilla, niin sitten koodi palauttaa halvimman 3h pätkän saatavilla olevasta datasta.katso liitettä 88988
   6. Lopuksi korvaa viimeisessä kohdassa haluamasi helper target -> entity_id -kohtaan. Tässä esimerkissä HomeAssistant ehdottaa oikeaa entity_id:tä, kun alkaa kirjoittamaan input_datetime.wash...katso liitettä 88989
   7. Tallenna/save
3. Nyt on helper olemassa ja automaatio, joka tietyn triggerin kohdatessaan laskee halutun pituisen pätkän alkuajankohdan. Viimeinen osuus on jonkin toimenpiteen käynnistys toisella automaatiolla. Sen voi tehdä näin:katso liitettä 88990

Tässä siis nyt kuvankaappauksin vähän ohjeentynkää. Toivottavasti saat toimimaan.

Tässä oli vähän ajatuksena, että näin tehtynä voit tehdä erilaisia helpereitä eri tarkoituksiin vaikka 10kpl etkä ole sidottu yhteen. Ja toisaalta jokainen voi määrittää halutun ajanjakson, jolta hinta haetaan. Jotkut haluavat sen olevan vuorokausi alkaen keskiyöstä, toinen vuorokausi alkaen kello15, kolmas taas 6h välein jne. riippuen käyttötarkoituksesta.

Kiitos @Temez! tämä selvensi...myös ajatusta taustalla. Kyllä sain jotenkin toimimaan. Oisko liukureita ja aikakentistä mitään ideaa noissa automaatioiden tekemisessä vai onko parempi tehdä staattisia settejä?

 

[amnk]

Toimiiko muilla control factorit tänään? Täällä on puolesta yöstä asti näyttänyt "Unavailable". {{ state_attr("sensor.shf_control_factor_1", "today_values") }} sanoo "Null" (tosin en ole ihan varma, pitäisikö tuon mitään näyttääkään).

Lisätään vielä, että {{ state_attr("sensor.shf_control_factor_1", "today_values") is iterable }} vastaa sekin False.

 

[heebo1974]

Toimiiko muilla control factorit tänään? Täällä on puolesta yöstä asti näyttänyt "Unavailable". {{ state_attr("sensor.shf_control_factor_1", "today_values") }} sanoo "Null" (tosin en ole ihan varma, pitäisikö tuon mitään näyttääkään).

Lisätään vielä, että {{ state_attr("sensor.shf_control_factor_1", "today_values") is iterable }} vastaa sekin False.

Sekoaisiko se tämän päivän aika poikkeuksellisesta hinnasta ?

 

[amnk]

Sekoaisiko se tämän päivän aika poikkeuksellisesta hinnasta ?

Jos joo, niin hyvä, että nyt eikä vaikka kolmen kuukauden päästä. Tuli ainakin hyvä oppitunti siitä, miten tällaiset tilanteet kannattaa ottaa säädöissä huomioon. Nyt kävi siis niin, että ilpin lämmityspyynti tipahti oletusarvoon 16 astetta loppuyön ajaksi. Tulevaisuudessa onneksi enää ei.

 

[Ninnannunna]

Toimiiko muilla control factorit tänään? Täällä on puolesta yöstä asti näyttänyt "Unavailable". {{ state_attr("sensor.shf_control_factor_1", "today_values") }} sanoo "Null" (tosin en ole ihan varma, pitäisikö tuon mitään näyttääkään).

Lisätään vielä, että {{ state_attr("sensor.shf_control_factor_1", "today_values") is iterable }} vastaa sekin False.

Eipä toimi täälläkään.

 

[Temez]

Koodikukkanen. Tämän päivän maksimihinta oli 0 €/kWh, joka kyseisen sensorin unavailable-ehdossa tulkittiin niin, että tietoja ei ole saatavilla.

Laitoin fiksiä versiona 0.2.3: https://github.com/T3m3z/spotprices2ha/

Jos joku ehtisi vielä tänään kokeilemaan (päivän maksimin ollessa 0€/kWh), niin tulisi varmistus, että toimii.

 

[Temez]

Muitakin pieniä parannuksia tullut. Versio 0.2.1 toi validoinnin SHF Price2 start/stoppiin. Nyt niitä ei saa vahingossa laitettua väärinpäin. Versio 0.2.2 taas alkoi huomioida SHF Rank Now:ssa Price1/Price2-muutokset. Versio 0.2.3 oli nyt korjaus tähän SHF Control Factor -ongelmaan.

Version	New features/notes
0.2.3	Fix for "SHF Control Factor" being unavailable if today max/min price is 0
0.2.2	"SHF Rank now" sensor takes now into account transmission fees etc configured using SHF Price 1/2
0.2.1	Add validation automation for SHF Price2 start/stop

 

[Ninnannunna]

Koodikukkanen. Tämän päivän maksimihinta oli 0 €/kWh, joka kyseisen sensorin unavailable-ehdossa tulkittiin niin, että tietoja ei ole saatavilla.

Laitoin fiksiä versiona 0.2.3: https://github.com/T3m3z/spotprices2ha/

Jos joku ehtisi vielä tänään kokeilemaan (päivän maksimin ollessa 0€/kWh), niin tulisi varmistus, että toimii.

Jep, näyttää pelaavan ainakin tuo +-1 nyt.

 

[Temez]

HomeAssistant pääsi taas hommiin. Huomisen osalta kovasti optimoitavaa. Nyt jännätään, että keitynkö elävältä ensi yönä ja jäädynkö päivällä. Polttopuita scripti ei pyytänyt polttamaan yhtään kuitenkaan:

 

[Mikusban]

Mitenkä configuration.yaml tulisi muokata että saan chartin näkyviin?
Ennestää on tuo packages: !include_dir_named packages käytössä ja pitäisi saada lisättyä pack_1: !include spot-price.yaml.

homeassistant:
packages: !include_dir_named packages
#packages:
#pack_1: !include spot-price.yaml

 

[Temez]

Mitenkä configuration.yaml tulisi muokata että saan chartin näkyviin?
Ennestää on tuo packages: !include_dir_named packages käytössä ja pitäisi saada lisättyä pack_1: !include spot-price.yaml.

homeassistant:
packages: !include_dir_named packages
#packages:
#pack_1: !include spot-price.yaml

Configuration.yamliin ei välttämättä tarvitse tehdä mitään muutoksia, jos sinulla on jo tuo kansio "packages" olemassa. Koeta tiputtaa tiedosto sinne, mutta muuta tiedostonimeksi spot_price.yaml (tässä oli jokin juttu, että include_dir_named ei vissiin tykkää alkuperäisestä nimeämisestä).

 

[Mikusban]

No niin, kiitos! Kaikenlaista ehdin kokeilla mutta tosiaankin tiedoston nimen vaihto auttoi. Olisihan sen pitänyt ymmärtää virhe ilmoituksestakin...

 

[kurre orava]

Pystyykö olemassa olevilla parametreilla ja apureilla tekemään seuraavanlaista ohjausta eli lämmitys sallittaisiin X määrällä vuorokauden tunteja (tuo hoitunee RANK toiminnolla sinänsä) mutta jos kyseessä on halpa vuorokausi jossa kaikkien tuntien hinnat vaikka alle 5c/kWh niin silloin lämmitystä voisi sallia koko vuorokaudelle.

Nyt olen manuaalisesti siirtänyt rajan mikä on sallittu hinta jolla voidaan vielä lämmittää mutta tuo vaatii tietty sen että käy koneella aina jossain vaiheessa iltapäivällä/illalla ja tarkkailee seuraavan päivän hinnat. Vuorokauden halvimmat 6 tuntia olen sit taas buustannut lämmitystä hiukan käyrään sivuttaissiirtämällä. tuota buustaustakin voisi jättää pois sellaisena vuorokautena kun hinnat ovat kautta linjan matalia. Kysymys on vaan se millä opettaa HA:lle se on kymppi paljon tai vähän?

 

[Pretor]

Pystyykö olemassa olevilla parametreilla ja apureilla tekemään seuraavanlaista ohjausta eli lämmitys sallittaisiin X määrällä vuorokauden tunteja (tuo hoitunee RANK toiminnolla sinänsä) mutta jos kyseessä on halpa vuorokausi jossa kaikkien tuntien hinnat vaikka alle 5c/kWh niin silloin lämmitystä voisi sallia koko vuorokaudelle.

Nyt olen manuaalisesti siirtänyt rajan mikä on sallittu hinta jolla voidaan vielä lämmittää mutta tuo vaatii tietty sen että käy koneella aina jossain vaiheessa iltapäivällä/illalla ja tarkkailee seuraavan päivän hinnat. Vuorokauden halvimmat 6 tuntia olen sit taas buustannut lämmitystä hiukan käyrään sivuttaissiirtämällä. tuota buustaustakin voisi jättää pois sellaisena vuorokautena kun hinnat ovat kautta linjan matalia. Kysymys on vaan se millä opettaa HA:lle se on kymppi paljon tai vähän?

Mulla ulkolämpötila ohjaa sallittua Rank-tuntien määrää omassa automaatiossaan joka on yksinkertaisesti vain litania jos/sitten -laukaisimia. Aina kun ulkolämpötila muuttuu, niin laukeaa joku jos/sitten -ehto ja asettaa sen hetkisen lämpötilan mukaisen sallitun Rankin. Erillinen automaatio sit käynnistelee VILPin sen mukaan onko Rank sallittu, vai ei, tai onko sähkön hinnan mukaan asetettu raja sallittu. Eli käytetään molempia Rank ja Price clear/detected attribuutteja.
Ei tuo täydellinen ohjaus ole. Eilen oli lämpötila nollan tienoilla (aamun) ja kaikki kalleimmat tunnit (niin ku monesti yleensä) osui 7-15 välille ja sähköki tosiaan oli kallista. Samaan aikaan sallittu Rank oli korkeimmillaan 19 ja pienimmillään 17 ja sehän tiesi sitä, että lämmitys oli just sen 7h pois päältä. Sisälämpö tippui 2'c, joten illalla paikattiin vajetta halvemmilla tunneilla.
Mulla on tällä hetkellä -5'c kaikki tunnit sallittu ja tuossa 0'c 19. Menee portaittain tuosta -5'c alkaen 1-2'c hypyin.
Jos sähkö on "halpaa" (asetetun rajan alle), niin silloinhan Rankia ei huomioida ollenkaan, vaan on jatkuva käyntilupa.

 

[haraldh]

BONUS: Hintojen visualisointi
EDIT: alkuperäisen postauksen jälkeen @aol paranteli kuvaajakoodia. Uusin versio täällä: https://github.com/T3m3z/spotprices2ha/

Tämä ei ole ihan täydellinen, mutta jos haluat visualisoida hinnat, niin tässä jotain ajatuksia (alkuperäinen toteutus täällä: https://www.creatingsmarthome.com/i...d-how-to-automate-devices-for-cheapest-hours/ ).

1. Lataa tiedosto apexcharts-card.js täältä: https://github.com/RomRider/apexcharts-card/releases/tag/v2.0.1
2. Mene File Editorilla Home Assistantin kansioon /config (eli sinne missä configuration.yaml on).
3. Tee kansio www ja lisää apexcharts-card.js tuohon kansioon.
4. Home Assistantissa mene etusivulle, ylälaidasta kolme pistettä, Edit Dashboard, uudestaan kolme palluraa ja Manage Resources.
5. Alhaalta Add Resource. Syötä URL:ksi /local/apexcharts-card.js ja valitse "JavaScript Module". Paina Updatea.
6. Mene takaisin etusivulle ja varmista, että olet muokkaustilassa (ylälaidasta kolme pistettä, Edit Dashboard). Paina alhaalta Add Card, etsi hakusanalla "Manual" ja valitse ainoa esille tullut vaihtoehto. Syötä vasemmalle seuraava koodi:

7. type: custom:apexcharts-card
   graph_span: 48h
   header:
     title: Electricity price (c/kWh)
     show: true
   span:
     start: day
   yaxis:
     - min: 0
       decimals: 2
       apex_config:
         forceNiceScale: true
   now:
     show: true
     label: Now
   series:
     - entity: sensor.electricity_price
       type: column
       float_precision: 3
       data_generator: |
         return entity.attributes.data.map((d, index) => {
           return [new Date(d["DateTime"]).getTime(), entity.attributes.data[index]["PriceWithTax"]];
         });

8. Paina Save ja nauti alla olevan kuvan mukaisesta graafista.

Yritin lisätä tämän, ensimmäinen kynnys oli että pitää laittaa päälle "Advanced mode" jotta pääsee lisäämään 5. kohdassa Resource. Tämän saa päälle omasta profiilista klikkaamalla alavasemmalta omaa nimeä.

Sitten spot-price.yaml:in tarjoamat nimet ovat vähän erilaisia, ja jos nyt ymmärsin oikein niin yllä olevan esimerkin sensor.electricity_price pitääkin nyt olla sensor.shf_electricity_price ja tällä lähti kuvaaja toimimaan ja näkymään.

Lisäisin vielä että oletuksena ensimmäinen dashboard ei ole muokattavissa, ja sinne ilmestyy oletuksena kaikki uudet sensorit jne. joten olisi hyvä lisätä ohjeisiin että tekee tälle pörssisähköjutulle vaikka oman dashboardin jonka voi muokata.

Kiitokset kaikille näistä, olen vasta asentanut HA:n ja ihan kivalta näyttää. fissio.fi on oikeasti ohjaamassa ainakin toistaiseksi, mutta appiukolle sai HA:n asennettua jotta hän pääsee näkemään oikeasti mielenkiintoisia käppyröitä samassa kuvaajassa kuten ILP:jen sähkönkulutus vs. sisä- ja ulkolämpötlat.

edit: Huomasin sitten että githubissa oli uudemmat ohjeet ja uudempaa koodia. Voisi ehkä muokata niitä ketjun ensimmäisiä viestejä niin että osoittavat vain ja ainoastaan uusimpaan versioon ja ohjeeseen?

 

[haraldh]

Koitin selailla ketjua läpi, onko jossain selostettu mitä nämä SHF Max Rank allowed, SHF Average price slideri jne tarkoittavat ja mitä ne tekevät? Ts. dokumentaatiota miten tätä integraatiota voi käyttää?

Jos aloittaisi vaikka sillä että saisin ohjattu LVV:n kahdelle halvimmille tunneille vuorokaudesta, voisiko joku selostaa miten tekee?

Seuraava esimerkki voisi olla ilmalämpöpumpun pyyntilämpötilan säätö arvoon x vuorokauden Z halvimmalle tunneille, ja arvoon y sitä kalliimmalle tunneille. Onko mahdollista säätää arvoa Z ennustetun ulkolämpötilan mukaan? Näillä saisi jo melkein fission korvattua tällä. Täällä saa ainakin apua.

 

[kurre orava]

Koitin selailla ketjua läpi, onko jossain selostettu mitä nämä SHF Max Rank allowed, SHF Average price slideri jne tarkoittavat ja mitä ne tekevät? Ts. dokumentaatiota miten tätä integraatiota voi käyttää?

Jos aloittaisi vaikka sillä että saisin ohjattu LVV:n kahdelle halvimmille tunneille vuorokaudesta, voisiko joku selostaa miten tekee?

Seuraava esimerkki voisi olla ilmalämpöpumpun pyyntilämpötilan säätö arvoon x vuorokauden Z halvimmalle tunneille, ja arvoon y sitä kalliimmalle tunneille. Onko mahdollista säätää arvoa Z ennustetun ulkolämpötilan mukaan? Näillä saisi jo melkein fission korvattua tällä. Täällä saa ainakin apua.

Tuossa noi oli hiukan avattu ja havainnollistettu (selaa sivulla alaspäin kunnes tulee "Automation ideas":

spotprices2ha/README.md at main · T3m3z/spotprices2ha

Simple copy-paste approach to fetch data from api.spot-hinta.fi (see https://spot-hinta.fi) to Home Assistant. Includes simple sensors and UI elements to ease automation work. - T3m3z/spotprices2ha

github.com

Mutta joo, myönnän auliisti että itsekin kävisin mieluusti sellaisella tukiopetustunnilla jossa nämä mahdollisuudet avattaisiin hiukan seikkaperäisemmin jotta tuosta saisi kaiken mahdollisen hyödyn irti.

 

[haraldh]

Lukaisin tuon, mutta millainen datarakenne tuo SHF Max Rank on? Muistan lukeneeneni että tunnit hintajärjestyksssä. Alkaako nollasta vaiko ykkösestä? Onko 1 halvin vai kallein?

Keksin tuossa välissä että tuo tehdään luomalla automaation, Settings -> Automations, Create Automation.

Ehkä joku screenshot missä näytetään miten? Onko tämä esimerkiksi oikein mun LVV-esimerkissä;