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ä eikä uusia ominaisuuksia enää uskaltanut lisätä huoletta — ensimmäinen ajatus oli siivota Home Assistant.
Ajatus vaikutti loogiselta. Automaatioita voisi järjestellä paketteihin, nimeämiskäytäntöjä yhtenäistää ja YAML:ia selkeyttää. Kaikki tuntui korjattavissa olevalta, kunhan kokonaisuuden vain kävisi kunnolla läpi.
Kävin läpi.
Mitä enemmän kokonaisuutta tutkin, sitä selvemmäksi yksi asia tuli: ongelma ei ollut YAML.
Ongelma oli siinä, mihin päätöksenteko oli kertynyt
Home Assistantiin oli vuosien varrella kertynyt paljon muutakin kuin integraatioita ja käyttöliittymää. Samassa kokonaisuudessa ratkaistiin esimerkiksi:
- milloin auto lataa
- mitä kuormaa priorisoidaan
- milloin aurinkoylijäämä menee hinnan edelle
- milloin tehoraja ohittaa muut tavoitteet
Nämä ovat järjestelmätason päätöksiä. Ongelma ei ollut se, etteikö Home Assistantilla voisi toteuttaa logiikkaa, vaan se, että päätökset olivat hajallaan eri automaatioissa ilman yhtä yhteistä priorisointimallia.
Kun yksi automaatio päätti käynnistää latauksen, toinen saattoi samaan aikaan yrittää rajoittaa sitä. Molemmat saattoivat olla yksittäin järkeviä, mutta kumpikaan ei omistanut kokonaisuutta.
Tässä projektissa päätin siksi erottaa Home Assistantin roolin järjestelmätason optimoinnista. Home Assistant jäi integraatioiden, tilan seurannan ja käyttöliittymän keskeiseksi alustaksi, mutta koko talon priorisointia ei enää rakennettaisi hajalleen sen erillisiin automaatioihin.
Pelkkä vanhan rakenteen siistiminen olisi tehnyt samasta vastuunjaosta siistimmän näköisen. Se ei olisi ratkaissut itse ongelmaa.
Tärkein yksittäinen päätös
Tärkein arkkitehtuuripäätös koko projektissa oli tämä:
Tässä EnergyHubissa Home Assistant ei enää omista järjestelmätason optimointia.
Se kerää ja välittää tietoa, hallitsee integraatioita, tarjoaa käyttöliittymän ja toimii osana ohjauspolkua. Päätökset siitä, milloin kuormia kannattaa käyttää, mitä priorisoidaan ja miten ristiriitaiset tavoitteet sovitetaan yhteen, keskitetään omaan päätöksentekologiikkaansa.
Tämä yksi päätös selkeytti paljon muuta. Kun vastuut ovat näkyviä, on helpompi päättää, kuuluuko uusi toiminto laiteintegraatioon, automaatioon, optimointiin vai fyysisen ohjauksen sallittavuuteen.
HEOMF:n optimoinnin arkkitehtuurissa sama periaate näkyy loogisten vastuiden erottamisena: integraatio, automaatio, optimointi ja fyysinen toteutus eivät ole sama tehtävä, vaikka osa niistä pyörisi samalla teknisellä alustalla.
Miltä työnjako näytti ennen ensimmäistä koodiriviä?
Projektin toteutusta varten jaoin vastuut neljään käytännön kokonaisuuteen. Tämä oli toteutustapa, ei vaatimus siitä, että jokaisen vastuun pitäisi aina olla oma erillinen ohjelmistonsa tai fyysinen laitteensa.
Kenttä- ja laitetaso
Täällä ovat fyysiset laitteet ja niiden suorat rajapinnat: Shelly-releet, lämpöpumpun ja invertterin Modbus-yhteydet, energiamittaukset ja laitteiden omat säätimet.
Tärkeä tavoite oli, etteivät laitteiden omat turvalliset käyttörajat riippuisi siitä, että ylemmän tason optimointi toimii juuri sillä hetkellä. Se ei tarkoita, että koko kenttätaso olisi täysin itsenäinen kaikissa häiriöissä, vaan että vian vaikutus pyritään rajaamaan mahdollisimman lähelle sitä toimintoa, jota se koskee.
Integraatio ja tilannekuva
Home Assistantin tehtäväksi jäi laiteintegraatioiden kokoaminen, mittausten ja tilojen tarjoaminen muulle järjestelmälle sekä käyttöliittymä.
Ajatus ei ollut tehdä HA:sta passiivista putkea. Se voi sisältää myös automaatiota ja paikallista tilalogiikkaa. Rajaus koski ennen kaikkea sitä, ettei koko talon optimointipäätöksiä enää hajautettaisi ympäri järjestelmää.
Päätöksenteko ja orkestrointi
Node-RED valittiin tässä projektissa paikaksi, johon järjestelmätason päätöksentekoa alettiin keskittää. Sen tehtäväksi suunniteltiin hinnan, aurinkotuotannon, tehon, lämpötilojen ja käyttäjän tavoitteiden yhdistäminen yhteiseen päätöspolkuun.
Tässä kerroksessa ratkaistaan esimerkiksi, milloin autoa kannattaa ladata, milloin lämpöpumpulle annetaan poikkeava tavoite ja mikä kuorma väistää, jos kaikkia tavoitteita ei voida toteuttaa samaan aikaan.
Observointi ja historiatieto
Aikasarjatietokannan ja visualisoinnin tehtäväksi suunniteltiin muutakin kuin energiankulutuksen näyttäminen. Järjestelmästä piti myöhemmin pystyä tarkistamaan myös päätöksiä ja niiden seurauksia.
Tätä ei kannata ajatella täysin erillisenä ohjauskerroksena, vaan toimintona, joka kulkee muiden vastuiden rinnalla. Ilman historiatietoa ja diagnostiikkaa hiljainen vika voi näyttää pitkään normaalilta toiminnalta.
MQTT rajapinnaksi kerrosten väliin
Yksi keskeisistä suunnittelupäätöksistä oli käyttää MQTT:tä sovituissa kohdissa järjestelmän sisäisenä viestiväylänä. Tarkoitus oli vähentää suoria riippuvuuksia niin, ettei päätöksentekologiikan tarvitse tuntea jokaisen laitteen omaa rajapintaa.
Suunnitelman mukaisia aiheita olivat esimerkiksi:
energyhub/system/safety_trip
energyhub/command/ev/allowedMQTT ei itsessään takaa, että vastaanottajan ollessa poissa jokainen viesti automaattisesti odottaa ja toimitetaan myöhemmin. Se riippuu muun muassa QoS-tasosta, retained-viesteistä, sessiosta ja sovelluksen omasta suunnittelusta.
Arkkitehtuuripäätös oli siksi laajempi kuin “käytetään MQTT:tä”: viestien merkitys, säilyvyys, vanheneminen ja vastaanottajan käyttäytyminen piti määritellä erikseen.
Tavoite oli, että yhden komponentin vaihto tai uudelleenkäynnistys ei pakota kirjoittamaan koko järjestelmän logiikkaa uudelleen.
Miksi juuri Node-RED?
Kysymys ei ollut siitä, etteikö Home Assistantin automaatioilla voisi rakentaa monimutkaistakin päätöksentekoa. Tässä projektissa Node-RED sopi kuitenkin paremmin siihen tapaan, jolla halusin nähdä ja testata päätöspolun.
Energiaoptimointi ei ollut enää vain yksittäinen “jos X, tee Y” -reaktio. Päätöksessä saatettiin joutua huomioimaan yhtä aikaa esimerkiksi hinta, aurinkotuotanto, kokonaisteho, lämpötila ja käyttäjän asettama tavoite.
Node-REDissä tällaisen päätösketjun pystyi rakentamaan näkyväksi flow’ksi, jossa lähtötiedot, ehdot, prioriteetit ja lopputulos voitiin erottaa toisistaan.
Toinen syy oli vikatilanteiden eksplisiittinen käsittely. Puuttuva hintatieto, vanhentunut mittaus tai vastaamaton laite piti saada omaksi tunnetuksi tilakseen sen sijaan, että automaatio vain jäisi hiljaa tekemättä.
Tämä oli siis EnergyHubin toteutusvalinta, ei yleinen väite siitä, että Node-RED olisi optimointiin aina Home Assistantia parempi.
Miksi kriittinen päätöspolku haluttiin paikalliseksi?
Kolmas keskeinen päätös oli sijoittaa EnergyHubin varsinainen päätöksenteko paikalliselle Lenovo ThinkCentre -koneelle Debianin ja Docker Composen päälle.
Tavoitteena ei ollut poistaa pilveä järjestelmästä. Hintatiedot, sääennusteet ja osa laitekohtaisesta datasta tulevat joka tapauksessa ulkoisista palveluista.
Sen sijaan halusin, ettei talon sisäinen päätöspolku olisi tarpeettomasti riippuvainen jatkuvasta internet-yhteydestä. Paikalliset mittaukset, laiteintegraatiot ja keskeinen ohjaus pystyvät toimimaan paikallisessa verkossa, vaikka uusi ulkoinen tieto olisi hetken poissa.
Tämä ei vielä tee järjestelmästä automaattisesti vikasietoista. Myös Lenovo, paikallinen verkko tai oma ohjelmisto voivat vikaantua. Siksi myöhempi työ joutui käsittelemään erikseen fallbackit, watchdogit, datan tuoreuden ja fyysisen toteuman verifioinnin.
Mitä päätettiin jo tässä vaiheessa jättää ratkaisematta?
Arkkitehtuuripäätöksiä tehdessä oli tärkeää erottaa rakenne varsinaisesta optimointilogiikasta.
Kerrosmalli ei vielä kerro, mikä on oikea sähköauton latausraja, kuinka paljon lämmitystä kannattaa siirtää tai mikä ennustemalli toimii parhaiten. Se ei myöskään tee järjestelmästä luotettavaa vain siksi, että komponentit on nimetty eri kerroksiin.
Arkkitehtuurin tehtävä oli tehdä nämä myöhemmät ongelmat ratkaistaviksi yksi kerrallaan:
- päätöslogiikka voidaan muuttaa ilman että laiteintegraatio kirjoitetaan uudelleen
- uusi mittaus voidaan lisätä yhteiseen tilannekuvaan ilman että jokainen ohjaus lukee sitä suoraan
- vikatilanteen paikka voidaan rajata paremmin
- uuden ominaisuuden vastuu voidaan määrittää ennen toteutusta
Juuri tätä varten arkkitehtuuri tehtiin ennen koodia.
Yksi päätös vaikutti kaikkeen myöhempään
Jälkikäteen katsottuna tärkein ratkaisu ei ollut Node-RED, MQTT, Debian eikä Lenovo. Ne olivat toteutusteknologioita.
Tärkein ratkaisu oli päättää, ettei koko järjestelmä enää kasva yhden työkalun sisällä sen mukaan, mihin uusi automaatio sattuu helpoimmin syntymään.
Päätöksenteko, integraatio, fyysinen toteutus ja havaittavuus saivat omat vastuunsa.
Myöhemmät osat näyttävät, että rajat eivät pysyneet käytännössä aivan näin yksinkertaisina. Se oli odotettavissa. Olennaisempaa oli, että järjestelmällä oli ensimmäistä kertaa rakenne, jonka sisällä näitä rajoja voitiin tarkentaa ilman että palattiin vanhaan hajautettuun automaatiomalliin.
Seuraavaksi: Home Assistant integraatiokerroksena
Osa 3: Home Assistant integraatiokerroksena käsittelee sitä, miten entiteettimalli rakennettiin, mitä integraatioita tarvittiin ja miten rajapinta päätöksentekokerrokseen toteutettiin käytännössä.
Tekninen perusalusta on kuvattu erillisessä Debian + Docker + Home Assistant + Node-RED -ohjeessa.
HEOMF Case: Oma talo -sarjan pääsivulta löydät kaikki sarjan osat.