Case: Oma talo dokumentoi yhden oikean omakotitalon EnergyHubin rakentamisen lähtötilanteesta tuotantoon, häiriöihin ja jatkuvaan kehittämiseen.
Tämä ei ole valmiiksi suunnitellun järjestelmän jälkikäteen kirjoitettu esittely. Sarja etenee samaa tahtia toteutuksen kanssa: arkkitehtuuripäätökset, ensimmäiset ohjaukset, käyttöönotossa löytyneet viat, palautustestit ja myöhemmin datan laatu sekä päätösten jäljitettävyys.
Mukana ovat myös ratkaisut, jotka osoittautuivat vääriksi tai keskeneräisiksi. Juuri niiden kautta näkyy, miten järjestelmä muuttuu yksittäisistä automaatioista hallittavaksi kokonaisuudeksi.
Projektikartta
EnergyHub rakentuu vaiheittain
Sarjaa voi lukea alusta kronologisena projektipäiväkirjana tai hypätä suoraan kiinnostavaan vaiheeseen. Kokonaisuus on kasvanut samalla kun oikean järjestelmän vaatimukset ovat paljastuneet.
Vaihe 1
Lähtötilanne ja arkkitehtuuriOsat 0–6 · miksi uusi järjestelmä rakennettiin ja miten vastuut erotettiin.Vaihe 2
Päätöksenteko ja ohjausOsat 7–13 · hinta, teho, MQTT, Node-RED, Thermia ja EV.Vaihe 3
Käyttöönotto ja kovennusOsat 14–18 · FMA, watchdogit, final gate ja todelliset viat.Vaihe 4
Käyttöliittymä ja arkiOsat 19–21 · käsiohjaus, Voimapirtti ja määräaikalataus.Vaihe 5
Data ja jäljitettävyysOsat 22–25 · datalaatu, palautus, ohjaushistoria ja taloudellinen vaikutus.Vaihe 6
Alusta ja jatkuvuusOsasta 26 eteenpäin · migraatio, UPS, ulkopuolinen valvonta ja hallittu toipuminen.Osat 0–6
Lähtötilanne ja arkkitehtuuri
Ensin puretaan vanhan toteutuksen rajat, tutkitaan vuoden mittausdata ja tehdään ne arkkitehtuuripäätökset, joiden varaan myöhempi ohjaus rakennetaan.
Miksi kaikki rakennettiin uudelleen
Vanha automaatio toimi, mutta vastuut ja riippuvuudet eivät enää kestäneet järjestelmän kasvua.
Lue osa 0 →Mitä vuosi dataa kertoo ennen optimointia
Lähtötilanne numeroina: kulutus, aurinkosähkö, omakäyttö, hinnat ja tehopiikit ennen uutta EnergyHubia.
Lue osa 1 →Arkkitehtuuripäätökset: mitä päätettiin ennen koodia
Kerrosmalli, Node-REDin rooli ja ohjausvastuut määritellään ennen ensimmäistä tuotanto-ohjausta.
Lue osa 2 →Home Assistant integraatiokerroksena
HA yhdistää kenttälaitteet ja normalisoi niiden tiedot ilman, että varsinainen optimointipäätös jää sinne.
Lue osa 3 →Kerrosmalli ja vastuunjako
Mitä kukin kerros saa tehdä ja miksi fyysinen toteutus erotetaan päätöksenteosta.
Lue osa 4 →Prioriteetit, tilakoneet ja fallback
Miten järjestelmä ratkaisee ristiriitoja ja mitä tapahtuu silloin, kun jokin syöte tai palvelu puuttuu.
Lue osa 5 →HA:n rooli ja entiteettimalli
Mittaukset, kyvykkyydet ja ohjausrajapinnat nimetään niin, ettei yksittäinen laite vuoda optimointilogiikkaan.
Lue osa 6 →Osat 7–13
Päätöksenteko ja fyysinen ohjaus
Arkkitehtuuri alkaa tehdä oikeita päätöksiä. Mukaan tulevat hinta, pääsulakkeet, aurinkoylijäämä, viestintäkerros sekä lämpöpumpun ja sähköauton todelliset ohjauspolut.
Hinta ja sulakkeet
Halpa sähkö ei riitä päätökseksi, jos samaan aikaan kokonaisteho uhkaa pääsulakkeita.
Lue osa 7 →MQTT — viestintäkerros
Yhteinen viestiväylä erottaa päätöksenteon laiteintegraatioista ja tekee tilan näkyväksi muille kerroksille.
Lue osa 8 →Hintaohjauksen flow Node-REDissä
Hintatieto muuttuu päätökseksi vasta sääntöjen, tilan ja reunaehtojen läpi kuljettuaan.
Lue osa 9 →Aurinko ja teho Node-REDissä
Aurinkoylijäämä ja talon hetkellinen teho tuodaan samaan päätöksentekoon hinnan kanssa.
Lue osa 10 →Konfliktit — kun kolme tavoitetta taistelee
Hinta, aurinko ja tehoraja eivät aina osoita samaan suuntaan. Järjestelmä tarvitsee prioriteetit.
Lue osa 11 →Thermia Modbus-ohjaus
Lämpöpumpun mittaus ja ohjaus toteutetaan niin, että valmistajan oma logiikka ja suojaukset jäävät voimaan.
Lue osa 12 →Sähköauton latauksen optimointi EnergyHubissa
EV-lataus kytketään hintaan, aurinkoon, kokonaistehoon ja turvalliseen releohjaukseen.
Lue osa 13 →Osat 14–18
Käyttöönotto, kovennus ja operointi
Kun järjestelmä alkaa oikeasti ohjata taloa, teoriassa toimiva arkkitehtuuri joutuu kosketuksiin vikatilanteiden, restartien, stale-datan ja omien turvamekanismiensa kanssa.
Ennen käyttöönottoa — ohjauslogiikan läpikäynti ja kehityskohteet
Ennen tuotantovastuuta tarkistetaan koko päätösketju ja etsitään kohdat, joissa oletukset voivat pettää.
Lue osa 14 →Kun käyttöönotto paljasti piiloviat: FMA-kovennus
Häiriötilat tehdään näkyviksi ja päätöksen sekä fyysisen toteuman erot aletaan valvoa systemaattisesti.
Lue osa 15 →Kun kukaan ei katso: vahtikoira hiljaisille vioille
Heartbeat, watchdog ja järjestelmän terveys tuovat näkyviin viat, joissa mikään ei kaadu mutta jokin lakkaa toimimasta.
Lue osa 16 →Lämpöpumppu final gate -polkuun
Ohjauspolku viedään loppuun asti niin, että päätös, komento ja fyysinen reletila voidaan todentaa myös restartin yli.
Lue osa 17 →Kaksi minuuttia päällä, kolme pois: kun oma turvamekanismi sahasi EV-relettä
Väärä readback, stale-tieto ja liian usein tehty admission-päätös muodostavat itseään ruokkivan oskillaation.
Lue osa 18 →Osat 19–21
Käyttöliittymä ja arjen ohjaus
Tekninen järjestelmä saa käyttöliittymän, mutta käyttäjälle ei anneta suoraa relevaltaa. Jokainen pyyntö kulkee saman päätös- ja turvaketjun läpi kuin automaatiokin.
Käsiohjaus: tabletti, joka ei saa ohjata mitään
Käyttäjän nappi tuottaa pyynnön, ei fyysistä komentoa. Turvakerrokset säilyvät myös käsiohjauksessa.
Lue osa 19 →Voimapirtti: kun teknisesti toimiva paneeli ei vielä ollut hyvä käyttöliittymä
Insinöörin tilanäkymä muutetaan koko perheen käyttöön sopivaksi esityskerrokseksi.
Lue osa 20 →Auto täyteen aamukuudeksi: miksi määräaikalataus ei ole ajastin
Tavoite-SOC, deadline ja varttihinnat muodostavat suunnitelman, jonka pitää myös huomioida auton todellinen latauskäyttäytyminen.
Lue osa 21 →Osat 22–25
Data, palautettavuus ja jäljitettävyys
Kun ohjaus toimii, seuraava vaatimus on pystyä todistamaan miksi päätös syntyi, mitä oikeasti tapahtui ja paljonko päätöksellä oli merkitystä.
Voiko dataan luottaa? EnergyHub alkaa rakentaa aineistoa, ei vain ohjata
Raakatelemetriasta rakennetaan aineistoa, jonka tuoreus, tila ja käyttökelpoisuus voidaan todentaa ennen mallintamista.
Lue osa 22 →Varmuuskopio ei ole varmuuskopio ennen palautustestiä
Puhdas Debian, palautuspaketti ja restart-testi osoittavat, palautuuko järjestelmä oikeasti tyhjältä koneelta.
Lue osa 23 →Yksi rivi, joka kertoo totuuden: EnergyHub rakentaa jäljitettävän ohjaushistorian
Päätös, lupa, komento ja fyysinen toteuma sidotaan samaan ajalliseen tapahtumaan jälkikäteistä auditointia varten.
Lue osa 24 →Sama kysymys, eri taso: paljonko rahaa liikkui juuri siinä vartissa
Ohjaushistoriaan liitetään taloudellinen näkökulma: mitä päätös merkitsi juuri kyseisen vartin hinnalla ja energialla.
Lue osa 25 →Osasta 26 eteenpäin
Alustan kestävyys, migraatio ja jatkuvuus
Kun ohjaus, käyttöliittymä ja datakerros ovat jo tuotannossa, huomio siirtyy alustan elinkaareen: vanhan järjestelmän hallittuun purkamiseen, sähkönsyötön varmistamiseen, ulkopuoliseen valvontaan ja hallittuun toipumiseen.
Home Assistant -migraatio ei ollut varmuuskopion palautus vaan arkeologinen tutkimus
Vanhaa HA:ta ei kloonata sokkona: tarpeelliset integraatiot siirretään, päällekkäiset ohjaukset jätetään taakse ja hyödyllinen seuranta rakennetaan uudelleen nykyisen arkkitehtuurin päälle.
Lue osa 26 →Teoriasta toteutukseen – ja jatkuvaan ylläpitoon
Case-sarjan rinnalla Ohjeet-sivu kokoaa käytännön toteutusohjeet Debianista ja Node-REDistä Modbusiin, varmuuskopiointiin, UPS:ään ja järjestelmän kovennukseen.