EMHASS optimointi ratkaisu Home Assisntanttiin
- Viestiketjun aloittaja dbwarrior
- Aloituspäivämäärä
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:
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" ?
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.
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:
"kirjastoa" on nyt tuunattu lisää. Kaveriksi tuotu kohtuu tukeva testiautomaatio. On itselle eka HA projekti jossa busines logiikkaa voipi testata läppärillä ja "tuotantoon" voi viedä testattua koodia.
Vielä puuttuu tuo HAEO ennusteen seuraaminen mutta konsepti alkaa siinäkin kirkastua.
Se mikä tuossa ulkopuolinen "kirjasto" lähetsymisessä yllätty positiivisesti on AI agentti pohjaisessa devi kyvykkyydessä.
voi antaa suoraan taskina uuden ominaisuuden ja parhaimmillaan se sitten puksuttaa niin kauan että uuden ominaisuuden ominaisuuden buisnelogiikkaa testaava testi on passed. Eli enhän minäkään tälläista Python "kirjastoa" itse ois jaksanut alkaa tekemään, mutta nyt tuli aika kivasti kivuttomasti.
Vielä puuttuu tuo HAEO ennusteen seuraaminen mutta konsepti alkaa siinäkin kirkastua.
Se mikä tuossa ulkopuolinen "kirjasto" lähetsymisessä yllätty positiivisesti on AI agentti pohjaisessa devi kyvykkyydessä.
voi antaa suoraan taskina uuden ominaisuuden ja parhaimmillaan se sitten puksuttaa niin kauan että uuden ominaisuuden ominaisuuden buisnelogiikkaa testaava testi on passed. Eli enhän minäkään tälläista Python "kirjastoa" itse ois jaksanut alkaa tekemään, mutta nyt tuli aika kivasti kivuttomasti.
Se mikä tuosta kuvasta ei kyllä selviä ainakaan :
Kotiakkua on primääri netotuskohde joka tietty tuottaa tarvittessa tehoa jotta netto nollaan päästään. Jos ei ennusteen anneta ohjata niin käyttäjän asettama latausteho käytännössä rajaa sen, mitä muille "netottajille" jää prioriteetti järjestyksessä jaettavaksi.
Nämä EV, rele1 ja rele2 prioriteetit on käyttäjän asetettavissa. Esim jos haluaa ohjata kaiken PV:n ensisijaisesti saunan kontaktorille(rele2) niin se onnistuu vaihtamalla sen prioriteeti korkeimmaksi.
Sitten on myös mahdollista asettaa esim EV:lle tasainen 3kw latausteho joka ei sitten riipu siitä onko just sillä hetkellä PV:tä tarjolla 2 vai 4kw
Sama homma noille releille. Niille löytyy myös tällainen "force on" käsite.
Kaikki nämä yhdessä tuotta käytännössä mahdollisuuden aika joustavasti mennä erillaiset käyttäjätarpeet läpi niin ettei osto tai myyntiä synny päivässä(jos ei niin haluta)
Kotiakkua on primääri netotuskohde joka tietty tuottaa tarvittessa tehoa jotta netto nollaan päästään. Jos ei ennusteen anneta ohjata niin käyttäjän asettama latausteho käytännössä rajaa sen, mitä muille "netottajille" jää prioriteetti järjestyksessä jaettavaksi.
Nämä EV, rele1 ja rele2 prioriteetit on käyttäjän asetettavissa. Esim jos haluaa ohjata kaiken PV:n ensisijaisesti saunan kontaktorille(rele2) niin se onnistuu vaihtamalla sen prioriteeti korkeimmaksi.
Sitten on myös mahdollista asettaa esim EV:lle tasainen 3kw latausteho joka ei sitten riipu siitä onko just sillä hetkellä PV:tä tarjolla 2 vai 4kw
Sama homma noille releille. Niille löytyy myös tällainen "force on" käsite.
Kaikki nämä yhdessä tuotta käytännössä mahdollisuuden aika joustavasti mennä erillaiset käyttäjätarpeet läpi niin ettei osto tai myyntiä synny päivässä(jos ei niin haluta)
Nyt refactoroin toteutuksen niin, että löytyy myös tuki käyttötapaukselle:
EV on primääri latauskohde aseteltavalla maksimilla ja jos sen jälkeen jää ylimääräistä niin sitten prioriteetti järjesyksessä loput. Esim (Aku, lvv jne)
Oli lähtenyt kehittymään siihen suuntaan että kotiakku oli kiinteästi primääri kohde eikä voinut muuta kuin rajoittaa sen tehoa joka sitten "valutti" mahdollisen ylijäämän seuraaville kohteille.
EV on primääri latauskohde aseteltavalla maksimilla ja jos sen jälkeen jää ylimääräistä niin sitten prioriteetti järjesyksessä loput. Esim (Aku, lvv jne)
Oli lähtenyt kehittymään siihen suuntaan että kotiakku oli kiinteästi primääri kohde eikä voinut muuta kuin rajoittaa sen tehoa joka sitten "valutti" mahdollisen ylijäämän seuraaville kohteille.