Sähköauton latauksen optimointi EnergyHubissa

Tämä on kolmastoista osa sarjasta joka dokumentoi EnergyHub-järjestelmän rakentamisen vanhaan rintamamiestaloon. Edellisessä osassa käsiteltiin Thermia-lämpöpumpun Modbus-ohjaus. Tässä osassa tarkastellaan kahta toisiinsa kytkeytyvää kokonaisuutta: sähköauton latausta ja aurinkoinvertterin ohjausta — ja sitä miten ne toimivat yhdessä energiajärjestelmässä.

---

Sähköauto on kotitalouden energiankäytön kannalta poikkeuksellinen kuorma. Se on suuri — tyypillisesti 11 kW kolmivaiheisena, tässä asennuksessa 3,6 kW Nissan Leafin yksivaiheisen latauksen vuoksi — mutta täysin siirrettävissä. Toisin kuin lämmitys tai valaistus, auton lataus ei ole sidottu kellonaikaan. Se voidaan tehdä milloin tahansa yön tai päivän aikana, kunhan auto on kotona ja johdossa.

Tämä joustavuus tekee EV-latauksesta optimoinnin kannalta kiinnostavimman yksittäisen kuorman. Mutta se tekee siitä myös vaikeimman — koska ajoituksen optimointi vaatii tietoa jota ei aina ole saatavilla: milloin auto tarvitaan seuraavaksi, paljonko akkua tarvitaan, ja miten latausteho käyttäytyy akun loppupuolella.

Kolme tietolähdettä

EnergyHubin EV-integraatio perustuu kolmeen tietolähteeseen joilla on tarkasti rajatut roolit.

Nissan API tarjoaa akun varaustason (SOC), arvioidun latausajan ja auton yleisen tilan. Se ei ole reaaliaikainen — tiedot päivittyvät vain kun auto on hereillä: latauksen alussa ja lopussa, HVAC-käynnistyksen yhteydessä tai kun update-nappia painetaan manuaalisesti. Nissan API:n lataus-tila (charging) on epäluotettava — se voi näyttää ”ei lataa” vaikka auto lataa.

ShellyPro3EM63 mittaa EV-pistokkeen todellisen latausvirran reaaliajassa. Tämä on latauksen luotettava tilan lähde. Kun Phase A teho ylittää 100 W ja ohjausrele on päällä, auto lataa. Kun teho on lähellä nollaa mutta rele on edelleen päällä, akku on täynnä tai lataus on estynyt.

ShellyPro1 ohjaa erillistä 25 ampeerin relettä joka sallii tai estää latauksen fyysisesti. Node-RED lähettää ohjauskomennon MQTT:n kautta ShellyPro1:lle, joka kytkee releen. Laturi on Walle 16 (3-vaiheinen 11 kW), mutta Nissan Leaf latautuu yksivaiheisesti — kaikki latausteho tulee Phase A:lta, noin 3,6 kW.

Nissan API    → SOC, arvioitu latausaika (ei reaaliaikainen)
ShellyPro3EM63 → todellinen latausteho (reaaliaikainen, luotettava)
ShellyPro1     → latauksen ohjausrele

Kolmen lähteen yhdistelmä ratkaisee ongelman jota mikään niistä ei yksin ratkaise.

Nissan API:n rajoitteet käytännössä

29.5.2026 klo 15:20 EV-telemetria näytti:

json

{
  "soc_pct": 70,
  "charging": false,
  "shelly_power_w": 3699,
  "shelly_relay_on": true
}

Nissan API sanoi charging: false. ShellyPro3EM63 mittasi 3699 W. Auto latasi täydellä teholla.

Tämä ei ole bugi — se on Nissan API:n suunniteltu toiminta. API päivittää latauksen tilan vain kun auto raportoi muutoksesta pilveen. Shelly mittaa pistokkeen tehon jatkuvasti.

