Case: oma talo — Osa 10

Written by

in

Aurinko ja teho Node-REDissä

Tämä on kymmenes osa sarjasta joka dokumentoi EnergyHub-järjestelmän rakentamisen vanhaan rintamamiestaloon. Edellisessä osassa käytiin läpi hintaohjauksen päätöslogiikka Node-REDissä. Tässä osassa tarkastellaan kahta toisiinsa kytkeytyvää kokonaisuutta: aurinkoinvertterin tehonrajoitusta negatiivisilla hinnoilla ja vaihevirtojen reaaliaikaista valvontaa.


Aurinkopaneeli tuottaa sähköä aina kun aurinko paistaa. Se ei kysy onko hinta hyvä tai huono. Ilman ohjausta kaikki ylijäämä menee verkkoon — myös silloin kun hinta on negatiivinen ja jokainen myyty kilowattitunti maksaa omistajalle.

Tämä oli EnergyHubin yksi keskeisimmistä motivaatioista: rakentaa logiikka joka reagoi negatiivisiin hintoihin automaattisesti, rajoittaa vientiä älykkäästi ja ohjaa ylijäämä ensin omaan käyttöön.

Aurinkoylijäämä — mitä se tarkoittaa käytännössä

Aurinkoylijäämä on se osa tuotannosta joka ylittää talon hetkellisenkulutuksen. Jos aurinko tuottaa 8 kW ja talo kuluttaa 2 kW, ylijäämä on 6 kW — se menee verkkoon ellei sitä ohjata muualle.

EnergyHubissa ylijäämä lasketaan reaaliajassa:

javascript

s.solarExcessW = Math.max(0, s.pvPowerW - Math.max(0, s.gridPowerW))
s.isSolarExcess = s.solarExcessW > s.solarExcessThresholdW  // oletusarvo 2000 W

gridPowerW on positiivinen kun ostetaan verkosta ja negatiivinen kun myydään. Kaava ottaa tämän huomioon: jos verkosta ostetaan (gridPowerW > 0), ylijäämää ei ole vaikka aurinko tuottaisi.

Ylijäämä ohjataan ensisijaisesti omaan kulutukseen — EV-lataukseen tai lämpöpumpun boostiin. Vasta sen jälkeen, ja vain jos hinta on negatiivinen, rajoitetaan invertterin tehoa.

PV-rajoitus negatiivisilla hinnoilla

Kun spot-hinta laskee alle p_negative_price-kynnyksen ja aurinko tuottaa yli 500 W, Priority Resolver laskee sopivan rajoitusprosentin:

javascript

if (s.isNegativePrice && s.pvPowerW > 500) {
    const ownLoad = Math.max(300, s.pvPowerW + Math.min(0, s.gridPowerW));
    const pct = Math.max(10, Math.min(95,
        Math.round((ownLoad / s.pvPowerW) * 100)
    ));
    decisions.pvCurtailPct = pct;
}

ownLoad on talon hetkellinen omakäyttö — kuinka paljon aurinkosähköä kuluu itse. Rajoitusprosentti on tämän suhde invertterin nimellistehoon (15 kW). Jos talo kuluttaa 3 kW, rajoitus asetetaan 20 %:iin — invertteri saa tuottaa enintään 3 kW jotta vienti minimoidaan.

Normaalitilassa invertteri on asetettu 110 %:iin — Sungrowin tapa ilmaista ”ei rajoitusta, käytä kaikki mitä paneeleilla on”. Kun negatiivinen hinta aktivoituu, rajoitus lasketaan dynaamisesti ja asetetaan esimerkiksi 24 %:iin. Kun hinta palaa normaaliksi, palataan 110 %:iin.

Rajoituslaskennassa minimiarvo on 10 % eikä 0 %. Täysi sammutus aiheuttaa invertterin uudelleenkäynnistyksen ja voi johtaa ohjausongelmiin — 10 % on turvallinen alaraja joka pitää invertterin aktiivisena. Maksimiarvo rajoituslaskennassa on 95 % — tämä estää tilanteen jossa laskettu rajoitusarvo heiluisi juuri 100 %:n tuntumassa pienten kulutusvaihteluiden mukana. Täyteen tehoon palataan aina 110 %:n kautta, ei 100 %:n.

Modbus-ohjaus käytännössä

Komento kulkee Node-REDistä HA:lle MQTT:n kautta: energyhub/command/pv/curtail_pct: 24. HA vastaanottaa sen ja kirjoittaa Modbus-rekistereihin.

