Foorumilaisten automaatioalgoritmit lämmityksen hintaoptimointiin?

  • Viestiketjun aloittaja Viestiketjun aloittaja Temez
  • Aloituspäivämäärä Aloituspäivämäärä
Huomenna (la) ja ehkä seuraavanakin päivänä (su) on pörssisähkö halpaa ja ilmakin lämpenee. Menneet viikot ovat olleet siis pörssisähkön hinnan osalta kalliita ja ilma kylmää. Öljyllä on lämmitetty taloa. Nyt, ensi yönä tulee automatisoitu muutos öljystä sähkölämmitykseen (boileri, lattialämmitys ja ilp:t. Ilp:t tosin vain lämpötilasäädöllä.

Säätöohjelma poistaa luvan öljylämmityksestä ja antaa luvan em kun pörssisähkön hinta painuu alle 3 c/kWh (klo 05.). Tähän on ollut valmius jo noin vuoden verran mutta nyt vasta kokeeksi käyttöön. Krafiikkaa muutoksesta myöhemmin.

Säätöohjelma on kuitenkin tehty niin että pörssisähkön hinta vaikuttaa em laitteiden asetusarvoon ja esim tuo 3 c/kWh raja ei välttämättä tarkoita sitä että boileri varautuisi heti "täyteen" vaan vasta silloin kun pörssisähkö on halvimmillaan. Saunominenkin tekee jotain tähän .

Saapi nähdä miten menee! :grandpa:
 
Minulla samansuuntaista tapahtuu, mutta vaihtoehtoinen lämmitystapa on polttopuu ja varaavat takat. Ehkä laitan jossain vaiheessa kuvaajia joulukuun sähkönkulutuksista. Tänään "pompsahtaa".

Puhelimella eilen otettu kuvankaappaus "ohjauksesta" alla. Sähkölämmitystä napsahti päälle nyt aamupäivästä, kun hinta halpeni. Sähkölämmityksen hintarajan alle jääviä tunteja jäi myös "hyödyntämättä" aamulta, kun automaation mielestä päivän energiantarve saavutetaan vähemmällä määrällä tunteja. Lisäksi huomionarvoista, että myös PILPin käymistä automatiikka on päättänyt (yrittää) rajoittaa, sillä pe 15.12. iltapäivän hintojen ollessa niin korkeat tuli COP huomioiden siltikin halvemmaksi tehdä kyseinen lämpöosuus tänään 16.12. Lämpötilat talossa eivät ole tasaiset, mutta aamutakissa ei tullut aamusella kuitenkaan vilu.

1702716569910.png
 
Minulla samansuuntaista tapahtuu, mutta vaihtoehtoinen lämmitystapa on polttopuu ja varaavat takat. Ehkä laitan jossain vaiheessa kuvaajia joulukuun sähkönkulutuksista. Tänään "pompsahtaa".

Puhelimella eilen otettu kuvankaappaus "ohjauksesta" alla. Sähkölämmitystä napsahti päälle nyt aamupäivästä, kun hinta halpeni. Sähkölämmityksen hintarajan alle jääviä tunteja jäi myös "hyödyntämättä" aamulta, kun automaation mielestä päivän energiantarve saavutetaan vähemmällä määrällä tunteja. Lisäksi huomionarvoista, että myös PILPin käymistä automatiikka on päättänyt (yrittää) rajoittaa, sillä pe 15.12. iltapäivän hintojen ollessa niin korkeat tuli COP huomioiden siltikin halvemmaksi tehdä kyseinen lämpöosuus tänään 16.12. Lämpötilat talossa eivät ole tasaiset, mutta aamutakissa ei tullut aamusella kuitenkaan vilu.

Näytä liitetiedosto 91686
Onko muuten ha companion app käytössä androidluurissa? Kysyn siksi että minulla ainakin noin monta eri lähdettä apexchartissa kaataa koko appin.
 
Onko muuten ha companion app käytössä androidluurissa? Kysyn siksi että minulla ainakin noin monta eri lähdettä apexchartissa kaataa koko appin.
On joo käytössä. Ei ole ollut ongelmia. Välillä ehkä vähän hitaasti renderöi puhelimessa graafin tai reagoi puhelimen kääntämiseen pystystä vaakaan, mutta ei muita ongelmia.
 
Onko muuten ha companion app käytössä androidluurissa? Kysyn siksi että minulla ainakin noin monta eri lähdettä apexchartissa kaataa koko appin.

Täällä taitaa yhdessä näkymässä olla parhaimmillaan 9 eri apexchartia, joissa neljästä kuuteen lähdettä. Pääosin toimii mobiilisovelluksella ihan hyvin.

Ongelmia tuottaa paljon datapisteitä sisältävät lähteet, jotka ehkä vielä päivittyvät usein, esim. päävirtojen hetkellinen teho ja näiden summa. Näitä ei tarvitse olla näkymässä kuin yksi tai kaksi, kun joillain sovellusversioilla on tullut ongelmaa.
 
Niin joo, varsinaistesta aiheestakin vielä. Nyt tuli taas jatkuvasti halventuvan sähkön kanssa tilanne, että lämmitys ei tahdo lähteä kunnolla päälle. Sallitut tunnit karkaa vain eteenpäin, kun uusia halvimpia"tarkasteluikkunaan" pikkuhiljaa tulee.

Tämä näkyy siinä, että sisälämpötila seilaa hieman normaalia alempana eli on ollut eilisestä iltapäivästä luokkaa 20,5 astetta.

Perälautana on toki huonelämpötila, joka alkaa vaikuttaa pyyntiin aika voimakkaasti, jos lämpötila tästä vielä tippuisi. Toisaalta, jos vuorokausitasolla ei toteudu riittävästi lämmitystunteja, lisätään lämmitystunteja tulevalle jaksolle.
 
En ole vielä toteuttanut, mutta koetan tähän avata pohtimaani parannusta omaan ohjaukseeni (joka toimii siis niin, että lämpötilaennusteen perusteella laskettu kokonaisenergiantarve katetaan järjestyksessään halvimmalla mahdollisella lämmitystavalla kunnes energiantarve on katettu). Minulla on vähän jotain samankaltaista ongelmaa kuin Sukella. Ja myös sellaista "ominaisuutta", että sisälämpötila seilaa huonoimmillaan 2-3 astetta eestas, kun varaavuutta on heikosti ja halpaan aikaan puskettu lämpö on näkyy melkein heti sisälämpötilassa.

Ajattelin, että jos tekisi malliin jonkinlaisen rangaistuksen riippuen etäisyydestä lämmityshetkeen. Eli jos tänään kello 15-16 tarvitaan 5kWh energiaa, niin oikean sähkönhinnan päälle laitettaisiin jokin x snt/kWh * etäisyys tunteina lämmityshetkeen. Näin kyseisen hetken lämmitystarvetta ei katettaisi huomenna kello 23-24 eli yli 30h päästä - paitsi, jos hinnat tosiaan ovat niin "sekaisin", että "sakkolisästä" huolimatta kyseinen tunti jäisi halvimmaksi.

Sopivasti tuo x snt/kWh "sakko" valitsemalla saisi varmaan ohjattua lämmitystä lähemmäksi tarvehetkeä kuitenkaan menetettäisi sitä, että jos siellä onkin 12h pätkä 2€/kWh -> ei käytetä kyseisiä hetkiä kuin äärimmäisessä hädässä. Jos tarkasteluväli kovakoodataan, että on pakko lämmittää 12h jaksoissa (kyseinen pituus oli nyt vain satunnaisesti valittu), niin silloin lämmityshetki ei jousta.
 
Itsellä Pörssäri käytössä. Tyyliin LVV 4 halvinta tuntia. Jne.

Mutta tuossa on ongelma - esim. halvimmat tunnit ovat 04-06, ja ja sitten 02-04 edelliset halvimmat. Voi ihan mainiosti käydä niin, että LVV lämmittää 2 ekaa tuntia, ja halvimmat tunnit jää hyödyntämättä.

Eli sääntöpohjainen optimointi ei anna välttämättä optimia ratkaisua.

Linear Programming -tyyypinen ohjelmtointi ratkaisisi asian. Eli on 1) syötearvot - esim. sähkönhinta 2) rajoitteet - esim. lämpötila tai LVV:n teho ja 3) tavoitefunktio - tässä varmaankin minimoi kokonaiskustannus.

