Pörssisähköohjaus made easy

[tk-]

Jaahas.
Onkohan joku hässäkkä kun ohjaustiedot ei näy?
Lattialämmitys tuli lisättyä Shellyn ja pörssärin taakse kuluneella viikolla.
Tuli taas todettua Shellyn päivityksen tarpeellisuus ennenkuin lisää skriptejä

Oli varmaan joku ongelma tuon highchartsin serverin kanssa? Ohjaustiedot kyllä tietokannassa oli normaalisti. Ollaan tehty tuo niin, että hakee javascriptin sieltä highchartsista, mutta varmaan pitää jatkoa ajatellen kopioida se serverille jos tuollaista ongelmaa tekee toisinaan.

 

[tk-]

Itsellä on myös kompuran esto AUX1:ssä ja lämpimän veden esto AUX2:ssa.

Vastukset pitää muistaa ottaa tavalla tai toisella pois päältä, jos käyttää kompuran estoa. Muuten alkaa lämmittää vastuksilla, kun asteminuutit laskevat riittävän alas.

Tuossa edellä kaba hyvin avaa asiaa. Valmiiksi asennetuilla skripteillä Shellyjä saa esim Nurkan takaa -verkkokaupasta ja Shellykaupasta, molemmat luotettavia kotimaisia toimijoita, olen henkilökohtaisesti ollut yhteydessä molempiin kauppiaisiin. Toki skriptin laitto Shellyyn sinällään ei ole kovin kummoinen juttu tehdä itsekään. Tuolla ohjesivustolla on siihenkin kuvalliset ohjeet olemassa.

 

[kaba]

Oli varmaan joku ongelma tuon highchartsin serverin kanssa? Ohjaustiedot kyllä tietokannassa oli normaalisti. Ollaan tehty tuo niin, että hakee javascriptin sieltä highchartsista, mutta varmaan pitää jatkoa ajatellen kopioida se serverille jos tuollaista ongelmaa tekee toisinaan.

Joo, ei näy ohjaustiedot tälläkään hetkellä.
Ei siitä tosin haittaakaan ole sillä ohjaus toimii muuten normaalisti.

 

[tk-]

Joo, ei näy ohjaustiedot tälläkään hetkellä.
Ei siitä tosin haittaakaan ole sillä ohjaus toimii muuten normaalisti.

Testasin itse ongelmitta, ja samoin teki Attekin useammalla eri laitteella ja selaimella. En tiedä onko tuo nyt sitten vaatinut vielä selaimen välimuistin tyhjentämisen kertaalleen jos js on jäänyt joku kerta latautumatta, ja sitten sitä ei haetakaan uusiksi.

Mutta tosiaan sen olemassaolo on täysin informatiivisuutta varten, se hakee tietonsa siitä samasta ohjaustiedosta mikä on palvelimelle muodostettu ja mistä sitten laitteetkin sen kyselee. Toki käyttäjänä on mahdotonta tietää, että onko kyse ohjaustiedon puuttumisesta vai sivuston graafiongelmasta, eli hyvä kuitenkin kun nämä aina tuodaan esiin, niin tarkistetaan tilanne.

 

[kaba]

En tiedä onko tuo nyt sitten vaatinut vielä selaimen välimuistin tyhjentämisen kertaalleen jos js on jäänyt joku kerta latautumatta, ja sitten sitä ei haetakaan uusiksi.

Tämä auttoi.

 

[Hjalmaar]

Onkohan ongelma vain minulla vai mistä syystä tuossa ei enää näy kellonajat?

 

[JwL]

Huomasin saman muutama päivä sitten

 

[tk-]

Onkohan ongelma vain minulla vai mistä syystä tuossa ei enää näy kellonajat?

Graafin kanssa on ollut jotain hässäkkää viime päivinä, epäilyksenä oli ettei olisi saanut ladattua javascript-kirjastoa oikein tuolta highchartsin palvelimelta ja siksi se ei osalla näkynyt ollenkaan. Täytyy siis jatkossa siirtää kirjasto omalle serverille, useimmilla on graafiongelmiin auttanut selaimen välimuistin tyhjennyt. Ajat tuossa kuitenkin oikein on tulleet kun kerran palkitkin on oikein piirtyneet.

 

[VaNaHaKettu]

Graafin kanssa on ollut jotain hässäkkää viime päivinä, epäilyksenä oli ettei olisi saanut ladattua javascript-kirjastoa oikein tuolta highchartsin palvelimelta ja siksi se ei osalla näkynyt ollenkaan. Täytyy siis jatkossa siirtää kirjasto omalle serverille, useimmilla on graafiongelmiin auttanut selaimen välimuistin tyhjennyt. Ajat tuossa kuitenkin oikein on tulleet kun kerran palkitkin on oikein piirtyneet.

Itsellä myös tämä ongelma näkyvissä. Olin juuri tyhjentänyt välimuistin koska oli ongelmana, että koko graafi jäi näkymättä.
Lisäksi tuo kellonaikojen puuttuminen tulee toisellakin selaimella.

 

[kaba]

