Howard
EnergyLab

Hvorfor bygge sin egen energistyring?

Solceller, husbatteri og elbil burde kunne arbejde godt sammen. Inverteren er den enhed, der omformer strømmen og forbinder solceller og batteri med husets elinstallation. Men producenterne bruger forskellige apps, tjenester på nettet og måder at udveksle oplysninger på. Udstyret kan derfor fungere godt hver for sig uden at samarbejde eller udnytte energien bedst muligt.

Samtidig er mange kommercielle løsninger forbundet med abonnementer, begrænsede funktioner eller afhængighed af producenternes systemer. Derfor har jeg valgt at bygge min egen løsning.

Jeg vil selv bestemme, hvordan data indsamles, hvordan energistyringen beregnes, og hvilke handlinger systemet må udføre.

Projektet består af flere sammenhængende dele:

• Min egen aflæsningsenhed, kaldet en dongle, som allerede læser oplysninger direkte fra min inverter og leverer dem til energiflowet.
• InverterLab, et virtuelt testanlæg, der efterligner en inverter og dens måde at udveksle oplysninger på (Modbus).
• En separat simulator til energistyring, hvor jeg afprøver økonomien i batteribrug, bilopladning og belastningen af elinstallationen.
• Energi Agent, siden på computer og mobil, hvor jeg ser målinger, planer og forklaringer.
• AI-Hub, som giver adgang til den kunstige intelligens, der hjælper med at forklare og efterprøve resultater.
• API-Butler, som samler data, udfører beregninger og håndterer godkendt styring.

Jeg bygger altså ikke bare endnu en app, der viser, hvor meget strøm jeg bruger. Jeg bygger en platform, der skal hjælpe mig med at træffe bedre beslutninger om energi – og dokumentere, om de faktisk virker.

Min egen aflæsningsenhed – direkte kontakt med inverteren

Min egen dongle er taget i brug på min Growatt SPH3600 hybridinverter. Den læser lokale målinger af solproduktion, husets strømforbrug, batteri og elnet og leverer dem til systemets fælles datagrundlag. Energiflowet på web og mobil bruger allerede disse målinger, når de er gyldige og tilstrækkeligt nye. Normalt sender producentens datalogger målingerne til en tjeneste på nettet, hvor anlægget kan følges.

Jeg læser nu oplysningerne direkte ved anlægget. Det giver hyppigere opdateringer til energiflowet og gør visningen mindre afhængig af producentens tjeneste. Min dongle bruger Wi-Fi til mit lokale netværk og et RS485-kabel til inverteren.

Den nuværende dongle: aflæsning uden styring

I brug nu: Min dongle læser lokale målinger. Den nuværende udgave kan ikke ændre inverterens indstillinger.

Indstillinger i dag: Jeg bruger API-Butler til at sende godkendte ændringer gennem Growatts tjeneste på nettet, eksempelvis husbatteriets ladeperioder. Før donglen hentede jeg også målingerne ad den vej. Growatt kan stadig bruges som reserve til energiflowet.

Næste opdatering: Planen er, at donglen også skal kunne ændre indstillinger direkte på inverteren. Den funktion skal udvikles, testes og efterprøves på mit eget udstyr, før jeg tager den i brug.

Det er en vigtig afgrænsning, fordi inverteren er forbundet med både husets elinstallation og batterisystem. Jeg skal kunne forstå og efterprøve softwarens funktion, inden jeg giver den yderligere ansvar. Og her spiller InverterLab en central rolle.

InverterLab – et virtuelt testanlæg

Hvordan tester man kommunikation med en inverter uden at skulle eksperimentere på det rigtige energianlæg? Man bygger en simulator.

Det er tanken bag InverterLab.

InverterLab er mere end en idé eller en side med grafer. Jeg har bygget en model, der beregner energiens bevægelse, og et testbord, jeg kan følge i browseren. Andre programmer kan tale med modellen gennem Modbus, den kommunikationsform jeg tester. Modellen efterligner centrale dele af en Growatt SPH3600.