Tämä on se syy miksi EnergyHubissa latauksen tila ei koskaan perustu Nissan API:n charging-arvoon. Se perustuu Shellyn mittaukseen.

Pääsulakkeet — turvallisuus ennen hintaa

EV on kotitalouden suurin yksittäinen kuorma. Walle 16 -laturi Nissan Leafin yksivaiheisella latauksella ottaa ~3,6 kW yhdeltä vaiheelta — noin 16 ampeeria. Kun tähän lisätään talon muu kulutus, 25 ampeerin pääsulake on jo lähellä.

Tämä on yksi tärkeimmistä syistä miksi EV-latausta pitää ohjata älykkäästi eikä vain kytkeä päälle halvalla tunnilla. Jos lämpöpumppu käy täydellä teholla ja EV lataa yhtä aikaa, L1-vaihe voi ylittää 25 ampeerin rajan.

EnergyHubissa vaihekohtainen virta mitataan 10 sekunnin välein. Safety Guardian valvoo rajoja:

• 22,5 A — varoitustaso, peak_protection aktivoituu
• 24,5 A — turvalaukaisin, EV-lataus katkaistaan välittömästi

EV-lataus on ensimmäinen kuorma joka pudotetaan kun sulake uhkaa — se on suuri, ei-kriittinen ja helposti ohjattava. Turvallisuus menee aina hinnan edelle.

Latauspäätöslogiikka

Priority Resolver (EnergyHubin keskitetty päätöksentekokerros) tekee EV-latauksen päätöksen samassa syklissä kaiken muun kanssa. Logiikka etenee tuttuun tapaan — turvallisuus ensin, talous viimeisenä.

javascript

// Luotettava latauksen tila Shellystä
s.evActuallyCharging = s.shellyPowerW > 100 && s.shellyRelayOn
s.evFull = s.shellyPowerW < 100 && s.shellyRelayOn

// Latauspäätös
if (!s.cap.evChargeAllowed) {
    decisions.ev = false  // capability estää
} else if (s.isPeakLoad) {
    decisions.ev = false  // sulake uhkaa
} else if (s.isNegativePrice) {
    decisions.ev = true   // negatiivinen hinta — lataa
} else if (s.isSolarExcess && s.evSocPct < 95) {
    decisions.ev = true   // aurinkoylijäämä — käytä itse
} else if (s.isCheapPrice && s.evSocPct < 90) {
    decisions.ev = true   // halpa hetki — lataa
} else if (s.evSocPct < 20) {
    decisions.ev = true   // akku liian tyhjä — lataa aina
} else {
    decisions.ev = false  // ei tarvetta
}

SOC-raja on tärkeä: lataus ei jatku jos akku on jo riittävän täynnä. ”Halpa hinta” ei tarkoita että ladataan vaikka akussa on jo 85 % — se tarkoittaa että käytetään halpa hetki hyväksi jos latausta tarvitaan.

Aurinkoylijäämä ja EV

Aurinkoylijäämä on EV-latauksen kannalta paras tilanne. Aurinko tuottaa enemmän kuin talo kuluttaa, ylijäämä menisi verkkoon — EV voi käyttää sen.

EnergyHub laskee aurinkoylijäämän reaaliajassa:

javascript

// gridPowerW on negatiivinen kun myydään verkkoon
s.solarExcessW = Math.max(0, -s.gridPowerW)  // vienti verkkoon = ylijäämä
s.isSolarExcess = s.solarExcessW > 2000       // yli 2 kW ylijäämä

Kun ylijäämää on yli 2 kW ja EV tarvitsee latausta, lataus sallitaan. EV:n 3,6 kW kulutus nostaa talon omaa kulutusta — verkkoon menevä ylijäämä pienenee ja aurinko kattaa suuremman osan omasta kulutuksesta.

Tässä on aurinkoinvertterin ja EV-latauksen koordinoinnin ydin: ne optimoidaan yhdessä, ei erikseen. Sama Priority Resolver joka päättää PV-rajoituksesta päättää myös EV-latauksesta. Ne eivät taistele keskenään.

