Figuur 1: HEMS se voor- en agterkant en kontroleskerm aansigte

Van Monitering na Beheer

’n Belangrike deel van die projek lê in die skuif van monitering na beheer. Die verslag sit drie bedryfsmodusse uiteen. Normal mode maak vorige geprogrammeerde instellings skoon en laat die stelsel in bystand. Blackout mode berei die huis vir ’n onderbreking voor deur nie-noodsaaklike laste af te skakel en die battery so vinnig as wat die omsetterinstellings dit toelaat te laai. Automated mode hanteer die daaglikse besluitneming. In daardie modus kyk die beheerder na batterylaaitoestand, sonopwekking, huishoudelike las, weerdata en beurtkragskedules, en besluit dan hoe die stelsel vir die komende ure voorberei moet word.

Daardie besluitnemingsproses sluit twee praktiese take in. Eerstens beplan die HEMS batterylaaiing voor geskeduleerde onderbrekings. Tweedens kyk dit vir tye wanneer sonopwekking groter is as die huis se behoefte en skakel dan sekere laste aan sodat oortollige sonkrag binne die huis gebruik word. In die projekdemonstrasie het daardie logika ’n swembadpompskakelaar deur ’n Sonoff-toestel beheer. Die verslag se beheer-vloeidiagram op bladsy 25 wys hoe die stelsel hierdie toestande tydens elke siklus nagaan en dan enige omsetterveranderings as een instellingsaksie bevestig.

Praktiese Gebruik van Voorspelling

Die projek se voorspellingslaag gebruik ’n LightGBM-regressiemodel wat met historiese las- en weerdata opgelei is en in ’n plaaslike SQLite-databasis gestoor word. In plaas daarvan om huishoudelike vraag as ’n vaste gemiddelde te behandel, gebruik die model tydsgebaseerde kenmerke, weerinsette, naweek- en vakansievlae, vertragingswaardes uit vroeër dae, en rollende gemiddeldes. Eenvoudig gestel, probeer dit die huis se patrone uit vorige data leer en gebruik dan daardie patroon om toekomstige vraag tydens ’n geskeduleerde beurtkragvenster te skat.

Dieselfde beheersiklus sluit ’n sonkragskatting in. Die verslag gebruik die pvlib Python-biblioteek saam met die huis se koördinate, sonposisie, wolkbedekking en paneelkapasiteit om waarskynlike PV-uitset oor dieselfde tydperk te skat. Die beheerder kombineer dan die voorspelde las en beraamde sonopwekking om te bereken hoeveel batterylaai die huis moontlik voor beurtkrag nodig sal hê. Dit maak van die HEMS ’n beplanningsinstrument, nie net ’n lewendige monitor nie.

Wat die Toetse Gewys het

Die verslag gee die stelsel ’n deeglike ronde validering. Dit het nagegaan dat die skerms met hul lewendige databronne ooreenstem, dat omsetterdata reg oor tyd geplot word, en dat skermwisseling glad bly. Die omsetterdatastroom het elke 15 sekondes nuwe waardes getrek en dit in SQLite gestoor, wat beteken het dat die stelsel tot sewe dae se historiese energievloei kon vertoon in plaas van net die huidige omsettertoestand. Op die energievloeigrafiek wys die verslag roostergebruik, batterylaaiing, batteryontlading, die begin van PV-opwekking en oggendlaspieke uit.

Die masjienleermodel is op nuwe data getoets en het ’n validerings-RMSE van 412.43 W en ’n validerings-MAE van 218.83 W getoon. Die verslag noem ’n gemiddelde voorspellingsakkuraatheid van 79.85% oor ’n 30-dae-gesimuleerde tydperk. ’n Afsonderlike laaiplantoets oor 15 gesimuleerde dae het ’n gemiddelde beplanningsfout van 6.05 kWh vir ’n 10 kWh-batterystelsel getoon. 

Bedryfsmodustoetse het daarna gekyk of die beheerder daardie besluite in die praktyk uitvoer. In Blackout mode het die stelsel die swembadpomp afgeskakel en die battery vir ’n onderbreking voorberei. In Automated mode het dit in een toetsgeval op die beplande tyd begin laai en in ’n ander geval ’n demonstrasielas aangeskakel toe sonopwekking groter was as huishoudelike vraag.

’n Projek soos hierdie werk net as dit lank kan aanhou loop sonder om te vries of geheue te verloor. Die verslag gee nuttige aandag aan daardie deel van die werk. Die stelsel gebruik agtergrond-drade vir dataversameling en skeduleer dan koppelvlakopdaterings op die hoof-UI-draad sodat die paneel responsief bly. 

’n Afsonderlike hulpbronbestuurder hou grafiekobjekte dop en ruim dit op wanneer skerms verander. In toetse het geheuegebruik by sowat 242 MB gestabiliseer en ’n 48-uur lopie by 245 MB geëindig, wat op bestendige werking dui eerder as op ’n groeiende lek. Toetse met medestudente het nog ’n laag bygevoeg deur te kyk of mense sonder voorafkennis die koppelvlak kon gebruik sonder om dit te breek.

Finale Gedagtes

Wat die projek bo ’n gewone beheerpaneel lig, is sy mengsel van sagteware, beheerlogika en plaaslike gebruik. Dit hou nie by die wys van grafieke op nie. Dit probeer die huis se energiestelsel vroeër laat optree deur data wat reeds beskikbaar is te gebruik. Die verslag se voorlopige kostedeel skat die hardeware op ongeveer R3,650 en gee ’n moontlike terugbetaaltyd van omtrent 10 maande onder ’n beperkte swembadpompscenario. Daardie syfer hang van die genoemde aannames af en moet dus nie as ’n algemene besparingsbelofte gelees word nie. Tog maak die projek ’n duidelike saak uit vir ’n klein, plaaslike beheerder wat huishoudings ’n nouer greep gee op batterygebruik, sontydsberekening en voorbereiding vir onderbrekings.