Kun optimoinnista tuli järjestelmä

OSA 1:ssa syntyi motivaatio, OSA 2:ssa tehtiin ensimmäiset kokeilut ja OSA 3:ssa data pakotti ajattelemaan laajemmin.

OSA 4 on se kohta, jossa optimointi muuttuu “kikkailusta” järjestelmäksi.

Kun ohjaus alkoi olla päivittäistä manuaalityötä ja mukaan tuli yhä enemmän reunaehtoja (mukavuus, sulakkeet, COP, käyttövesi), kävi selväksi, että pelkkä ajastus tai yksittäinen pilvipalvelu ei riitä. Tarvittiin oma “kotitalouden energian käyttöjärjestelmä”.

Tässä kohtaa Home Assistant (HA) nousi keskiöön.

Miksi Home Assistant?

Kotitalouden energiankäytön ohjaus on käytännössä säätöjärjestelmä, jossa on:

• useita mittauksia (hinta, teho, lämpötilat, ennusteet)
• useita toimilaitteita (lämpöpumppu, EV-lataus, releet, varaajat)
• ristiriitaisia tavoitteita (halpa hinta vs COP vs mukavuus vs sulakkeet)
• sekä poikkeustilanteita (pakkasjakso, sähkökatko, datakatko, laitevika)

Tällaisessa kokonaisuudessa HA:n vahvuus on:

• paikallinen logiikka (ei riippuvuutta pilvestä)
• laaja integraatiotuki (Nordpool, Shelly, Modbus, P1/HAN, API:t)
• mahdollisuus rakentaa “PLC-tyylinen” ohjausrakenne (tilakoneet, prioriteetit, hystereesit)
• läpinäkyvyys: näet mitä järjestelmä tekee ja miksi

Samaan aikaan pitää myöntää yksi asia suoraan:

Home Assistant on aluksi hankalampi kuin valmiit “optimointipalvelut”.
Mutta se on ainoa tapa rakentaa ohjaus, joka huomioi kaikki sinun reunaehtosi.

Perusperiaate: Ohjauskerrokset (Layering)

Tärkein arkkitehtuurinen päätös oli jakaa logiikka kerroksiin.

Ajattelen tätä kuin teollisuusautomaatiota: ensin turvallisuus, sitten rajoitteet, vasta sitten optimointi.

Kerros 0: Turva ja perustoiminta

• Mitä tapahtuu, jos HA kaatuu?
• Mitä tapahtuu, jos wifi pätkii?
• Mitä tapahtuu, jos mittausdata puuttuu?

Perusajatus: talon pitää pysyä lämpimänä ja turvallisena, vaikka optimointi loppuisi.

Kerros 1: Rajoitteet (Constraints)

• Pääsulake ja vaihekuorma
• Käyttöveden minimilämpö
• Sisälämpötilan alaraja
• Lämpöpumpun suojaehdot
• Järjestelmän “ei ikinä” -säännöt

Kerros 2: Optimointi (Price / PV / Forecast)

• Halvimmat tunnit
• PV-tuotannon hyödyntäminen
• Sääennuste
• Käyttöjaksojen määrän valinta
• Dynaaminen priorisointi

Tämä arkkitehtuuri oli koko järjestelmän käännekohta.
Ilman kerrosjakoa logiikka muuttuu nopeasti sekavaksi “jos tämä niin tuo” -rakenteeksi.

Kerrosmalli mahdollistaa:

• laajennettavuuden
• vikatilanteiden hallinnan
• optimoinnin kehittämisen ilman, että turvallisuus vaarantuu

Uusi konfiguraatio keväällä 2025

Keväällä 2025 tein tietoisesti päätöksen: mittausjakso oli ohi, nyt voi kehittää.

Suurin muutos oli siirtyminen yhden pitkän ajon mallista monijaksoiseen ohjaukseen, jossa lämmitys jaetaan vuorokauden sisällä useampaan osaan.

Tämä oli iso askel kohti “COP-ystävällistä” ja mukavuusrajoissa pysyvää optimointia.