Jos Shellyn apista laittaa laitteen päälle, niin ajaako tuo pörssärin ohjauksen yli? Ja laitteen apista sammuttamisen jälkeen menee taas pörssärin ohjauksen mukaisesti.

 

[hyperstaattinen]

Jos Shellyn apista laittaa laitteen päälle, niin ajaako tuo pörssärin ohjauksen yli? Ja laitteen apista sammuttamisen jälkeen menee taas pörssärin ohjauksen mukaisesti.

Oman kokemukseni mukaan taitaa skripti ajaa kaiken yli.

Mielestäni toimii siis siten, että jos Pörssäri käynnistäisi vaikkapa lämmityksen yöllä neljän halvimman tunnin ajaksi (klo 00-04) ja haluaisit väliaikaisesti, että lämmitys onkin päällä koko yön (vaikkapa klo 21-07). Illalla laitat sen Shellyn appista lämmityksen päälle klo 21, niin skriptistä tuleva poiskytkentäkäsky sammuttaa lämmityksen joka tapauksessa klo 04.

 

[kaba]

Jotenkin noin järkeilin myös ja varmaan kehittäjätkin. Kuinkahan usein nuo skriptit haetaan?
Nyt siis laitoin 2 h ennen pörssärin ohjausta apista päälle. Pörssärin ohjauksen aikana sitten pois. Tuntiin ei ainakaan mennyt päälle joten laitoin taas apista koska halpoja tunteja.
Eiköhän tuo lähde rullaamaan ajallaan.

 

[tk-]

Jotenkin noin järkeilin myös ja varmaan kehittäjätkin. Kuinkahan usein nuo skriptit haetaan?
Nyt siis laitoin 2 h ennen pörssärin ohjausta apista päälle. Pörssärin ohjauksen aikana sitten pois. Tuntiin ei ainakaan mennyt päälle joten laitoin taas apista koska halpoja tunteja.
Eiköhän tuo lähde rullaamaan ajallaan.

Se manuaalinen ohjaus pysyy halutussa tilassa kunnes vastakkainen ohjaus tulee seuraavan kerran vastaan. Eli juuri noin, että jos pitäisi olla 00-04 ja laitat päälle jo 22, niin päälläoloaika on 22-04. Yksi vaihtoehto on sitten laittaa skripti pois päältä tilanteessa missä haluaa manuaalisen ohjauksen toimivan pidempään.

Tähänkin on pohdittu josko jatkoon pitäisi tuoda valinta, että kuinka kauan odotellaan, että palataan seuraamaan Pörssäri-ohjausta, mutta se toki vaatii vähän skriptin uudistamista. Ehkä seuraavaan skriptiversioon yritetään lisätä se.

 

[Hjalmaar]

Graafin kanssa on ollut jotain hässäkkää viime päivinä, epäilyksenä oli ettei olisi saanut ladattua javascript-kirjastoa oikein tuolta highchartsin palvelimelta ja siksi se ei osalla näkynyt ollenkaan. Täytyy siis jatkossa siirtää kirjasto omalle serverille, useimmilla on graafiongelmiin auttanut selaimen välimuistin tyhjennyt. Ajat tuossa kuitenkin oikein on tulleet kun kerran palkitkin on oikein piirtyneet.

Olen tyhjennellyt välimuistit, koittanut eri laitteilla ja eri selaimilla mutta en saa aikoja näkyviin. Kosmeettinen ongelma toki vain kun ohjaus toimii.

 

[VaNaHaKettu]

Olen tyhjennellyt välimuistit, koittanut eri laitteilla ja eri selaimilla mutta en saa aikoja näkyviin. Kosmeettinen ongelma toki vain kun ohjaus toimii.

Itselläkin sama homma puhelimen kanssa nyt. Kerran sain toimimaan kun tyhjensin välimuistin mutta nyt ei auta sekään. Toisella selaimella puhelimella pelaa graafi kuten tietokoneella myöskin. Tosin kellonajat puuttuu tuosta uudesta graafista.

 

[tk-]

Itselläkin sama homma puhelimen kanssa nyt. Kerran sain toimimaan kun tyhjensin välimuistin mutta nyt ei auta sekään. Toisella selaimella puhelimella pelaa graafi kuten tietokoneella myöskin. Tosin kellonajat puuttuu tuosta uudesta graafista.

Tämä on kaikin puolin kummallinen ongelma, kun ei tule esiin minulla tai Atella millään laitteella, ja siksi sen debuggaus on äärimmäisen vaikeaa. Mutta jotenkin sen pitää liittyä graafikirjaston ja/tai nettiselainten päivittymiseen. Pyritään lähiviikkoina saamaan tuo selvitettyä.

Jos joku onnistuu kaivamaan sieltä selaimesta jotain JavaScript-virheitä, niin niitä voi palautelomakkeella laittaa, voisi auttaa asiassa eteenpäin.

 

[Matti1965]

Asensin Pörssäri - Etusivu sovelluksena. Silloin toimii kellonajat. Selain on Edge ja Win11.

 

[VaNaHaKettu]

Asensin Pörssäri - Etusivu sovelluksena. Silloin toimii kellonajat. Selain on Edge ja Win11.