PV-rajoitus ja EV yhtä aikaa

Negatiivisilla hinnoilla tilanne on mielenkiintoinen. PV-rajoitus on aktiivinen — invertteri rajoitettu esimerkiksi 25 %:iin. Samaan aikaan EV haluaa ladata.

Priority Resolver ratkaisee tämän koordinoidusti: jos EV lataa, se nostaa talon omaa kulutusta. Kasvanut omakäyttö tarkoittaa että PV-rajoitusta voidaan löysätä — invertteri saa tuottaa enemmän koska enemmän menee omaan käyttöön eikä verkkoon.

javascript

// Laske PV-rajoitus ottaen huomioon EV-lataus
const evLoad = decisions.ev ? 3600 : 0
const ownLoad = Math.max(300, s.pvPowerW + Math.min(0, s.gridPowerW) + evLoad)
const pct = Math.max(10, Math.min(95, Math.round((ownLoad / s.pvPowerW) * 100)))
decisions.pvCurtailPct = pct

Käytännössä algoritmi arvioi kuinka paljon aurinkotuotannosta käytetään paikallisesti — oma kulutus plus EV-lataus — ja säätää invertterin tehorajan sen mukaan. Mitä enemmän omaa kulutusta, sitä korkeammalle rajoitus asetetaan ja sitä enemmän aurinko saa tuottaa.

EV-lataus ja PV-rajoitus lasketaan samassa päätössyklissä. Tulos: aurinko tuottaa enemmän, EV lataa aurinkosähköllä, verkkoon ei mene negatiivisella hinnalla myytävää sähköä.

Latauksen ajoittaminen — nykyinen tila

Nykyisessä toteutuksessa EV-lataus perustuu reaaliaikaiseen tilanteeseen: hintaan, aurinkoon ja sulaketilanteeseen. Järjestelmä tekee päätöksen joka minuutti sen hetkisen datan perusteella.

Tämä on toimiva mutta ei optimaalinen ratkaisu. Se ei osaa vastata kysymykseen: ”milloin kannattaa aloittaa lataus jotta akku on täynnä klo 7:00 halvimmilla tunneilla?”

Vastaukseen tarvitaan kaksi asiaa jotka ovat vielä kehitysvaiheessa:

Tapering-malli — Nissan Leaf 39 kWh ei lataudu tasaisella 3,6 kW teholla koko ajan. Latausteho laskee akun loppupuolella, arviolta noin 90 % SOC:n jälkeen. Ilman tätä mallia ei voi laskea tarkasti milloin lataus valmistuu.

Lähtöaikaohjaus — käyttäjä asettaa milloin auto tarvitaan. Järjestelmä laskee milloin lataus pitää viimeistään aloittaa jotta akku on täynnä ajoissa. Tätä varten tarvitaan kolme ominaisuutta:

• ”Täysi akku klo 06:00” -painike
• Säädettävä lähtöaika
• ”Lataa nyt täyteen” -ohitus

Nämä ominaisuudet odottavat tapering-mallin valmistumista.

Tapering — mitattu käyrä

29.5.2026 tehtiin täydellinen latausmittaus ShellyPro3EM63:lla. Data kattaa SOC 85 %:sta täyteen. Lataus alkoi noin 70 %:sta mutta jatkui keskeytymättä loppuun.

SOC	Latausteho	Huomio
85–95 %	~3 710–3 780 W	Tasainen täysi teho
98 %	~2 870 W	Tapering alkaa
100 %	~630 W	Loppuvaihe, jatkuu ~60 min

Tapering alkaa noin 97–98 % SOC:ssa. Tämä on huomattavasti myöhemmin kuin monilla muilla EV:llä — Leaf lataa täydellä teholla poikkeuksellisen pitkään. Tapering-vaiheen kesto on noin 60–75 minuuttia.