Jeg kan ændre solproduktionen og husets forbrug og derefter se, hvordan energien fordeler sig mellem huset, batteriet og elnettet. Batteriets niveau ændrer sig, efterhånden som modellen oplader eller aflader batteriet. Samtidig kan et eksternt program kommunikere med simulatoren, som om den var en inverter.

Det gør det muligt at teste både energimodellen og selve kommunikationen.

Et testbord, hvor jeg kan se systemet arbejde

InverterLab har også fået et webbaseret testbord. Det giver mulighed for at følge energimodellen visuelt, mens jeg arbejder med forskellige scenarier. Testbordet understøtter adskilte udgaver af simulatoren med hver deres testværdier.

Det betyder, at forskellige forsøg ikke behøver at påvirke hinanden. Når det er relevant, kan jeg se automatiserede test på skærmen og følge energiflowets ændringer. Andre kontroller kan køre i baggrunden.

Jeg starter testforløb, når der er noget konkret, jeg ønsker at undersøge, frem for at lade unødvendige test køre konstant. Jeg anvender manualer, registerdokumentation og afgrænset firmwareanalyse til at gøre modellerne mere præcise. Ukendte funktioner skal fortsat stå som ukendte.

Jeg vil hellere have en model, der er dokumenteret inden for et afgrænset område, end en simulator, der foregiver at kunne efterligne alt.

En separat simulator undersøger økonomi og energistyring

Ved siden af InverterLab har jeg en anden simulator – et program, hvor jeg kan afprøve energiplaner uden at ændre det rigtige anlæg. Den beskæftiger sig ikke primært med inverterens interne adresser med måledata, men med økonomien og valget af energiplaner. Her kan jeg afprøve forskellige måder at bruge batteriet på, bilopladning og situationer, hvor husets el-faser belastes forskelligt.

Jeg har blandt andet gennemført årssimuleringer adskilt fra det rigtige anlæg med udgangspunkt i 2025. Her sammenlignede jeg forskellige batteristrategier med antagelser om 10 og 20 procent batteritab. Formålet var at undersøge, hvordan økonomien påvirkes af elpriser, tab, forbrug og forskellige ladeplaner.

Hvor historiske oplysninger ikke var tilstrækkelige, anvendte jeg beregnede mønstre for, hvornår og hvor meget strøm der bruges. Det gør simuleringerne velegnede til at sammenligne scenarier, men det er ikke det samme som fuldstændige historiske målinger. Derudover skal jeg undgå at bruge kendskab til årets faktiske vejr som bevis for, hvad en prognosebaseret styring realistisk kunne have forudsagt.

En simulator kan vise muligheder. Den kan ikke i sig selv bevise fremtidige besparelser.

API-Butler – samler oplysninger og styrer anlægget

API-Butler er den centrale platform i min energistyring. Den samler målinger, beregner økonomi, udarbejder planer og håndterer godkendte automatiske handlinger. Det er vigtigt at forstå, at API-Butler ikke blot videresender kommandoer fra en AI.

De økonomiske beregninger og sikkerhedsregler ligger i almindelig software. API-Butler håndterer også udførelsen, afslutningen og oprydningen efter midlertidige styringshandlinger. På den måde er ansvaret samlet ét sted.

Én beregning – flere måder at forstå den på

En vigtig forbedring har været at sikre en fælles beregning af planen og dens økonomi. Jeg ønsker ikke, at webappen, mobilappen og AI'en hver især beregner deres egen version af virkeligheden. Derfor skal de anvende de samme centrale oplysninger.

API-Butler samler målingerne og udfører beregningerne. Solprognosen bidrager med forventet produktion, mens Ladeanalyse, elpriser og forbrugsdata hjælper med at vurdere behovet. Systemet sammenligner ekstra batteriopladning med normal drift.