Tämä näyttää toimivan, kiitti tiedosta!

 

[tk-]

Voi toimia joko tuon sovelluksen ansioista tai sitten tänään tehty pieni fixi tuohon graafin päivämäärämuodostukseen poisti sen jumituksen. En vielä uskaltanut siitä kovaan ääneen huudella ennenkuin somekansa vahvistaa vian poistuneen!

 

[JwL]

Voi toimia joko tuon sovelluksen ansioista tai sitten tänään tehty pieni fixi tuohon graafin päivämäärämuodostukseen poisti sen jumituksen. En vielä uskaltanut siitä kovaan ääneen huudella ennenkuin somekansa vahvistaa vian poistuneen!

Nyt toimii!

 

[kaba]

tänään tehty pieni fixi tuohon graafin päivämäärämuodostukseen poisti sen jumituksen.

Tämä auttoi. Nyt toimii.

 

[masipila]

@tk- ajattelin vaan huikata uudelleen, että se viime keväänä yhdessä huurustelemamme lämmitysalgoritmi todellakin on kick-ass -tasoa. Lämmitys on nyt mallia hands off, kun aikaisemmin tein siihen pientä hienosäätöä säännöllisesti. Sisälämpötila pysyy nyt tasaisena about +/- 0.5 asteen hahlolla, kun algoritmi tööttää lisää lämpöä etukäteen jos sääennusteessa näkyy isompia lämpötilapudotuksia. Tämä ennakkolämmitys toimii minulla tällä hetkellä tällaisilla parameterilla ja tällaisella konseptilla:

• Vuorokausi on jaettu 4 x 6h osiiin
• Jokaiselle osalle lasketaan ensin lämmitystarve, josta 50% kiinnitetään kyseiselle 6h ajalle
• Jokaisen osan lämmitystarpeesta 50% sallitaan siirto saman vuorokauden sisällä halvimmille ajankohdille
• Jos sääennusteessa näkyy 2 asteen pudotus kolmen perättäisen 6h osion keskilämpötilassa, on kyseessä "iso lämpötilapudotus"
  • Tällöin lämmitystarpeet kuplivat ylöspäin, eli osion A lämmitystarpeeksi laitetaan osion B lämmitystarve ja osion B lämmitystarpeeksi laitettaan osion C lämmitystarve.
  • Lisäksi tuo lämmitystarpeen jousto laitetaan 0%:iin, eli näiden 6h osioiden lämmitystarvetta ei voi siirtää muille vuorokauden ajanhetkille halvemman hinnan perässä.

Tämän lisäksi minulla on vielä maalämpöpumpun kompressorin käynnistykertoja säästävä logiikka:

• Olen parametroinut että lyhin sallittu lämmitysjakso on 0.5h. Jos olisi tulossa lyhyt vartin lämmitysjakso, niin se yhdistetään joko aiempaan tai seuraavaan lämmitysjaksoon riippuen siitä kumpi on halvempi.
• Olen parametroinut että jos kahden lämmitysjakson väli on 1h tai lyhyempi, niin lämmitysjaksot yhdistetään, ettei jää lyhyttä paussia lämmitysjaksojen väliin.
• Näissä kummassakin siirrossa on parametroituna 2 c/kWh hintaraja, eli yhdistämisiä ei tehdä, jos silloin sattuisi olemaan päivän isoin hintapiikki

Koko komeudelle on parisen sataa testiautomaatiokeissiä, eli logiikan pitäisi olla aikalailla ehjää. Härveli on kokonaan avointa lähdekoodia jos haluat prujata sieltä Pörssäriin jotain: Home

Cheers,
Markus

 

[tk-]

@tk- ajattelin vaan huikata uudelleen, että se viime keväänä yhdessä huurustelemamme lämmitysalgoritmi todellakin on kick-ass -tasoa. Lämmitys on nyt mallia hands off, kun aikaisemmin tein siihen pientä hienosäätöä säännöllisesti. Sisälämpötila pysyy nyt tasaisena about +/- 0.5 asteen hahlolla, kun algoritmi tööttää lisää lämpöä etukäteen jos sääennusteessa näkyy isompia lämpötilapudotuksia. Tämä ennakkolämmitys toimii minulla tällä hetkellä tällaisilla parameterilla ja tällaisella konseptilla:

• Vuorokausi on jaettu 4 x 6h osiiin
• Jokaiselle osalle lasketaan ensin lämmitystarve, josta 50% kiinnitetään kyseiselle 6h ajalle
• Jokaisen osan lämmitystarpeesta 50% sallitaan siirto saman vuorokauden sisällä halvimmille ajankohdille
• Jos sääennusteessa näkyy 2 asteen pudotus kolmen perättäisen 6h osion keskilämpötilassa, on kyseessä "iso lämpötilapudotus"
  • Tällöin lämmitystarpeet kuplivat ylöspäin, eli osion A lämmitystarpeeksi laitetaan osion B lämmitystarve ja osion B lämmitystarpeeksi laitettaan osion C lämmitystarve.
  • Lisäksi tuo lämmitystarpeen jousto laitetaan 0%:iin, eli näiden 6h osioiden lämmitystarvetta ei voi siirtää muille vuorokauden ajanhetkille halvemman hinnan perässä.

