Kotitalouden energianhallinta rakentuu usein automaatioalustan ympärille. Home Assistantiin liitetään mittareita ja laitteita, Node-REDiin syntyy ohjauslogiikkaa ja vähitellen järjestelmä tekee yhä enemmän päätöksiä ilman käyttäjän jatkuvaa osallistumista.
Tämä on luonteva kehityspolku. Ongelmia syntyy vasta silloin, kun samaan automaatiokerrokseen alkaa huomaamatta kertyä kaikki: integraatiot, käyttöliittymä, laitekohtaiset yksityiskohdat, turvallisuusrajat, käyttäjän ohitukset ja koko talon optimointipäätökset.
Siksi automaation tärkein arkkitehtoninen tehtävä ei ole olla koko järjestelmän “aivot”. Sen tehtävä on yhdistää eri osat toisiinsa ja toteuttaa niiden välinen hallittu työnkulku.
Mitä automaatiokerros oikeastaan tekee?
Edellisessä osassa kenttäkerros määriteltiin fyysisen ohjauksen ja laitekohtaisten rajojen tasoksi. Automaatiokerros sijaitsee sen yläpuolella ja yhdistää fyysiset laitteet järjestelmätason toimintaan.
Sen tehtäviä voivat olla esimerkiksi:
- eri laitteiden ja protokollien yhdistäminen
- mittausten normalisointi yhteiseen muotoon
- tilatiedon välittäminen ylemmälle päätöksenteolle
- ohjauspyyntöjen välittäminen kenttäkerrokselle
- yksinkertaisten determinististen sääntöjen ja tilakoneiden toteuttaminen
- käyttötilojen, käsiohjausten ja käyttöliittymän tilan hallinta
- tapahtumien, virheiden ja palautetiedon välittäminen observointiin
Automaatio siis myös tekee päätöksiä. Oleellista on minkä tasoisia päätöksiä se tekee ja mitä vastuuta sille annetaan.
Paikallinen sääntö ja järjestelmätason optimointi ovat eri asioita
Kaikkea päätöksentekoa ei ole järkevää siirtää erilliseen optimointipalveluun. Esimerkiksi “jos kriittinen mittaus on vanhentunut, estä uusi suuri kuorma” on luonteva deterministinen automaatiosääntö. Samoin käyttötilan vaihto, aikakatkaisu tai manuaaliohjauksen automaattinen päättyminen voivat hyvin kuulua automaatiokerrokseen.
Sen sijaan kysymys siitä, mille huomisen varteille lämmitys, sähköauton lataus ja käyttövesi kannattaa yhdessä sijoittaa suhteessa hintaan, sääennusteeseen, aurinkotuotantoon ja mukavuusrajoihin, on järjestelmätason optimointiongelma.
Hyvä nyrkkisääntö on:
Automaatio toteuttaa selkeitä ja ennustettavia toimintaperiaatteita. Optimointi ratkaisee usean tavoitteen ja vaihtoehdon välisiä kompromisseja.
Home Assistant voi olla paljonkin – kun vastuut ovat selvät
Kerrosarkkitehtuuria ei pidä tulkita niin, että Home Assistant pitäisi rajata pelkäksi käyttöliittymäksi. Sama alusta voi toimia integraatio-, automaatio- ja käyttöliittymäkerroksena, ja pienessä järjestelmässä se voi sisältää myös osan optimoinnista.
Arkkitehtuurin ongelma syntyy vasta, jos vastuut kietoutuvat niin tiukasti yhteen, ettei enää tiedetä, missä päätös syntyy, mikä sääntö voi kumota sen tai mikä komponentti viime kädessä ohjaa fyysistä laitetta.
Siksi teknistä jakoa tärkeämpi on looginen jako:
| Kysymys | Luonteva vastuu |
|---|---|
| Mikä laite on kyseessä ja mikä on sen tila? | Integraatio / automaatio |
| Onko mittaus käyttökelpoinen? | Automaatio / tilannekuva |
| Mitä käyttäjä on juuri pyytänyt? | Käyttötila / automaatio |
| Mikä vaihtoehto on kokonaisuuden kannalta paras? | Optimointi |
| Saako fyysinen komento toteutua? | Kenttä- ja laitetason rajat |
Käyttötilat tekevät järjestelmästä hallittavan
Pelkkä automaatioiden joukko ei vielä muodosta ymmärrettävää järjestelmää. Käyttäjän ja muun logiikan pitää tietää, missä toimintatilassa järjestelmä on.
Käyttötilat ovat tähän hyödyllinen tapa. Ne eivät ole vain käyttöliittymän nappeja, vaan eksplisiittisiä tiloja, joilla on määritelty merkitys.
Normal / Auto
Järjestelmä toimii normaalin optimoinnin ja automaatioiden mukaisesti. Käyttäjän aiemmat tilapäiset ohitukset eivät ole enää voimassa.
Manual / Override
Käyttäjä pyytää tietyn toiminnon tilapäisesti normaalin optimoinnin edelle. Hyvä ohitus on rajattu sekä sisällöltään että kestoltaan: esimerkiksi “lataa auto nyt neljä tuntia” on selkeämpi kuin pysyvä kytkin, joka saattaa unohtua päälle.
Boost / Comfort
Tilapäinen tavoitteen muutos, jossa järjestelmälle annetaan lupa käyttää tavallista enemmän energiaa tietyn lopputuloksen saavuttamiseksi. Esimerkiksi käyttövesi voidaan lämmittää nopeammin tai lämmityksen mukavuustavoitetta nostaa.
Block / Safe fallback
Joissakin tilanteissa tietty optimointitoiminto estetään tai järjestelmä siirtyy ennalta määriteltyyn varatilaan. Tämä ei tarkoita, että “vain kriittiset kuormat jäävät päälle”, vaan että kyseisen toiminnon käyttäytyminen vikatilanteessa on määritelty etukäteen.
Käyttötilojen tarkat nimet eivät ole tärkeitä. Tärkeää on, että niiden merkitys, prioriteetti ja päättymisehto tunnetaan.
Manuaaliohjaus on osa suunniteltua järjestelmää
Täysin automaattinen energianhallinta on hyvä tavoite toistuville päätöksille, mutta käyttäjällä on aina tietoa, jota järjestelmällä ei välttämättä ole.
Auto voidaan tarvita poikkeuksellisesti aikaisemmin. Talossa voi olla tavallista enemmän vieraita. Käyttövettä halutaan juuri nyt lisää. Huoltotilanteessa automaattinen ohjaus halutaan estää.
Siksi hyvä järjestelmä tarvitsee käsiohjauksen, mutta käsiohjauksen pitää olla hallittu:
- käyttäjä näkee selvästi, että ohitus on aktiivinen
- ohituksella on ymmärrettävä vaikutus
- turvallisuus- ja fyysiset rajat ovat edelleen voimassa
- tilapäisellä ohituksella on mieluiten automaattinen päättymisehto
- paluu normaaliin automaattitilaan on yksiselitteinen
Manuaaliohjaus ei siis ole automaation epäonnistuminen. Se on osa rajapintaa ihmisen ja järjestelmän välillä.
Prioriteetit pitää ratkaista yhdessä paikassa
Kun järjestelmässä on optimointi, käsiohjaus, tehorajoitus ja erilaisia käyttötiloja, syntyy väistämättä ristiriitoja.
Esimerkiksi optimointi haluaa ladata autoa, käyttäjä on painanut “lataa nyt” -painiketta, mutta liittymän hetkellinen kuormitus on liian suuri. Mikä näistä voittaa?
Ratkaisun ei pitäisi riippua siitä, missä järjestyksessä kolme erillistä automaatiota sattuvat laukeamaan. Järjestelmällä pitää olla eksplisiittinen prioriteettimalli.
Yksi mahdollinen järjestys voisi olla:
- Fyysiset ja turvallisuuteen liittyvät rajat
- Pakottavat käyttöehdot ja määräajat
- Käyttäjän tietoinen tilapäinen ohitus
- Normaali optimointipäätös
Tarkka järjestys riippuu järjestelmästä. Oleellista on, että ristiriita ratkaistaan tietoisesti eikä automaatioiden sivuvaikutuksena.
Esimerkki: sähköauton lataus
Hyvä latausketju voidaan kuvata näin:
- Optimointi ehdottaa latausta nyt hinnan, aikarajan ja muun järjestelmän perusteella.
- Automaatiokerros yhdistää päätökseen auton saatavuuden, aktiivisen käyttötilan, käsiohjauksen ja mittausten validiteetin.
- Yhteinen sallittavuuslogiikka muodostaa lopullisen pyynnön, esimerkiksi
charge_allowed = true. - Kenttäkerros toteuttaa pyynnön vain, jos paikalliset fyysiset rajat sallivat sen.
- Takaisinmittaus vahvistaa, että lataus todella käynnistyi.
Tällöin automaatio tekee paljon muutakin kuin vain “välittää komennon”. Se yhdistää eri lähteistä tulevat tilat yhden selkeän sopimuksen ympärille. Silti varsinainen pitkän aikavälin optimointipäätös ja fyysinen turvallisuus pysyvät erillisinä vastuualueina.
Tilannekuva kuuluu automaation tärkeimpiin tehtäviin
Automaatiokerros on luonteva paikka muuttaa laitekohtainen raakadata järjestelmän ymmärtämiksi tiloiksi.
Yhdeltä laitteelta voi tulla relay=on, toiselta teho watteina ja kolmannelta valmistajakohtainen toimintatila. Ylemmän optimoinnin ei pitäisi joutua tulkitsemaan kaikkia näitä erikseen.
Automaatiokerros voi muodostaa niistä esimerkiksi yhteisiä käsitteitä:
availablerunningpower_wdata_freshmanual_override_activecontrol_allowed
Tämä vähentää riippuvuutta yksittäisten valmistajien rajapinnoista ja tekee ylemmän tason logiikasta helpommin testattavaa.
Automaatio tarvitsee näkyvyyden omaan toimintaansa
Järjestelmän pitää pystyä vastaamaan myös kysymykseen “miksi tämä tapahtui?”. Pelkkä tieto siitä, että sähköauton lataus on pois päältä, ei riitä, jos mahdollisia syitä on useita.
Hyödyllisiä tiloja voivat olla esimerkiksi:
- optimointi ei pyydä latausta
- auto ei ole käytettävissä
- käyttäjä on estänyt latauksen
- tehoraja estää käynnistyksen
- mittausdata on vanhentunut
- komento lähetettiin mutta fyysistä vastetta ei havaittu
Kun päätöspolku on näkyvä, järjestelmää voidaan sekä käyttää että korjata ilman arvailua.
Pilvipalvelu voi olla lähde, mutta ei oletettu totuus
Automaatiokerros yhdistää usein myös pilvipalveluita. Niitä ei tarvitse vältellä, mutta niiden tila pitää käsitellä samalla tavalla kuin muidenkin tietolähteiden: arvo voi puuttua, vanhentua tai olla hetkellisesti ristiriidassa muun mittauksen kanssa.
Jos pilvestä saatava tieto katoaa, automaatiokerroksen tehtävä on välittää tämä tila eteenpäin eikä teeskennellä viimeistä tunnettua arvoa tuoreeksi. Ylemmän päätöksenteon tai paikallisen fallback-logiikan tehtävä on sen jälkeen päättää, mitä puuttuva tieto tarkoittaa kyseiselle toiminnolle.
“Yhdistäjä, ei aivot” on vastuunjakoa, ei tekninen kielto
Otsikon tarkoitus ei ole väittää, että automaatioalustan pitäisi olla tyhmä tai ettei siellä saisi olla logiikkaa. Päinvastoin: hyvä integraatio- ja automaatiokerros voi sisältää paljon tarkkaa, determinististä älykkyyttä.
Raja kulkee siinä, mitä tapahtuu kun järjestelmä kasvaa. Jos päivän hinnan ennuste, lämpömalli, auton aikaraja, käyttäjän ohitus, releen Modbus-osoite ja pääsulakkeen suojalogiikka päätyvät samaan automaatioon, vastuut ovat sekoittuneet.
Hyvä automaatio tekee eri järjestelmistä yhden hallittavan kokonaisuuden. Se ei yritä ratkaista kaikkia ongelmia samassa paikassa.
Seuraavaksi: missä optimointipäätös syntyy?
Kun mittaukset, laiteintegraatiot, käyttötilat ja fyysinen ohjaus on erotettu toisistaan, voidaan käsitellä varsinaista optimointikerrosta: mitä kokonaisuutta optimoidaan, millä aikajänteellä ja miten ristiriitaiset tavoitteet sovitetaan yhteen.
Osa 7: Optimointi – missä päätökset syntyvät jatkaa tästä.
Optimoinnin arkkitehtuuri -sarjan pääsivulta löydät kaikki sarjan osat.