EMHASS optimointi ratkaisu Home Assisntanttiin
- Keskustelun aloittaja dbwarrior
- Aloitettu
Itsellä ei suoraa kokemusta, mutta tässä pari syytä, miksi en päätynyt emhassiin. Päätin itse tehdä oman optimointiratkaisun lämmitykseen, kun en löytänyt tukea COP:n asettamiselle per lämmityslaite ja toisaalta en keksinyt, että miten olisi voinut lisätä muita energialähteitä (esimerkiksi puu/öljy). Jos noihin muilla vinkkiä, niin mielelläni otan vastaan. Vaihtaisin varmaan emhassiin, jos nämä ratkeaisi.
Mutta jos noita tarpeita ei ole, niin paperilla kuulostaa tosi hyvältä paneelien ja akkujen optimointiin.
Mutta jos noita tarpeita ei ole, niin paperilla kuulostaa tosi hyvältä paneelien ja akkujen optimointiin.
Ehkä se ei ole ongelma. Ei tosiaan liikaa kannata kuunnella minua tässä, sillä en ole emhassia kokeillut. Koetan vain tuoda esille, että mitkä asiat minua mietitytti. Tuolla COP-asialla voi olla merkitystä, jos käyttää sitä "Deferrable load thermal model"ia. Olihan siellä kai myös mahdollisuus asettaa, että minimituntimäärät lämmitykselle per lämmönlähde eri lämpötiloissa.
Itsellä kun on nykyohjauksessa pilpin kompura, pilpin sähkövastukset, kaksi ilppiä ja optimointimalli pyytää laittamaan tarvittaessa puuta takkaan, ni näiden tekeminen emhassin puolelle tuntui haastavalta dokumentaation perusteella. Ja kun oma malli optimoi erikseen ylä- ja alakerran, joissa vähän eri asetuslämpötilat. Ja pilp tietysti lämmittää molempia kerroksia ilmanvaihdon kautta (+alakertaa lattialämmityksen kautta). Ja kun on omia lisäsääntöjä optimoinnissa, että esim. pilpin kompurasta on vuorokausitasolla otettu kaikki irti (tuloilman lämmitystä varten) ennen muihin lämmönlähteisiin siirtymistä.
Ja riippuu, että haluatko käyttää taloa "lämpöakkuna". Jos ajattaa ilppiä ja mlp:tä vaan pitääkseen sisälämpötilan asetuspisteessä, ni sithän tuo varmaan toimii oikein hyvin? Kun se (käsittääkseni) osaa ennustaa sitä sähkönkulutusta ja senhän luulis toimivan ihan ok. Että ajetaan ilppiä akuista jne.
Noh, tässä omia aatteita. Toivottavasti kuulemme oikeita käyttökokemuksia myös eikä vaan tämmöistä mutuilua. Semmoinen "kirjasto valmiita talokonffeja" olisi varmasti kiva tähän emhassiinkin.
Itsellä kun on nykyohjauksessa pilpin kompura, pilpin sähkövastukset, kaksi ilppiä ja optimointimalli pyytää laittamaan tarvittaessa puuta takkaan, ni näiden tekeminen emhassin puolelle tuntui haastavalta dokumentaation perusteella. Ja kun oma malli optimoi erikseen ylä- ja alakerran, joissa vähän eri asetuslämpötilat. Ja pilp tietysti lämmittää molempia kerroksia ilmanvaihdon kautta (+alakertaa lattialämmityksen kautta). Ja kun on omia lisäsääntöjä optimoinnissa, että esim. pilpin kompurasta on vuorokausitasolla otettu kaikki irti (tuloilman lämmitystä varten) ennen muihin lämmönlähteisiin siirtymistä.
Ja riippuu, että haluatko käyttää taloa "lämpöakkuna". Jos ajattaa ilppiä ja mlp:tä vaan pitääkseen sisälämpötilan asetuspisteessä, ni sithän tuo varmaan toimii oikein hyvin? Kun se (käsittääkseni) osaa ennustaa sitä sähkönkulutusta ja senhän luulis toimivan ihan ok. Että ajetaan ilppiä akuista jne.
Noh, tässä omia aatteita. Toivottavasti kuulemme oikeita käyttökokemuksia myös eikä vaan tämmöistä mutuilua. Semmoinen "kirjasto valmiita talokonffeja" olisi varmasti kiva tähän emhassiinkin.
Jäi vaivaamaan tämä asia ja lueskelin tätä sivua: https://emhass.readthedocs.io/en/latest/thermal_model.html#implementing-the-model
Jos oikein tulkkasin, niin tuo kutsu tekee optimoinnin kaikille kuormille. Ja mukana pitää siis tosiaankin olla tiedot kaikista kuormista. Ja kuormien hinnat ovat yhteiset eli jos jaat ne COP:lla, niin jonkun kuorman hinta on ns. väärin (tosin ei aivot nyt sanoneet, että onko tämä ongelma). Jos taas laitat lämmittimen tehon antotehon mukaan, niin sit akusta kulutetaan tosiaankin antotehon eikä ottotehon mukaan. Jos taas pistät sinne pelkän ottotehon, niin sit pitäisi alkaa jotenkin niitä huoneen ominaisuuksia muuttamaan (cooling_constant/heating_rate), että ne täsmää siihen talon/huoneen lämpökapoihin jne, jotta lukemat täsmää?
Kyselin myös kielimalleilta ja olivat samaa mieltä ongelmista. Tosin saatoin ehkä johdatella kysymyksenasettelussa. Jotenkin tuntuu, että jotenkin vaikea tätä yhtälöä saada toimimaan, jos on yhtään lämmitintä, jonka COP ei ole 1.
Sattuisikohan jollakin foorumilaisella olemaan EMHASS oikeasti käytössä, että voisi kommentoida?
Jos oikein tulkkasin, niin tuo kutsu tekee optimoinnin kaikille kuormille. Ja mukana pitää siis tosiaankin olla tiedot kaikista kuormista. Ja kuormien hinnat ovat yhteiset eli jos jaat ne COP:lla, niin jonkun kuorman hinta on ns. väärin (tosin ei aivot nyt sanoneet, että onko tämä ongelma). Jos taas laitat lämmittimen tehon antotehon mukaan, niin sit akusta kulutetaan tosiaankin antotehon eikä ottotehon mukaan. Jos taas pistät sinne pelkän ottotehon, niin sit pitäisi alkaa jotenkin niitä huoneen ominaisuuksia muuttamaan (cooling_constant/heating_rate), että ne täsmää siihen talon/huoneen lämpökapoihin jne, jotta lukemat täsmää?
Kyselin myös kielimalleilta ja olivat samaa mieltä ongelmista. Tosin saatoin ehkä johdatella kysymyksenasettelussa. Jotenkin tuntuu, että jotenkin vaikea tätä yhtälöä saada toimimaan, jos on yhtään lämmitintä, jonka COP ei ole 1.
Sattuisikohan jollakin foorumilaisella olemaan EMHASS oikeasti käytössä, että voisi kommentoida?
Sattui silmiin Emhassille ihan käyttöliittymän kautta konffattava vaihtoehto: http://haeo.io/
Kurkkaapa tämä. Siinä voi tehdä itse monimutkaisia topologioita. Thermal Modelia eli talon lämpötilaennustetta ei vielä ole, mutta ehkä sen voisi mallintaa Batteryna, jossa ennustettu Load (=lämpöhäviöt) ja sitten useampi Grid (=lämpöpumppu tai muu lämmönlähde, jolla Batterya ladataan), joille esilaskettuna energianhinnat jaettuna ennustetulla COP-arvolla. (Ilma)lämpöpumpun maksimiteho sitten Grid->Battery välisen Connectionin "Max Power Source→Target" -arvoksi.
Täällä vertailu Emhassin ominaisuuksiin: https://haeo.io/user-guide/alternatives/
Täällä esimerkkisysteemi: https://haeo.io/user-guide/examples/sigenergy-system/#system-overview
Kurkkaapa tämä. Siinä voi tehdä itse monimutkaisia topologioita. Thermal Modelia eli talon lämpötilaennustetta ei vielä ole, mutta ehkä sen voisi mallintaa Batteryna, jossa ennustettu Load (=lämpöhäviöt) ja sitten useampi Grid (=lämpöpumppu tai muu lämmönlähde, jolla Batterya ladataan), joille esilaskettuna energianhinnat jaettuna ennustetulla COP-arvolla. (Ilma)lämpöpumpun maksimiteho sitten Grid->Battery välisen Connectionin "Max Power Source→Target" -arvoksi.
Täällä vertailu Emhassin ominaisuuksiin: https://haeo.io/user-guide/alternatives/
Täällä esimerkkisysteemi: https://haeo.io/user-guide/examples/sigenergy-system/#system-overview
Viimeksi muokattu:
- Keskustelun aloittaja
- #10
Asentelin tuon HAEO:n käyttöön ja näytti ihan lupaavalta kun kokonaisuus sisälti nodet:
Kotiakku
Kuorma
PV
Verkko
Sitten kun pitäisi saada mukaan tuo että on isosti hyvin paikalla olevaa EV akustoa niin menikin sormi suuuhun.
Teoriassa voisi olla akusto jossa ei ole export tehoa, mutta sitten pitäisi saada kuitenkin joku rahallinen arvo tuonne akkuun ladatulle sähkölle.
Osaako joku ideoida miten noista rakennus palikoista syntyisi toimiva "piirustus" ?
Kotiakku
Kuorma
PV
Verkko
Sitten kun pitäisi saada mukaan tuo että on isosti hyvin paikalla olevaa EV akustoa niin menikin sormi suuuhun.
Teoriassa voisi olla akusto jossa ei ole export tehoa, mutta sitten pitäisi saada kuitenkin joku rahallinen arvo tuonne akkuun ladatulle sähkölle.
Osaako joku ideoida miten noista rakennus palikoista syntyisi toimiva "piirustus" ?
- Keskustelun aloittaja
- #12
Nyt kun alkaa oma "EMS" olla pystyssä, niin pysähdyin miettimään onkohan tämä menossa johonkin sellaiseen suuntaan joka on jo ratkaistu toisten toimesta jossain projektissa.
Kiinnostaisi kuulla mihin ratkaisuun muut ovat päätyneet tilanteessa, jossa HAEO toimii hyvin optimointimoottorina / horizonin tuottajana, mutta käyttötarve ei lopu vielä siihen.
Meillä tarve on käytännössä tällainen:
- HAEO / vastaava optimizer antaa eteenpäin katsovan horisontin
- mutta lisäksi tarvitaan reaaliaikainen paikallinen EMS-kerros, joka tekee päätöksiä “nyt”
- mukana on kotiakkuinvertterin setpoint-ohjaus
- EV-latauksen dynaaminen virtaohjaus
- rele-/kuormaohjaus prioriteeteilla
- vartti netotukseen pystyvä looppi
- safety / fallback -logiikka (stale data, degraded mode, battery protect, manual-safe jne.)
- eli käytännössä planner + realtime executor + guard layer
Olisi mielenkiintoista kuulla:
1. Oletteko ratkaisseet tämän HAEO + omat HA-automaatio/-EMS -kerroksella?
2. Vai oletteko siirtyneet johonkin muuhun, kuten evcc, openWB, EMHASS, Hanergy, AURUM tms.?
3. Jos käytätte jotain näistä, saako siihen oikeasti tuotua optimizerin horizonin sisään niin, että realtime-ohjaus edelleen jää local control -kerrokselle?
4. Missä teillä menee raja optimizerin ja execution layerin välillä?
Kiinnostaa erityisesti kokemukset sellaisista toteutuksista, joissa ohjataan yhtä aikaa:
- akkua
- EV-latausta
- muita joustavia kuormia
Ja vielä niin, että järjestelmä pysyy ymmärrettävänä ja ylläpidettävänä.
Kaikki arkkitehtuurikuvat, kokemukset, “tähän päädyttiin ja miksi” -vastaukset kiinnostavat.
Kiinnostaisi kuulla mihin ratkaisuun muut ovat päätyneet tilanteessa, jossa HAEO toimii hyvin optimointimoottorina / horizonin tuottajana, mutta käyttötarve ei lopu vielä siihen.
Meillä tarve on käytännössä tällainen:
- HAEO / vastaava optimizer antaa eteenpäin katsovan horisontin
- mutta lisäksi tarvitaan reaaliaikainen paikallinen EMS-kerros, joka tekee päätöksiä “nyt”
- mukana on kotiakkuinvertterin setpoint-ohjaus
- EV-latauksen dynaaminen virtaohjaus
- rele-/kuormaohjaus prioriteeteilla
- vartti netotukseen pystyvä looppi
- safety / fallback -logiikka (stale data, degraded mode, battery protect, manual-safe jne.)
- eli käytännössä planner + realtime executor + guard layer
Olisi mielenkiintoista kuulla:
1. Oletteko ratkaisseet tämän HAEO + omat HA-automaatio/-EMS -kerroksella?
2. Vai oletteko siirtyneet johonkin muuhun, kuten evcc, openWB, EMHASS, Hanergy, AURUM tms.?
3. Jos käytätte jotain näistä, saako siihen oikeasti tuotua optimizerin horizonin sisään niin, että realtime-ohjaus edelleen jää local control -kerrokselle?
4. Missä teillä menee raja optimizerin ja execution layerin välillä?
Kiinnostaa erityisesti kokemukset sellaisista toteutuksista, joissa ohjataan yhtä aikaa:
- akkua
- EV-latausta
- muita joustavia kuormia
Ja vielä niin, että järjestelmä pysyy ymmärrettävänä ja ylläpidettävänä.
Kaikki arkkitehtuurikuvat, kokemukset, “tähän päädyttiin ja miksi” -vastaukset kiinnostavat.
- Keskustelun aloittaja
- #13
Päädyin tekemään oman pyscript toteutuksen (tai tekoäly teki, minä speksasin)
Tuo tuntuu tällä hetkellä oikein mitoitetulta ratkaisulta.
Jos joku tarvii "projektilleen" pohjaa niin mielellään jaan.
Tuolla setuplla saapi luotua rele tyyppisiä ja säädettäviä kuormia tuottamaan vartti netotukseen optimi lopputulos.
Tai ostamaan verkosta jos alitetaan rajahinta, tai myymään sinne.
Lisäksi kyky ottaa vastaan esim HAEO optioiminti horisontin tulosta pitäisikö ostaa tai myydä. Tuon ulkopuolisen tiedon käyttämisen voi skipata käyttäjän toiveesta.
Ai:n katselmointi palaute oli tällaista:
Tuo tuntuu tällä hetkellä oikein mitoitetulta ratkaisulta.
Jos joku tarvii "projektilleen" pohjaa niin mielellään jaan.
Tuolla setuplla saapi luotua rele tyyppisiä ja säädettäviä kuormia tuottamaan vartti netotukseen optimi lopputulos.
Tai ostamaan verkosta jos alitetaan rajahinta, tai myymään sinne.
Lisäksi kyky ottaa vastaan esim HAEO optioiminti horisontin tulosta pitäisikö ostaa tai myydä. Tuon ulkopuolisen tiedon käyttämisen voi skipata käyttäjän toiveesta.
Ai:n katselmointi palaute oli tällaista: