WitFlow – standalone energiaohjaus ilman Home Assistant -kerrosta

[Linksu]

WitFlow – standalone energiaoptimointi Raspberry Pi:llä ilman Home Assistant -kerrosta

Olen rakentamassa Raspberry Pi 4:lle uutta energiaoptimointijärjestelmää nimeltä WitFlow.

Ajatus ei ole tehdä uutta “älykotijärjestelmää”, vaan mahdollisimman kevyt, vakaa ja suoraan energiaoptimointiin tehty runtime.

Projektin tausta on omassa järjestelmässä:

- Growatt WIT hybrid-invertteri
- Panasonic Aquarea + HeishaMon
- Nord Pool
- RuuviTagit
- myöhemmin P1-kuormamittaus
- akkuohjaus
- thermal battery / MPC-optimointi

Aluksi kaikki pyöri Home Assistantin kautta, mutta aika nopeasti tuli vastaan sama ongelma jonka moni muukin on huomannut:

energiaoptimointi ei oikeasti tarvitse koko Home Assistant -stackia ympärilleen.

Tämä ei ole HA:n haukkumista — Home Assistant on erinomainen yleisautomaatioalusta.

Mutta energiaoptimointi on hyvin erilainen kuorma kuin tavallinen kotiautomaatio.

Kun mukana alkaa olla:

- jatkuva Modbus-pollaus
- MQTT
- historian tallennus
- hintadata
- optimizer
- MPC-laskenta
- lämpöpumpun mallinnus
- akun optimointi

…niin HA:n ympärille alkaa helposti muodostua:

- template-sensoreita
- helper-entiteettejä
- automaatioita
- pyscriptejä
- Node-REDiä
- AppDaemonia
- EMHASSia
- MQTT-välitasoja

Lopputulos toimii, mutta kokonaisuus muuttuu helposti vaikeasti ylläpidettäväksi.

WitFlowin idea on poistaa kaikki ylimääräinen välistä.

Nykyinen kehitysversio pyörii Dockerilla Raspberry Pi 4:llä.

Mukana tällä hetkellä:

- FastAPI backend
- SQLite historian tallennus
- Growatt WIT read-only Modbus
- Nord Pool integraatio
- Mosquitto MQTT
- HeishaMon MQTT subscriber
- Ruuvi BLE integraatio
- optimizer skeleton
- dashboard
- runtime health monitoring
- stale detection
- retention cleanup
- progressive ML-kuormitusennuste
- akun energiakerrosten hintaseuranta

Kaikki toimii tällä hetkellä read-only moodissa:

- ei Modbus writejä
- ei lämpöpumpun ohjausta
- ei automaattista akun ohjausta vielä

Halusin ensin rakentaa vakaan telemetry + optimizer -pohjan ennen control layeria.

Suurin hyöty ei välttämättä ole CPU-kuormassa vaan arkkitehtuurissa.

WitFlowissa:

- optimizer näkee datan suoraan
- ei tarvitse kymmeniä template-entiteettejä
- ei tarvitse HA service call -ketjuja
- ei tarvitse MQTT → HA → automation → REST → script -polkuja
- ei tarvitse erillistä EMHASS-kerrosta

Tavoite on:

sensori → runtime → optimizer → control layer

mahdollisimman suoralla polulla.

Lisäksi:

- SQLite täysin paikallisesti
- ei pilviriippuvuutta
- ei HA entity-mallia
- ei HA-version rikkoutumisketjuja
- ei integraatiokerrosten ketjureaktioita

Pitkän aikavälin tavoitteet:

- standalone Raspberry Pi runtime
- oma optimizer engine
- Panasonic Aquarea MPC
- thermal battery -malli
- akun hintapohjainen optimointi
- P1-kuormamittaus
- turvallinen control layer
- manual approval mode
- myöhemmin täysin automaattinen optimointi

Nykyinen standalone-testijärjestelmä pyörii jo onnistuneesti Raspberry Pi 4:llä:

- Docker
- Mosquitto
- API
- dashboard
- optimizer
- SQLite
- runtime health
- ML-ennuste
- battery economics

Seuraavana vaiheena:

- oikea HeishaMon telemetry
- WIT runtime validointi
- P1 integraatio
- optimizerin kehitys
- thermal model
- MPC

Ajattelin avata projektia tänne, koska täällä on paljon porukkaa jotka ovat painineet samojen asioiden kanssa:

- Aquarea
- HeishaMon
- Nord Pool
- HA + EMHASS
- thermal battery
- hybrid-invertterit
- hintapohjainen optimointi

Kommentit ja ajatukset kiinnostaa erityisesti niiltä jotka ovat rakentaneet vastaavia järjestelmiä.

 

[Linksu]

Pieni päivitys WitFlow-projektiin.

WitFlow on Raspberry Pi 4:lle rakennettava standalone energiaohjausjärjestelmä, jonka tavoite on korvata Home Assistant omassa energiaoptimointikäytössä.

Nykyinen suunta:

• Growatt WIT -telemetria
• Panasonic Aquarea / HeishaMon MQTT
• RuuviTag sisä-/ulkolämpötilat
• Nord Pool + pidempi hintaennuste
• Solcast / Forecast.Solar PV-ennuste
• oma PV-ennusteen korjaus oman katon/varjostusten mukaan
• oppiva lämpömalli
• dry-run MPC akulle + lämpöpumpulle
• SQLite historia
• dashboard
• Raspberry Pi standalone Docker-asennus

Tärkeä periaate on edelleen turvallisuus: kaikki on vielä recommendation/read-only -tilassa. Eli ei Modbus writejä, ei lämpöpumpun setpoint-muutoksia eikä akun automaattiohjausta.

Uutta on se, että järjestelmä alkaa nyt jo simuloida mitä se tekisi: milloin kannattaisi ladata akkua, milloin käyttää lämpömassaa, milloin esilämmittää ja milloin säästää energiaa kalliille tunneille. Tämä näkyy dashboardissa dry-run MPC -suosituksina, mutta ei vielä ohjaa mitään itse.

Yksi mielenkiintoinen osa on PV-ennusteen oppiminen: järjestelmä vertaa ennustetta todelliseen tuotantoon ja alkaa korjata ennustetta oman katon varjostusten mukaan. Sama ajatus on tulossa lämpömalliin: talon lämpöinertiaa ja lämmitysvasteita opitaan historiasta, mutta selitettävästi eikä black-box AI:na.

Tavoite ei ole rakentaa yleistä älykotia, vaan kevyt paikallinen energiaohjain:
sensori → historia → ennuste → oppiva malli → optimizer → myöhemmin turvallinen ohjaus.

Seuraavaksi tarkoitus on testata tätä enemmän oikealla Raspberryllä ja siirtää Growatt WIT mahdollisesti suoraan USB-RS485 Modbus RTU:n kautta WitFlowille.

 

[jalih]

Itse taas tein niin päin, että muutin oman Pörssäriä hyödyntävän palveluna pyörivän 8th ohjelmointikielellä toteutetun ohjaus softani käskyttämään IP-Symcon:ia. Tämä muutos toi mukanaan älyttömän paljon hyötyjä kuten, että ohjauslaitteet eri ohjauskanavilla voivat käytännössä olla ihan mitä vain. Lisäksi nyt voi IP-Symcon:in visualisoinnin kautta seurata ohjauksien tilaa ja hoitaa tarvittaessa manuaali-ohjaukset. Nyt minulla on työn alla palveluna pyörivä ohjelma, jota voi ajaa ohjaus softan kaverina kosketusnäytöllä varustetuilla ohjaustietokoneilla. Tämä siis muodostaa Pörssäri ohjauksista natiivin graafisen käyttöliittymän, mistä Pörssäri ohjauksien tilaa voi seurata tai muuttaa.

Mitä ohjelmointikieltä käytät toteutukseen?

 

[Linksu]

WitFlow on tehty tällä hetkellä pääosin Pythonilla.

Runtime pyörii FastAPI:n päällä Dockerissa ja mukana on mm:

• Modbus TCP/RTU
• MQTT
• Nord Pool / PV forecast
• MPC dry-run
• thermal model
• JK-BMS telemetry
• Home Assistant bridge

Ajatus on ollut tehdä siitä enemmän standalone “energy runtime” kuin pelkkä HA-integraatio.

UI on oma selainkäyttöliittymä ja lisäksi siihen tuli nyt MQTT Discovery -pohjainen Home Assistant bridge, jolloin HA:ta voi käyttää halutessaan dashboardina/automaatiokerroksena.

Ohjauspuoli on tällä hetkellä vielä recommendation-only / dry-run vaiheessa eli ei tehdä automaattisia write-komentoja inverterille tai lämpöpumpulle ilman erillistä control layeria.

 

[exrx]

Itsellä sama suunta, kyllästyin siihen että joku kohta hajosi HA:ssa lähes jokaisen päivityksen yhteydessä. Mietin asiaa ja totesin, että lopulta en tarvitse HA:ta yhtään mihinkään, koska kaikki sensorini, kamerat, kytkimet ym ovat sellaisia, joissa on avoin rajapinta. Olen aikanaan rakentanut HA:n täysin pilviriippumattomaksi joten tämä oli helppo juttu muuttaa omalle alustalle.

Käytössä on

- RPI4
- Influx + Grafana pidemmän ajan trendien katsomista varten
- zigbee2mqtt zigbee-antureiden ja kytkimien liittämiseen
- opendtu mikroinverttereitä varten
- Broadlink IR -blastereita ILP:en ohjaamista varten
- Shelly-releitä kiertovesipumppujen ohjaukseen (lämmitys, lämminvesikierto)

Käytin päivän siihen, että koodasin sensorointi- ja automaatioalustan ChatGPT:n avulla. HA pyörii vielä rinnalla mutta tavoite on luopua siitä kokonaan.

@Linksu miten teit nuo oppivat ennusteet ja säädöt?