Ennen käyttöönottoa — ohjauslogiikan läpikäynti ja kehityskohteet

Tämä on neljästoista osa sarjasta joka dokumentoi EnergyHub-järjestelmän rakentamisen vanhaan rintamamiestaloon. Edelliset osat ovat kuvanneet arkkitehtuurin, komponentit ja integraatiot. Tässä osassa pysähdytään ennen live-käyttöönottoa: käydään läpi mitä on rakennettu, missä on tunnettuja puutteita ja mitä pitää vielä tehdä ennen kuin uusi järjestelmä ottaa täyden kontrollin.

---

Järjestelmä on pyörinyt shadow-moodissa useita viikkoja. Home Assistant ja Node-RED tekevät päätöksiä — mutta eivät toteuta niitä. Vanhat automaatiot ohjaavat laitteita edelleen. Uusi järjestelmä seuraa, laskee ja kirjaa.

Tämä on tarkoituksellinen valinta. Shadow-moodi on turvaverkko: jos päätöslogiikassa on virhe, se näkyy lokissa eikä laitteen käyttäytymisessä. Ennen live-käyttöönottoa on hyvä pysähtyä ja katsoa mitä on opittu.

Mikä toimii hyvin

Datarkerros on vakaa. Kaikki mittaukset kulkevat luotettavasti: P1-mittari, Sungrow Modbus, Thermia Modbus, Shelly-mittarit ja Nissan API. MQTT-väylä välittää tiedot Node-REDille ja InfluxDB tallentaa historian Grafana-visualisointia varten.

Safety Guardian toimii. Vaihevirtojen valvonta 10 sekunnin syklissä on osoittautunut toimivaksi. 25.5.2026 tapahtuma — L1-vaihe nousi 23,8 ampeerin, Guardian laukaisi peak_protection-moodin, EV-lataus estettiin — meni täsmälleen suunnitelman mukaan. Laukaisu 23,8 ampeerin kohdalla voi herättää kysymyksen miksi reagoitiin ennen 25 ampeerin pääsulakkeen rajaa. Vastaus on ennakointi: Safety Guardian toimii ennakkovaran varassa, ei sulakkeen nimellisrajan mukaan. 25 ampeerin gG-sulake kestää lyhyet ylitykset hyvin — tavoitteena on estää pitkäkestoinen kuormitus, ei reagoida sulakkeen palamiseen. Laukaisu tapahtui jo 23,8 ampeerin kohdalla vaikka pääsulakkeet ovat 25 ampeeria: tämä on tarkoituksellista. Safety Guardian perustuu ennakoivaan rajaan, ei sulakkeen nimellisrajan ylittymiseen. Konservatiivinen varoitusraja 22,5 ampeeria antaa aikaa reagoida ennen kuin todellinen sulakeriski syntyy.

PV-rajoituslogiikka on testattu. Sungrow-invertterin Modbus-ohjaus toimii. Dynaaminen rajoituslaskenta omakäytön perusteella on validoitu käytännössä. DC-potentiaaliaukko on dokumentoitu ja ymmärretty.

EV-telemetria on kunnossa. Kolmen tietolähteen arkkitehtuuri — Nissan API, ShellyPro3EM63, ShellyPro1 — toimii suunnitelman mukaan. Tapering-käyrä on mitattu: lataus täydellä 3,6 kW teholla SOC 97 %:iin asti, sen jälkeen ~75 minuutin laskeva vaihe.

Thermia-integraatio on validoitu. EVU/Boost-ohjaus Shelly Pro 2:n kautta toimii. Boost trigger-and-release on testattu käytännössä. Comfort wheel kirjoitetaan Modbus-rekisteriin suoraan.

Tunnettuja puutteita ja kehityskohteita

1. Ohjauslogiikan parametrit ovat hajallaan

Hintakynnykset, lämpötilatavoitteet ja muut ohjauspisteet ovat tällä hetkellä osittain Node-REDin koodissa, osittain 00_core.yaml:ssa. Ennen live-käyttöönottoa kaikki moodikohtaiset parametrit pitää koota yhteen paikkaan josta käyttäjä voi muuttaa niitä ilman koodin muokkaamista.

Tavoitetila: 00_core.yaml sisältää kaikki säädettävät parametrit selkeästi dokumentoituna. Node-RED lukee ne telemetrian kautta. Ei hardkoodattuja arvoja. Koska kaikki säädöt ovat yhdessä paikassa, virhekin vaikuttaa laajasti — parametrimuutokset versioidaan ja dokumentoidaan ennen käyttöönottoa. Koska kaikki säädöt ovat yhdessä paikassa, yksittäinen virhe vaikuttaa laajasti — siksi parametrimuutokset dokumentoidaan ja versioidaan.

2. Operating moodit eivät ole viimeisteltyjä

Normal, peak_protection ja emergency toimivat. Mutta vacation, guest, cheap_energy ja solar_maximize ovat osittain toteutettuja. Erityisesti vacation-moodi — joka tarvitsee omat lämpötilaminimit käyttövedelle ja huonelämpötilalle — on kesken.

3. EV-latauksen ajoitusoptimointi puuttuu

Nykyinen logiikka reagoi reaaliaikaiseen tilanteeseen: hintaan, aurinkoon, sulakkeeseen. Se ei osaa vastata kysymykseen ”milloin kannattaa aloittaa lataus jotta akku on täynnä klo 7:00”. Tähän tarvitaan lähtöaikaohjaus ja tapering-mallin integrointi päätöslogiikkaan.

Tämä on tiedostettu rajoite. Se ei estä live-käyttöönottoa — nykyinen kynnyslogiikka toimii — mutta se on selkeä kehityskohde.

4. Watchdog puuttuu — live-käyttöönoton ehto

