Konfliktit — kun kolme tavoitetta taistelee

Tämä on yhdestoista osa sarjasta joka dokumentoi EnergyHub-järjestelmän rakentamisen vanhaan rintamamiestaloon. Edellisissä osissa rakennettiin päätöslogiikka, MQTT-viestintä ja aurinkoinvertterin ohjaus. Tässä osassa käsitellään tilannetta joka on arkkitehtuurin todellinen koetinkivi: mitä tapahtuu kun useampi tavoite haluaa samaa asiaa yhtä aikaa — tai estää toisiaan.

---

Kello on 14:00. Aurinko tuottaa 11 kW. Sähkön hinta on 1,2 senttiä — halpa. EV on kytkettynä ja haluaa ladata. Lämpöpumppu on juuri käynnistynyt käyttöveden boostin. L1-vaihe on 23,8 ampeeria.

Kolme asiaa haluaa tapahtua. Yksi pakottaa toisen pois.

Tämä on konflikti. Ja konflikti ei ole poikkeustilanne — se on normaalitila kaikissa energiajärjestelmissä joissa on useampi ohjattava kuorma.

Miksi konfliktit ovat vaikeita

Yksittäinen automaatio ei näe konflikteja. Se näkee vain oman ehtonsa: ”jos hinta alle X, lataa auto.” Se ei tiedä että samaan aikaan lämpöpumppu boostaa, sulake on jo 90 %:lla ja aurinkoinvertteri on rajoitustilassa.

Kun järjestelmässä on kolme automaatiota jotka kaikki yrittävät ohjata samaa relettä tai samaa kokonaiskulutusta, tuloksena on arvaamaton käyttäytyminen. Automaatio A sallii latauksen. Automaatio B estää sen. Automaatio C sallii sen taas. Rele flippaa minuutin välein — tai pahimmillaan sekunnin välein.

Tätä kutsutaan control fightiksi. Se ei näy virheenä logeissa. Se näkyy vain käyttäytymisessä — satunnaisena, selittämättömänä toimintana.

EnergyHubissa control fight on estetty arkkitehtuurisesti: yksi komponentti tekee kaikki päätökset, muut toteuttavat. Node-REDin Priority Resolver on se yksi komponentti. Se ei kilpaile muiden kanssa — ei ole muita. Konfliktia ei ratkaista siellä missä se syntyy, vaan yhdessä keskitettyssä päätöspisteessä.

Konfliktityypit

EnergyHubissa on kolme tyypillistä konfliktirakennetta.

Resurssikonflikti — kaksi kuormaa haluaa samaa rajallista resurssia. Tyypillisin tapaus: EV ja lämpöpumppu haluavat molemmat ladata/boostata samaan aikaan, mutta sulake ei kestä kumpaakin. Toisen pitää väistyä.

Tavoitekonflikti — kaksi optimointitavoitetta osoittavat eri suuntiin. Tyypillisin tapaus: hinta on halpa joten lämpöpumppu haluaa boostata (kuluta enemmän), mutta samaan aikaan aurinko ylituottaa ja invertteri on rajoitustilassa (tuotetaan vähemmän). Boostaaminen olisi järkevää — mutta rajoitustilassa se merkitsee verkkosähkön ostamista eikä aurinkosähkön käyttöä.

Aikakonflikti — päätös on oikea nyt mutta väärä viiden minuutin päästä. Tyypillisin tapaus: EV-lataus sallitaan koska hinta on halpa, mutta aurinko on laskemassa ja viidentoista minuutin päästä verkkosähkön hinta nousee huipputunnille.

Miten Priority Resolver ratkaisee konfliktit

Priority Resolver ei neuvottele. Se käy tilanteen läpi kiinteässä järjestyksessä ja ensimmäinen osuma ratkaisee.

Turvallisuus voittaa aina. Jos sulake on uhattuna, kuormat pudotetaan prioriteettijärjestyksessä riippumatta hinnasta, aurinkotilanteesta tai käyttäjän toiveista. EV menee ensin pois koska se on suurin yksittäinen kuorma. Kiuas menee toisena. Lämpöpumppu blokataan vain jos kompressori pyörii yli 60 %:lla — alle sen se saa jatkaa.