Tämän lisäksi minulla on vielä maalämpöpumpun kompressorin käynnistykertoja säästävä logiikka:

• Olen parametroinut että lyhin sallittu lämmitysjakso on 0.5h. Jos olisi tulossa lyhyt vartin lämmitysjakso, niin se yhdistetään joko aiempaan tai seuraavaan lämmitysjaksoon riippuen siitä kumpi on halvempi.
• Olen parametroinut että jos kahden lämmitysjakson väli on 1h tai lyhyempi, niin lämmitysjaksot yhdistetään, ettei jää lyhyttä paussia lämmitysjaksojen väliin.
• Näissä kummassakin siirrossa on parametroituna 2 c/kWh hintaraja, eli yhdistämisiä ei tehdä, jos silloin sattuisi olemaan päivän isoin hintapiikki

Koko komeudelle on parisen sataa testiautomaatiokeissiä, eli logiikan pitäisi olla aikalailla ehjää. Härveli on kokonaan avointa lähdekoodia jos haluat prujata sieltä Pörssäriin jotain: Home

Cheers,
Markus

Mahtavaa kuulla! Meillä on tuossa ohjaustiedon muodostuksen uudistus meneillään, niin tämä aiemmin keskusteltu oli jo tulossa aiemminkin osaksi sitä. Täytyy vielä hioa sitä esimerkkiesi avulla.

Ilmeisesti mitään isompaa tarvetta parametroinnille ei ole ilmaantunut? Esimerkiksi, että käyttäjä saisi määrittää fiksoitujen tuntien osuuden itse tai tuon ”suuren lämmönvaihtelun” itse? Oletko huomannut ulkolämmön lämmetessä ylilämmitystaipumusta, eli pitäisikö tuota tarpeen muutosta tehdä myös toiseen suuntaan?

 

[masipila]

Ai niin, unohtu mainita edellisestä viestistä että jos sääennusteessa näkyy 2 asteen pudotus kahden perättäisen 6h osion keskilämpötilassa, mutta sitten keskilämpötila tasaantuu eikä putoa enää lisää, niin kyseessä "tavallinen lämpötilapudotus".

Tällöin osioiden lämmitystarpeet pysyvät ennallaan, mutta tuo joustavuus menee nollaan. Eli näiden 6h osioiden lämmitystarvetta ei voi siirtää muille vuorokauden ajanhetkille halvemman hinnan perässä.

 

[masipila]

Ilmeisesti mitään isompaa tarvetta parametroinnille ei ole ilmaantunut? Esimerkiksi, että käyttäjä saisi määrittää fiksoitujen tuntien osuuden itse tai tuon ”suuren lämmönvaihtelun” itse?

Nämä on kaikki parametroitavia, kun kaikki talot ovat erilaisia. Kaikki parametrit on dokumentoitu täällä: 4.x ‐ Usage example: Heating period optimizer

Ja valinnaiset parametrit samalla sivulla heti noiden pakollisten parametrien alapuolella.

 

[masipila]

Oletko huomannut ulkolämmön lämmetessä ylilämmitystaipumusta, eli pitäisikö tuota tarpeen muutosta tehdä myös toiseen suuntaan?

Ehkä lievää, mutta olen toistaiseksi antanut tuon mennä täysin automaatilla kun ideana on kerätä nyt tämä talvi käytännön kokemusta siitä kuinka hyvin tämä toimii hands off.

Tuon ylilämmityksen kompensoinnin suhteen olen ehkä enemmän kallellaan todellisen sisälämpötilan takaisinkytkentään kuin että algoritmi alkaisi vähentää oma-aloitteisesti lämmitystarvetta lämpenevän sääennusteen perusteella. Siinä kun voi käydä kirjaimellisesti kylmät, jos lämpötilan nousu viivästyy tai ei tapahdu ollenkaan.

Tällainen takaisinkytkentä on tuolla minun toteutuksellani jo nyt mahdollinen, mutten käytä sitä itse. Testasin deviympäristössä sellaista ja kirjoitin siitä proof of conceptin openHABin foorumille tähän viestiin (tuo esimerkki on tosin takaisinkytkentä toiseen suuntaan, eli miten lämmitystä voidaan lisätä jos sisälämpötila putoaa alemmas kuin olisi suotavaa, mutta samalla logiikka toimii myös toiseen suuntaan)

Spot Price Optimizer: Advanced algorhitms to optimize heating, charging of electric vehicles, water boilers and more

I just realized that this is already now possible and can be done without changes to the openHAB Spot Price Optimizer, all the needed logic can be written to Rule scripts. If somebody is interested, you can achieve this like this: Detecting if additional heating is needed Have an indoor...

community.openhab.org

 

[tk-]

Ehkä lievää, mutta olen toistaiseksi antanut tuon mennä täysin automaatilla kun ideana on kerätä nyt tämä talvi käytännön kokemusta siitä kuinka hyvin tämä toimii hands off.