Sitten haetaan optimiratkaisu.
Tähän on näköjään olemassa ratkaisuja Home Assistanttiin https://emhass.readthedocs.io/en/latest/

Tuossa on mukana esim. aurinkosähköennuste jne.
Mikään jokamiehen ratkaisuhan tuo ei ole, vaan vaatii aikapaljonkin tekniikan taitamusta ja myös matematiikan osaamista, että saa homman toimimaan.

Että toimisi optimisti, niin vaatisi esim LVV:n lämmön mittausta lähtöarvoksi = saa määrittettyä lämmitystarpeen ja sen mukaan esim avausskenaariossa voi tiettää etukäteen, että 2 halvinta tuntia oikeasti riittävät.

Onko jollakin kokemusta EMHASSista?
 
Viimeksi muokattu:
Oma logiikka on ollut muualla jo esillä, mutta laitetaan myös tänne. Käytössä Nilan EC9, jonka lämmitysvastuksia ohjataan varaamaan lattiaan lämpöä. Tämän hetkinen logiikka on "Tunti noin maksimilämmitystä halvimmalla tunnilla nollassa ja aina tunti lisää lämmitystä seuraavaksi halvimmalta tunnilta lämpötilan tippuessa -5C". Nilan ei anna suoraan ohjata vastuksia, joten logiikka on toteuttu ohjaamalla lattialämmitykseen lähtevän veden minimilämpöä, minkä takia ohjaus on vähän sinne päin. Tämä on ihan hyvä aloitusarvaus, mutta varsinkin todella kylmillä keleillä tunti ei riitä. Tammikuussa automaatio pyöri noin kolme viimeistä viikkoa ja keskihinnaksi jäi vajaa 10 snt/kWh ilman marginaalia.

Omassa talossa valtaosa lämmityksestä hoituu ILP:n kautta, joten lattialämmityksen suurempi optimointi jääköön tekemättä ja keskityn lähinnä ajamaan laatoitetuille alueille mukavuuslämpöä hinnan perusteella (Pyynti 32C kun hinta siirtoineen alle 6,5 snt/kWh). Mikäli Nilan on ainoa tai pääsääntöinen lämmönlähde tätä kannattaisi kehittää vielä pidemmälle.

Alla vielä koodi siitä kiinnostuneille. sensor.average_temperature_difference_next_24_hours on periaatteessa tulevan 24h lämmitystarveluku, mutta onnistuin rikkomaan met.no integraation 24h ennusteen weather-cardin muutosten myötä ja tämän tarkkuus ei ole mitä pitäisi.

Koodi:
alias: Floor Heating Based on Rank and Temperature Difference
description: >-
  Set min supply temperature based on rank and temperature difference without
  considering electricity price
trigger:
  - platform: state
    entity_id: sensor.shf_rank_now