Sungrow SG15RT -invertterissä rajoitus tapahtuu kahdella rekisterillä:

  • Rekisteri 5006 — Power Limitation Switch. Tämä on bittikenttä, ei yksinkertainen 0/1-kytkin. SG15RT:llä se on pysyvästi tilassa 170 (”Enabled”) — invertteri hyväksyy rajoituskomennot eikä rekisteriin tarvitse koskea.
  • Rekisteri 5007 — rajoitusarvo (0–1100, yksikkö 0,1 % nimellistehosta. Tähän rajoitus kirjoitetaan.

24 % rajoitus tarkoittaa arvoa 240 rekisterissä 5007. Rajoitus aktivoituu pelkällä tällä kirjoituksella — 5006 pysyy koko ajan tilassa 170. Täyteen tehoon palataan kirjoittamalla 5007:ään arvo 1100 (= 110 %).

Tämä on Sungrow-spesifinen toteutus — SMA, Fronius, ABB ja Huawei SUN2000 käyttävät omia rekisterikarttojaan, mutta SunSpec-standardia tukevat laitteet jakavat yhteisen osoitteiston. Rekisteritason yksityiskohdat on kuvattu tarkemmin ohjeessa Sungrow Modbus + tehonrajoitus.

DC-potentiaaliaukko — mitä tapahtuu invertterin sisällä

25.5.2026 tehdyssä testissä havaittiin jotain odottamatonta. Kun invertteri rajoitettiin 24 %:iin, MPPT-jännite nousi 501 voltista 544 volttiin — nousu noin 43 volttia. Virta laski vastaavasti 11,7 ampeerista 7,0 ampeeriin.

Tämä paljastaa miten invertteri toteuttaa rajoituksen: se ei leikkaa AC-puolelta vaan siirtää paneelien toimintapisteen pois maksimitehopisteestä (MPP). Invertteri nostaa DC-jännitettä tarkoituksella, jolloin paneelit tuottavat vähemmän virtaa ja siten vähemmän tehoa.

Käytännön seuraus: kun invertteri on rajoitustilassa, DC-rekisterit eivät kerro saatavilla olevaa paneelipotentiaalia — ne kertovat vain invertterin valitseman toimintapisteen. Testissä todellinen saatavilla oleva paneeliteho oli noin 11 kW, mutta rajoitustilan DC-teho näytti vain noin 3,8 kW. Jos haluaa tietää paljonko aurinkoa ”oikeasti” olisi saatavilla, pitää tehdä lyhyt testipulssi jossa rajoitus nostetaan hetkellisesti 110 %:iin ja mitataan toteutuva teho.

30 päivän historiadatasta laskettu normaali MPPT-jännite on 474–515 V (keskiarvo 494 V, hajonta 20,8 V). Rajoituksen aikana mitattu 544 V on yli kaksi standardipoikkeamaa normaalin yläpuolella päiväaikaan — tilastollisesti selvästi poikkeava tapahtuma.

Taloudellinen realismi

Negatiivisten hintojen aiheuttama tappio on tällä hetkellä Suomessa pieni mutta kasvava.

Vuonna 2025 tehdyn analyysin tulokset olivat yllättävän maltilliset. Negatiivisilla hinnoilla myytiin noin 651 kWh sähköä 115 tunnin aikana — kokonaistappio oli noin 2 euroa. Painotettu myyntihinta näillä tunneilla oli -0,344 snt/kWh. Suhteessa kokonaisuuteen — koko vuoden myyntitulo oli noin 359 € 8 632 myydystä kilowattitunnista — negatiivisten hintojen vaikutus oli pieni.

Mutta analyysi paljasti tärkeän asian: suurin osa tappiosta syntyi lievästi negatiivisilla hinnoilla, ei äärimmäisissä piikeissä. Yksittäiset -500 EUR/MWh -hetket ovat dramaattisia mutta harvinaisia. Lievästi negatiivisia tunteja on paljon enemmän — ja niiden määrä kasvaa joka vuosi. Nolla- tai negatiivisen hinnan tunteja oli Suomessa vuonna 2024 peräti 994 — lähes 41 vuorokautta.

Yksittäisenä päivänä 25.5.2026 tappio ilman rajoitusta olisi ollut noin 0,5 euroa. Trendi on selvä: rajoituksen taloudellinen hyöty kasvaa suoraan negatiivisten tuntien määrän mukana. Jos 2026 jatkaa samaa trendiä, vuositason tappio ilman rajoitusta voi olla helposti 10–30 euroa 15 kW järjestelmällä. Ei suuri summa — mutta automatisoitu suojaus ei myöskään maksa mitään käytön jälkeen.

Safety Guardian — vaihevirtojen reaaliaikainen valvonta

PV-rajoitus on proaktiivinen toimenpide — se reagoi hintaan ennen kuin ongelma syntyy. Safety Guardian on reaktiivinen — se reagoi vaihevirtoihin kun ne jo ovat korkealla.

Safety Guardian pyörii erillisessä Node-RED-flow’ssa ja kuuntelee energyhub/telemetry/phases-topicia joka päivittyy 10 sekunnin välein. Se ei odota minuuttisykliä.

Logiikka on yksinkertainen mutta tehokas:

javascript

const maxA = Math.max(Math.abs(l1), Math.abs(l2), Math.abs(l3));
const warnLimit = 30;   // A → peak_protection
const reduceLimit = 36; // A → kuormanpudotus
const tripLimit = 40;   // A → safety trip
const hysteresis = 25;  // A → paluu normal

if (maxA >= tripLimit) {
    // SAFETY TRIP — välitön toiminta
    return safety_trip: true
}
if (maxA >= warnLimit && mode !== 'peak_protection') {
    // Pyydä moodinvaihtoa
    return mode: 'peak_protection'
}
if (mode === 'peak_protection' && maxA < hysteresis) {
    // Paluu normaaliin
    return mode: 'normal'
}

Nämä kynnykset eivät olleet alusta asti tällaiset. Suunnitteluvaiheessa lähdettiin konservatiivisista arvoista — varoitus jo 22,5 ampeerissa ja laukaisu 24,5 ampeerissa, mikä on 90 % ja 98 % 25 ampeerin sulakkeesta. Käytännön käytössä nämä osoittautuivat liian herkiksi: järjestelmä reagoi normaaleihin kulutuspiikkeihin turhan usein. Kynnyksiä nostettiin tuotantokäyttöön arvoihin 30 / 36 / 40 A, jotka antavat enemmän pelivaraa normaalille kuormalle mutta puuttuvat silti tilanteeseen selvästi ennen sulakkeen todellista laukeamista.

Hystereesi on tärkeä: moodiin ei palata heti kun virta laskee alle varoitusrajan — vasta kun se laskee selvästi alle sen. Tämä estää moodin flippaamisen edestakaisin pienten vaihteluiden mukana.

Toimintaperiaate näkyi käytännössä jo aikaisin: kun L1 nousi varoitusrajan yli, Guardian laukaisi peak_protection-moodin ja EV-lataus estettiin. Kun virta laski hystereesirajan alle, Guardian palautti normal-moodin. Koko tapahtuma hoitui ilman käyttäjän toimenpiteitä — juuri kuten reaktiivisen suojan kuuluu toimia.

Aurinko ja sulakkeet — sama ongelma eri suunnista

Aurinkoinvertteri ja sulakevalvonta ratkaisevat saman ongelman eri suunnista.

Sulakevalvonta katsoo kuinka paljon verkosta ostetaan ja pudottaa kuormia kun raja lähestyy. Aurinkoinvertteri vaikuttaa siihen kuinka paljon verkkoon myydään ja siten epäsuorasti myös siihen paljonko talo nettona kuluttaa.

Yhdessä ne muodostavat kaksisuuntaisen tehonhallinnan: Safety Guardian estää liian suuren oston, PV-rajoitus minimoi turhan myynnin. Kumpikaan ei yksin riitä — yhdessä ne pitävät talon tehotasapainon hallinnassa sekä ostopuolella että myyntipuolella.

Mitä testistä opittiin — arkkitehtuurin synty

Käytännön testi vuonna 2025 paljasti jotain odottamatonta. Kun invertterin tehoa alettiin rajoittaa Modbusin kautta, huomattiin että rajoitus ei ole irrallinen toiminto — se muuttaa koko järjestelmän dynamiikan.

Kun aurinkotuotantoa rajoitettiin, EV-latauksen logiikka muuttui. Lämmityksen optimointi muuttui. Ylijäämäenergian hyödyntäminen muuttui. Useat automaatiot alkoivat vaikuttaa toisiinsa tavalla jota kukaan ei ollut suunnitellut.

Johtopäätös oli selvä: invertterin tehorajoitus ei voi olla yksittäinen automaatio. Se vaatii keskitetyn tilannekuvan, prioriteetit, ohjauksen omistajuuden ja eri järjestelmien koordinoinnin. Tarvitaan EnergyHub-arkkitehtuuria.

Tästä havainnosta syntyi koko sarjan kantava teema:

Energian optimointi ei ole yksittäinen automaatio-ongelma — se on arkkitehtuuri-ongelma.

Miksi tämä ei onnistu pelkällä ajastimella

Yksinkertaisempi ratkaisu olisi ajastaa invertteri pois päältä kun hinta on negatiivinen. Se toimisi — mutta karkeasti.

Ongelma on että negatiivinen hinta ei tarkoita automaattisesti että rajoitus on järkevää. Jos talo kuluttaa paljon — kiuas käy, EV latautuu, lämpöpumppu boostaa — invertteri voi tuottaa täydellä teholla eikä mitään mene verkkoon. Rajoitus olisi turha.

EnergyHubin logiikka laskee reaaliaikaisesti paljonko vientiä oikeasti on ja rajoittaa sen verran kuin tarpeen. Ei enemmän. Tämä on tarveperustaista ohjausta — ei kynnysohjausta.


Seuraavaksi: Osa 11 — Konfliktit. Kun aurinko tuottaa, hinta on halpa ja sulake uhkaa yhtä aikaa — miten järjestelmä ratkaisee kolmen tavoitteen ristiriidan.

Tekninen toteutus: PV-rajoitus Modbus-ohjauksella on kuvattu tarkemmin ohjeessa Sungrow Modbus + tehonrajoitus.