Arkkitehtuuripäätökset: mitä päätettiin ennen koodia

Ensimmäinen reaktio ongelmaan oli väärä.

Kun Osa 0:ssa kuvattu tilanne alkoi olla selvä — järjestelmä oli kasvanut hallitsemattomaksi, ohjausvastuu oli epäselvä, uusia ominaisuuksia ei uskaltanut lisätä — ensimmäinen ajatus oli: siivotan Home Assistantin.

Ajatus vaikutti loogiselta. Automaatioita voisi järjestellä paketteihin. Nimeämiskäytäntöjä voisi yhtenäistää. YAML:ia voisi selkeyttää. Kaikki tuntui korjattavissa olevalta — kunhan vain käy läpi kunnolla.

Kävin läpi.

Mitä enemmän kokonaisuutta tutki, sitä selvemmäksi yksi asia tuli: ongelma ei ollut YAML.

Ongelma oli siinä, mihin päätöksenteko oli kertynyt

Home Assistant oli vuosien varrella ottanut vastuulleen asioita joita sille ei ollut alun perin suunniteltu. Se ei enää vain välittänyt tietoa ja ohjannut laitteita. Se yritti samalla ratkaista:

• milloin auto lataa
• mitä priorisoidaan
• milloin aurinko voittaa hinnan
• milloin teho voittaa kaiken muun

Nämä ovat optimointikysymyksiä. Ja ne oli ratkaistu hajallaan — eri automaatioissa, eri logiikalla, ilman yhteistä priorisointimallia. Kun yksi automaatio teki päätöksen latauksen käynnistämisestä, toinen saattoi samanaikaisesti tehdä päätöksen sen rajoittamisesta. Kumpikaan ei tiennyt toisesta.

Tämä ei ole Home Assistantin vika. Se on erinomainen työkalu integraatioon, tilan seurantaan ja käyttöliittymään. Mutta se ei ole suunniteltu olemaan optimointimoottori — eikä sen pitäisi olla.

Siivous olisi järjestellyt olemassa olevan sekamelskan siistimmin. Se ei olisi ratkaissut ongelmaa.

Tärkein yksittäinen päätös

Tärkein arkkitehtuuripäätös koko projektissa oli tämä:

Home Assistant ei enää omista optimointia.

Se toimii integraatiokerroksena. Se kerää datan, hallitsee integraatiot, tarjoaa käyttöliittymän ja välittää ohjauskomennot laitteille. Mutta päätökset — milloin, mitä, missä järjestyksessä — tehdään muualla.

Tämä yksi päätös selkeytti kaiken muun. Kun rooli on selkeä, on myös selvää mitä HA:han kuuluu ja mitä ei. Uusi automaatio ei enää tarkoita lisää päätöksentekoa HA:han — se tarkoittaa uutta integraatiota tai uutta ohjauskomentoa rajapinnalle.

HEOMF-arkkitehtuurissa tämä vastaa kerrosten erottamista: automaatiokerros ja optimointikerros ovat eri asioita, ja niiden sekoittaminen on yksi yleisimmistä syistä sille että järjestelmät kasvavat hallitsemattomiksi.

Kerrosmalli käytännössä

Uusi järjestelmä rakentuu neljään kerrokseen, joilla kullakin on yksi selkeä vastuu.

Kenttäkerros on laitteet ja niiden suora ohjaus — Shelly-releet, Modbus-yhteydet lämpöpumppuun ja invertteriin, virta-anturit. Tämä kerros toimii itsenäisesti. Jos kaikki muu hajoaa, kenttäkerros pitää laitteet turvallisessa tilassa.

Integraatiokerros on Home Assistant. Se lukee datan kenttäkerrokselta, pitää yllä järjestelmän tilaa, tarjoaa käyttöliittymän ja välittää ohjauskomennot. Se ei päätä — se välittää.

Optimointikerros on Node-RED. Se lukee hintatiedon, aurinkosähkön tuotannon ja tehon, tekee priorisointipäätökset ja lähettää ohjauskomennot integraatiokerrokselle. Tässä kerroksessa asuu varsinainen logiikka: milloin auto lataa, milloin lämpöpumppu boostataan, milloin kuorma pudotetaan.

Havaintokerros on aikasarjatietokanta ja visualisointi. Se tallentaa kaiken — ei vain kulutuksen vaan myös päätökset ja niiden tulokset. Ilman tätä ei voi tietää toimiiko optimointi oikein, eikä hiljaisia vikoja huomata ennen kuin ne ovat kasvaneet ongelmiksi.