Tuon ylilämmityksen kompensoinnin suhteen olen ehkä enemmän kallellaan todellisen sisälämpötilan takaisinkytkentään kuin että algoritmi alkaisi vähentää oma-aloitteisesti lämmitystarvetta lämpenevän sääennusteen perusteella. Siinä kun voi käydä kirjaimellisesti kylmät, jos lämpötilan nousu viivästyy tai ei tapahdu ollenkaan.

Tällainen takaisinkytkentä on tuolla minun toteutuksellani jo nyt mahdollinen, mutten käytä sitä itse. Testasin deviympäristössä sellaista ja kirjoitin siitä proof of conceptin openHABin foorumille tähän viestiin (tuo esimerkki on tosin takaisinkytkentä toiseen suuntaan, eli miten lämmitystä voidaan lisätä jos sisälämpötila putoaa alemmas kuin olisi suotavaa, mutta samalla logiikka toimii myös toiseen suuntaan)

Spot Price Optimizer: Advanced algorhitms to optimize heating, charging of electric vehicles, water boilers and more

I just realized that this is already now possible and can be done without changes to the openHAB Spot Price Optimizer, all the needed logic can be written to Rule scripts. If somebody is interested, you can achieve this like this: Detecting if additional heating is needed Have an indoor...

community.openhab.org

Itse olen ajatellut tuota takaisinkytkentää todellisen lämpötilan mukaan 5%/aste -tavalla, mutta toteutukseksi saakka se ei vielä ole kerennyt. Mutta teoreettieslla tasolla menisi niin, että jos ollaan tavoitelämpötilan alla, niin seuraavien periodien lämmitystarvetta lisättäisiin suunnitelmaan ja jos yläpuolella, niin toisinpäin. Tuossa voitaisiin taklata esimerkiksi takan tuoma lisälämmitys. Ehkä jollain parametroinnilla pitäisi sitten voida määrittää montako periodia "lämpötilapoikkeamaa" huomioidaan ennenkuin palataan takaisin tavanomaiseen algoritmiin ja toisena parametrina, että jos prosentti onkin esimerkiksi 3-7 tuon yleisesti ajatellun 5 sijaan.

Miltä tällainen ajatus kuulostaisi?

 

[masipila]

Itse olen ajatellut tuota takaisinkytkentää todellisen lämpötilan mukaan 5%/aste -tavalla, mutta toteutukseksi saakka se ei vielä ole kerennyt. Mutta teoreettieslla tasolla menisi niin, että jos ollaan tavoitelämpötilan alla, niin seuraavien periodien lämmitystarvetta lisättäisiin suunnitelmaan ja jos yläpuolella, niin toisinpäin. Tuossa voitaisiin taklata esimerkiksi takan tuoma lisälämmitys. Ehkä jollain parametroinnilla pitäisi sitten voida määrittää montako periodia "lämpötilapoikkeamaa" huomioidaan ennenkuin palataan takaisin tavanomaiseen algoritmiin. Miltä tällainen ajatus kuulostaisi?

Joku tällainen kuvio varmaan voisi olla toimiva.

Tämä takaisinkytkentä on sillä tavalla aika haastava konsepti, että se on about täysi vastakohta tuolle etukäteen lasketulle lämmityksen ajastukselle. Meidän maalämpöpumpussa ainakin on asteminuuttien konsepti, jolla hommaa hanskataan, mutta en ehkä lähtisi ihan siihen.

Eka kysymys on tietty että pollaako joku härveli lämpötilasensoria ajoittain vai onko mittari sellainen, joka puskee uuden arvon kun lämpötila muuttuu. Niin tai näin, niin tämä takaisinkytkentälogiikka pitää rakentaa niin että ei ajauduta jatkuvaan ylös/alas kilpajuoksuun. Mutta erityisesti jos on tiheä pollausväli / sensorsi puskee lukemia aina kun lämpötila muuttuu tietyn thresholdin verran.

Anyway, seuraavan 6h alkuun odottelu voi olla pitkä aika, jos liian kylmä tilanne havaitaan juuri jakson alussa. Mietin tuon tuossa proof of conceptissani siten, että jos tavoitelämpö on alaraja on vaikka 19.5, niin jos lämpötila on tämän alle, niin siinä tilanteessa lasketaan now + 6h jakson (pyöristettynä tasavarttiin) lämmitystarve uusiksi tuoreimman sääennusteen mukaan. Ja sitten siihen tarpeeseen lisätään naksu lisää. (Minun ratkaisussani ohjaussignaali ei enää tiedä mistä jaksosta on kyse sen jälkeen kun ohjaukset on tallennettu tietokantaan, se on vain yksi vuorokauden mittainen aikasarja, joten on täysin OK laskea siitä joku mielivaltainen pätkä uusiksi ja ylikirjoittaa se osuus).

Minulla ei ollut tuossa nopsassa PoCissa mukana mitään aikaa, jonka sisällä tämä logiikka ei alkaisi uudelleen, which is not good, koska on enemmän kuin todennäköistä että esim. 20 min päästä tulee uusi lukema joka on edelleen alarajan alapuolella. Eli joku "tarve lasketaan uusiksi max kerran kuuteen tuntiin" (tämä olisi ehkä luonnollista olla sama parametrit kuin lämmitysosioiden määrä) pitäisi olla.