condition: []
action:
  - service: number.set_value
    entity_id: number.nilan_central_heating_min_supply_temperature
    data_template:
      value: >
        {% set electricity_price =
        states('sensor.shf_electricity_price_now')|float %} {% set rank =
        states('sensor.shf_rank_now')|int %} {% set temperature_difference =
        states('sensor.average_temperature_difference_next_24_hours')|float %}

        {% if electricity_price < 0.065 %}
          32
        {% else %}
          {% if temperature_difference > 29 %}
            {% if rank in [1, 2, 3, 4] %}
              32
            {% elif rank in [5, 6, 7, 8, 9] %}
              22
            {% elif rank >= 10 and rank <= 22 %}
              19
            {% elif rank in [23, 24] %}
              17
            {% else %}
              19  # Default value for ranks not covered above
            {% endif %}
          {% elif 22 <= temperature_difference <= 29 %}
            {% if rank in [1, 2, 3] %}
              32
            {% elif rank in [4, 5, 6, 7, 8, 9] %}
              22
            {% elif rank >= 10 and rank <= 22 %}
              19
            {% elif rank in [23, 24] %}
              17
            {% else %}
              19  # Default value for ranks not covered above
            {% endif %}
          {% elif 15 <= temperature_difference < 22 %}
            {% if rank in [1, 2] %}
              32
            {% elif rank in [3, 4, 5, 6, 7, 8, 9] %}
              21
            {% elif rank >= 10 and rank <= 22 %}
              18
            {% elif rank in [23, 24] %}
              17
            {% else %}
              19  # Default value for ranks not covered above
            {% endif %}
          {% else %}
            {% if rank == 1 %}
              32
            {% elif rank in [2, 3, 4, 5, 6, 7, 8, 9] %}
              21
            {% elif rank >= 10 and rank <= 22 %}
              18
            {% elif rank in [23, 24] %}
              17
            {% else %}
              19  # Default value for ranks not covered above
            {% endif %}
          {% endif %}
        {% endif %}

Nilanin kompressori pyörii 24/7 lämmityskaudella ja tekee sivussa riittävästi lämmintä käyttövettä meidän tarpeisiin. Lämmityskauden ulkopuolella LVV:ssä pidetään aina vähintään 30/35C lämpö ja muuten lisätään hinnan/tunti-rankin perusteella

Koodi:
alias: Hot Water Based on Electricity Price and Rank
description: ""
trigger:
  - platform: state
    entity_id: sensor.shf_rank_now
condition: []
action:
  - service: water_heater.set_temperature
    entity_id: water_heater.nilan_bottom_water_heater
    data_template:
      temperature: >
        {% set rank = states('sensor.shf_rank_now')|int %} {% set price =
        states('sensor.shf_electricity_price_now')|float %}

        {% if price < 0.065 %}
          55
        {% elif price >= 0.065 and price < 0.08 %}
          {% if rank == 1 %}
            55
          {% elif rank == 2 %}
            55
          {% else %}
            50
          {% endif %}
        {% elif price >= 0.08 and price < 0.20 %}
          {% if rank == 1 %}
            45
          {% elif rank == 2 %}
            40
          {% else %}
            35
          {% endif %}
        {% else %}
          {% if rank == 1 %}
            40
          {% elif rank == 2 %}
            35
          {% else %}
            30
          {% endif %}
        {% endif %}
 
Mites lvv:n rajat olette säädelleet paneelien kanssa? If 5min kulutus -2000wh, start LVV, if 5min kulutus 1000wh stop LVV? Mietin nyt valmiiksi millaiset rajat kannattaisi laittaa, pystyy toki kiinteällä nyt hieman pelaamaan ennakkoon ja tutkimaan mitä käy
 
Mulla oman käytön maksimointi perustuu netotukseen. Vastukset syö 3kW (tai 2kW) ja enimmäisylijäämät on 1-1,5kW. Yleensä 3kW ajan 13 minuuttia kahden peräkkäisen vartin (eli 30min) jaksoon yli 15min tasejaksorajan.
2kW vastusta yleensä 20min.
En välitä, jos menee vähän myynti- tai ostopuolelle.
Tuya apissa on kaikki tehtävä ajastimin ja käynnistysehdoin.
 
On tullut pikkuhiljaa kaiken muun ohella sorvailtua uutta versiota lämmityksen optimointialgoritmista ja mennee testiin tässä piakkoin. Aiemmin sentin kymmenysten takia lämmitystä ohjautui helposti aina ajallisesti samaan kasaan ilman merkittävää rahallista hyötyä ja tämä sai sitten sisälämpötilan heilumaan ehkä enemmän kuin olisi mukavaa.

Uusi algoritmi:
  1. Laske lämmitystarve tunneittain (parametreina ulkolämpötilaennuste, haluttu sisälämpötila, auringon säteilyennuste ja nykyinen yli-/alilämpö). Lopputulos siis, että kello 1 tarvitaan 2kWh, kello 2 tarvitaan 2,2kWh jne.
  2. Laske lämmityslaitteille € per tuotettu kWh -perushinta jokaiselle tunnille. Vaikkapa, että sähkön hinta on 3snt/kWh, mutta lämpöpumpun COP huomioiden hinta onkin vaikka 1snt/lämpökWh.
  3. Käy läpi lämmitystarpeet tunneittain alkaen sähkönhinnaltaan kalleimmasta tunnista (aloitus kalleimmasta, jotta on mahdollisimman paljon lämmittimiä "vapaana" sen hetken ohittamiseen).
    1. Lämmitystarpeet katetaan aina halvimmalla tuotantomuodolla, mutta kohdassa 2 lasketun perushinnan päälle lisätään lämmitystarpeen ja varsinaisen lämmityksen etäisyyteen perustuva "sakko" (kokeilen aluksi tämmöistä hatusta heitettyä +0,15snt per jokainen tunti). Käytännössä tämä tarkoittaa sitä, että jos kello 10 tarvitaan 2kWh energiaa ja sen saa kello 1 hintaan 1snt/kWh, mutta kello 6 hintaan 1,1snt/kWh, niin valitaan tuo kello 6, jotta ollaan lähempänä tarvehetkeä.

EDIT: käytännössä tällä saa siis aina kalleimmat hetket ohitettua perustuen siihen, että miten paljon on valmis maksamaan siitä, että lämmitys tapahtuu juuri tarvehetkellä eikä esim. kolmen, kuuden tai 12 tunnin päästä.
 
