Ønsker å dele en enkel fremgangsmåte for å estimere effektforbruket innenfor en klokketime. Har sett mange forumposter både her og på facebookforumet at mange lager regler som:
trigger han meter
→ if power_han>x [W]
→ skru av/ned apparat/varmekilde N
Dette fungerer helt sikkert greit, men det er jo helt unødvendig å bli “knocked out” av korte effekttopper, når de oppstår.
En bedre kontroll/estimat for timeseffekten er å ta påløpt forbruk inneværende time, pluss nåværende forbruk multiplisert med gjenværende tid av timen. Om man vil gjøre det hakket mer avansert kan man også lage en glidende middelverdi for effekten siste x minutter i stedet for nåværende momentanforbruk. Men lar den ligge nå.
Dette er åpenbart ikke noe nytt, men her følger en mulig implementering:
Trigger 1:
Trigger er Tibber Pulse som rapporterer effekt (evt.meter.report) hvert fjerde sekund. Bruker videre en rate limiter på 10s, og dytter momentaneffekten inn i global variabel power_han.
Trigger 2:
Trigger er også Tibber Pulse, men nå den utvidede rapporten, evt.meter_ext.report, som rapporteres hvert 20. sekund. Denne trenger vi fordi den rapporterer akkumulert energi for dagen, som vi trenger for å gjøre kalkulering for påløpt forbruk inneværende time. Energirapport som gir totalt påløpt forbruk for måleren vil også fungere (dersom den rapporteres med nok desimaler).
NB! Noen av nodene her er kun for å pynte de globale variablene til å ha maksimalt 3 desimaler.
Node2, ta ut brukt energi for døgnet:
Node3, maks tre desimaler, og skriv til energy_day:
Node4, finn forbrukt energi for timen ved å trekke fra energy_hour_start:
Node5, maks tre desimaler og dytt til energy_hour_consumed:
Node6, finn nåværende minutt i timen:
Node7, prediker forbruk som energy_hour_consumed+(power_han/1000)*((60-current_min)/60):
Node8, maks 3 desimaler, skriv til energy_hour_estimated:
Variablene som brukes er da (her lagres de fleste i minnet):
…
…
…
…
Trigger 3:
Nå trenger vi å nullstille variabel energy_hour_start hver time. Bruk time trigger med 0 * * * * og noen sekunders delay. Delay er for å la den andre triggeren hente data på riktig side av timen, spesielt ved midnatt er det kritisk. Tibber pulse rapporterer evt.meter_ext.report ved minuttstart, så her må man bare se hva som blir OK.
Node 3 dytter da energy_day fra den andre triggeren inn i en variabel energy_hour_start.
.
Sånn, da har vi estimatet. Dette bruker jeg da i en annen flow, som har kontroll over forbruksenheter. Denne kjører annenhvert minutt. Et kriterie for action kan da være:
Her bruker jeg grense på 9.8kWh/h. Videre gjør jeg ingenting før det har påløpt litt forbruk, ingen vits å styre på rett etter klokka hel. Dette kommer nok an på hvor mye forbruk du har kontroll på også. Har du god kontroll kan du vente litt. Det siste kriterie er fordi det er Easee som i utgangspunktet kjører lastbalansering (via Tibber), så ønsker ikke å gjøre noe med mindre den har strupet en god del ned.
For optimal ytelse krever systemet videre en logikk for å skru på igjen forbruksenheter. Selv har jeg andre flows som styrer all oppvarming og VVB etter strømpris, og som kjører hvert minutt over hel.