Det tager højde for den samlede købspris inklusive afgifter og betaling for at bruge elnettet, batteritab, slid, forventet solproduktion, husforbrug og anlæggets begrænsninger. En billig nattetime er derfor ikke automatisk et argument for at oplade batteriet. Den nuværende batteriautomatik kræver mindst én krones beregnet fordel efter tab og slid ved både 10 og 20 procent antaget batteritab.

Disse tabsprocenter er beregningsforudsætninger, ikke to fysisk målte egenskaber ved mit batteri. Det er vigtigt, fordi jeg ikke ønsker at ændre antagelserne, blot fordi én simulering viser et attraktivt resultat.

Energi Agent – overblik og forklaringer på web og mobil

Energi Agent er min side i browseren, hvor jeg følger systemet. Her skal jeg kunne følge solproduktionen, husforbruget, batteriniveauet, elpriserne og den forventede udvikling. Men jeg vil også kunne forstå de planer, som API-Butler beregner.

Hvis systemet eksempelvis vurderer, at det kan betale sig at oplade batteriet fra elnettet, skal jeg kunne se hvorfor. Jeg skal kunne se det tidsrum, hvor opladningen er planlagt, hvor meget ekstra energi der planlægges købt, og hvad den økonomiske fordel forventes at være. Og hvis en plan ændrer sig, skal det fremgå, hvad den tidligere plan var, og hvorfor den blev ændret.

Også på mobilen

Jeg udvikler samtidig en mobilvenlig webapp, der kan åbnes fra telefonens hjemmeskærm. Den skal anvende samme datagrundlag som hovedsiden. Det betyder, at jeg ikke har tre forskellige systemer, der forsøger at beregne den samme energiplan.

Jeg har én fælles beregning, som præsenteres på forskellige måder.

AI'en skal kunne forklare – ikke selv styre inverteren

Gennem AI-Hub arbejder jeg med at knytte kunstig intelligens til energisystemet. Her skal AI'en hjælpe med at forstå og efterprøve oplysningerne. Hvorfor blev en bestemt batteriplan valgt?

Hvorfor blev den blokeret? Hvad ændrede sig i solprognosen eller elpriserne? Og viser målingerne, at en planlagt opladning faktisk fandt sted?

Det er spørgsmål, hvor kunstig intelligens kan være nyttig. Men den kunstige intelligens har ikke fri kontrol over inverteren. Selve styringen ligger i API-Butlers almindelige software med faste sikkerhedsregler.

Jeg skelner mellem fire trin: Systemet har beregnet en plan; udstyret har svaret på en besked; inverterens indstilling er læst tilbage og bekræftet; og målingerne viser, at opladningen faktisk sker. Et svar fra udstyret er altså ikke i sig selv bevis for opladning.

En god AI-forklaring er ikke det samme som et bevis for, at noget fysisk er sket.

En vigtig milepæl: Automatisk opladning af det rigtige husbatteri

Jeg har også nået konkrete resultater på det fysiske energianlæg. Under et normalt automatisk forløb blev ladeindstillingen bekræftet på inverteren, og målingerne viste, at husbatteriet fik strøm fra elnettet. Bagefter fjernede systemet de midlertidige ladeindstillinger efter sine sikkerhedsregler. Det er det, jeg kalder oprydning.

Det var en væsentlig milepæl. Men forløbet afslørede også en fejl i mine daværende regler for, hvilken opladning der skal have forrang.

Da bilens forbrug stoppede batteriopladningen for tidligt

Systemets log over udførte handlinger viste, at husbatteriets ladeperiode blev afsluttet før tid. En regel tog strømforbrug fra ladestanderen som bevis for, at bilens batteri blev opladet. Men bilen kan også bruge strøm til eksempelvis forvarmning.

Jeg kunne ikke med sikkerhed fastslå, hvad bilen anvendte strømmen til i det konkrete historiske forløb. Derimod kunne jeg konstatere, at reglen var for grov. Derfor blev den ændret.

