Home Assistant integraatiokerroksena
Tämä on kolmas osa sarjasta joka dokumentoi EnergyHub-järjestelmän rakentamisen vanhaan rintamamiestaloon. Edellisessä osassa käytiin läpi arkkitehtuuripäätökset ennen koodia — miksi järjestelmä jaettiin kerroksiin ja kenen vastuulle kukin päätös kuuluu. Tässä osassa tarkastellaan sitä, mitä Home Assistantin rooli tarkoittaa käytännössä.
Kun EnergyHub-arkkitehtuuria suunniteltiin, yksi kysymys nousi toistuvasti esiin: pitääkö Home Assistantin päättää vai vain välittää?
Vanhassa järjestelmässä HA teki molempia. Se luki arvot, vertasi kynnysarvoihin ja ohjasi laitteita — kaikki samassa automaatiossa. Tämä tuntui tehokkaalta kunnes tuli tilanne, jossa aurinko tuotti, hinta oli halpa, EV halusi latautua ja lämpöpumppu kilpaili samasta sähköstä. Kukaan ei tiennyt kenen vuoro oli päättää.
EnergyHubissa vastaus on selkeä: Home Assistant ei omista energian optimointiin liittyviä priorisointipäätöksiä.
Arkkitehtuuri yhdellä silmäyksellä
┌─────────────────────────────────────────┐
│ Kenttäkerros │
│ Sungrow (Modbus) · Thermia (Modbus) │
│ Shelly-releet · P1-mittari │
└────────────────────┬────────────────────┘
│ lukee / ohjaa
┌────────────────────▼────────────────────┐
│ Home Assistant — integraatiokerros │
│ Normalisoi · Julkaisee · Välittää │
│ Ylläpitää tilaa · Fallback-logiikka │
└──────────┬──────────────────┬───────────┘
│ MQTT telemetria │ MQTT komennot
▼ ▲
┌─────────────────────────────────────────┐
│ Node-RED — optimointikerros │
│ Päättää · Priorisoi · Ohjaa │
└─────────────────────────────────────────┘HA on väylä, ei aivot. Node-RED on aivot, ei kädet.
Mitä integraatiokerros tarkoittaa
HA:n tehtävä on kolmiosainen. Se lukee laitteiden tilat Modbusin ja muiden integraatioiden kautta, normalisoi ne yhdenmukaisiksi mittauksiksi ja julkaisee ne MQTT:n kautta ylöspäin päätöksentekijälle — Node-RED:lle. Toiseen suuntaan se vastaanottaa Node-REDiltä komennot MQTT:n kautta ja välittää ne laitteille.
HA myös ylläpitää järjestelmän tilaa ja sisältää turvalogiikan — jos Node-RED ei vastaa, HA pitää laitteet viimeisessä tunnetussa turvallisessa tilassa. Nämä ovat paikallisia, reaktiivisia toimia — ei optimointipäätöksiä.
Miksi tämä jako kannattaa
Yksinkertaisin syy on debuggaus. Kun jotain menee väärin — ja se menee — on arvokasta tietää missä kerroksessa ongelma on. Jos HA raportoi oikean arvon mutta laite ei reagoi, vika on kenttäkerroksessa. Jos HA raportoi oikein mutta Node-RED tekee väärän päätöksen, vika on logiikassa. Jos HA raportoi väärin, vika on integraatiossa.
Ilman tätä jakoa kaikki sekoittuu.
Toinen syy on testattavuus. Node-RED:n päätöslogiikkaa voidaan simuloida lähettämällä MQTT-viestejä suoraan — HA:ta ei tarvita testiin lainkaan. Samoin HA:n Modbus-lukuja voidaan tarkistaa ilman että Node-RED on edes käynnissä.
Kolmas syy on fallback. Jos Node-RED kaatuu, HA jatkaa mittaamista. Se ei ohjaa mitään, mutta se ei myöskään tee vääriä päätöksiä. Laitteet jäävät viimeiseen tunnettuun tilaan. Tämä on parempi kuin tilanne jossa koko järjestelmä menee sekaisin yhden komponentin kaatuessa.
Kanoniset mittaukset
Yksi konkreettinen ratkaisu joka nousi arkkitehtuuripäätöksistä on kanoninen mittauskerros. Kaikki HA:ssa lasketut sensorit alkavat etuliitteellä m_ — ”measurement”. Ne ovat template-sensoreita jotka normalisoivat raakadatan yhtenäiseen muotoon.
Tässä on keskeinen ero: raakadata ei ole sama asia kuin luotettava järjestelmätason mittaus. P1-mittarin raakaarvo voi olla positiivinen tai negatiivinen riippuen integraatiosta. Nordpool-integraation yksikkö voi olla senttiä tai euroa. Modbus-rekisteri voi palauttaa unknown jos yhteys katkeaa.
Kanoninen kerros ratkaisee tämän abstrahoinnilla. sensor.m_grid_power_w kertoo verkkotehon watteina — positiivinen tarkoittaa ostoa, negatiivinen myyntiä. sensor.m_spot_price_eur_kwh kertoo hinnan aina euroissa per kilowattitunti. Kaikki muu järjestelmä käyttää näitä arvoja, ei raakadataa.
Jos Nordpool-integraation yksikkö vaihtuu tai P1-mittarin API muuttuu, korjaus tehdään yhteen paikkaan. Node-RED ei tiedä eikä sen tarvitse tietää mistä luku tulee. Tämä vähentää riippuvuuksia ja tekee järjestelmästä huomattavasti helpommin ylläpidettävän.
Capability-flagit
Toinen keskeinen rakenne on capability-flagit — boolean-arvot jotka kertovat mitä järjestelmä tällä hetkellä sallii.
c_ev_charge_allowed kertoo saako EV ladata. c_hp_boost_allowed kertoo saako lämpöpumppu boostata. c_pv_curtail_allowed kertoo saako aurinkoinvertterin tehoa rajoittaa.
Tässä on tärkeä arkkitehtuurinen ero: capability ei ole komento. Capability kertoo käyttöoikeuden, ei päätöstä. Node-RED päättää haluaako se ladata autoa, mutta se kysyy ensin onko se sallittua. Jos c_ev_charge_allowed on false, Node-RED ei edes harkitse latausta riippumatta siitä kuinka halpaa sähkö on.
Useimmat kotiautomaatiojärjestelmät rakentavat logiikan muotoon ”jos hinta < X, lataa auto”. EnergyHubissa rakenne on kolmitasoinen: onko laitteen käyttö sallittua (capability) — haluaako järjestelmä käyttää sitä (päätös) — tekeekö laite sen (komento). Tämä erottelu tekee manuaalisesta ohituksesta triviaalia: käyttäjä kääntää flagin, Node-RED kunnioittaa päätöstä ilman että logiikkaan tarvitsee koskea.
Operating mode — järjestelmätason prioriteettikerros
Järjestelmällä on aina yksi aktiivinen tila. Operating mode toimii järjestelmätason prioriteettikerroksena — se määrittää koko järjestelmän käyttäytymisen prioriteetit yhdellä asetuksella.
normal on oletustila jossa hinta ja aurinko ohjaavat päätöksiä. peak_protection aktivoituu kun vaihevirta lähestyy sulakerajaa — kaikki ei-kriittinen kuorma putoaa välittömästi. vacation pitää lämmityksen minimissä. emergency sammuttaa kaiken ohjauksen ja jättää laitteet turvalliseen tilaan.
HA pitää kirjaa tilasta input_select.sys_operating_mode-entiteetissä. Node-RED voi pyytää tilamuutosta MQTT:n kautta, mutta HA kirjaa sen ja julkaisee takaisin kaikille osapuolille. Näin tila on aina yhdessä paikassa eikä hajautunut ympäri järjestelmää.
Tämä rakenne muistuttaa teollisuusautomaation toimintatilamallia — ja syystä. Kotitalouden energiajärjestelmällä on samat haasteet: eri prioriteetit eri tilanteissa, turvallisuusrajat joita ei saa ylittää, ja tarve toimia ennakoitavasti myös poikkeavissa tilanteissa.
Mitä HA ei tee
On yhtä tärkeää kertoa mitä HA ei tee kuin mitä se tekee.
HA ei laske kannattaako EV-lataus juuri nyt. Se ei vertaa spot-hintaa kynnysarvoon. Se ei päätä milloin lämpöpumppu boostataan tai milloin aurinkoinvertterin tehoa rajoitetaan. Nämä kaikki tapahtuvat Node-REDissä, jossa logiikka on eksplisiittistä JavaScript-koodia eikä piilotettuna YAML-automaatioiden ketjuun.
HA ei myöskään pidä muistia optimointipäätöksistä. Jos Node-RED käynnistyy uudelleen, se lukee HA:n julkaiseman tilan ja jatkaa siitä — historia ei ole tarpeen.
Käytännössä
EnergyHubissa HA pyörii Docker-kontissa Lenovo ThinkCentrellä. Se on asennettu ilman HAOS:ia — pelkkä HA Core kontissa. Tämä tarkoittaa täyttä kontrollia siitä mitä koneella pyörii, mutta myös sitä että lisäosat kuten Nordpool-integraatio tulevat HACS:in kautta.
Pakettipohjainen konfiguraatio pitää asiat järjestyksessä. Jokainen toiminnallinen kokonaisuus on omassa YAML-tiedostossaan:
00_core.yaml— järjestelmäparametrit ja globaalit boolean-arvot10_integrations.yaml— Modbus, Nordpool, P1-mittari20_measurements.yaml— kanoniset m_-sensorit30_load_ev.yaml— EV-latauksen tilakone31_load_heatpump.yaml— lämpöpumpun EVU/Boost-ohjaus40_optimization.yaml— MQTT-rajapinta Node-REDiin50_reporting.yaml— energiamittarit ja raportointi
Kun jotain muuttuu, tiedetään heti missä tiedostossa muutos tehdään. Tekninen toteutus löytyy ohjeesta HA:n valmistelu integraatiokerrokseksi.
Seuraavassa osassa käydään läpi kerrosmalli kokonaisuudessaan — miten HA, Node-RED ja kenttäkerros kommunikoivat keskenään ja mikä on MQTT:n rooli tässä arkkitehtuurissa. Kaikki liikkuvat osat alkavat hahmottua kokonaisuudeksi.
Piditkö artikkelista?
Seuraa blogia myös Blogit.fi:ssä, niin löydät uudet kirjoitukset helposti.