Kerrosten välinen kommunikaatio kulkee MQTT:n kautta. Jokainen kerros julkaisee tilansa ja kuuntelee komentoja — se ei puhu suoraan toiselle kerrokselle. Käytännössä tämä näyttää esimerkiksi tältä:

energyhub/system/safety_trip

energyhub/command/ev/allowe

Optimointikerros ei sammuta latausta suoraan. Se julkaisee päätöksen, jonka integraatiokerros välittää oikealle laitteelle. Jos integraatiokerros on hetkellisesti alhaalla, viesti odottaa — laite ei saa ristiriitaista komentoa.

Tämä tarkoittaa, että yhden kerroksen voi vaihtaa tai päivittää ilman että muut hajoavat.

Koko arkkitehtuurin taustalla on yksi suunnitteluperiaate: järjestelmän pitää toimia ilman päivittäistä seurantaa tai säätöä. Tämä asettaa vaatimukset vikasietoisuudelle, fallback-logiikalle ja havaintokerrokselle — ne eivät ole lisäominaisuuksia vaan arkkitehtuurin ydin.

Miksi Node-RED eikä HA-automaatiot

Kysymys tulee aina: miksi Node-RED, eikö HA riitä?

Home Assistantin automaatiot ovat erinomaisia reaktiiviseen ohjaukseen — ”jos X tapahtuu, tee Y”. Mutta energiaoptimointi on harvoin näin yksinkertaista. Se on useimmiten: ”ota huomioon hinta, aurinkotuotanto, talon lämpötila, sulakkeiden tila ja käyttäjän toiveet — ja päätä sen perusteella mitä tehdään seuraavat neljä tuntia.”

Tämä on priorisointiongelma, ei reaktio-ongelma. Node-RED:ssä se on luonteva rakentaa visuaalisena flow’na jossa data kulkee solmujen läpi, ehdot tarkistetaan järjestyksessä ja lopputulos on yksi selkeä ohjauskomento. Logiikka on näkyvissä, testattavissa ja muutettavissa ilman että koskee muuhun järjestelmään.

Toinen syy on vikasietoisuus. Node-RED-flow voi eksplisiittisesti käsitellä tilanteet joissa data puuttuu, hintatieto ei päivity tai jokin laite ei vastaa. HA-automaatiossa nämä tilanteet jäävät helposti käsittelemättä — automaatio yksinkertaisesti ei laukea, eikä kukaan huomaa.

Miksi paikallinen eikä pilvi

Kolmas keskeinen päätös oli paikallisuus. Kaikki kriittinen logiikka pyörii paikallisella laitteistolla — Lenovo ThinkCentre mini-PC, Debian, Docker Compose. Ei pilvipalveluja optimointipolulla.

Syy on yksinkertainen: sähköjärjestelmän pitää toimia kun internet ei toimi. Jos optimointilogiikka on pilvipalvelussa ja yhteys katkeaa, mitä tapahtuu? Parhaassa tapauksessa laitteet jäävät viimeiseen tilaansa. Pahimmassa tapauksessa jokin automaatio tekee päätöksen vanhentuneella datalla.

Paikallinen järjestelmä toimii autonomisesti. Hintatiedot haetaan kerran päivässä ja tallennetaan paikallisesti. Reaaliaikaiset mittaukset — teho, aurinkotuotanto, vaihevirrat — kulkevat paikallisessa verkossa ilman internet-riippuvuutta.

Tämä on HEOMF-white paperissa kuvattu keskeinen periaate: ohjauksen luotettavuus ei saa riippua pilvipalvelun saatavuudesta.

Mitä nämä päätökset eivät ratkaise

On tärkeää sanoa myös mitä arkkitehtuuripäätökset eivät tee.

Ne eivät automaattisesti tee järjestelmästä parempaa. Kerrosmalli on rakenne, ei ratkaisu. Jos optimointilogiikka on huono, se on huono siistissäkin rakenteessa. Jos prioriteetit ovat väärät, ne ovat väärät Node-RED:ssäkin.

Arkkitehtuuri tekee yhden asian: se tekee ongelmien löytämisestä ja korjaamisesta hallittavaa. Kun logiikka on yhdessä paikassa ja vastuunjako on selkeä, virhe löytyy nopeasti. Ja kun uusi ominaisuus lisätään, tiedetään mihin se kuuluu.

Se on tarpeeksi hyvä syy rakentaa oikein.

Seuraavaksi: Osa 3 — Home Assistant integraatiokerroksena. Miten entiteettimalli rakennettiin, mitä integraatioita tarvitaan ja miten rajapinta optimointikerrokseen toimii käytännössä.

Tekninen toteutus: Debian + Docker + HA + Node-RED -asennus on kuvattu erillisessä ohjeartikkelissa.