Datan perusteella voidaan rakentaa kaksivaiheinen malli:

javascript

function estimateChargeTime(socPct, targetPct) {
    const capacity = 39       // kWh
    const taperingStart = 97  // % — mitattu
    const fullPower = 3.75    // kW — mitattu keskiarvo
    const taperingDuration = 75  // min — mitattu

    if (targetPct <= taperingStart) {
        // Tasainen lataus
        const energyNeeded = (targetPct - socPct) / 100 * capacity
        return energyNeeded / fullPower * 60  // minuuttia
    } else {
        // Tasainen osuus + tapering
        const flatEnergy = Math.max(0, taperingStart - socPct) / 100 * capacity
        const flatTime = flatEnergy / fullPower * 60
        const taperingPct = targetPct - Math.max(socPct, taperingStart)
        const taperingTime = taperingPct / (100 - taperingStart) * taperingDuration
        return flatTime + taperingTime
    }
}

// Esimerkki: SOC 70 % → 100 %
// Tasainen osuus: (97-70)/100 * 39 / 3.75 * 60 = ~168 min
// Tapering: 75 min
// Yhteensä: ~243 min = noin 4h (Nissan API näytti 4.5h — linjassa)

Tämä malli on riittävän tarkka lähtöaikaohjauksen laskentaan. Yksittäinen mittaus ei riitä lopulliseksi malliksi — tarvitaan useampi lataus eri SOC-tasoilta — mutta suuntaviivat ovat selvillä.

Miksi EV on vaikein kuorma optimoida

Lämpöpumppua optimoidaan talon lämpömassaa vasten — rakennuksen lämpötila muuttuu hitaasti ja puskuri on suuri. Aurinkoenergiaa optimoidaan hetkellistä tilannetta vasten — päätökset tehdään minuuteissa.

EV on erilainen. Optimointihorisontti on tunteja — ”milloin auto tarvitaan seuraavaksi” — mutta tieto tulevaisuudesta on epävarmaa. Käyttäjä voi muuttaa suunnitelmiaan. Auto voi olla poissa odottamatta.

Tämä tekee EV-optimoinnista ajoitusongelman eikä pelkän kynnysongelman. Ratkaisu vaatii:

• Tietoa nykyisestä SOC:sta (Nissan API)
• Tietoa latausdynamiikasta (tapering-malli)
• Tietoa tulevista hinnoista (Nordpool day-ahead)
• Tietoa auton tarvitsimisjasta (käyttäjän syöte)

Kolme ensimmäistä on saatavilla tai rakenteilla. Neljäs odottaa käyttöliittymää.

Mitä on rakennettu, mitä tulee

Toimii nyt:

• EV-latauksen sallinta/esto MQTT-komennolla
• Reaaliaikainen latauksen tila Shellystä
• SOC-tietoisuus Nissan API:sta
• Aurinkoylijäämän hyödyntäminen lataukseen
• Hintaohjattu lataus (kynnyslogiikka)
• Automaattinen Leaf-tietojen päivitys latauksen alkaessa ja loppuessa

Kehitysvaiheessa:

• Tapering-malli (tarvitaan mittausdata)
• Lähtöaikaohjaus (tarvitaan tapering-malli)
• EV-UI: ”täysi klo 06:00”, säädettävä lähtöaika, ”lataa nyt” -ohitus

Arkkitehtuurinen johtopäätös: EV-lataus on yksinkertaiselta näyttävä ongelma joka piilottaa sisäänsä ajoitusongelmat, epäluotettavat tietolähteet ja koordinointitarpeen muiden kuormien kanssa. Yksittäinen automaatio ei riitä — tarvitaan Priority Resolver joka näkee koko tilanteen.

---

Seuraavaksi: Osa 14 — Käyttöönotto ja häiriöt. Mitä tapahtui kun järjestelmä otettiin käyttöön — ja mitä opittiin.