Lämmitystarpeet katetaan aina halvimmalla tuotantomuodolla, mutta kohdassa 2 lasketun perushinnan päälle lisätään lämmitystarpeen ja varsinaisen lämmityksen etäisyyteen perustuva "sakko" (kokeilen aluksi tämmöistä hatusta heitettyä +0,15snt per jokainen tunti). Käytännössä tämä tarkoittaa sitä, että jos kello 10 tarvitaan 2kWh energiaa ja sen saa kello 1 hintaan 1snt/kWh, mutta kello 6 hintaan 1,1snt/kWh, niin valitaan tuo kello 6, jotta ollaan lähempänä tarvehetkeä.

Itsellä on algoritmi joka laskee halvimman ajoituksen lämmittämiselle. Sen etuna on se, ettei tarvitse yrittää päätellä parasta strategiaa. Käytän sitä tosin vain käyttövesivaraajan lämmittämiseen, mutta algoritmi toki soveltuu kaikenlaiseen, missä tiedetään tarve ja kapasiteetti etukäteen.

Esimerkiksi se osaa määrittää kuinka paljon ja milloin kannattaa lämmittää etukäteen sähkön hinnan noustessa ja mihin väliin kannattaa sijoittaa lisälämmitys, jos hintapiikki on pitkä. Algoritmi siis hakee strategian, joka tuottaa minimikustannuksen.

Omassa algoritmissa ei siis lasketa "sakkoja" vaan lasketaan arvioitu hinta suunnitelman mukaiselle lämmitykselle. Algoritmi yrittää pienentää tätä kokonaishintaa lisäämällä ja vähentämällä lämmitystehoa kussakin 15 minutin slotissa kunnes mikään muutos ei enää paranna sitä. Raja-arvoina toimii varaajan minimi ja maksimilämpö, joita se ei saa ylittää ja varaajan lämpeneminen ja jäähtyminen on myös mallinnettu siihen.

Tarvittaessa se siis lämmittää varaajan vaikka maksimilämpöön, jos se on edullisempaa kuin lämmittäminen hintapiikin aikana.

Talon lämmittämisen optimoinnissa sen sijaan käytän ihan manuaalista ajastinta. Lämmitys (VILP) pois silloin kun se on liian kallista. Rakennus kuitenkin jäähtyy melko hitaasti niin tästä ei ole yleensä mitään haittaa.
 
Joo. Minulla ei varaajakapasiteettia ole kuin mitä nyt vanhasta Niben PILPistä löytyy kodinhoitohuoneen nurkasta. Käytännössä ei siis mitään.

Aiempi algoritmi optimoi juurikin hinnan mukaan niin, että halvimmat lämmitystavat (PILP, suorasähkö, varaavat takat) käyttöön, mutta siinä senttien säästö aiheutti sen, että kaikki lämmitys saattoi tapahtua yöllä vaikka päivällä olisi ollut vain 0,1 snt/kWh kalliimpi tunti. Tämä taas puutalossa saa aikaan merkittävän sisälämpötilan heilunnan, jota koetan tällä "sakottamisella" vähentää.

Suurempi varaajakapasiteettihan tietysti poistaisi tämän koko "sakottamisen" tarpeen.
 
senttien säästö aiheutti sen, että kaikki lämmitys saattoi tapahtua yöllä vaikka päivällä olisi ollut vain 0,1 snt/kWh kalliimpi tunti. Tämä taas puutalossa saa aikaan merkittävän sisälämpötilan heilunnan, jota koetan tällä "sakottamisella" vähentää.

Sinulla on puuttunut mallista rakennuksen jäähtyminen ja lämpötilarajat joissa pitäisi pysyä. Systeemillä pitää olla selkeä tavoite jota se optimoi. Sakotuksella voit toki ohjata sitä oikeaan suuntaan, mutta täydellinen optimointikin on mahdollista.
 
Näinhän se on. Ehkä jossain vaiheessa. Toistaiseksi minulle riittää 80/20-periaatteen perusteella epätäydellinen ratkaisu.
 
Sellainen huomio tässä tuli tehtyä kun asiaa ajattelin lisää, että kv-varaajan kanssa säätäminen tehdään ylilämmittämällä sitä juuri ennen kallista hintaa. On tärkeää osata mitoittaa se oikein, että lämmitys riittää hintapiikin yli eikä lämmitä liikaa. Pointti on se, että lämmöllä on alaraja, jota ei saisi alittaa.

Huonelämmön sijaan teen päinvastoin. En yleensä lämmitä etukäteen, paitsi jos on tulossa pitempi piikki. Annan lämmön laskea. Esim. tänään katkaisen VILPin kello 19 ja käynnistän kello 00. Käynnistys myöhemmin siksi, että heti aluksi se käy pitkään saadakseen lämmön takaisin, joten kannattaa odottaa siihen saakka kun hinta on hyvin halpa.
 
Eikö vain parin kalleimman tunnin estäminen lämmitykseen ja käyttövesivaraajan lämmitys vain yön halvimmilla tunneilla ole aivan riittävä hintaoptimointi
 
Eikö vain parin kalleimman tunnin estäminen lämmitykseen ja käyttövesivaraajan lämmitys vain yön halvimmilla tunneilla ole aivan riittävä hintaoptimointi
Ajattelin tälle talvikaudelle tätä jo käytössä ollutta rank-hintakatto systeemiä jalostaa niin että automatisoin sopivat lämpötilarajat joilla määritän monellako halvalla rankilla lämmitetään. Toistaiseksi olen manuaalisesti slideristä valinnut monellako rankilla lämmitetään kun sähkön hinta on kipurajan yläpuolella. Nyt on esim riittänyt ihan hyvin 16tuntia lämpöä ja 8 kalleinta pois. Joku varmistus pitänee laittaa jos lämpö putoaa liian alas jos kaikki kalliit tunnit peräkkäin.
Viime talvena oli käytössä myös ilpin puhalluslämmön pudotus kylmimmillä keleiilä. Enpä tiedä onko hyötyä.
ILP pääasiallisena lämmitysmuotona.
 