Tämä ei ole optimointipäätös — se on fyysinen rajoite. Sulake ei jousta.

Moodi määrittää kehyksen. Kun operating mode on peak_protection, hintaoptimointia ei tehdä lainkaan. Kun moodi on vacation, mukavuus väistyy minimikulutuksen tieltä. Moodi ei ole yksityiskohta — se on koko päätöskehys.

Capability on portti. Ennen kuin yksikään optimointipäätös tehdään, tarkistetaan onko toimenpide ylipäätään sallittu. c_ev_charge_allowed: false sulkee EV-latauksen kokonaan riippumatta muista olosuhteista. Tämä on käyttäjän hallintapiste — ei optimoinnin asia.

Hinta ja aurinko ovat viimeisenä. Vasta kun turvallisuus on varmistettu, moodi tarkistettu ja capabilityt selvitetty, päästään varsinaiseen optimointiin: onko hinta halpa, onko aurinkoylijäämää, kumpi kuorma hyötyy enemmän.

Resurssikonflikti käytännössä: EV vs lämpöpumppu

25.5.2026 klo 14:05 tilanne oli tämä:

• L1-vaihe: 23,8 A (sulakemaksimi 25 A, varoitusraja 22,5 A)
• EV latautui täydellä 3,6 kW teholla
• Lämpöpumppu käynnisti käyttöveden boostiin

Varoitusraja ylittyi heti kun lämpöpumppu käynnistyi. Safety Guardian havaitsi tilanteen 10 sekunnin sisällä ja laukaisi peak_protection-moodin.

Priority Resolver sai tiedon moodinvaihdosta. Päätökset:

• EV: off — suurin yksittäinen kuorma, poistuu ensin
• HP: normal — kompressori alle 60 %, saa jatkaa

EV:n sammuminen vapautti noin 16 ampeeria L1-vaiheelta (3,6 kW yksivaiheisena ≈ 16 A). Virta laski 16,2 ampeerin. Kun virta oli pysynyt alle 18,75 ampeerin (75 % sulakerajasta) riittävän kauan, Safety Guardian palautti normal-moodin.

Koko tapahtuma kesti 15 minuuttia. Käyttäjä ei tehnyt mitään.

Tavoitekonflikti: aurinko vs halpa hinta

Tämä on hienosyisempi konflikti jota ei aina huomata.

Tilanne: spot-hinta on 1 senttiä — halpa. Aurinko tuottaa 10 kW mutta talossa kulutus on vain 2 kW. Ylijäämä on 8 kW joka menee verkkoon. Hinta on positiivinen joten myynti on edelleen tuottoisaa — PV-rajoitusta ei aktivoida.

Lämpöpumppu haluaa boostata koska hinta on halpa. Järjestelmä sallii sen.

Mutta boostin käynnistyminen nostaa kulutusta 2 kW:lla. Se pienentää verkkoon menevää ylijäämää — mutta se myös tarkoittaa että aurinko kattaa boostin ilman verkkosähkön ostoa. Tulos: sama sähkölasku, lämpimämpi käyttövesi. Konflikti ratkesi luontevasti.

Eri tilanne: spot-hinta on -0,5 senttiä — negatiivinen. PV-rajoitus on aktiivinen, invertteri rajoitettu 25 %:iin. Lämpöpumppu haluaa boostata käyttövettä.

Tässä on tavoitekonfliktin ydin. Jos boosti tehdään nostamatta PV-rajoitusta, invertteri tuottaa edelleen vain 25 % — ja boostin tarvitsema lisäenergia ostetaan verkosta. Maksetaan verkkoon myymisestä ja ostetaan samaan aikaan verkkosähköä. Molemmat suunnat ovat tappiollisia.

Oikea ratkaisu on säätää PV-rajoitusta boostin tarpeen mukaan. Jos lämpöpumppu tarvitsee lisää tehoa, rajoitusta nostetaan — invertteri saa tuottaa enemmän ja boosti katetaan omalla aurinkosähköllä. Tämä on sama metodi jota käytetään muulloinkin: rajoitusta säädetään dynaamisesti omakäytön perusteella, ei kiinteällä arvolla.