Monijaksomalli (esimerkki-ajattelu)

• Kesä: käyttövesi 2 × 1 h / päivä
• Kevät/syksy: 3 jaksoa / päivä
• Talvi: 4 jaksoa / päivä

Tämä sopi erityisen hyvin osittain varaavaan vesikiertoiseen lattialämmitykseen.

Samalla se vähensi kahta ongelmaa:

1. Lämpötilan heilahtelu pieneni
2. “Kaksi vuorokautta lähes ilman lämmitystä” -tilanne käytännössä poistui

Sulakevahti: optimoinnin pakollinen perusta

Kun sähköauto, maalämpö ja sauna osuvat samoihin halpoihin tunteihin, optimointi voi nostaa huipputehoa.

Tämä on optimoinnin paradoksi:

• lasku voi pienentyä
• mutta liittymätehon tarve voi kasvaa

Koska olin 3×25 A liittymällä, sulakevahdista tuli käytännössä pakollinen.

Sulakevahdin peruslogiikka

• Jos mikä tahansa vaihe ylittää 25 A → EV-lataus pois
• Palautus vasta, kun virta on selvästi alle rajan (hystereesi), ettei tule sahausta

Tämä yksi logiikka teki optimoinnista mahdollisen ilman jatkuvaa varomista.

Tärkeä huomio:

Sulakevahdin ei pidä “optimoida”. Sen pitää suojata.

Sulakevahti kuuluu aina kerrokseen 1 (rajoitteet), ei kerrokseen 2 (optimointi).

Vaihekuorman tasaus (vinokuorma)

Sulakevahdin jälkeen seuraava askel oli rehellinen sähkötekniikka.

Monessa talossa kuormat eivät ole tasapainossa:

• yksi vaihe on jatkuvasti raskaampi
• muilla on varaa

Tämä aiheuttaa sen, että “sulakeongelma” ei ole kokonaistehon ongelma vaan yhden vaiheen ongelma.

Ratkaisuvaihtoehdot ovat käytännössä:

1. Kuormien uudelleen kytkentä vaiheille (sähkötyö)
2. Ohjauksen ajoitus niin, ettei sama vaihe kuormitu samaan aikaan
3. Pitkällä tähtäimellä: laitteet jotka tukevat vaiheohjausta tai dynaamista vaiheiden käyttöä

Tässä kohtaa optimointi ei ole enää pelkkää ohjelmointia. Se on osa sähkösuunnittelua.

Lämpöpumpun ohjaus: EVU, Boost ja “COP-ajattelu”

Thermia Calibra 12:n ohjaus meni käytännössä näin:

• EVU/estot toimivat “kytkimenä”: saako pumppu käydä vai ei
• Boost nostaa tavoitetasoa, mutta voi heikentää COP:ia
• menoveden lämpötilan nostaminen nostaa kompressorin työmäärää

OSA 2:ssa lähdin mallilla:

“lyhyt, kova ajo halvalla hinnalla”

OSA 4:ssa mallista tuli:

“riittävästi ajoa sopivissa jaksoissa, niin että COP pysyy järkevänä ja mukavuus säilyy”

Tämä on myös se kohta, jossa sääennuste ja ulkolämpötila alkoivat aidosti vaikuttaa ohjaukseen.

Ohjauksen “tilakone”: kesä / välikausi / talvi

Yksi käytännöllisimmistä arkkitehtuuriratkaisuista on tehdä tilat:

• Kesätila: pääpaino käyttövedessä
• Välikausi: 2–3 lämmitysjaksoa
• Talvitila: 4 jaksoa, sulake- ja COP-rajoitteet korostuvat

Tila voi perustua esimerkiksi:

• ulkolämpötilan liukuvaan keskiarvoon
• tai lämmitystarvelukuun (HDD)
• tai yksinkertaisesti kalenteriin + lämpötilaan

Tässä on tärkeä periaate:

Järjestelmä ei saa vaihtaa tilaa liian herkästi.
Käytä hystereesiä ja viivettä.