Eikö vain parin kalleimman tunnin estäminen lämmitykseen ja käyttövesivaraajan lämmitys vain yön halvimmilla tunneilla ole aivan riittävä hintaoptimointi

Mikä on riittävä? Käyttövesivaraajan lämmittäminen yöllä kerran vuorokaudessa ei ole optimaalinen ratkaisu enää nykyaikana. Sähköä kuluu vähiten, jos varaajaa lämmitetään tasaisesti koko päivä, jotta sen lämpötila pysyisi lähellä minimiä. Optimointi on sitten näiden kahden välillä tasapainoilua.

Tässä esimerkki seuraavalle vuorokaudelle

1728658092598.png

Siniset on lämmitysjaksoja. Ne osuvat selvästi juuri ennen hinnan nousua (punainen). Huomiselle on vielä huomioitu aurinkopaneelien tuottoa, joten aamulla ei tarvitsekaan lämmittää koko päiväksi.
 
Niben lämpökäyrää säädän automatiikalla alas ottaen ulkolämpötilan, hintapiikit (yli 30 c) ja vrk:n kuusi kalleinta tuntia huomioon. Toisaalta taas jos on halvempi hintajakso ennen selkeästi kalliimpaa jaksoa, käyrää säädetään vastaavasti pykälän ylös. Muuten mennään normikäyrällä. Talossa vesikiertoinen lattialämmitys.
 
Mikä on riittävä? Käyttövesivaraajan lämmittäminen yöllä kerran vuorokaudessa ei ole optimaalinen ratkaisu enää nykyaikana. Sähköä kuluu vähiten, jos varaajaa lämmitetään tasaisesti koko päivä, jotta sen lämpötila pysyisi lähellä minimiä. Optimointi on sitten näiden kahden välillä tasapainoilua.

Tässä esimerkki seuraavalle vuorokaudelle

Näytä liitetiedosto 100553
Siniset on lämmitysjaksoja. Ne osuvat selvästi juuri ennen hinnan nousua (punainen). Huomiselle on vielä huomioitu aurinkopaneelien tuottoa, joten aamulla ei tarvitsekaan lämmittää koko päiväksi.
Miksei olisi riittävä lämmittää kerran vuorokaudessa halvimmalla tunnilla? Minulla ainakin riittää yksi tunti lvv lämmitystä jotta hanasta tulee reilusti yli 50 asteista vettä koko päivän. Ei ole lämpötilaseurantaa, mutta nuppi osoittaa noin 65 astetta.
 
Palatakseni edelliseen, koska kiinnostaa olisilko lisäoptimoinnista mitään hyötyä, tarkistin viime yön lvv kulutuksen joka oli 2,75kWh hintaan -0,25c/kWh. Olisinko hyötynyt jakamalla tämän kulutuksen pitkin päivää, vai oliko erityistapaus?
 
Käyttövedessä kyllä energiaa kuluu vähiten jos pitää varaajan mahdollisimman viileänä kokoajan. Mutta kyllä jos kerran vuorokaudessa halvimmalla tunnilla lataa varaajan, luulisi hinnassa voittavan silti.

Jäähän se varaajan hukkaenergia sisään kuitenkin ja vapautuu varaajasta 50-100W teholla about. Eli koko vuorokauden irtoaa tilaan sitä halvimmalla kerättyä lämpöä.
 
Ihan perstuntumalla väittäisin että nyt näillä reilusti heittelevillä hinnoilla tää mun systeemi minulla itselläni on hyvä. Enemmän lämmintä vettä kuluttavilla ei välttämättä. Mutta jos tasaisemmat hinnat niin Arisoftin systeemi varmasti parempi. Joku enemmän matematiikkaa osaava varmaan osaisi laskea.
 
Ihan perstuntumalla väittäisin että nyt näillä reilusti heittelevillä hinnoilla tää mun systeemi minulla itselläni on hyvä. Enemmän lämmintä vettä kuluttavilla ei välttämättä. Mutta jos tasaisemmat hinnat niin Arisoftin systeemi varmasti parempi. Joku enemmän matematiikkaa osaava varmaan osaisi laskea.
Varaajan idea on että sinne ladataan lämpöä yli tarpeen se kannattaa tehdä vuorokauden kahden halvimman tunnin aikaan sillä erotuksella että ainakin toinen tunti on aamuyöllä pienellä varaajalla.Myös lämmönkulutusta voi ja kannattaa rajoittaa kalliiden tuntien aikana vaikka pesuhuoneen lattialämmitystä estämällä joka kuluttaa yllättävän paljon ,riittävästä kosteudenpoistosta suihkun jälkeen on syytä huolehtia kuitenkin
 
Palatakseni edelliseen, koska kiinnostaa olisilko lisäoptimoinnista mitään hyötyä, tarkistin viime yön lvv kulutuksen joka oli 2,75kWh hintaan -0,25c/kWh. Olisinko hyötynyt jakamalla tämän kulutuksen pitkin päivää, vai oliko erityistapaus?

Itsellä käynyt usein niin että varaaja tulee lämmitettyä maksimiin erityisesti keskellä päivää kun muuten aurinkopaneeleiden tuotto menisi negatiivisella hinnalla myyntiin. Eli jos on paneelit pitää kulutus olla normaalisti 15 minuutin sykleissä tasaisesti pitkin päivää ja mielellään vielä auringon paisteen ja myyntihinnan mukaan säädettynä. Muuten voi käydä niin että joutuu maksamaan siitä ettei käytä sähköä.
 
Vettä on virrannut Vuoksessa ja lämmitysoptimointiprojekti saanut jatkoa pikkuhiljaa - hitaasti, mutta varmasti vartti siellä ja vartti täällä.