Nu kræver en tidlig afslutning også nye oplysninger fra bilens officielle tjeneste, som både bekræfter opladning og viser strøm til opladningen. Forvarmning eller andet strømforbrug, hvis formål jeg ikke kender, må ikke alene afslutte en allerede planlagt ladeperiode for husbatteriet. Rettelsen er afprøvet med 44 beståede test uden forbindelse til det fysiske udstyr, inklusive eksisterende sikkerhedstest, og installeret med backup.

Elbil, sol og husbatteri skal arbejde sammen

Det handler ikke kun om at finde den billigste time til bilen. Når jeg sætter ladekablet i, er målet, at systemet automatisk beregner en ladeplan ud fra bilens senest gyldige oplysninger, dens manglende opladning og det tidspunkt, hvor den skal være klar. Elpriser, forventet sol, husets forbrug og den tilgængelige ladeeffekt skal indgå i samme beregning. Planen skal kunne ændres, hvis forudsætningerne ændrer sig.

Bilen skal have den strøm, den behøver, samtidig med at der er plads til resten af huset. Hvis madlavning eller andre apparater belaster en af husets tre el-faser hårdt, skal bilens ladestrøm kunne sænkes. Når der igen er plads, kan den hæves efter de aftalte regler. Lavere ladeeffekt kræver en ny plan, som viser den opladning, bilen eventuelt stadig mangler ved afgang.

På solrige dage skal beregningen også kunne vælge mellem strøm fra solcellerne, elnettet eller en kombination. Det er ikke altid bedst at vente på solen, hvis bilen skal bruges tidligere. Omvendt kan det være fordelagtigt at lægge opladningen, når der forventes overskydende sol. Det skal afgøres ud fra data og økonomi frem for et fast klokkeslæt.

Husbatteriet indgår i det samme samspil. Det kan være en fordel at bruge lagret strøm, men det kan også være bedre at gemme den til dyrere timer og købe bilens strøm direkte fra nettet. Beregningen skal medregne batteriets tab og slid, så strøm fra batteriet ikke behandles som gratis. At holde strømmen tilbage er en mulig strategi, som kræver særskilt afprøvning og godkendelse af den fysiske styring; det er ikke en funktion, jeg her påstår er aktiveret.

Jeg vil heller ikke have, at husbatteriet begynder at lade fra nettet oven i bilens opladning med fuld styrke. Husbatteriets ladevindue skal i stedet tilpasses bilens faktiske opladning og den ledige kapacitet. Når bilen er færdig, kan husbatteriet få plads, hvis der stadig er et rentabelt vindue. Et resterende bilbehov efter afgang skal fortsat vises, men må ikke i sig selv spærre husbatteriets plan.

API-Butler står for beregninger og godkendt styring. Energi Agent skal gøre det let at se, hvad der er planlagt, hvad der eventuelt spærrer, og hvad målingerne faktisk bekræfter. Samspillet er afprøvet i de virtuelle forløb nedenfor; det betyder ikke, at alle de beskrevne muligheder er i drift på det rigtige anlæg.

Jeg har testet samspillet i energistyringssimulatoren. Den virkelige bilstyring er fortsat slået fra. De virtuelle forsøg beviser derfor ikke, at den rigtige ladestander er blevet reguleret.

Friske data er ikke nødvendigvis samtidige data

Når jeg samler oplysninger fra flere forskellige energikilder, opstår endnu en udfordring. Målingerne kan være indsamlet på forskellige tidspunkter. Min lokale aflæsningsenhed kan levere én måling, inverterens tjeneste på nettet en anden og husets elmåler en tredje.

Selvom API-Butler samler dem i samme svar, betyder det ikke automatisk, at de beskriver præcis samme øjeblik. Derfor arbejder jeg med at vise måletidspunkter og tydeligt markere gamle oplysninger. Jeg gemmer også de senest indsamlede oplysninger ét fælles sted, kaldet fællescachen, så flere sider kan bruge de samme målinger.