Itse en ehkä lähtisi tekemään tätä siten, että lämmitystarvetta lasketaan uusiksi pidemmälle kuin tuo 1 jakson pituus. Jos logiikka laukeaa silloin uudelleen, niin lauetkoot, mutta tilanne voi olla silloin jo tosi erilainen jos ylilämpö johtui vaikkapa kiertoilmatakasta, jossa ei ole varaavaa elementtiä.

Markus

 

[masipila]

Noniin, hetken taas näköjään ajatus muhinut. Yksi kohtalaisen simppeli approach olisi että ajastetusti aina osion alussa (juuri sitä ennen) tsekattaisiin sisälämpötila. Jos on alle alarajan / yli ylärajan, niin sitten lasketaan kyseisen jakson lämmitystarve uusiksi ja säädetään sitä vähän ylös tai alas.

Tämä ei toimi tuohon takkaesimerkkiin kovin hyvin, jos takan poltto ei osu sopivasti juuri jakson loppuun siten että alkavan jakson lämmitystarve tulisi huomioitua. Eli siihen tarpeeseen olisi parempi approach tarkkailla lämpötilaa "jatkuvasti" ja laskea rullaavasti esim. now + 6h lämmitystarve uusiksi, säätää sitä, ja tallentaa muuttujaan että uudelleenlaskenta on tehty nyt, jotta seuraavan kerran tämä säätölogiikka voi astua peliin vasta esim. 6h päästä ettei säädetä kilpaa ylös ja alas.

Lisäksi tuohon tarvitaan lokitus, koska ensisijaisesti lämpökäyrä pitäisi ensin saada kohdilleen jotta tällainen ad hoc -säätö olisi enemmän poikkeus kuin sääntö.

Thoughts?

 

[tk-]

Noniin, hetken taas näköjään ajatus muhinut. Yksi kohtalaisen simppeli approach olisi että ajastetusti aina osion alussa (juuri sitä ennen) tsekattaisiin sisälämpötila. Jos on alle alarajan / yli ylärajan, niin sitten lasketaan kyseisen jakson lämmitystarve uusiksi ja säädetään sitä vähän ylös tai alas.

Tämä ei toimi tuohon takkaesimerkkiin kovin hyvin, jos takan poltto ei osu sopivasti juuri jakson loppuun siten että alkavan jakson lämmitystarve tulisi huomioitua. Eli siihen tarpeeseen olisi parempi approach tarkkailla lämpötilaa "jatkuvasti" ja laskea rullaavasti esim. now + 6h lämmitystarve uusiksi, säätää sitä, ja tallentaa muuttujaan että uudelleenlaskenta on tehty nyt, jotta seuraavan kerran tämä säätölogiikka voi astua peliin vasta esim. 6h päästä ettei säädetä kilpaa ylös ja alas.

Lisäksi tuohon tarvitaan lokitus, koska ensisijaisesti lämpökäyrä pitäisi ensin saada kohdilleen jotta tällainen ad hoc -säätö olisi enemmän poikkeus kuin sääntö.

Thoughts?

Joulunpyhät meni kinkkua sulatellessa, niin palataapas arkeen tämän osalta.

Tuo koodiin melkolailla lisää kompleksisuutta jos miettii tuollasta nyt + 6h -tyyppistä ratkaisua? Itse olen pohtinut tuota olemassaolevan periodin muokkausta sillä, että sillekin voidaan tarvittaessa laskea uusi lämmitystarve tuolla sisälämpökorjauksella, mutta periodi pysyy samana. Tässä ratkaisussa täytyy vaan pysyä tietoisena montako tuntia lämmitys on kyseisen kuluvan periodin aikana ollut jo sallittu, jotta se voidaan ottaa jakson kokonaistuntimäärässä sitten loppujakson osalta huomioon.

Tuo kuulostaa järkevälle, että lähtökohtaisesti vain kuluva ja seuraava periodi olisi tuon lämpötilakompensoinnin kohteena, ja sitten palataan normaaliin. Tuo logitus kuulostaa myös järkevälle, eli jos x vuorokauden seurantajaksolla, mikä tuossa riittäväksi katsotaankaan, joudutaan jatkuvasti korjaamaan niin sitten korjattaisiinkin sitä lämmitystarvetta. Toki sen järkevä toteutus tuon tuntimäärä/lämpötila täytyy pohtia huolella, sen sijaan jos käytetään tuota talon vuosilämmitystarvetta niin sen korjaaminen on helpompaa.

 

[masipila]

Tuo koodiin melkolailla lisää kompleksisuutta jos miettii tuollasta nyt + 6h -tyyppistä ratkaisua? I

Riippuu tietty siitä miten ohjaukset on tietokantaan tallennettu. Itselläni ohjaukset on puhdas aikasarja vartin resoluutiolla, eli tallennettu data on täysin tietämätön lämmitysosion olemassaolosta, sellainen on olemassa vaan tilapäisesti siinä vaiheessa kun ohjaukset lasketaan.