Jos Node-RED kaatuu tai MQTT-yhteys katkeaa, laitteet jäävät viimeiseen ohjattuun tilaan. Tällä hetkellä ei ole mekanismia joka havaitsisi tämän ja palautuisi turvalliseen tilaan automaattisesti. Watchdog on suunniteltu mutta ei toteutettu.

Tämä on lähes ehdoton vaatimus ennen EV- ja HP-ohjauksen live-käyttöönottoa. Ilman watchdogia järjestelmähäiriö voi jättää lämpöpumpun EVU-tilaan tai EV-latauksen estetyksi ilman että kukaan huomaa. Watchdog toteutetaan ennen vaihetta 2.

5. Sääennusteet ja lämpöinertia eivät ole mukana

Optimointi perustuu tämän hetken dataan. Huomisen kylmyys ei vaikuta tämän päivän lämmityspäätöksiin. Talon lämpömassa — kuinka kauan se pysyy lämpimänä ilman lämmitystä — ei ole mallinnettu. Nämä ovat seuraavan kehitysvaiheen aiheita.

Shadow-moodin havainnot

Muutaman viikon shadow-moodi on tuottanut ensimmäisiä vertailuhavaintoja.

Hintaohjauksen ero: Uusi järjestelmä olisi useammin estänyt lämpöpumpun kalliina tunteina. Vanha järjestelmä reagoi hintaan hitaammin koska sillä ei ole yhtä tarkkaa hintadataa käytössä reaaliajassa.

EV-latauksen ero: Uusi järjestelmä ottaa sulaketilanteen huomioon ennen latauksen sallimista. Vanhassa järjestelmässä EV-lataus on yksinkertaisempi ON/OFF-päätös ilman vaihevirtatietoisuutta.

PV-rajoitus: Vanha järjestelmä rajoittaa invertteria negatiivisilla hinnoilla kiinteällä prosentilla. Uusi laskee rajoituksen dynaamisesti omakäytön perusteella — tulos on useimmiten erilainen.

Nämä erot ovat pieniä yksittäisinä päivinä. Kumulatiivinen vaikutus näkyy vasta kuukausien datasta.

Live-käyttöönoton suunnitelma

Live-käyttöönotto tehdään vaiheittain, ei yhdellä kertaa.

Vaihe 1: PV-rajoitus live Ensimmäisenä otetaan live-tilaan PV-rajoitus negatiivisilla hinnoilla. Se on yksisuuntainen — rajoittaa invertteria — eikä ohjaa mitään fyysistä relettä. Pienin riski.

Vaihe 2: HP EVU live Toisena lämpöpumpun EVU-ohjaus kalliina tunteina. Tämä on suurin yksittäinen vaikutus taloudelliseen optimointiin. EVU on konservatiivinen — käytännön testien perusteella ohjaus toimii ennakoivasti eikä ole aiheuttanut äkillisiä katkaisuja käynnissä olevalle kompressorille.

Vaihe 3: EV-lataus live Kolmantena EV-latauksen ohjaus. Tässä vaiheessa Safety Guardian on jo osoittanut toimivuutensa ja EV-telemetria on vakiintunut.

Vaihe 4: HP Boost live Viimeisenä lämpöpumpun Boost-ohjaus käyttöveden ajoittamiseen. Tämä vaatii eniten luottamusta järjestelmän logiikkaan koska se aktiivisesti käynnistää toimenpiteitä eikä vain estä niitä.

Jokaisen vaiheen jälkeen seurataan vähintään viikko ennen seuraavaa vaihetta ja tarkistetaan hyväksymiskriteerit:

• ei virheellisiä ohjauksia viikon aikana
• observability-loki vastaa toteutunutta laitekäyttäytymistä
• manuaalinen ohitus toimii odotetusti
• vanha automaatio ei taistele uutta vastaan Jokaiselle vaiheelle on rollback-suunnitelma: jos poikkeama havaitaan — virheellinen ohjaus, odottamaton laitekäyttäytyminen tai lokin ja todellisuuden ristiriita — kyseinen live-flag palautetaan false-tilaan ja vanha automaatio jatkaa ohjausta. Palautus on yhden muuttujan asia ja tapahtuu sekunteissa.

Mitä live-käyttöönotto ei tarkoita

Live-käyttöönotto ei tarkoita että vanha järjestelmä sammutetaan. Molemmat pyörivät rinnakkain — uusi ottaa kontrollin yksi osa-alue kerrallaan. Shadow/live-mekanismi on juuri tätä varten: energyhub_hp_live_control ja energyhub_ev_live_control -flagit ohjaavat kumpi järjestelmä on aktiivinen.

Live-käyttöönotto ei myöskään tarkoita että optimointi on valmis. Se tarkoittaa että arkkitehtuuri on riittävän vakaa kantaakseen vastuun — ja että voidaan alkaa kerätä oikeaa dataa oikeista päätöksistä.

Live-käyttöönoton tärkein tavoite ei ole säästö. Se on ohjausvastuun siirto hallitusti yhdelle arkkitehtuurille — pois hajautetuista automaatioista, kohti keskitettyä päätöksentekoa joka tietää mitä tekee ja miksi.

Teoria ja todellisuus kohtaavat vasta kun järjestelmä ohjaa oikeita laitteita oikeilla päätöksillä. Tässä vaiheessa EnergyHub ei ole enää kokeilu, mutta se ei ole vielä valmis optimointijärjestelmä. Se on hallitusti käyttöönotettava ohjausarkkitehtuuri.

---

Seuraavaksi: Osa 15 — Live-käyttöönotto. Miten vaiheistus eteni käytännössä ja mitä tapahtui ensimmäisten viikkojen aikana.