Det begrænser unødvendige forespørgsler til producenternes tjenester. Samtidig kan energiflowet opdateres uafhængigt af de tungere økonomiske beregninger.

De fejl, jeg finder, er en del af fremskridtet

Noget af det mest interessante ved projektet er, hvordan arbejdet hele tiden udvikler sig. I begyndelsen handler det om at få kommunikation og målinger til at fungere. Men når det lykkes, kommer de sværere spørgsmål.

Er værdierne korrekte? Er målingerne fra tidspunkter, der kan sammenlignes? Kan jeg stole på simulatorens svar?

Hvorfor blev en plan ændret? Og kan jeg dokumentere, at en fysisk handling havde den ønskede virkning? Arbejdet med InverterLab viser værdien af denne tilgang.

Jeg fjernede ikke programmets kontrol af, at det taler med den forventede enhed, for at få testen til at bestå. Jeg rettede simulatoren, så den svarede korrekt. På samme måde har erfaringerne fra energistyringen vist, at løsningen på en forkert beslutning ikke altid er at tilføje endnu en undtagelse.

Nogle gange er det bedre at fjerne en upræcis regel og erstatte den med en mere dokumenterbar betingelse. Det giver både enklere software og større mulighed for at forstå, hvad systemet faktisk gør.

Hvad er næste skridt?

Jeg vil fortsat dokumentere donglens målekvalitet og afprøve den lokale ændring af indstillinger, som er planlagt til næste opdatering. Godkendelse, bekræftelse og sikker fjernelse af midlertidige indstillinger skal følge med. En besked med ukendt resultat må ikke blot gentages. InverterLab skal også udbygges med flere dokumenterede svar, registerfunktioner og fejlsituationer.

Energistyringssimulatoren skal fortsat anvendes til at undersøge økonomi og strategier under forskellige antagelser. Jeg skal også arbejde videre med at dokumentere den faktiske virkning af automatiske handlinger og sikre, at planer og forklaringer bygger på det samme datagrundlag. Samtidig skal Energi Agent og mobilappen blive mere overskuelige, så systemets beslutninger bliver lettere at forstå.

Projektet er bygget til mit eget anlæg og mine behov. Jeg udvikler og tilpasser det løbende ud fra de erfaringer, jeg får i den daglige drift. Det er mit personlige udviklingsprojekt, ikke en løsning lavet til andre.

På længere sigt vil jeg kunne inddrage flere af mine energienheder i samme platform. Nye muligheder skal undersøges og dokumenteres på mit eget anlæg, før jeg tager dem i brug.

Jeg bygger mere end en side med målinger

Projektet begyndte med ønsket om at forstå og kommunikere bedre med mit eget energianlæg. Nu er det blevet en samlet udviklingsplatform med udstyr til at læse oplysninger, virtuelle testanlæg, økonomiske beregninger, web- og mobilsider og automatisk energistyring. InverterLab gør det muligt at afprøve min firmwarekode mod en virtuel inverter.

Energistyringssimulatoren hjælper mig med at undersøge økonomiske strategier og komplekse driftssituationer. API-Butler samler data, beregner planerne og håndterer de godkendte handlinger på det rigtige anlæg. Energi Agent viser mig, hvad der foregår.

Og AI-Hub giver mulighed for at bruge kunstig intelligens til at forklare og efterprøve resultaterne. Jeg har dokumenteret både vellykkede kommunikationstests, gennemførte simuleringer og et fysisk automatisk batteriladeforløb. Men jeg har også fundet fejl og mangler, som har ført til konkrete forbedringer.

Det er netop pointen.

Intelligent energistyring handler ikke kun om at beregne den rigtige handling. Det handler om at forstå beslutningen, udføre den sikkert og bagefter kunne dokumentere, hvad der faktisk skete.

Det er dét system, jeg bygger.

Carsten Howard

API-Butler · Energi Agent · InverterLab · AI-Hub

Bygget med nysgerrighed og teknologi.