Muuten järjestelmä “sekoilee” kelien vaihdellessa.

Hintadata: Nordpool on vain yksi signaali

Kun ohjaus muuttui järjestelmäksi, hinnasta tuli yksi signaali muiden joukossa.

Hintaa ei voi käyttää “yksinvaltiaana”, koska:

• COP vaihtelee
• sulakkeet rajoittavat
• mukavuus rajoittaa
• käyttövesi rajoittaa
• PV-tuotanto muuttaa logiikkaa

Siksi käytännössä tein ohjauksen niin, että:

• Hinta valitsee “hyvät ikkunat”
• Rajoitteet päättävät, mitä niissä ikkunoissa saa tehdä

Tämä erottaa kestävän ohjauksen “pörssisähkökikkailusta”.

Aurinkosähkö muuttaa kaiken

Kun aurinkosähkö tuli mukaan keväällä 2025, optimointi ei enää ollut pelkkää kulutuksen siirtoa halvemmalle hinnalle.

Siitä tuli myös:

• oman tuotannon hyödyntämistä
• myynnin vs itse käytön tasapainoa
• ja käytännössä “päiväaikaan siirtyvää” optimointia

Tämä näkyi erityisesti kesällä:

• hinnat voivat olla nollassa
• PV tuottaa paljon
• ja silti suuri osa tuotannosta menee myyntiin

Kun järjestelmä osaa hyödyntää PV:tä, se voi:

• lämmittää käyttöveden tuotannon aikaan
• nostaa lattialämmön lämpöä varovasti (jos hyötyä)
• ajoittaa EV-latausta keskelle päivää

Tässä kohtaa ohjaus alkaa näyttää jo “kotien energiahubilta”.

Luotettavuus ja “mitä jos data puuttuu?”

Tämä on osa, jonka moni harrastaja ohittaa — mutta se on ammattilaisjuttu.

Kysymykset jotka pitää ratkaista:

• Mitä jos Nordpool-hinta ei päivity?
• Mitä jos ulkolämpötila-anturi antaa virhettä?
• Mitä jos Shelly ei vastaa?
• Mitä jos HA boottaa kesken ohjauksen?

Periaate:

• Kaikki tärkeät ohjaukset tarvitsevat “fallbackin”.

Käytännössä se tarkoittaa:

• jos hinta puuttuu → käytä viimeistä tunnettua hintaa tai siirry “perusjaksoon”
• jos lämpötila puuttuu → käytä varovaisempaa lämmitysjaksotusta
• jos mittaus puuttuu → estä aggressiiviset toiminnot (EV-lataus, boost)
• jos HA on alhaalla → laitteet palaavat oletustilaan (lämmitys päälle, optimointi pois)

Tämä on iso osa sitä, miksi oma ohjaus kannattaa tehdä kunnolla.

Miksi tästä syntyy kehikko (HEOMF)

Kun rakennat ohjauksen näin, huomaat nopeasti, että kaikki eivät ole samalla “tasolla”.

Joku on tasolla:

• “katson hinnat ja laitan ajastuksen”

Toinen on tasolla:

• “minulla on sulakevahti ja dynaaminen lämmitys”

Kolmas on tasolla:

• “minulla on ennusteet, PV-integraatio ja monimuuttujainen optimointi”

Tässä vaiheessa alkoi käytännössä syntyä ajatus kypsyysmallista:

• ei yhtä oikeaa tapaa
• vaan tasoja ja valmiuksia

Ja juuri tähän blogisarja myöhemmin linkittyy.

OSA 4 Yhteenveto

OSA 4:n ydinsanoma on tämä:

Kun kotitalous alkaa optimoida sähköä, se muuttuu järjestelmäksi.
Ja järjestelmää ei voi ohjata yhdellä säännöllä.

Home Assistant ei ollut vain “älykoti-alusta”.
Siitä tuli energianhallinnan alusta.

Kun ohjaus rakennetaan kerroksittain:

• turva
• rajoitteet
• optimointi

… siitä tulee hallittava, laajennettava ja luotettava.