Päädyin Arisoftin kommentista siirtymään sakotuksesta sinne oikean optimoinnin puolelle. Nyt rullaa Home Assistantissa ruma DIY-addon, joka latailee sähkönhinnat+sään ja tuuttaa ulos optimoidun lämmitysstrategian erikseen ylä- ja alakerralle, kun haluan pitää ne erilämpöisinä. Talo on puurunkoinen, joten varaavuutta ei hirveästi ole.

Ajattelin postata tänne, kun ekaa kertaa nyt tulee jotain esiteltävää optimointitulosta. Huomenna 31.12.2024 on alkupäivä hinta matala, joten lämmittimet (vihreä/keltainen) ajetaan tasaisella kaasulla. Kello 16 hinta nousee, joten sitä ennen ladataan lämpöä taloon nostamalla kummankin lämmittimen tehoja ja varataan taloon lämpöä (punainen ja liila viiva). Sitten rullaillaan alamäkeen ilta. Edit/lisäys: tämä ottaa siis huomioon myös sen, että korkeampi sisälämpötila tarkoittaa isompia häviöitä eli siksi esim. huomenna ajetaan aluksi tasaisella kaasulla.

1735565838283.png


Monenlaista pientä paranneltavaa on listalla. Täytyy vielä upottaa tähän mm. auringon lämmittävä vaikutus ja hioa sitä mallia, jonka perusteella tuo ennustelee sisälämpötilaa. Päätin alkuun valita yksinkertaisen RC-mallin = ylä- ja alakerralla tietty lämpökapasiteetti ja lämpöhukka ulos. Todellisuudessa lattialämmitys varaa itseensä joksikin aikaa lämpöä enemmän kuin mitä malli nyt uskoo asian olevan.

Rahallisesti tästä ei tainnut tulla hirveästi säästöä. Jos oikein laskin, niin 0,6€. Mutta toisaalta huomenna ei olekaan mikään erikoisen korkeiden hintojen päivä. Seuraillaan, että miten tämä tästä kehittyy eteenpäin. Ja toisaalta lukija muistakoon, että hullulla on halvat huvit. Ilmaisethan ne ei ole, koska sähkö kuitenkin maksaa jotain.
 
Ja kun noita varaavia takkoja on useampia, niin niistä parissa on lämpömittarit pintalämpötilaa mittaamassa, joiden avulla yritän arvata, että paljonko ne luovuttavat lämpöä sisäilmaan. Malli koettaa laskeskella, että paljonko olisi sopiva määrä polttaa puita ylä- ja alakerrassa, jotta sisälämpötila pysyisi yli minimirajan. Sähköllä toimivat lämmittimet sitten tulevat paikkaamaan, jos esim. aamuyöstä takkojen teho ei riitäkään pitämään lämpöjä yllä. Toisaalta sähkölämmittimistä leikataan halpanakin aikana, jos takoissa on vielä luovutettavaa lämpöä tallessa. Takkojen ominaisuudet/parametrit tästä ovat vähän hakusessa, kun kerätyn datan sovitus antoi vaihtelevia tuloksia, mutta jokin arvaus senkin suhteen on nyt paikallaan. Pitänee tarkennella sitä(kin), kunhan saa enemmän kerättyä dataa talteen käyrien sovittamista varten.

Kiitos @Arisoft hyvään suuntaan työntämisestä. "Syytän/kiitän" sinua siitä, että lipsahdin syvemmälle tähän kaninkoloon, josta ei taida enää päästä pois :)
 
Vettä on virrannut Vuoksessa ja lämmitysoptimointiprojekti saanut jatkoa pikkuhiljaa - hitaasti, mutta varmasti vartti siellä ja vartti täällä.

Päädyin Arisoftin kommentista siirtymään sakotuksesta sinne oikean optimoinnin puolelle. Nyt rullaa Home Assistantissa ruma DIY-addon, joka latailee sähkönhinnat+sään ja tuuttaa ulos optimoidun lämmitysstrategian erikseen ylä- ja alakerralle, kun haluan pitää ne erilämpöisinä. Talo on puurunkoinen, joten varaavuutta ei hirveästi ole.

Ajattelin postata tänne, kun ekaa kertaa nyt tulee jotain esiteltävää optimointitulosta. Huomenna 31.12.2024 on alkupäivä hinta matala, joten lämmittimet (vihreä/keltainen) ajetaan tasaisella kaasulla. Kello 16 hinta nousee, joten sitä ennen ladataan lämpöä taloon nostamalla kummankin lämmittimen tehoja ja varataan taloon lämpöä (punainen ja liila viiva). Sitten rullaillaan alamäkeen ilta. Edit/lisäys: tämä ottaa siis huomioon myös sen, että korkeampi sisälämpötila tarkoittaa isompia häviöitä eli siksi esim. huomenna ajetaan aluksi tasaisella kaasulla.
Miten säädät Nibeä? Itse pelaan pelkällä offsetillä (vastusta en vielä säädä pörssihinnan mukaan - se kuitenkin estetään poissaolotiedon mukaan)
 
Miten säädät Nibeä? Itse pelaan pelkällä offsetillä (vastusta en vielä säädä pörssihinnan mukaan - se kuitenkin estetään poissaolotiedon mukaan)
Minulla on vanha Nibe F410p PILP. DIY-optoerotin feikkailee sisälämpötila-anturin (alkuperäinen osa taitaa olla RG10) pyyntilämpötilaa ylös/alas ja Nibe sitten sisäisellä logiikalla kääntelee sunttia sen mukaan. Aika karkeaa tuolla saa aikaan tällä hetkellä, mutta tuo optimointimalli tuntuu antavan vaihtoehdoiksi pääosin "hinta tasainen, aja tasaisella kaasulla ulkolämpötilan mukaan", "himmaillaan, pidä PILP käynnissä" tai "aja täysiä, koska halutaan varata lämpöä tulevaa hinnannousua varten". Nuo saan tällä hetkellä suht kivuttomasti aikaan. Pitää tarkentaa säätöä, jos tarvetta ilmenee.