Toisin sanoen, omassa toteutuksessani on täysin samantekevää etsinkö nykyhetkestä seuraavan alkavan vartin ja käytän sitä tarkastelujakson alkuhetkenä & loppuhetkenä siitä (esim.) 6h eteenpäin. Itse asiassa tämä on helpompi logiikka kuin että ensin yritän päätellä mikä alkuperäisen laskennan lämmitysjakso on kyseessä ja sitten sen alku- ja loppuhetket kuten edellä.

Mutta kuten sanottua, riippuu tietty siitä missä muodossa data on tallennettu. Minulla on on js-jodan ZonedDateTime objekteja joten ajan lisääminen toiseen on triviaali oneliner.

Tässä ratkaisussa täytyy vaan pysyä tietoisena montako tuntia lämmitys on kyseisen kuluvan periodin aikana ollut jo sallittu, jotta se voidaan ottaa jakson kokonaistuntimäärässä sitten loppujakson osalta huomioon.

Jep. Tuossa minun flexible heating need -konseptissa tämän merkitys korostuu, koska sisälämmön liiallinen lasku voi olla seurausta siitä että tuo flexibility-parametri säädetty liian aggressiiviseksi ja lämmitystarvetta on siirretty halvempien hintojen toivossa muualle.

Mutta ajatuksena tässä minulla oli että ensin otetaan tuo now (pyöristettynä seuraavaan alkavaan varttiin) + 6h, sitten lasketaan tuoreimman sääennusteen perusteella paljonko tälle jaksolle pitäisi olla lämmitystä. Seuraavaksi luetaan tämän jakson ohjauksista kuinka paljon lämmitystä on tulossa. Ja sitten ylikirjoitetaan ohjaus tälle jaksolle siten, että sille taataan juuri laskettu lämmitystarve ja vähän ekstraa.

Markus

 

[masipila]

Virittelin muuten välipäivien aikana kuormantausksen alkavana vuonna oletettavasti yleistyvää tehotariffia silmälläpitäen, kun openHABin yhteisössä norjalaiset peräänkuuluttivat sellaista. Heillä kuukausimaksu määräytyy tällaisen taulukon perusteella: Our grid tariffs | BKK.no/en

Toteutin tämän seuraavasti.

Ensin pitää olla hyvä käsitys siitä, kuinka suuria kuormia on. Meillä on
- 0.65 kW pohjakulutus talvella
- 11 kW sähköauton laturi
- 11 kW kiuas
- 3 kW lämminvesivaraaja
- 2 kW maalämpöpumppu

Eli esim. tuolla Norskien taulukolla tavoitteena olisi, että piikit eivät saa ylittää 15 kW rajaa. To be on the safe side, pidetään rajana 14 kW ja siihen asti optimoidaan hinnan perusteella.

Käytännössä tähän on helppo osua, kunhan ei sauno samaan aikaan kuin autoa ladataan ja kunhan lämminvesivaraaja ei ole samaan aikaan päällä kuin auton laturi tai kiuas.

Toteutin tämän siten, että tietokantaan tulee yksi uusi aikasarja, EstimatedTotalLoad.

Ensin tähän aikasarjaan alustetaan pohjakulutus 0.65 kW. Seuraavaksi voidaan laittaa käyttäjän määrittelemä vakiokuorma halutuille ajoille, esim 1 kW klo 16-19 välille.

Tämän jälkeen optimoidaan sähköauton lataus lataustarpeen mukaisesti.

Seuraavaksi lämminvesivaraajan optimointi, jossa otetaan hinnan perusteella halvin ajanjakso, kunhan tuo 14 kW raja ei ylity.

Sitten maalämpöpumpun optimointi, kunnioittaen kuitenkin tuota 14 kW rajaa.

Markus

 

[tk-]

Riippuu tietty siitä miten ohjaukset on tietokantaan tallennettu. Itselläni ohjaukset on puhdas aikasarja vartin resoluutiolla, eli tallennettu data on täysin tietämätön lämmitysosion olemassaolosta, sellainen on olemassa vaan tilapäisesti siinä vaiheessa kun ohjaukset lasketaan.

Toisin sanoen, omassa toteutuksessani on täysin samantekevää etsinkö nykyhetkestä seuraavan alkavan vartin ja käytän sitä tarkastelujakson alkuhetkenä & loppuhetkenä siitä (esim.) 6h eteenpäin. Itse asiassa tämä on helpompi logiikka kuin että ensin yritän päätellä mikä alkuperäisen laskennan lämmitysjakso on kyseessä ja sitten sen alku- ja loppuhetket kuten edellä.

Mutta kuten sanottua, riippuu tietty siitä missä muodossa data on tallennettu. Minulla on on js-jodan ZonedDateTime objekteja joten ajan lisääminen toiseen on triviaali oneliner.


Jep. Tuossa minun flexible heating need -konseptissa tämän merkitys korostuu, koska sisälämmön liiallinen lasku voi olla seurausta siitä että tuo flexibility-parametri säädetty liian aggressiiviseksi ja lämmitystarvetta on siirretty halvempien hintojen toivossa muualle.