EnergyHubissa Priority Resolver tekee tämän koordinoinnin: se laskee sekä PV-rajoituksen että lämpöpumpun ohjaustarpeen samassa päätössyklissä, ei erikseen. Boostin ja rajoituksen välinen tasapaino löytyy yhdessä laskennassa.

Aikakonflikti: oikea päätös väärään aikaan

Aikakonflikti on vaikein hallita koska se vaatii tulevaisuuden ennustamista.

Yksinkertainen esimerkki: klo 13:55 hinta on halpa, EV-lataus sallitaan. Klo 14:00 hinta nousee kalliiseen — mutta EV on jo latauksessa eikä järjestelmä reagoi ennen seuraavaa minuuttisykliä.

EnergyHubissa tähän ei ole täydellistä ratkaisua — ja sen myöntäminen on tärkeä osa realistista arkkitehtuurikuvausta. Minuuttisykli tarkoittaa että järjestelmä voi ”jäädä kiinni” väärään tilaan enintään minuutin ajaksi.

Pahempi tapaus: EV-lataus aloitetaan koska tuntihinta on halpa, mutta varttihinta — joka on tullut käyttöön 2025 — on jo noussut kalliiseen. Tähän tarvitaan varttitason hintadata — ja logiikka joka osaa toimia sillä. Tuntipohjainen logiikka ei riitä kun markkina- ja mittausjakso siirtyy 15 minuuttiin.

Toinen pahempi tapaus: aurinkoylijäämä on suuri juuri nyt, mutta pilvi on tulossa. Järjestelmä ei tiedä tätä ellei sääennustedataa integroida.

Nämä ovat tunnettuja rajoitteita. Ne eivät estä järjestelmää toimimasta — ne rajoittavat sen optimaalisuutta reunatapauksissa.

Ownership — kuka saa päättää

Konfliktien hallinta ei ole vain logiikkakysymys. Se on omistajuuskysymys.

EnergyHubissa omistajuus on eksplisiittinen: Node-RED päättää, HA toteuttaa, kenttälaitteet toimivat. Ketjussa ei ole rinnakkaisia päätöksentekijöitä. Ei ole HA-automaatiota joka ohittaa Node-REDin. Ei ole Node-RED-flow’ta joka kirjoittaa suoraan Modbus-rekisteriin ohi HA:n.

Tämä on se asia jonka puuttuminen tekee useimmista kotiautomaatiojärjestelmistä hallitsemattomia. Kymmenen automaatiota voivat kaikki olla oikein yksin — mutta yhdessä ne luovat konflikteja joita kukaan ei suunnitellut.

Shadow/live-mekanismi on toinen omistajuuden ilmentymä. Kun kaksi järjestelmää on käynnissä samanaikaisesti — vanha ja uusi — vain toinen saa ohjata kutakin laitetta. Raja on eksplisiittinen eikä se riipu siitä kumpi ”ehtii ensin.”

Konfliktit ovat tietoa

Lopuksi näkökulma joka muuttaa suhtautumisen konflikteihin.

Konflikti ei ole virhe — se on signaali. Kun Priority Resolver estää EV-latauksen sulakeongelman takia, se kertoo jotain tärkeää: talo kuluttaa liikaa yhdellä vaiheella. Kun lämpöpumpun boosti estetään negatiivisen hinnan aikana, se kertoo että aurinkotuotanto ja kulutus eivät ole tasapainossa.

EnergyHubin observability-kerros tallentaa nämä signaalit. InfluxDB:stä näkee jälkikäteen kuinka usein Peak Protection laukesi, milloin EV-lataus estettiin ja mistä syystä. Nämä eivät ole häiriöitä jotka pitää piilottaa — ne ovat dataa joka kertoo miten järjestelmää pitää kehittää.

Konflikti jota ei näe ei katoa. Se vain toimii äänettömästi väärällä tavalla.

---

Seuraavaksi: Osa 12 — Thermia Modbus-ohjaus. Miten maalämpöpumpun EVU- ja Boost-signaalit toimivat käytännössä ja miten ne integroidaan EnergyHubiin.