Tai kun oikeastaan ainoat säätömahdollisuudet tuossa on "vastusten esto" ja sitten koettaa vaikuttaa sisäiseen logiikkaan tuon sisälämpöanturin tulojen kautta. Tai muutoin pitäisi mennä muuttelemaan koneen 230V kytkentöjä ja siihen en ole vielä lähtenyt. Nykyinen systeemi tehty niin, että repimällä yhden virtalähteen irti muuttuu Nibe taas käyräohjatuksi, niin allekirjoittaneen maatessa koomassa sairaalassa saa talon lämpenemään ilman sen kummempia ihmettelyjä.
 
Vettä on virrannut Vuoksessa ja lämmitysoptimointiprojekti saanut jatkoa pikkuhiljaa - hitaasti, mutta varmasti vartti siellä ja vartti täällä.

Päädyin Arisoftin kommentista siirtymään sakotuksesta sinne oikean optimoinnin puolelle. Nyt rullaa Home Assistantissa ruma DIY-addon, joka latailee sähkönhinnat+sään ja tuuttaa ulos optimoidun lämmitysstrategian erikseen ylä- ja alakerralle, kun haluan pitää ne erilämpöisinä. Talo on puurunkoinen, joten varaavuutta ei hirveästi ole.
Mitenkäs Home Assistantin sääennusteesta saisi ulos seuraavan 12 tunnin keskilämpötilan? Olen ns hakannut päätäni seinään Met.no integraation kanssa, mutta ei vaan onnistu. Nyt käytössä systeemi joka "arpoo" ilpille pyyntilämpötilan huonelämpötilojen, ulkolämpötilan, tuloilman, tulevan ja nykyisen sähkön hinnan perusteella. Lämpötilat tipahtavat herkästi alle toivotun pakkasen kiristyessä nopeasti joten ennakointi olisi senkin suhteen tarpeen.
 
Tuohon oli mulla toimiva ratkaisu, ennenkuin HA muutti koko weather systeemin toiminnan. Aivan saatanan sekavaa, ja kun vanhoista foorumiratkaisuistakaan ei ole apua. Ollut siis itsellä rikki jo kotvan aikaa.
 
Tällainen template antaa jonkin vastauksen:


Koodi:
sensor:
  - name: "12 Hour Average Temperature"
    unique_id: "twelve_hour_avg_temperature"
    unit_of_measurement: "°C"
    state: >
      {% set forecast = state_attr("sensor.weather_koti_hourly", "forecast") %}
      {% if forecast %}
        {% set now = now() %}
        {% set twelve_hour_forecast = forecast |
           selectattr("datetime", ">=", now.isoformat()) |
           selectattr("datetime", "<", (now + timedelta(hours=12)).isoformat()) |
           map(attribute='temperature') | list %}
        {{ twelve_hour_forecast | average | round(1) if twelve_hour_forecast | length > 0 else 'unavailable' }}
      {% else %}
        unavailable
      {% endif %}
    availability: >
      {{ state_attr("sensor.weather_koti_hourly", "forecast") is iterable }}
 
Mitenkäs Home Assistantin sääennusteesta saisi ulos seuraavan 12 tunnin keskilämpötilan? Olen ns hakannut päätäni seinään Met.no integraation kanssa, mutta ei vaan onnistu. Nyt käytössä systeemi joka "arpoo" ilpille pyyntilämpötilan huonelämpötilojen, ulkolämpötilan, tuloilman, tulevan ja nykyisen sähkön hinnan perusteella. Lämpötilat tipahtavat herkästi alle toivotun pakkasen kiristyessä nopeasti joten ennakointi olisi senkin suhteen tarpeen.
Automaation sisällä saat sen näin:
1735665762360.png


Esimerkkikoodi kirjoittaa 12h keskiarvon pysyvään notifikaattiin, mutta tuon voi kirjoittaa muuallekin tarvittaessa. Vaihda kumpaankin kohtaan oikea weather-tyypin sensori, jotta saat oikean sijainnin tiedot.
YAML:
action: notify.persistent_notification
metadata: {}
data:
  message: >-
    {{ hourly['weather.koti'].forecast[0:12] | map(attribute='temperature') | average }}
 
Tulipa nopeat ja selkeät vastaukset eli vähän hitaampikin ymmärsi. :)
Muutin koodin vielä niin, että pullauttaa ulos suoraan 12 seuraavan tunnin keskiarvon erotuksen tämän hetkiseen ja vähennän tämäm sitten erikseen pyyntilämpötilasta. Pitää tietty hieroa sopivaa kerrointa vielä jotta saa mahdollisimman tasaisen sisälämpötilan.
action: input_number.set_value
metadata: {}
data:
value: >-
{{ ((hourly['weather.forecast_home'].forecast[0:12] |
map(attribute='temperature') | average | round(1)) -
(hourly['weather.forecast_home'].forecast[0:1] |
map(attribute='temperature') | average | round(1))) | round(1) }}
target:
entity_id: input_number.12h_average_temp
enabled: true
 
Täällä mennään suurin piirtein alla olevan mukaisesti. Aika sekavahan tuosta on tullut, eikä toimivuutta ole päästy kokeilemaan kuin vasta toukokuun alusta lähtien. Sähkösopimus on kiinteähintainen syksyyn saakka, mutta tuntihintaoptimointi on ollut kuitenkin jo käytössä testimielessä. En oikeastaan muista enää kaikkia yksityiskohtia. Täytyy katsella tarkemmin, kunhan lämmityskausi ja pörssisähkö astuu kuvioihin mukaan.

Lasketaan sääennusteesta tarvittavien lämmitystuntien määrä. Valitaan tarkastelujaksolta tarvittava määrä halvimpia tunteja (sallitut tunnit 1). Tarkastelujakso on tiedossa olevien tuntihintojen loppuun saakka. Jos tuntihintoja on tiedossa alle 24 h, katsotaan sääennuste kuitenkin aina vähintään 24 h päähän ja tuntitarve skaalataan jäljellä olevien tuntihintojen määrän mukaan.