Mutta ajatuksena tässä minulla oli että ensin otetaan tuo now (pyöristettynä seuraavaan alkavaan varttiin) + 6h, sitten lasketaan tuoreimman sääennusteen perusteella paljonko tälle jaksolle pitäisi olla lämmitystä. Seuraavaksi luetaan tämän jakson ohjauksista kuinka paljon lämmitystä on tulossa. Ja sitten ylikirjoitetaan ohjaus tälle jaksolle siten, että sille taataan juuri laskettu lämmitystarve ja vähän ekstraa.

Markus

Se miksi itse pitäytyisin tuossa alkuperäisessä periodissa ja sen laskennan muuttamisessa on juurikin yksinkertaistaminen. Meillä esimerkiksi talossa käy niin, että kun ihmiset on poissa tuottamasta lämpöä ruuanlaitolla, saunomisella jne, niin jo parissa päivässä sisälämpö laskee lähes asteen. Eli yllättävän iso merkitys on juurikin tuollaisella satunnaisuudella paljonko sattuu porukkaa olemaan kotona jne.

Sitä voi parametroida loputtomiin, tuoda erilaisia tuuli- ja aurinkokompensaatioita jne. Loppuviimeksi en usko, että sillä isollakaan parametrien määrällä päästään merkittävästi parempaan tarkkuuteen, vaan lähinnä tarve olisi osata huomioida isot äkilliset muutokset, esim juurikin takan lämmitys, nopea kylmeneminen, nopea lämpeneminen jne.

Pörssärissä kanssa se lopullinen ohjausdata on tallennettuna varttikohtaisesti, ja sieltä toki pystyy lukemaan aina ohjausten laskennassa myös sen edeltävän periodisuunnitelman. Siksi oma ajatus menee tuohon suuntaan, että pysytellään niissä alkuperäisissä aikaperiodeissa, ja tarkistetaan aina kuluvalle periodille jo toteutunut lämmitys ja kytketään sitten päälle enää se määrä mikä tarvitsee JOS lämmitykset lasketaan uusiksi. Nykymuodossa ne lasketaan käytännössä 3h välein kun sääennuste päivitetään, mutta jatkossahan tuossa voisi tarkistaa lämpötilaa esimerkiksi tunnin välein ja tarvittaessa sitten korjata.

Tuo lämpötilatiedon saanti serverille on vielä toteuttamatta, ajatuksena siihen olisi tehdä erillinen mqtt-serveri mihin voi erilaisilla laitteilla dataa lähettää helposti, ja sitten käyttäjä voi liittää ohjauksiin ne sensoritiedot sieltä mqtt-serveriltä. Katsotaan josko ehdittäisiin toteuttamaan tässä lähiaikoina vähintäänkin testipuolelle.

Virittelin muuten välipäivien aikana kuormantausksen alkavana vuonna oletettavasti yleistyvää tehotariffia silmälläpitäen, kun openHABin yhteisössä norjalaiset peräänkuuluttivat sellaista. Heillä kuukausimaksu määräytyy tällaisen taulukon perusteella: Our grid tariffs | BKK.no/en

Toteutin tämän seuraavasti.

Ensin pitää olla hyvä käsitys siitä, kuinka suuria kuormia on. Meillä on
- 0.65 kW pohjakulutus talvella
- 11 kW sähköauton laturi
- 11 kW kiuas
- 3 kW lämminvesivaraaja
- 2 kW maalämpöpumppu

Eli esim. tuolla Norskien taulukolla tavoitteena olisi, että piikit eivät saa ylittää 15 kW rajaa. To be on the safe side, pidetään rajana 14 kW ja siihen asti optimoidaan hinnan perusteella.

Käytännössä tähän on helppo osua, kunhan ei sauno samaan aikaan kuin autoa ladataan ja kunhan lämminvesivaraaja ei ole samaan aikaan päällä kuin auton laturi tai kiuas.

Toteutin tämän siten, että tietokantaan tulee yksi uusi aikasarja, EstimatedTotalLoad.

Ensin tähän aikasarjaan alustetaan pohjakulutus 0.65 kW. Seuraavaksi voidaan laittaa käyttäjän määrittelemä vakiokuorma halutuille ajoille, esim 1 kW klo 16-19 välille.

Tämän jälkeen optimoidaan sähköauton lataus lataustarpeen mukaisesti.

Seuraavaksi lämminvesivaraajan optimointi, jossa otetaan hinnan perusteella halvin ajanjakso, kunhan tuo 14 kW raja ei ylity.

Sitten maalämpöpumpun optimointi, kunnioittaen kuitenkin tuota 14 kW rajaa.

Markus

Tällainen meilläkin on tulossa tuohon seuraavaan versioon, eli käyttäjä saa määrittää maksimitehon mitä varttikohtaisesti ei ylitetä. Uskoisin tehotariffien lisääntyvän tulevaisuudessa paljonkin. Toki parametrointi tässäkin tulee olemaan sitten vielä vähän arvoitus, koska välillä tulee myös tilanteita missä pitää laskea kannattaako ylittää jokin porras, jättää sähkö kokonaan käyttämättä vai maksaa siitä vähän enemmän jossain kohdassa, mutta kuitenkin niin ettei tehoraja ylity.