Aurinkoennusteeseen tuo laskenta perustuu, haetaan nykyisellään forecast.solar -palvelusta. Ei sillä toki täysin nollanetotukseen päästä, mutta ei tuossa isompaa heittoa ole tuntitasolla ollut ennuste vs toteuma.
Pörssisähköohjaus made easy
- Keskustelun aloittaja tk-
- Aloitettu
Sattui pieni dns-fiba kun poistin legacya sotkemasta hommaa. Korjattu nyt.
Pahoittelen lyhyttä katkoa, ohjauksiin tällä tuskin on ollut vaikutusta.
Viimeksi muokattu:
- Liittynyt
- 14.04.2022
- Viestejä
- 253
En ole vielä Pörssärin käyttäjä, joten en tiedä, vaikka olisi Pörssärin perusominaisuus tai kehitetty juuri tällaista varten, mutta onnistuuko Pörssärin kanssa esimerkiksi neljän tai viiden halvimman yösähkötunnin hakeminen? Yösähköaika vaikka klo 23-07 ja tältä väliltä haetaan esimerkiksi neljän halvimman peräkkäisen tunnin jakso (keskiarvoisesti halvin nelituntinen pätkä). Ajattelin, josko tälläista kytkentämahdollisuutta voisi soveltaa sähköauton lataukseen älyttömän sähköautolaturin, kontaktorin ja Shelly-releen kanssa.
- Liittynyt
- 19.11.2016
- Viestejä
- 4 240
Saa, voit valita x määrän halvimpia tunteja halutun aikarajan sisällä eli oletuksena koko vuorokausi mutta sieltä voi täpätä ne tunnit jotka haluaa ohjauksen olevan voimassa.
- Liittynyt
- 14.04.2022
- Viestejä
- 253
Ja ovat nimanomaisesti peräkkäiset tunnit, eli halvin neljän tunnin keskiarvo valitulta ajanjaksolta?
- Liittynyt
- 31.08.2020
- Viestejä
- 140
Minusta tämmöstä "etsi halvin 4h yhtenäinen jakso" ei ole olemassa Pörssärissä.
Tilastollisesti 02-06 osuu aika hyvin. Tuo onnistuu myös Pörssärillä.
- Liittynyt
- 19.11.2016
- Viestejä
- 4 240
Piti tarkastaa, ei ole vaihtoehdoissa valintaa että saisi peräkkäiset tunnit.
Mutta onko joku syy miksi pitää olla peräkkäiset tunnit? Yleensähän ne yöllä ovat peräkkäin kyllä.
- Liittynyt
- 14.04.2022
- Viestejä
- 253
Kiitos tarkastamisesta. Ajatuksena kun oli sähköauton lataaminen, niin en tiedä, miten auto suhtautuu katkolatauksiin? Välittääkö se mitään, vai luuleeko, että laturissa on virhetilanne, eikä suostu enää jatkamaan latausta uudestaan ennen latauskaapelin pois käyttämistä.
- Liittynyt
- 14.04.2022
- Viestejä
- 253
Okei. Yleensä toki halvimmat tunnit osuvat noin, jolloin syntyy yhtenäinen jakso.
Telaketju88
Tukijäsen
- Liittynyt
- 27.02.2017
- Viestejä
- 742
Ei välitä mitään.
Tällä hetkellä ohjaukset menee aina vuorokauden sisällä, eli pitää käytännössä valita aikaväli 00-07. Tuo yhtämittainen halvin jakso oli ajatuksena aiemmin tehdä, mutta ei ehditty tuohon vanhaan versioon tehdä ja nyt ollaan jo kovasti uutta tekemässä. Sinne se on kyllä tulossa, mutta nykyisellään valitsee vain x määrän halvimpia tunteja, eli välttämättä ei ole yhtämittainen.
Autoa ladattaessa etenkin talvella tuo on järkevämpää yhtämittaisena, koska akkua on turha päästää välissä jäähtymään. Ulkolämmön ollessa reilusti plussan puolella ei sinällään ole niin merkitystä, ja tuossa voisi ehkä olla paikkansa myös lämpötilan huomioon ottamiselle jotta voidaan antaa "pätkäladata" lämpöiseen aikaan ja yhtämittainen jakso sitten kylmempään aikaan.
- Liittynyt
- 14.04.2022
- Viestejä
- 253
Kehitysajatus kuulostaa hyvältä. Täytyy kokeilla ottaa Pörssäri käyttöön, kun latausasema saadaan asennettua.
Minkälainen latausasema on tulossa? Osa niistä kai vastaanottaa myös ulkoista potentiaalivapaata ohjausta, niin sitä voi toteuttaa esimerkiksi Shellyllä. Osassa voi olla jopa omia rajapintojaan netin yli, ja semmoisiakin voidaan yrittää jatkossa tuoda mukaan. Itse ohjaan brutaalisti sähköä katkomalla, mutta latausasemana on "tyhmä" Ellin seat-brändätty boksi, niin siinä ei oikein muutakaan vaihtoehtoa jää. Tosin tilasin siihen älyä tilalle toisen boksin muodossa, ja tarkoitus on katsoa voisiko sitä ohjata jotenkin lan-yhteyden kautta sitten jatkossa sähköjä katkomatta.
- Liittynyt
- 14.04.2022
- Viestejä
- 253
Laturiksi on tulossa WALLe-laturi. En ole kovinkaan tutustunut laturin ominaisuuksiin. Sen vain tiedän, että kyseessä ei ole mikään älylaturi.
Edit. En olisi ehkä itse kyseistä laturia hankkinut, vaan olisin ottanu älykkäämmän laturin, mutta kyseinen latauslaite tulee sähköautokaupan kylkiäisenä.
Edit. En olisi ehkä itse kyseistä laturia hankkinut, vaan olisin ottanu älykkäämmän laturin, mutta kyseinen latauslaite tulee sähköautokaupan kylkiäisenä.
Olisiko mahdollista hyödyntää myös aurinkopaneeli järjestelmässä missä on myös akut mukana ?
Ajatuksena olisi että akkuja ladattaisiin ja purettaisiin mahdollisimman järkevästi hintojen mukaan. Esim jos päivällä on tietyissä tunneissa kalliimpaa kuin toisissa niin silloin myydään maksimit verkkoon ja halvemmilla lataillaan.
Ajatuksena olisi että akkuja ladattaisiin ja purettaisiin mahdollisimman järkevästi hintojen mukaan. Esim jos päivällä on tietyissä tunneissa kalliimpaa kuin toisissa niin silloin myydään maksimit verkkoon ja halvemmilla lataillaan.
Tämäntyyppinen on todo-listalla jatkoa ajatellen. Se saadaan omana logiikkanaan tuohon kylkeen sitten rakennettua, ja varmaan vähän käyttäjävalintojakin sille tarvitsee tehdä.
Tähän voisi vaikka vähän brainstormata minkätyyppinen sen logiikan pitäisi olla? Itselle ei ole vielä aivan selvää miten akkuja kannattaisi hallita, eli esimerkiksi onko tavoitetila käyttää niitä jollain tietyllä alueella vaikkapa 30-80 vs 0-100, miten akkusyklien maksimimäärä tulisi ottaa huomioon akusta otetun sähkön laskennallisessa hinnassa jne.
Hianoa kuulla että tätä on jo mietitty! Tosiaan kyllähän tuo laskenta menee näin auringon paistellessa kohtuu monimutkaiseksi kun pitäisi omankin tuotannon käyttö tietenkin maksimoida.
Talvikuukaudet ovat sitten vähän yksinkertaisempia kun tuotantoa ei ole, tosiaan näissä LFP akuissa on cyclit +6k niin niitä kyllä kestää purkaa ja ladata aika vapaasti. Toki jos hintahyötyä ei montaa senttiä ole niin silloin ei taida kannattavaa olla. Huawein akuissa tällä hetkellä väli on 10-100% omassa käytössä.
Eli esim. käyttökohde:
Omakotitalo pörssisähköllä
Caruna Yleissiirto eli 5,07+2,79372 c/kWh = 7,86372 c/kWh
Eli jos mietitään akuista myynnin hyötyä niin pitäisi tuon siirto kattaa sekä tietty ostetun energian hinta. Myydessä sähköstähän saa pörssinhinta alv.0 ja kuluja tulee mahdollinen välityspalkkio mutta ei siirtoa.
Kiva nähdä että Pörssärin kehittäjät ovat aktiivisia tällä foorumilla ja suhtautuvat asiaan sillä tavalla, että keskusteluista voi jättää "tämä ohjaushärveli on parempi kuin tuo ohjaushärveli" sävyt pois.
Olen itse toteuttanut openHAB:n päälle tällaisen harrasteproggiksen
github.com
Ja tässä statistiikkaa mitä olen saanut aikaan sähkölaskulla
Minua kiinnostelisi tehdä yhteistyötä talon lämmitystä optimoivan algoritmin kehittämisessä - siten että yhdessä fiilistellyt konseptit voi toteuttaa sekä Pörssäriin että tuohon omaan tunkkiini, koska se ei ole keneltäkään pois että konseptuaalisesti hyvä algoritmi olisi useammassa eri vaihtoehdossa toteutettuna.
Tässä alkuun omia ajatuksia siitä, mitä olen puolentoista vuoden aikana oppinut oman talomme sielunelämästä.
Oman talomme lämmitystarve on aikalailla lineaarinen suhteessa ulkolämpötilaan. Lasken lämmitystarpeen näiden pisteiden avulla:
- sääennusteen keskilämpötila -25, lämmitystunteja 24
- sääennusteen keskilämpötila +10, lämmitystunteja 2 (nämä 2 tuntia ovat käyttöveden lämmitystä varten)
Lisäksi taloa lämpenee erityisesti näin keväisin huomattavan paljon ison Eteläsuuntaisen 4x4 metrin ikkunan vuoksi. Meillä ei ole aurinkopaneeleita, mutta minulla on ollut nyt pari kuukautta forecast.solar:n tuotantoennusteeseen perustuva kompensaatiovirveli, jonka perusteella lämmitystunteja vähennetään jos huomisesta on tulossa kovin aurinkoinen.
Lisäksi minulla on kompensaatio toiseen suuntaan, eli jos ulkolämpötila sääennusteen perusteella on putoamassa vuorokauden jälkimmäisellä puoliskolla kovasti, niin sitten lämmitystä lisätään (etupeltoon), jotta sisälämpötila pysyy tasaisempana.
Olen kokeillut muutamaa eri lähestymistapaa tuon lämmitysoptimiointialgoritmin suhteen, mutta en ole vielä keksinyt Täydellistä Algoritmia tähän monitavoiteongelmaan, jossa on kolme eri optimointitavoitetta:
1) Lämmityksen ajoittaminen halvoille tunneille
2) Sisälämpötilan seilaamisen pitäminen tolkun rajoissa
3) Maalämpöpumpun kompressorin käynnistyskertojen minimointi
Kylmällä kelillä, kun lämmitystarve on suuri, niin tällä wikisivulla kuvattu algoritmi toimii varsin lähellä optimia:
github.com
Tässä siis EI metsästetä vuorokauden halvimpia tunteja ja sallita niitä, vaan päinvastoin. Eli algoritmi etsii päivän kalleimmat piikit ja blokkaa ne, mutta samalla pitää huolen että blokattujen piikkien väliin taataan konfiguroitavissa oleva määrä lämmitysaikaa (eli nämä blokattavat kalliit piikit eivät voi olla täysin peräjälkeen koska silloin talo jäähtyy liikaa).
Kuten mainittu, tämä algorimti toimii meidän talomme kohdalla pääsääntöisesti oikein hyvin silloin kun lämmitystuntien määrä on kohtalaisen suuri ja kun päivän hinnat ovat normaalin kaksikyttyräisen muotoisia.
However, tämä algoritmi voi tuottaa tosi hassuja tuloksia silloin, kun lämmitystarpeen määrä laskee. Silloin voi käydä näin (pidempi taustoitus yllä linkatulla wikisivulla).
Tämän ilmiön vuoksi omat ohjaussääntöni toimivatkin siten, että jos lämmitystarve on 7h tai vähemmän, niin silloin ei käytetä tätä "peak period blocker" -algoritmia, vaan etsitään vuorokauden halpoja yhtäjaksoisia pätkiä ja sallitaan ne.
Tämän pitkän jorinan kautta sitten Pörssäriin. Pörssärin lämmitysalgoritmi ilmeistesti toimii siten, että
- vuorokausi voidaan jakaa haluttuun määrään osia, esim. 3 x 8h tai 4 x 6h tai mitä tahansa muuta.
- Ja sitten jokaisen periodin kohdalle lasketaan kyseisen periodin keskilämpötilan perusteella tarvittava määrä lämmitystunteja.
- Ja poimitaan sitten halvimmat yksittäiset tunnit ja sallitaan ne.
Jos tätä peilaa noihin ihan postaukseni alussa mainittuun kolmeen optimointitavoitteeseen, niin tämä optimoi kaikista parhaiten tasaista sisälämpötilaa, mutta voisin kuvitella että tämä saattaa johtaa ei-optimaaliseen tulokseen kahden muun optimointitavoitteen suhteen. Eli voi olla, että keskellä päivää lämmitetään kalliimmilla tunneilla "liikaa", tai siis tätä lämmitystä olisi voinut siirtää joko vähän aikaisemmaksi tai myöhemmäksi siten että lämmitys olisi ollut yöpainotteisempaa ja päivällä lämmitetään vain juuri sen verran että lämpötila ei vajoa liikaa. Ja toisekseen, tämä voi johtaa siihen, että erityisesti on-off pumppujen kohdalla tulee ylimääräisiä kompressorin käynnistymisiä (tai siis ylimääräisiä as in että saavutettu hintahyöty ei ole niin suuri, että kannattaa pätkäkäyttää kompuraa edestakaisin).
Olen viime aikoina huurustellut kaksivaiheista optimointialgoritmia, joka tekisi ensin tuon peak period blocker -konseptin mukaisen optimoinnin, mutta sen jälkeen tarkastelisi että kannattaisiko lopputulosta "liuuttaa" joko vasemmalle tai oikealle sen mukaan, millaisia hintoja sieltä löytyy ympäristöstä.
Mutta millaisia kokemuksia ja ajatuksia teillä muilla on?
Cheers,
Markus
Olen itse toteuttanut openHAB:n päälle tällaisen harrasteproggiksen
Home
Openhab Spot Price Optimizer modules help you to optimize energy consumption to the cheapest hours of the day. - masipila/openhab-spot-price-optimizer
github.com
Ja tässä statistiikkaa mitä olen saanut aikaan sähkölaskulla
Toteutunut keskihinta/kk pörssisähköllä.
Pari viikkoa vajaa 6 kuukautta takana vuoden sopimuksesta (7,98 snt/kWh). Soppari otettu 19.10. ja siitä hetkestä: Oma spot-keskiarvo (sis. marginaali): 11,338265 snt/kWh Oma spot-keskiarvo (ei marginaalia): 10,938265 snt/kWh Spot keskiarvo: 8,84 snt/kWh Kulutusvaikutus %: +23,77 %...
bbs.io-tech.fi
Minua kiinnostelisi tehdä yhteistyötä talon lämmitystä optimoivan algoritmin kehittämisessä - siten että yhdessä fiilistellyt konseptit voi toteuttaa sekä Pörssäriin että tuohon omaan tunkkiini, koska se ei ole keneltäkään pois että konseptuaalisesti hyvä algoritmi olisi useammassa eri vaihtoehdossa toteutettuna.
Tässä alkuun omia ajatuksia siitä, mitä olen puolentoista vuoden aikana oppinut oman talomme sielunelämästä.
Oman talomme lämmitystarve on aikalailla lineaarinen suhteessa ulkolämpötilaan. Lasken lämmitystarpeen näiden pisteiden avulla:
- sääennusteen keskilämpötila -25, lämmitystunteja 24
- sääennusteen keskilämpötila +10, lämmitystunteja 2 (nämä 2 tuntia ovat käyttöveden lämmitystä varten)
Lisäksi taloa lämpenee erityisesti näin keväisin huomattavan paljon ison Eteläsuuntaisen 4x4 metrin ikkunan vuoksi. Meillä ei ole aurinkopaneeleita, mutta minulla on ollut nyt pari kuukautta forecast.solar:n tuotantoennusteeseen perustuva kompensaatiovirveli, jonka perusteella lämmitystunteja vähennetään jos huomisesta on tulossa kovin aurinkoinen.
Lisäksi minulla on kompensaatio toiseen suuntaan, eli jos ulkolämpötila sääennusteen perusteella on putoamassa vuorokauden jälkimmäisellä puoliskolla kovasti, niin sitten lämmitystä lisätään (etupeltoon), jotta sisälämpötila pysyy tasaisempana.
Olen kokeillut muutamaa eri lähestymistapaa tuon lämmitysoptimiointialgoritmin suhteen, mutta en ole vielä keksinyt Täydellistä Algoritmia tähän monitavoiteongelmaan, jossa on kolme eri optimointitavoitetta:
1) Lämmityksen ajoittaminen halvoille tunneille
2) Sisälämpötilan seilaamisen pitäminen tolkun rajoissa
3) Maalämpöpumpun kompressorin käynnistyskertojen minimointi
Kylmällä kelillä, kun lämmitystarve on suuri, niin tällä wikisivulla kuvattu algoritmi toimii varsin lähellä optimia:
Usage example: PeakPeriodOptimizer ‐ Optimizing heating of the house
Openhab Spot Price Optimizer modules help you to optimize energy consumption to the cheapest hours of the day. - masipila/openhab-spot-price-optimizer
github.com
Tässä siis EI metsästetä vuorokauden halvimpia tunteja ja sallita niitä, vaan päinvastoin. Eli algoritmi etsii päivän kalleimmat piikit ja blokkaa ne, mutta samalla pitää huolen että blokattujen piikkien väliin taataan konfiguroitavissa oleva määrä lämmitysaikaa (eli nämä blokattavat kalliit piikit eivät voi olla täysin peräjälkeen koska silloin talo jäähtyy liikaa).
Kuten mainittu, tämä algorimti toimii meidän talomme kohdalla pääsääntöisesti oikein hyvin silloin kun lämmitystuntien määrä on kohtalaisen suuri ja kun päivän hinnat ovat normaalin kaksikyttyräisen muotoisia.
However, tämä algoritmi voi tuottaa tosi hassuja tuloksia silloin, kun lämmitystarpeen määrä laskee. Silloin voi käydä näin (pidempi taustoitus yllä linkatulla wikisivulla).
Tämän ilmiön vuoksi omat ohjaussääntöni toimivatkin siten, että jos lämmitystarve on 7h tai vähemmän, niin silloin ei käytetä tätä "peak period blocker" -algoritmia, vaan etsitään vuorokauden halpoja yhtäjaksoisia pätkiä ja sallitaan ne.
Tämän pitkän jorinan kautta sitten Pörssäriin. Pörssärin lämmitysalgoritmi ilmeistesti toimii siten, että
- vuorokausi voidaan jakaa haluttuun määrään osia, esim. 3 x 8h tai 4 x 6h tai mitä tahansa muuta.
- Ja sitten jokaisen periodin kohdalle lasketaan kyseisen periodin keskilämpötilan perusteella tarvittava määrä lämmitystunteja.
- Ja poimitaan sitten halvimmat yksittäiset tunnit ja sallitaan ne.
Jos tätä peilaa noihin ihan postaukseni alussa mainittuun kolmeen optimointitavoitteeseen, niin tämä optimoi kaikista parhaiten tasaista sisälämpötilaa, mutta voisin kuvitella että tämä saattaa johtaa ei-optimaaliseen tulokseen kahden muun optimointitavoitteen suhteen. Eli voi olla, että keskellä päivää lämmitetään kalliimmilla tunneilla "liikaa", tai siis tätä lämmitystä olisi voinut siirtää joko vähän aikaisemmaksi tai myöhemmäksi siten että lämmitys olisi ollut yöpainotteisempaa ja päivällä lämmitetään vain juuri sen verran että lämpötila ei vajoa liikaa. Ja toisekseen, tämä voi johtaa siihen, että erityisesti on-off pumppujen kohdalla tulee ylimääräisiä kompressorin käynnistymisiä (tai siis ylimääräisiä as in että saavutettu hintahyöty ei ole niin suuri, että kannattaa pätkäkäyttää kompuraa edestakaisin).
Olen viime aikoina huurustellut kaksivaiheista optimointialgoritmia, joka tekisi ensin tuon peak period blocker -konseptin mukaisen optimoinnin, mutta sen jälkeen tarkastelisi että kannattaisiko lopputulosta "liuuttaa" joko vasemmalle tai oikealle sen mukaan, millaisia hintoja sieltä löytyy ympäristöstä.
Mutta millaisia kokemuksia ja ajatuksia teillä muilla on?
Cheers,
Markus
Tutustuin tuohon sinun ohjausalgoritmiin, loistavaa työtä! Olen ehdottomasti samaa mieltä siitä, että "parviäly" johtaa parhaaseen lopputulokseen, ja ehdottomasti viedään tätä asiaa yhteistuumin eteenpäin! Pörssärin kanssa meillä on alunperinkin ollut se ajatus, että vaikka enimmäkseen onkin Shellyjen kanssa oltu tekemisissä, niin ei ohjattava kuorma tiedä mikä unix-aikaleimaa tulkitseva ohjauslaite siltä sähköjä pätkii. En ole itse vielä oikein löytänyt markkinoilta ylivertaista tuotetta millä ohjauksia toteuttaa. OpenHAB vaikuttaa mielenkiintoiselle, olisipa vain aikaa siihenkin tutustua..Kiva nähdä että Pörssärin kehittäjät ovat aktiivisia tällä foorumilla ja suhtautuvat asiaan sillä tavalla, että keskusteluista voi jättää "tämä ohjaushärveli on parempi kuin tuo ohjaushärveli" sävyt pois.
Olen itse toteuttanut openHAB:n päälle tällaisen harrasteproggiksen
Home
Openhab Spot Price Optimizer modules help you to optimize energy consumption to the cheapest hours of the day. - masipila/openhab-spot-price-optimizer
Ja tässä statistiikkaa mitä olen saanut aikaan sähkölaskulla
Toteutunut keskihinta/kk pörssisähköllä.
Pari viikkoa vajaa 6 kuukautta takana vuoden sopimuksesta (7,98 snt/kWh). Soppari otettu 19.10. ja siitä hetkestä: Oma spot-keskiarvo (sis. marginaali): 11,338265 snt/kWh Oma spot-keskiarvo (ei marginaalia): 10,938265 snt/kWh Spot keskiarvo: 8,84 snt/kWh Kulutusvaikutus %: +23,77 %...bbs.io-tech.fi
Minua kiinnostelisi tehdä yhteistyötä talon lämmitystä optimoivan algoritmin kehittämisessä - siten että yhdessä fiilistellyt konseptit voi toteuttaa sekä Pörssäriin että tuohon omaan tunkkiini, koska se ei ole keneltäkään pois että konseptuaalisesti hyvä algoritmi olisi useammassa eri vaihtoehdossa toteutettuna.
Suunnilleen noin, pienellä täsmennyksellä niin, että lasketaan vartteja. Toistaiseksi jokaisella vartilla toki on tunnin sisällä sama hinta, mutta ajatuksena menee juuri noin kuten sanot.
Pitää täysin paikkansa mitä sanot, eli jos vain lasketaan jokaiselle periodille ulkolämmön mukaan lämmitystarve, niin se käyttää mahdollisesti vuorokauden kalleimmastakin jaksosta suuren osan tunteja lämmitykseen vaikka ei olisi ollut välttämätöntä.
Pörssärin logiikkaa ei oikeastaan ole ehditty tuosta ensimmäisestä perustasosta vielä kehittää eteenpäin. Sitä on tehty osissa, ja ihan ensimmäinen steppi olikin, että päästään hehtaarilleen oikeaan lämmitysmäärään. Meillähän tuo lämmitysvarttien arvio lähtee siitä, että käyttäjä ilmoittaa kiinteistönsä vuosienergiatarpeen sekä lämmityslaitteen tehon. Eli ei tarvitsisi tietää montako tuntia lämmitystä tarvitaan. Ainakin omat kokemukset on olleet sen suuntaiset, että hehtaarille osutaan, ja pienet korjaukset joko kulmakertoimeen tai käyrän siirtymään on riittäneet pitämään talon tasalämpöisenä.
Oma ajatukseni seuraavasta vaiheesta olisi se, että hintatietojen voimassaoloajan periodien keskilämpötilan ja hintojen keskiarvon (ja ehkä keskihajonnan) perusteella luotaisiin painostuskertoimet kuinka paljon minkäkin periodin lämmitystä lisätään tai vähennetään tuosta ulkolämmön mukaisesta lämmitystarpeesta. Jos seuraava jakso on halvempi/lämpöisempi niin lämmitetään vähemmän ja sama toisinpäin. Ja jonkinlainen alkuperäinen painotuskerroin vielä laskettaisin aluksi ottaen kaikki vuorokauden periodien keskihinnat suhteutettuna toisiinsa.
Seuraavat stepit sitten olisi vielä lämpöpumppujen käynnin optimointi sekä mahdolliset aurinko- ja tuulikompensaatiot. Nykyisellään oman on-off-pumpun olen koettanut säätää niin, että se käy aina tauotta kun Pörssäri antaa sille luvan lämmittää. Toki se vaatii sekä varaavaa massaa pumpun perässä että riittävän hyvää lämmönjakokiertoa jottei kiertovesi nouse liian kuumaksi. Tämän talven perusteella kuitenkaan semmoista ongelmaa tässä talossa ei ollut. Mutta tuo varsinainen lämpöpumpun käynnin optimointi tulisi sitten viimeisenä peliin mukaan, invertteripumput on sitten vielä asia erikseen ja siinä tulee taas mukaan muuttujia mitä täytyy huomioida.
Semmoinen mikä itsellä on kanssa vielä käynyt mielessä on, että välttämättä joka päivä ei kannattaisi ylilämmittää ja seisottaa, vaan lämmittää koko päivä tasaisesti, koska hinnat on myös tasaiset. Onkin ajatuksissa ollut myös ehkä enemmän sitten keskihajonnan avulla päättää kumpaa lämmitysmoodia käytetään. Hyötysuhde kuitenkin aina vähän heikkenee, ja varsinkin ilmalämpöpumpuilla ja ilma-vesilämpöpumpuilla sekin alkaa taas olla merkityksellistä ettei turhaan ajettaisi pumppua täysillä kun koko päivän sähkönhinta on vaikkapa parin sentin sisällä.
@tk- tuo sinun lähestymistapasi missä tarkastellaan ensin kullekin periodille erikseen lämmitystarvetta kyseisen periodin sääennusteen mukaan on kyllä varmasti Ainoa Oikea (TM) tai ainakin Oikein Hyvä (TM) lähestymistapa.
About kaikissa muissa lähestymistavoissa käy helposti tällä tavalla, kuin minulla huomisen kanssa, ks. kuva alla.
Cheers,
Markus
About kaikissa muissa lähestymistavoissa käy helposti tällä tavalla, kuin minulla huomisen kanssa, ks. kuva alla.
- Huomisen lämmitystarve on 3h (tai siis 12 varttia)
- Algoritmini hakee halvimman yhtäjaksoisen 3h periodin joka on klo 15-17.
- Lämmityksessä tuohon aikaan vaan ei ole mitään mieltä kun ulkona on yli 10 astetta lämpimämpää kuin edeltävänä yönä.
Cheers,
Markus
@masipila En tiedä ainoa oikea tai edes paras, mutta omasta mielestä noita molempia koska asia palastellaan yksi asia kerrallaan.
Viimeiseksi sitten kun on tiedossa tuo varttimääräksi muunnettu lämmitystarve, niin kytketään halvimmat vartit ja/tai jaksot sen mukaan miten käyntiajan halutaan menevän.
Eli tavallaan jokaista osa-aluetta voidaan kehittää osissa, esim tuota erikseen erilaisille lämmityslaitteille jne.
- ensin lasketaan riittävän lyhyelle jaksolle keskilämpötila ja lämmitystarve
- sen jälkeen voidaan erilaisilla ehdoilla muokata kwh-määrää, esimerkiksi
- verrata päivän jaksoja toisiinsa ja painottaa lämmitystä halvempiin
- verrata seuraavan jakson lämpötilaan ja lisätä/vähentää
- valita jaksoja päivästä, vaikka aamupäivä kun kukaan ei ole kotona jolloin lämmitystä voi vähän vähentää
- jne
Viimeiseksi sitten kun on tiedossa tuo varttimääräksi muunnettu lämmitystarve, niin kytketään halvimmat vartit ja/tai jaksot sen mukaan miten käyntiajan halutaan menevän.
Eli tavallaan jokaista osa-aluetta voidaan kehittää osissa, esim tuota erikseen erilaisille lämmityslaitteille jne.
Viimeksi muokattu:
@tk-, tuo kuulostaa äkkiseltään kyllä viimosen päälle hyvältä konseptilta. Tässä on nyt kivasti aikaa ennen seuraavaa lämmityskautta ja dataakin on puolentoista vuoden aikana kertynyt aika kivasti, joten sieltä löytyy kyllä hinnan ja lämpötilan puolesta ties minkä muotoisia päiviä joilla voi sitten koittaa simuloida noita.
Cheers,
Markus
Note to self: testaa ainakin seuraavanlaisia päiviä:
- hinnat nousevat koko ajan iltaa kohti
- hinnat laskevat koko ajan iltaa kohti
- hintapiikkit epätavalliseen aikaan, eli ei aamulla eikä illalla, vaan yöllä tai keskellä päivää
- halvat tunnit yön sijaan keskellä päivää
- kovasti päivän aikana sahaava lämpötila
- kovasti päivän aikana lauhtuva lämpötila
- kovati päivän aikana kiristyvä pakkanen
Palaan tähän iterointiin parin viikon sisällä kun saadaan tuo sivustopäivitys puskettua läpi! Tänään on tullut sekä viimeisteltyä ohjausten muodostamista uudesta tietokantarakenteesta että kasattua tietokannan muutosskriptiä, ja jotain tuosta päivityksen suuruusluokasta kertoo ehkä se, että noin 400 riviä on koodia jo kasassa ennenkuin hintatietoja on vielä käsitelty ollenkaan...
Mutta kehitys kehittyy, ja mitä pidemmälle näitä uudistuksia lykkää, niin sitä vaikeammaksi se aina käy käyttäjämäärän jatkuvasti kasvaessa ja toiminnallisuuksien lisääntyessä.
Moi, Sama virhe allekirjoittaneellakin. Olen rekisteröitynyt Pörssäriin jo joulukuussa 2023, mutta vasta eilen aloin tekemään Shelly ohjauksia. Löytyy 3- ja 4-kanavainen shelly sekä 6kpl shelly-plugeja.
Pistä sähköpostilla tunnus osoitteeseen info (at) porssari .fi niin katson miksei sillä pääse kirjautumaan. Onko joskus päässyt, vai eikö aktivointimailia koskaan tullut?
Voiko aurinpaneelituoton mukaan ohjata shellykanavia ilman pakko-ohjaustunteja? Eli haluaisin että kun aurinko porottaa hyvin niin shelly kanava menisi päälle. En haluaisi että lattialämmitys/uima-allas lämpenee väkisin joka päivä vaan ainoastaan silloin kun aurinkopaneeleista tulee yli 50% teholla sähköä. Tämän tietysti saisi hoidettua erillisillä pihtimittareilla joita ei vielä ole. Luottoa on porssarin aurinkoennusteeseen sen verran että se voisi hoitaa homman ilman pihtimittareita.
Ei vielä, mutta tuohon uudelle sivustolle olisi tulossa aurinkotuottoon myös vaihtoehto minkä mukaan saa laitteen päälle vain ne tunnit, kun ennustettu aurinkotuotto on x-100% laitteen kaipaamasta tehosta, eli se ajaisi tuon käyttötarkoituksen kyllä. Pyritään tässä nyt tekemään töitä, että saataisiin se muutaman viikon sisään päivitysvalmiiksi.
@tk- Testailin paria eri lähestymistapaa ja simuloin niillä kummallakin koko menneen lämmityskauden (tai no, melkein koko, kun uutta kylmää pukkaa). Tässä muutamia hajatelmia.
Algoritmi 1: Yksittäisten halpojen tuntien metsästys
Vaihtoehto 1 johtaa luonnollisesti hieman halvempaan lopputulokseen, jos ainut optimointitavoite on halvimmat spottihinnat. However, jos on/off -pumpun pätkäkäyntiä haluaa välttää, niin silloin tuo algoritmi 2 voipi olla soveltuvampi. Erityisesti jos talo varaa hyvin lämpöä. Tässä pari esimerkkiviikkoa:
Algoritmi 1: Yksittäisen halpojen tuntien metsästys
Algoritmi 2: Pidemmät yhtenäiset lämmitysjaksot
Toinen esimerkkiviikko:
Algoritmi 1: Yksittäisten tuntien metsästys
Algoritmi 2: Pidemmät yhtenäiset lämmitysjaksot
Jos tätä eroa katsoo yhden tarkoitushakuisesti valitun päivän tarkkuudella ja zoomaa 4.2.2024, niin yksittäisten tuntien metsästys johti alla olevaan tulokseen.
Yllä olevassa kuvassa erityisesti aamuyöllä olisi voinut varsin hyvin selvitä yhdellä pidemmällä käyntijaksolla, kun tuntien hintaero oli desimaalien osissa.
Pohdintaa:
Komprerssoin käynnistysten määrän ero näiden kahden algoritmin välillä ei ole reaalimaailmassa erityisen suuri tai edes merkittävä niin kauan kuin spottihintojen resoluutio on tunti, mutta jos spottihintojen resoluutio muuttuu varttiin, niin siinä vaiheessa tästä todennäköisesti tulee merkittävä asia. Ainakaan itse en aio räpsiä maalämpöpumpun on/off-kompressoria vartin välein päälle ja pois.
Lisätestauksia ja havaintoja, osa 1
Testasin myös edellä olevista vertailuista riippumattomasti toista asiaa.
Lisähavaintoja, osa 2
Tämän pystyy klaaraamaan melko helposti siten, että määrittelee optimointijaksoille sallitun limityksen, esim. 2h, jolloin algoritmi toimii seuraavasti:
Cheers,
Markus
Edit: typoja
Algoritmi 1: Yksittäisten halpojen tuntien metsästys
- Vuorokausi jaettiin 3 x 8h osaan
- Jokaiselle 8h osalle laskettiin lämmitystarve
- Jokaiselle 8h osalle metsästettiin sitten tarvittava määrä yksittäisiä halvimpia tunteja
- (Tämä on siis hyvin lähellä Pörssärin tämänhetkistä logiikkaa, ainut ero tässä on kosenptuaalisesti että metsästin tunteja enkä vartteja, pyöristin lämmitystarpeen ylöspäin seuraavaan kokonaiseen tuntiin)
- Vuorokausi jaettiin 3 x 8h osaan
- Jokaiselle 8h osalle laskettiin lämmitystarve
- Jos lämmitystarve oli vähintään puolet 8h osasta, esim. 5H15M, niin tällöin lasketaan ensin kuinka pitkä periodi pitää olla estettynä (tässä 2H45M), etsitään kallein yhtäjaksoinen tämänpituinen piikki ja sallitaan loput
- Jos lämmitystarve on alle puolet 8h osasta, esim. 3H15M, niin tällöin etsitään halvin yhtäjaksoinen tämänpituinen periodi ja sallitaan se
Vaihtoehto 1 johtaa luonnollisesti hieman halvempaan lopputulokseen, jos ainut optimointitavoite on halvimmat spottihinnat. However, jos on/off -pumpun pätkäkäyntiä haluaa välttää, niin silloin tuo algoritmi 2 voipi olla soveltuvampi. Erityisesti jos talo varaa hyvin lämpöä. Tässä pari esimerkkiviikkoa:
Algoritmi 1: Yksittäisen halpojen tuntien metsästys
Algoritmi 2: Pidemmät yhtenäiset lämmitysjaksot
Toinen esimerkkiviikko:
Algoritmi 1: Yksittäisten tuntien metsästys
Algoritmi 2: Pidemmät yhtenäiset lämmitysjaksot
Jos tätä eroa katsoo yhden tarkoitushakuisesti valitun päivän tarkkuudella ja zoomaa 4.2.2024, niin yksittäisten tuntien metsästys johti alla olevaan tulokseen.
Yllä olevassa kuvassa erityisesti aamuyöllä olisi voinut varsin hyvin selvitä yhdellä pidemmällä käyntijaksolla, kun tuntien hintaero oli desimaalien osissa.
Pohdintaa:
Komprerssoin käynnistysten määrän ero näiden kahden algoritmin välillä ei ole reaalimaailmassa erityisen suuri tai edes merkittävä niin kauan kuin spottihintojen resoluutio on tunti, mutta jos spottihintojen resoluutio muuttuu varttiin, niin siinä vaiheessa tästä todennäköisesti tulee merkittävä asia. Ainakaan itse en aio räpsiä maalämpöpumpun on/off-kompressoria vartin välein päälle ja pois.
Lisätestauksia ja havaintoja, osa 1
Testasin myös edellä olevista vertailuista riippumattomasti toista asiaa.
- Optimoin 27h aikaväliä tämän päivän 22 - ylihuomisen 01
- Ja sitten seuraavana päivänä tuo jo aiemmin optimoitu viimeinen 3h laskettiin uudelleen ajatuksella sillä, että jos uutena päivänä olisikin tarjolla merkittävästi halvempia hintoja
- 9h optimointijaksot ovat siis 22-07, 07-18 ja 18-01
- Tänä esimerkkipäivänä keskimmäisen 07-18 jakson kaikki lämmitystunnit osuvat jakson alkuun
- Ja viimeisen 18-01 jakson kaikki lämmitystunnit osuvat jakson loppuun
Lisähavaintoja, osa 2
- Sekä algoritmissa 1 että 2 on sellainen ominiasuus, että noiden optimointijaksojen rajoilla voi tulla hieman epäoptimaalinen tulos, kuten alla olevassa kuvassa.
- Alla olevassa kuvassa optimointijaksot ovat klo 00-08, 8-16 ja 16-00 ja tässä on metsästetty algoritmillä 1 ykisttäisiä halvempia tunteja
- Klo 16-17 tunnin sijaan olisi ehkä kannattanut lämmittää klo 13-14.
Tämän pystyy klaaraamaan melko helposti siten, että määrittelee optimointijaksoille sallitun limityksen, esim. 2h, jolloin algoritmi toimii seuraavasti:
- Ensin optimoidaan 00 - 10
- Sitten optimoidaan 06 - 18
- Sitten optimoidaan 16 - 00
Cheers,
Markus
Edit: typoja
Liitteet
Testasin tuota limitystä hieman isommalla datasetillä ja eipä sekään ole oikotie onneen, siinä voi käydä nimittäin näin.
Pitäisi ehkä koittaa seuraavaksi millaiseksi homma menee, jos laskisi kunkin optimointijakson yhtenäisten lämmitysjaksojen hinnoille keskihajonnan. Ja sitten sen perusteella koittaisi painottaa optimointijakson keskelle osuvia lämmitysjaksoja, vaikka ne eivät olisikaan absoluuttisesti halvimpia.
Sivuhuomautus: Tiedostan antavani tuolle kompressorin käynnistymäärien minimoinnille ehkä enemmän painoarvoa kuin moni muu. Siinä on taustalla se, että meidän maalämpöpumppumme käynnistyi elämänsä ensimmäisen parin vuoden aikana hulppeat 22 000 kertaa (keskimäärin 28 kertaa vuorokaudessa) kun se oli oman automatiikkansa varassa (koska lämpimän käyttöveden kiertovesipumppu). Sen jälkeen kun aloitin oman pörssiohjauksen, käynnistyskertojen lukumäärä putosi 2,5:een / vrk. Jossain Foorumilla Joku Tiesi Kertoa (TM) että on-off pumppujen kompressorit kestävät noin 100k käynnistystä, niin sillä koitan optimoida noita käynnistyskertoja että pumppu saisi tuosta nihkeästä alusta huolimatta tolkullisen eliniän.
- Ensimmäinen kuva on ilman limitystä, ja lämmitys on jakautunut kivan tasaisesti ympäri päivän.
- Toisessa kuvassa on sallittu tunnin limitys, ja sen vuoksi (tai sen ansiosta) toinen yhtenäinen lämmitysjakso siirtyy 5h aiemmaksi.
Pitäisi ehkä koittaa seuraavaksi millaiseksi homma menee, jos laskisi kunkin optimointijakson yhtenäisten lämmitysjaksojen hinnoille keskihajonnan. Ja sitten sen perusteella koittaisi painottaa optimointijakson keskelle osuvia lämmitysjaksoja, vaikka ne eivät olisikaan absoluuttisesti halvimpia.
Sivuhuomautus: Tiedostan antavani tuolle kompressorin käynnistymäärien minimoinnille ehkä enemmän painoarvoa kuin moni muu. Siinä on taustalla se, että meidän maalämpöpumppumme käynnistyi elämänsä ensimmäisen parin vuoden aikana hulppeat 22 000 kertaa (keskimäärin 28 kertaa vuorokaudessa) kun se oli oman automatiikkansa varassa (koska lämpimän käyttöveden kiertovesipumppu). Sen jälkeen kun aloitin oman pörssiohjauksen, käynnistyskertojen lukumäärä putosi 2,5:een / vrk. Jossain Foorumilla Joku Tiesi Kertoa (TM) että on-off pumppujen kompressorit kestävät noin 100k käynnistystä, niin sillä koitan optimoida noita käynnistyskertoja että pumppu saisi tuosta nihkeästä alusta huolimatta tolkullisen eliniän.
Askartelin dashboardin jolla pystyy tarkastelemaan eri algoritmien tehokkuutta rahamielessä. Valitettavasti pitää ottaa lukemat kuukausi kerraallan, koska devitunkin puhti loppuu kesken jos yrittää rouskuttaa koko lämmityskauden kerralla.
Huomautuksia testiasetelmasta:
Algoritmi 2, lokakuu 2023
Algoritmi 3, lokakuu 2023
Algoritmi 1, marraskuu 2023
Algoritmi 2, marraskuu 2023
Algoritmi 3, marraskuu 2023
Algoritmi 1, joulukuu 2023
Algoritmi 2, joulukuu 2023
Algoritmi 3, joulukuu 2023
Huomautuksia testiasetelmasta:
- Korvasin norskien Black Fridayn datasetistä edellisen päivän hinnoilla, ettei se vääristä analyysiä.
- Kulutus on kyisesen algoritmin tuottamasta signaalista laskettu. MLP:n ottoteho on 2kW ja antoteho 8 kW.
- Algoritmi1 on siis simulaatio Pörssärin tämänhetkisestä lämmitysalgoritmista sillä erolla, että lämmitystarve on pyöristetty aina seuraavaan täyteen tuntiin. Tämän vuoksi alla olevissa kuvissa algoritmillä 1 on aina enemmän kulutusta kuin kahdella muulla. Suhteellisiin numeroihin tuo ei kuitenkaan hirveästi vaikuta.
- Algoritmi 2 viestissä #179 kuvattu algoritmi 2
- Algoritmi 3 on PeakPeriodOptimizer, jonka konsepti on kuvattu täällä: Usage example: PeakPeriodOptimizer ‐ Optimizing heating of the house
- Optimoinnit on ajettu pörssi+siirtohintaa vasten (itselläni on Carunan kausisiirto), mutta lukemat alla ovat pörissihintoja ilman siirtoa
- Pahoittelut kuvamuotoisesta datasta, en jaksa copy-pastettaa taulukkoon
- Tammi-maaliskuu tulee seruaavassa viestissä huomenna, koska tänne foorumille ei näköjään pysty laittaa 10 liitettä enempää yhteen viestiin
Algoritmi 2, lokakuu 2023
Algoritmi 3, lokakuu 2023
Algoritmi 1, marraskuu 2023
Algoritmi 2, marraskuu 2023
Algoritmi 3, marraskuu 2023
Algoritmi 1, joulukuu 2023
Algoritmi 2, joulukuu 2023
Algoritmi 3, joulukuu 2023
@masipila Vastaan nopeasti tähän väliin ja pidemmästi lähipäivinä. Mutta loistava tuo dashboard! Vastaa hyvin omaa käsitystä siitä, että tuo nykyinen systeemi ei ole ollut optimaalinen, etenkään jos käytetään alle 12h jaksoja. Suurin syy epäoptimaaliselle sähkönhinnalle on se, että ylipäänsä lämmitysohjausta on lähdetty tekemään osissa, ja ensimmäinen osa on ollut saada se lämmitystarpeen arvio ylipäänsä kohdilleen.
Tulevalle sivustolle tuodaan parempi "manuaalimoodi", mutta ideologisesti minua itseä kiinnostaa kaikista eniten "riittävän hyvä" optimointi missä käyttäjän tarvitsee vain syöttää rakennuksen kokonaislämpöenergiatarve vuositasolla.
Seuraavassa kehitysversiossa lämmitysperiodit jaetaan aina 3, 6, 12 tai 24h mittaiseen jaksoon, ja lisäksi otetaan huomion käyttäjän haluama minimikäyntiaika laitteelle välillä 15-60min.
Tulevalle sivustolle tuodaan parempi "manuaalimoodi", mutta ideologisesti minua itseä kiinnostaa kaikista eniten "riittävän hyvä" optimointi missä käyttäjän tarvitsee vain syöttää rakennuksen kokonaislämpöenergiatarve vuositasolla.
Seuraavassa kehitysversiossa lämmitysperiodit jaetaan aina 3, 6, 12 tai 24h mittaiseen jaksoon, ja lisäksi otetaan huomion käyttäjän haluama minimikäyntiaika laitteelle välillä 15-60min.
Sama. Olen omassa talossamme hienosäätänyt algoritmin tuottamia ajatuksia samalla kun olen seurannut miten se käyttäytyy erilaisissa olosuhteissa (ja miten talo varaa / jäähtyy erilaisissa olosuhteissa), mutta nyt on aika antaa automatiikan hoitaa homma...
Onko ajatuksenasi yhä että noiden lämmitysperiodien sisällä lasketaan lämmitystarve konseptuaalisesti about kuin nyt, vai oliko sinulla siihen jotain muita konseptuaalisia kehitysajatuksia?
Ajattelin itse näiden algoritmivertailujen perusteella koittaa kehittää tuota PeakPeriodOptimizeria siten, että piikkien väliin tulevan lämmitysjakson minimipituus ei olisi staattinen, vaan se laskettaisiin sääennusteen perusteella. Ja toisekseen, joku lämmitystuntien pieni siirto paikasta toiseen olisi kiva, mutta voi olla että tässä kohtaa kompleksisuus ylittää saavutettavan hyödyn...
Markus
Tässä vielä tammi-maaliskuu.
Algoritmi 1, tammikuu 2024
Algoritmi 2, tammikuu 2024
Algoritmi 3, tammikuu 2024
Algoritmi 1, helmikuu 2024
Algoritmi 2, helmikuu 2024
Algoritmi 3, helmikuu 2024
Algoritmi 1, maaliskuu 2024
Algoritmi 2, maaliskuu 2024
Algoritmi 3, maaliskuu 2024
- Helmikuun datassa on jotain, jonka vuoksi Grafana-dashboard vetää itsensä hirteen kulutusvaikutuksen laskennassa, joten ruksin sen punaisella kuvista yli
- Tammi- ja helmikuussa kuukausi on liian pitkä aikajakso jos haluaa verrata pörssin keskihintaan, sillä kuukaudensisäiset hinta- ja lämpötilavaihtelut olivat niin suuret että alla olevat lukemat antavat ymmärtää että pörssiohjausta ei olisi kannattanut tehdä (oma kk-keskihinta on suurempi kuin markkinoiden keskihinta). Tämä johtuu vain siitä, että osa kuukaudesta oli sekä kylmiä että hurjan kalliita ja kuukauden kulutus painottui voimakkaasti näille kylmille jaksoille.
Algoritmi 1, tammikuu 2024
Algoritmi 2, tammikuu 2024
Algoritmi 3, tammikuu 2024
Algoritmi 1, helmikuu 2024
Algoritmi 2, helmikuu 2024
Algoritmi 3, helmikuu 2024
Algoritmi 1, maaliskuu 2024
Algoritmi 2, maaliskuu 2024
Algoritmi 3, maaliskuu 2024
Se ajatus on pysynyt samana, eli ensin se laskenta ja sitten vertaillaan blokkien hintoja keskenään ja lämpötilanmuutosta, ja siirrellään ”jossain rajoissa” lämmitystä jaksosta toiseen kuitenkin niin, että vuorokauden lämmitystarve pysyy about muuttumattomana. Arvon vielä vähän sen välillä, että lasketaanko perustarve 3 vai 6 tunnin blokeissa, ja voikin olla, että se muuttuu vielä kolmeen.
Itse ohjauslooppia varten sitten ynnätään lämmitystarve yhteen noista edellä lasketuista blokeista sen jakson pituuden mukaan, oli se sitten sen 3, 6, 12 tai 24h.
Tuohon päällekytkentään kun piti saada tuo haluttu minimipituus, niin kokeillaan nyt tapaa missä lasketaan vartille hinta paljonko on siitä vartista eteenpäin minimijakson sisään jäävien varttien yhteenlaskettu hinta, ja sitten aletaan kytkemään minimijaksoja päälle halvimmasta vartista lähtien. Koska nuo jaksot voi mennä päällekkäin, niin tuota jatketaan tilanne tarkistaen niin pitkään kunnes haluttu varttimäärä on päällä siinä kyseisessä jaksossa.
Tuossa tavassa mielestäni pitäisi tulla aika hyvin vain halvimmat tunnit kytkettyä, mutta on vielä arvoitus miten se käyttäytyy jaksojen rajalla, ja jääkö sinne minkälaisia katkoja sitten väliin. Saadaan varmaan ensimmäisiä testiajoja tässä lähipäivinä, ja minulla HomeAssistant ”testaa rajapintaa” kotona, eli hakee sieltä vain ohjaustietoa mistä jää sitten se hiatoriagraafi, niin laitan tänne sitten lisätietoa.
Jep, tuo "Jossain Rajoissa" lienee se Holy Grail tässä.
Kokielin aiemmin viikonloppuna sellaista "kiristyvän pakkasen havainnoijaa", että analysoin aina 8h optimointiperiodia seuraavan kahden 8h periodin keskilämpötilaa.
- Laitoin analysaattoriin konfiguroitavan thresholdin, kuinka paljon periodin keskilämpötilan pitää muuttua, jotta muutos tulkitaan kylmenemiseksi tai lämpenemiseksi.
- Käytin testivaiheessa thresholdina 1 astetta.
- Eli suomeksi: Jos klo 00-08 välillä keskilämpötila on -5 ja klo 08-16 keskilämpötila on -7, niin tässä on eroa 2 astetta, joka on suurempi kuin tuo threshold.
- Jos periodin 1 ja 2 välillä on havaittu lämpötilapudotus JA periodin 2 ja 3 välillä suunta ei käänny takaisin ylös
- Niin silloin periodi 1 saa periodin 2 lämmitystarpeen. Periodien 2 ja 3 lämmitystarpeet pidetään ennallaan.
Mainitsin tämän lähinnä sillä, että tuo lämmityksen siirtäminen "Jossain Rajoissa" pelkkien hintojen perusteella ei ole kovin hyvä idea kiristyvien pakkasten aikaan.
Joo, tuo Jossain Rajoissa on juurikin se ”äly” minkä eteen on tarkoitus jatkossa sitten tehdä työtä. Tuo muu on puhdasta mekaniikkaa sinällään.Jep, tuo "Jossain Rajoissa" lienee se Holy Grail tässä.
Kokielin aiemmin viikonloppuna sellaista "kiristyvän pakkasen havainnoijaa", että analysoin aina 8h optimointiperiodia seuraavan kahden 8h periodin keskilämpötilaa.
Sitten tein sellaisen viritelmän, että
- Laitoin analysaattoriin konfiguroitavan thresholdin, kuinka paljon periodin keskilämpötilan pitää muuttua, jotta muutos tulkitaan kylmenemiseksi tai lämpenemiseksi.
- Käytin testivaiheessa thresholdina 1 astetta.
- Eli suomeksi: Jos klo 00-08 välillä keskilämpötila on -5 ja klo 08-16 keskilämpötila on -7, niin tässä on eroa 2 astetta, joka on suurempi kuin tuo threshold.
Tämä vaikutti ensivilkaisulta oikein hyvältä edesauttamaan sitä, että kiristyvien pakkasten aikaan lämmitystä lisätään hieman etupeltoon.
- Jos periodin 1 ja 2 välillä on havaittu lämpötilapudotus JA periodin 2 ja 3 välillä suunta ei käänny takaisin ylös
- Niin silloin periodi 1 saa periodin 2 lämmitystarpeen. Periodien 2 ja 3 lämmitystarpeet pidetään ennallaan.
Mainitsin tämän lähinnä sillä, että tuo lämmityksen siirtäminen "Jossain Rajoissa" pelkkien hintojen perusteella ei ole kovin hyvä idea kiristyvien pakkasten aikaan.
Minulla ei ole siihen toistaiseksi mitään vastauksia, mutta ajatuksena on yrittää saada siitä myös jollain tapaa parametroitava. Jos ajatellaan tuota alkuperäistä blokkiajattelua, eli lämmitystarve lasketaan 3h jaksoissa mutta käyttäjä valitsee 12h lämmitysjakson, niin siinä tilanteessa voidaan sallia todennäköisesti 100% vähennys jonkin jakson lämmityksessä jos se vaan mahtuu muihin. Sitten taas jos käytetään 3h periodia, eli lämmitystä täytyy joka jaksossa olla kun talo ei juuri varaa, niin todennäköisesti voidaan vähentää vähemmän, ehkä maksimissaan 50%?
Tätä täytyy testailla erilaisilla vaihtoehdoilla, ja oikeastaan olennaisinta olisi ehkä löytää nyt ne parametrit mitä säädetään ja minkä perusteella. Eli juuri tuota mitä teet, ja tuo raja-arvon etsiminen siihen koska täytyy ennakoida ja kuinka paljon on hyvä lähtökohta.
Noniin, ajatus alkaa jäsentyä...
For the sake of simplicity, seuraava konsepti on vasta tilanteeseen, jossa vuorokausi on jaettu 3 x 8 periodiin. Alla periodeja kutstuaan A1, A2, A3, seuraavan päivän periodeja B1, B2, B3 ja sitä seuraavan C1, C2, C3. Optimoitava vuorokausi on B.
Ensin periodeille B1, B2, B3 lasketaan normaalisti kyseisen periodin keskilämpötilan mukaan lämmitystarve. Sitten siirrytään analysoimaan kuinka paljon näillä periodeilla on joustovaraa siihen, voidaanko esim. periodilta B2 siirtää lämmitystä B1:lle tai B3:lle.
Vuorokauden ensimmäisen periodin (B1) kohdalla tarkastellaan ensin edellisen vuorokauden viimeistä periodia (A3).
For the sake of simplicity, seuraava konsepti on vasta tilanteeseen, jossa vuorokausi on jaettu 3 x 8 periodiin. Alla periodeja kutstuaan A1, A2, A3, seuraavan päivän periodeja B1, B2, B3 ja sitä seuraavan C1, C2, C3. Optimoitava vuorokausi on B.
Ensin periodeille B1, B2, B3 lasketaan normaalisti kyseisen periodin keskilämpötilan mukaan lämmitystarve. Sitten siirrytään analysoimaan kuinka paljon näillä periodeilla on joustovaraa siihen, voidaanko esim. periodilta B2 siirtää lämmitystä B1:lle tai B3:lle.
Vuorokauden ensimmäisen periodin (B1) kohdalla tarkastellaan ensin edellisen vuorokauden viimeistä periodia (A3).
- Tsekataan, oliko periodilla A3 yli- tai alilämmitystä periodin A3 lämmitystarpeeseen nähden. Eli jos lämpötilan mukaan olisi vaikka tarvinnut lämmittää 4h, mutta näistä 1h oli siirretty aikaisemmaksi periodille A1 tai A2, niin tästä syntyy "lämmitysvelkaa" jonka vuoksi uuden vuorokauden ensimmäisellä periodilla B1 on vähemmän joustovaraa.
- Tsekataan myös, päättyikö edellisen vuorokauden viimeinen periodi A3 lämmitykseen vai ei. Jos päättyi, niin sitten uuden vuorokauden ensimmäiselle periodille B1 on enemmän joustovaraa kuin esim. tilanteessa, jossa kaikki A3-periodin lämmitys tapahtui A3:n alussa.
- Lämpimällä kelillä joustovaraa on enemmän kuin kylmällä
- Kunkin periodin kohdalla tarkastellaan aina myös kahden seuraavan periodin lämpötiloja. Eli B1:n kohdalla periodeja B2 ja B3. B2:n kohdalla B3 ja C1. Ja B3:n kohdalla C1 ja C2.
- Jos ilma on kylmenemään päin, niin jostovara pienenee. Jos kumpikin seuraavista periodeista on lämpimämpiä, niin sitten joustovara lisääntyy.
- Kun jokaisen periodien B1-B3 joustovarat on selvillä, tiedetään myös näiden periodien ei-joustavan lämmitystarpeen määrä.
- Sanotaan vaikka, että periodien B1 lämmitystarve on 5h, josta joustavaa on 2h. Tämä tarkoittaa että 3h on ei-joustavaa.
- Valitaan ensin tälle 3h ei-joustavalle osalle halvimmat ajankohdat (joko yhtenäinen 3h jakso tai sitten pilkottuna halutunpituisiin minimijaksoihin)
- Kun ei-joustavat lämmitystarpeet on allokoitu, siirrytään joustavien lämmitystarpeiden allokointiin
- Valitaan ensin se lämmitysperioidi (B1-B3), jonka vapaat slotit ovat kalleimpia. Oletetaan että tämä on vaikkapa keskimmäinen periodi B2.
- Tyydytetään periodin B2 joustava lämmitystarve koko vuorokauden halvimmilla vapaana olevilla sloteilla, mistä tahansa periodista nämä slotit löytvätkin.
- Sitten sama temppu periodien B1 ja B3 joustavalle lämmitystarpeelle.
- Tähän voisi vielä tehdä sellaisen hifistelyn, että näitä joustavia tunteja pyritään liimaamaan jo valittujen slottien kylkeen, jolloin taas kompuran käynnistysmäärät minimoituvat.
Sotken vähän jäsentyneisyyttä!
Tykkään ajatuksesta määrittää jakson pakollinen lämmitys ja joustolämmitys. Lähtisin kuitenkin itse siitä, että käsitellään asiaa lämmitystarpeena/energiamääränä mahdollisimman pitkään. Ongelmaksi toki tulee yksinkertaistetussa mallissa se, että vaaditaan Pörssärin automaattilaskennan tapainen järjestelmä, missä käyttäjä ei määritäkään lämmityslaitteelle tuntimäärää, vaan jokaiselle lämmityslaitteelle antotehon minkä perusteella lasketaan se jakson tarvittava lämmitysmäärä.
Eli tässä on tavallaan kaksi tapaa lähestyä asiaan. Jos haluaan optimoida vain yksittäistä lämmityslaitetta jossa käyttäjä kertoo järjestelmälle tarvittavat lämmitystunnit kussakin lämpötilassa, niin sitten voidaan edetä tuolla esittämälläsi lämmitysajankohtavalinnalla. Meilläkin toki semmoinen on nimellä "mukavuuslämmitys", eli siinä mennään juurikin järjestelmä kerrallaan. Silloin lämmitystarvetta ei käsitellä kilowattitunteina, vaan ulkolämpötilan perusteella ekstrapoloituna aikana kyseiselle ajanjaksolle.
Jos puolestaan halutaan mahdollistaa useamman lämmitysjärjestelmän yhtäaikainen hyödyntäminen, niin sitten asiaa pitää tuossa vaiheessa vielä ajatella kilowattitunteina, koska eri järjestelmät vaativat eri ajan saman lämmitysenergian tuottamiseen.
Eli konkretiaa:
Mielestäni tuo lämpimän ja kylmän kelin erillinen joustovara tulee pääsääntöisesti taklattua jo sillä, ettää mitä kylmempää, niin sitä suurempi osa lämmitystunneista täyttyy ja sama päinvastoin. Eli joustoa tulee jo luonnostaan vähemmän. En lähtisi alussa siihen tekemään mitään sen kummempaa tarkastelua.
Ehkä tasaus olisi hyvä tehdä aina 3 periodin perusteella (edellinen - kuluva - seuraava), eli huolehditaan siitä, että toteutunut lämmitysenergian määrä tulee olemaan todellinen lämmitystarve. Periodin pituutta muuttamalla voidaan sitten vaikuttaa siihen, että kuinka paljon järjestelmä sallii optimointivaraa.
Optimitilanteessa lämmitysajankohtien valinta tehdään vasta lopuksi, ja siihen voi tarvittaessa jopa lisätä sitten älyä siihen suuntaan, että millä järjestelmien kokonaisuudella lämmitysenergia kannattaa tuottaa. Jos on oikein kylmää ja ilpin COP huono, suorasähkön käyttö ei ole enää niin epäedullista jos on todella halpoja vs todella kalliita tunteja periodin sisällä jne... Tämä vaatii lämmitystarpeen laskennan tarvittavan lämmitysenergian kautta.
Tykkään ajatuksesta määrittää jakson pakollinen lämmitys ja joustolämmitys. Lähtisin kuitenkin itse siitä, että käsitellään asiaa lämmitystarpeena/energiamääränä mahdollisimman pitkään. Ongelmaksi toki tulee yksinkertaistetussa mallissa se, että vaaditaan Pörssärin automaattilaskennan tapainen järjestelmä, missä käyttäjä ei määritäkään lämmityslaitteelle tuntimäärää, vaan jokaiselle lämmityslaitteelle antotehon minkä perusteella lasketaan se jakson tarvittava lämmitysmäärä.
Eli tässä on tavallaan kaksi tapaa lähestyä asiaan. Jos haluaan optimoida vain yksittäistä lämmityslaitetta jossa käyttäjä kertoo järjestelmälle tarvittavat lämmitystunnit kussakin lämpötilassa, niin sitten voidaan edetä tuolla esittämälläsi lämmitysajankohtavalinnalla. Meilläkin toki semmoinen on nimellä "mukavuuslämmitys", eli siinä mennään juurikin järjestelmä kerrallaan. Silloin lämmitystarvetta ei käsitellä kilowattitunteina, vaan ulkolämpötilan perusteella ekstrapoloituna aikana kyseiselle ajanjaksolle.
Jos puolestaan halutaan mahdollistaa useamman lämmitysjärjestelmän yhtäaikainen hyödyntäminen, niin sitten asiaa pitää tuossa vaiheessa vielä ajatella kilowattitunteina, koska eri järjestelmät vaativat eri ajan saman lämmitysenergian tuottamiseen.
Eli konkretiaa:
Mielestäni tuo lämpimän ja kylmän kelin erillinen joustovara tulee pääsääntöisesti taklattua jo sillä, ettää mitä kylmempää, niin sitä suurempi osa lämmitystunneista täyttyy ja sama päinvastoin. Eli joustoa tulee jo luonnostaan vähemmän. En lähtisi alussa siihen tekemään mitään sen kummempaa tarkastelua.
Ehkä tasaus olisi hyvä tehdä aina 3 periodin perusteella (edellinen - kuluva - seuraava), eli huolehditaan siitä, että toteutunut lämmitysenergian määrä tulee olemaan todellinen lämmitystarve. Periodin pituutta muuttamalla voidaan sitten vaikuttaa siihen, että kuinka paljon järjestelmä sallii optimointivaraa.
Optimitilanteessa lämmitysajankohtien valinta tehdään vasta lopuksi, ja siihen voi tarvittaessa jopa lisätä sitten älyä siihen suuntaan, että millä järjestelmien kokonaisuudella lämmitysenergia kannattaa tuottaa. Jos on oikein kylmää ja ilpin COP huono, suorasähkön käyttö ei ole enää niin epäedullista jos on todella halpoja vs todella kalliita tunteja periodin sisällä jne... Tämä vaatii lämmitystarpeen laskennan tarvittavan lämmitysenergian kautta.
Tuo on validi argumentti, siirrynpä siis omassa logiikassani lämmitystarpeeseen enkä lämmitysaikaan (kunnes vasta ihan lopussa). Oman maalämpöpumppuni tapauksessa ajatukset pysyvät aika kivasti kasassa, kun on helppo muuntokerroin kun antoteho on 8 kW josta tulee kivasti kokonaisluku 2 kWh jokaiselle vartille.
En ole ihan varma ymmärsinkö mitä tarkoitit tällä. Anyway, oma kohtalaisen hyvin varaava kivitalomme toimii eri lämpötiloilla aika eri tavoilla tuon joustovaran suhteen. Jos ollaan selvästi plussan puolella, voin tarvittaessa siirtää päiväajan lämmityksen kokonaan yölle. Pakkasella taasen on tarve lämmittää (lyhyemmin) myös päivällä, joka "katkaisee" sisälämpötilan laskun. Lähinnä ajan takaa tällä sitä, että miten tuo joustovara saadaan laskettua siten, että plussakeleillä 100% lämmitystarpeesta saadaan joustavaksi.
Tarkoitin sitä, että jos ajatellaan vaikkapa 50% olevan joustoa joka periodilla, ja loput joustamatonta, niin 0-kelillä "joustamatonta" lämmitystä on huomattavan paljon vähemmän kun kunnon pakkaskelillä. Eli sitä kautta ikäänkuin luonnostaan tuon joustamattoman lämmityksen määrä lähestyy nollaa, vaikka toki ei aivan nollaan mene. Hieman siinä optimaalisuutta saatetaan menettää, mutta uskoisin ettei sillä ole kovin isoa merkitystä isossa kuvassa ja sen vuoksi voidaan logiikkaa tuon osalta hyvinkin yksinkertaistaa olemaan välittämättä asiasta.
Tarvittaessa sitä sitten voi jatkossa vielä optimoida tekemällä joustoprosentista myös ulkolämmön perusteella liukuva.
Viimeksi muokattu:
Testailin tuota joustamattomien vs. joustavien tuntien konseptia. Se näyttäisi tuottavan oikein mukavannäköisiä tuloksia.
- Testasin jakaa vuorokauden 4x6h osaan.
- Jokaiselle osalle haetaan ensin halvin yhtäjaksoinen lämmitysjakso ei-joustaville tunneille (note to self: pitää testata vielä tarkemmin tosi kylmillä päivillä)
- Tässä optimoinnin vaiheessa sallin tunnin limityksen, eli ensimmäinen optimointi tehdään 00-07 välille, toinen 05-13 jne
- Joustavat tunnit laitetaan tunnin könteissä, paitsi viimeinen joka laitetaan esim. 75 min pätkässä ettei tule vartin pätkäkäyntä (note to self: laita "jakojäännös" ensimmäiseen eikä viimeiseen)
- Liittynyt
- 14.04.2022
- Viestejä
- 253
Vastaanpa vanhaan viestiin ja keskusteluihimme, joita kävimme reilu kuukausi sitten. Tuolloin sähköauto oli hankinnassa ja laturi vielä asentamatta. Nyt on auto ja laturi. Laturin sähkönsyöttöä ohjataan ulkoisen kontaktorin kautta Shelly-releen ja pörssärin hintatiedon ohjaamana.
Ongelma ei ole akuutti, mutta odotan aikanaan uuden sivuston mahdollistavan yhtenäisen, keskimääräisesti halvimpien tuntien käyttämisen, sillä vastaan tuli viikolla pieni haaste auton lataamisen kanssa. Lähtökohtaisesti auto latautuu hyvin myös tuntien pätkissä lataamalla. Auto ei näe tuntien pätkimisessä laturin virhetilannetta, mitä myös aikaisemmin täällä kysyin. Olen asettanut autoon akunsäästötoiminnon, joka lataa akun maksimissaan 80 %:n tasoon saakka. Mikäli auton haluaa ladata täyteen, battery care -toiminnon voi ohittaa kertaluontoisesti seuraavan latauksen ajaksi. Tässä yhteydessä pörssisähkön tuntihintojen mukaan pätkittävä lataus aiheuttaa ongelman, kun ohitusmahdollisuus menetään ensimmäisen lataussyksin aikana.
Asia konkretisoitui tällä viikolla, kun kokeilin ladata auton 100%:n tasoon. Lataus keskeytyi n. 90 %:n tienoille, kun yön ensimmäinen latausjakso riitti lataamaan auton tähän tasoon saakka. Ensimmäisen latausjakson jälkeen battery care -toiminto aktivoitui jälleen ja kun saman yön toinen latausjakso käynnistyi, ei auto ottanutkaan virtaa vastaan, sillä lataustaso oli jo ylittänyt akunsäästötoiminnon 80 %:n rajan.
Tämä on hyvä konkretia siitä, että tuo yhtenäinen jakso tarvitaan. Itse olin ajatellut sitä lähinnä pakkaskelejä varten, mutta tämä käyttötarkoitus on voimassa ympäri vuoden.
Se on jo toiminnallisesti toteutettu ja testissä tuossa lämmitysohjauksessa, missä käytännön sovellutus on määrittää pienin minimikäyntiaika laitteelle. Käytännössä samaa kaavaa fiksaamalla saadaan toteutettua tuo halutun tuntimäärän mukainen ”minimiaika” myös näihin muihin ohjauksiin, eli lopputulemana on yksittäinen halvin jakso.
Tämänhetkinen tavoite sivustopäivityksen toteutumiselle on 20.5. alkavalla viikolla siitä yksinkertaisesta syystä, että ”oikeat työt” häiritsee kyseisellä viikolla vähiten tätä projektia, ja saadaan ajoitettua päivitys semmoiseen hetkeen missä on oikeasti aikaa fiksailla samantien mahdollisesti esiintulevat akuutit ongelmat.
Uusi backend on pyörinyt nyt testirajapinnassa noin pari viikkoa melkolailla ongelmitta, joskin ihan jokaista mahdollista asetusvariaatioa ei ole ehditty vielä testaamaan eikä todennäköisesti hoksata testata. Todennäköisesti tuo sulakekoon mukainen kuormansuunnittelu ei ehdi mukaan heti tähän päivitykseen, mutta toisaalta se helpottaa isoa uudistusta kun se tehdään osissa, ja todellinen tarve sille käytännössä tulee vasta seuraavan lämmityskauden ainana.
Hieman väliaikatietoa...
Sain algoritmin tunkattua aika kivaan kuosiin. Tässä konseptuaalisesti mitä se tekee.
Esimerkki 1: viikon keskilämpötila +0.44
Esimerkki 2: Viikon keskilämpötila -2.15
Esimerkki 3: viikon keskilämpötila -5.72
Esimerkki 4: Viikon keskilämpötila -11.37
Esimerkki 5: Viikon keskilämpötila +7.07. Tässä on ehkä muutama lämmitysjakso ylimääräistä, mutta silti viikkotasolla tarkasteltuna vain saman verran kuin mitä maalämppumppuni vetelisi päivässä tai parissa jos antaisin sen toimia oman automatiikkansa varassa.
Työlistalla on vielä kaksi ominaisuutta.
1) Teen vielä sellaisen stepin tuohon välin, että juuri ennen kiristyvää pakkasta joustoa vähennetään ja lämmitystä lisätään hieman etupeltoon. Päädyin tässä siihen, että tarkastellaan aina senhetkistä ja kahta seuraavaa jaksoa:
Markus
Sain algoritmin tunkattua aika kivaan kuosiin. Tässä konseptuaalisesti mitä se tekee.
- Vuorokausi on jaettu 4 x 6h jaksoon
- Initialize: Jokaiselle jaksolle lasketaan sääennusteen perusteella lämmitystarve. Tarve jaetaan aluksi 50%/50% suhteessa joustavaan ja ei-joustavaan osaan.
- Merge short heating periods: Kahta perättäistä jaksoa verrataan toisiinsa. Jos jomman kumman jakson lämmitystarve (joustava ja ei-joustava yhteensä) on lämmitystunneiksi muutettuna alle määritellyn raja-arvon (käytin 1h rajaa testeissä), yhdistetään lämmitystarpeet kylmemmälle jaksolle.
- Optimize non-flexible heating need: Tämän jälkeen jokaisen jakson ei-joustava lämmitystarve allokoidaan halvimmalle yhtäjaksoiselle ajalle.
- Optimize flexible heating need: Kaikkien jaksojen joustava lämmitystarve lasketaan yhteen ja nämä allokoidaan lämmitystunneiksi muutettuna tunnin könteissä. Jakojäännös yhdistetään ensimmäiseen tuntiin.
- Fix the gaps: Tämän jälkeen koko optimointitulos analysoidaan ja jos kahden lämmitysjakson väliin jää konfiguroitavissa olevan levyinen lyhyt OFF-jakso (käytin testeissä 1h 15 min), niin lämmitysjaksot yhdistetään siirtämällä toista lämmitysjaksoista hinnan perusteella joko oikealle tai vasemmalle. Tässä on konfiguroitavissa oleva hintaraja (käytin testeissä 1 sentin hintarajaa), eli tästä siirrosta voi ottaa hintamielessä "takkiin", jos arvostaa yhtenäisiä käyntijaksoja enemmän kuin viimeisen sentin optimointia hintamielessä. Tuon hintarajan tarkoitus on lähinnä se, että tuota yhdistämistä ei tehdä jos välissä sattuu olemaan huippukallis hintapiikki. Mainittakoon että tämä fix the gaps -osuus osoittautui hieman kompleksimmaksi kuin äkkiseltään voisi arvata, mutta tulipahan tehtyä.
Esimerkki 1: viikon keskilämpötila +0.44
Esimerkki 2: Viikon keskilämpötila -2.15
Esimerkki 3: viikon keskilämpötila -5.72
Esimerkki 4: Viikon keskilämpötila -11.37
Esimerkki 5: Viikon keskilämpötila +7.07. Tässä on ehkä muutama lämmitysjakso ylimääräistä, mutta silti viikkotasolla tarkasteltuna vain saman verran kuin mitä maalämppumppuni vetelisi päivässä tai parissa jos antaisin sen toimia oman automatiikkansa varassa.
Työlistalla on vielä kaksi ominaisuutta.
1) Teen vielä sellaisen stepin tuohon välin, että juuri ennen kiristyvää pakkasta joustoa vähennetään ja lämmitystä lisätään hieman etupeltoon. Päädyin tässä siihen, että tarkastellaan aina senhetkistä ja kahta seuraavaa jaksoa:
- Jos seuraava jakso (current +1) kylmenee, ja lämpötila ei sen jälkeen (current +2) nouse (toisin sanoen: lämpötila pyysyy samalla kylmemmällä tasolla tai kylmenee vielä lisää), niin sitten tuolle "nollajaksolle" lisätään lämmitystarvetta ja ei-joustavan lämmitystarpeen osuutta vähennetään.
- Näin saadaan ajettua lämpöä betonilaattaan (tai muuhun varaavaan elementtiin) jo etupeltoon tai ainakin ohjattua lämmitystä niin, että juuri ennen kylmenemistä ei tulisi pitkää lämmityksetöntä aikaa.
- Jos forecast.solar:n aurinkotuotantoennusteen mukaan huomisesta on tulossa aurinkoinen päivä, niin sitten huomisen päiväajan jaksojen lämmitystarvetta lasketaan.
Markus
Uutiset
-
Corsair julkaisi 30 millimetrin paksuiset RS Max -tuulettimet ilman RGB-valoja
1.5.2024 22:47
-
Nubian 599 euron hintainen taittuvanäyttöinen Flip 5G -älypuhelin saataville Euroopassa
29.4.2024 22:10
-
EHA Awards 2024 -finalistit julki
29.4.2024 20:09
-
HP:lta langattomat HyperX-nappikuulokkeet ja -pelihiiri sekä uusi Omen-pelikannettava
27.4.2024 01:07
-
Live: io-techin Tekniikkapodcast (17/2024)
26.4.2024 12:29
Uutisia lyhyesti
-
Asus julkaisee Snapdragon X -kannettavan 20. toukokuuta- Vastauksia: 1
-
AMD juhlistaa 55 vuotista taivaltaan
- Vastauksia: 2
Uusimmat viestit
-
-
-
Codemasters EA Sports WRC <PC|PS5|XBOX X|S>- Viimeisin: WalluWaan
-