Lisätään lämmitystunneiksi myös tunnit, jotka ovat annetun marginaalin (prosenttia tai c/kWh) sisällä edellä valittujen tuntien keskihinnasta (sallitut tunnit 2).

Jos lämmitystunneissa tulee tauko valittua aikaa pidemmäksi, lisätään yksittäinen tunti katkaisemaan tauko (tämä lämmintä käyttövettä varten) (sallitut tunnit 3).

Muut tunnit pumpun on tarkoitus olla tekemättä töitä (kielletyt tunnit).

Ohjaus tapahtuu MLP:n sisälämpötilan asetusarvoa muuttamalla. Käytännössä tämä kaiketi muuttaa käyrän tasoa.

Halvimmilla tunneilla kasvatetaan MLP:n sisälämpöätilan arvoa reilusti, jotta pumppu heräisi töihin (sallitut tunnit 1). Marginaalin sisällä olevat tunnit ovat asetukseltaan melko neutraaleja eli niiden aikana pumppu on tehnyt aika pienillä kierroksilla töitä (sallitut tunnit 2). Loppujen tuntien aikana sisälämpätilan asetus on alhainen, jolloin pumppu yleensä myös pysähtyy tai pysyy pysähtyneenä (kielletyt tunnit).

Käyttöveden lämmitys asetetaan eco-tilaan, kun on menossa "kielletyt tunnit". Eco-tilassa käyttöveden rajalämpötilat ovat normaalia alempia.

Lisäksi käyttöveden lämmityksen osalta käytössä yöajan eco-tila, jos aamuun saakka on ns. sallittuja tunteja. Tällä saa siirrettyä loppuiltaan tai alkuyöhön muutoin ajoittuvan käyttöveden teon lähemmäksi aamun käyttöä.

MLP:n sisälämpötilan arvoa nostetaan tai lasketaan sisälämpötilan perusteella. MLP ei oikeasti tiedä sisälämpötilaa, mutta sitä voi silti käyttää käyrän tason säätämiseen. Sisälämpötila mitataan sitten muilla keinoilla. COP heikkenee suhteellisen paljon, jos MLP:tä yrittää ajaa mahdollisimman kovilla kierroksilla eli ihan pienellä marginaalilla ei kannata tunteja hylätä (sallitut tunnit 2 vastaa tähän). Suurinta osaa laskennassa käytettävistä "vakioista" saa muutettua HA:n kautta.

Ilmanvaihdon tuloilman lämmityksestä ajattelin tinkiä talvella, jos sähkön hinta menee kohtuuttoman kalliiksi. Tähän ei ole vielä ohjausta tehty. Nykyinen ohjaus sallii jonkin verran sisälämpötilan vaihtelua, eikä se ainakaan kevään aikana muodostunut häiritseväksi.

e. Lisäksi tunnin rank vaikuttaa suoraan vielä hieman lisäksi pyydettyyn lämpötilaan eli sallitut tai kielletyt tunnitkaan eivät ole samanarvoisia.

MLP:tä on nyt ajettu reilut puolitoista vuotta suurin piirtein lainauksessa mainitusti. Jotain hienosäätöä on matkan varrella tehty, mutta perusajatus on pysynyt aivan samana.

Koneen omasta lämmitystarvelaskennasta johtuen aloitukset ja lopetukset eivät mene aina täysin nappiin, mutta aivan riittävällä tavalla kone reagoi pyyntimuutoksiin.
 
On tuo chatgpt sitten ihme juttu. Pyysin sitä tekemään koodin ESP32:lle mikä haikisi minkä tahansa tunnin nord pool hinnan.
Varsinainen hakufunktio on alla.

// Nord Pool API endpoint and your API key
const String API_URL = "https://api.nordpoolgroup.com/v1/prices";
const String API_KEY = "your_API_key";

void fetchElectricityPrice(String country, String date, String hour) {
HTTPClient http;

String url = API_URL + "?country=" + country + "&date=" + date + "&hour=" + hour;

http.begin(url);
http.addHeader("Authorization", "Bearer " + API_KEY);

int httpCode = http.GET();

if (httpCode > 0) {
String payload = http.getString();
Serial.println("Response code: " + String(httpCode));
Serial.println("Response payload: ");
Serial.println(payload);

// Parse JSON response
DynamicJsonDocument doc(1024);
deserializeJson(doc, payload);

// Extract and display price information
float price = doc["data"][0]["value"]; // Adjust depending on the structure of the JSON response
Serial.println("Electricity Price: " + String(price) + " EUR/MWh");
} else {
Serial.println("Error fetching data: " + String(httpCode));
}

http.end();
}
 
Tammikuun aikaansaannokseni:

Tuon lisäksi toteutus joka valitsee varatun kapasiteetin x kWh lämmön kulutuksella ja y kWh latausnopeudella
0. Toteutus joka laskee tarvittavien tuntien määrän A sisälämpötilan ja vrk keskilämpötilan erotuksesta sekä lisää puskuriksi N astetta. Tätä ennustetta säädetään kolmen seuraavan vrk keskilämpötilan mukaan ylös tai alaspäin.
1. Kun on lämpövajaus A tuntia niin
- kuluvan päivän halvimmat kyseiset A tuntia
Tai jos huominen saatavilla
- kuluvan päivän tai huomisen halvimmat kyseiset A tuntia
2. Ylivaraaminen tavoiteasterajan yli (20% eli *1.2), kun hinta on päivän <avg/2 tai alle z eur rajan.
3. Ylivaraaminen tavoiteasterajan yli (40% eli *1.4), kun hinta on päivän <avg/3 tai alle w eur rajan

Viimeinen kohta minulta puuttuu vielä.

Samoin kun foreca hintapuntarin käyttö puskurin kasvatukseen yli 2,5vrk tyynen jakson näkyessä ennusteessa yli 3vrk päässä.
 
Viimeksi muokattu:
Takaisin
Ylös Bottom