Predikere og begrense timeseffekten på en god måte, et forslag (og oppskrift)

Ø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.
Screenshot 2023-12-08 at 11.30.48

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:
Screenshot 2023-12-08 at 11.56.04

Node3, maks tre desimaler, og skriv til energy_day:
Screenshot 2023-12-08 at 11.57.06

Node4, finn forbrukt energi for timen ved å trekke fra energy_hour_start:
Screenshot 2023-12-08 at 11.57.19

Node5, maks tre desimaler og dytt til energy_hour_consumed:
Screenshot 2023-12-08 at 11.57.50

Node6, finn nåværende minutt i timen:
Screenshot 2023-12-08 at 11.58.02

Node7, prediker forbruk som energy_hour_consumed+(power_han/1000)*((60-current_min)/60):
Screenshot 2023-12-08 at 11.58.09

Node8, maks 3 desimaler, skriv til energy_hour_estimated:
Screenshot 2023-12-08 at 11.58.18

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.

Screenshot 2023-12-08 at 12.24.25
Node 3 dytter da energy_day fra den andre triggeren inn i en variabel energy_hour_start.
Screenshot 2023-12-08 at 12.26.44
.

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.

7 Likes

Hei

Satt opp denne i går og fungerer utmerket. Har tidligare forsøkt det samme på egenhånd uten suksess. Takker så mykje for at du deler dette :slight_smile:

Er et godt hjelpemiddel for å komme under ønsket effektledd i nettleie. Er her i tillegg avhengig av en gjennonsnittlig/glattet HAN effektverdi då eg har et ventilasjonsanlegg med voldsomme effektpeaks ca kvart 50 sekund. Enda opp med å bruke current second og lagre til fleire variabler og regne ut gjennomsnitt. Det virker men sikkert meir elegante måter å gjere det på.

Takker også for det du og jig delte om å opprette str_map for termostater, dette er også noko eg tidligare har forsøkt på og komt litt til kort. Dette blir det neste eg må få satt opp.

Har no mykje å leike meg med no, var bare å få tid til det :slight_smile:

1 Like

Hei, så bra at du fant dette nyttig!

Når det gjelder snittverdi fra HAN, finnes det garantert en mer elegant måte å gjøre det på enn det du viser, men slik du gjør det vil nok også gjøre jobben. Ved et kjapt øyekast ser det jo ut som du løste dette veldig fint. Tenkte i starten å laste inn i en array, men fikk det aldri til, sånn syntaksmessig. Mitt problem er også at jeg må glatte ut effekten på grunn av varmeelementet på ventilasjonen som slår 1800W på og av svært hyppig (på i 5-10 sek). Jeg endte opp med å bruke $.val.last_e_import og stoppeklokke, også finne snittforbruket i et tidsrom basert på den forbrukte energien. Oppdaterer hvert 20 sekund.

Jeg har forøvrig merket meg to problemer med denne oppskriften/flowen;

  1. Tibber playground-integrasjonen stopper. Dette skjer kanskje 1 gang pr 14 dager.
  2. Av en eller annen merkelig grunn har energiforbuket ved start av timen blitt helt feil (variabelen som lagres ved start av hver time). Dette fører da til at timeseffektestimatet kan bli veldig stort, eller negativt. Skjer ca like hyppig som punkt 1, så mistenker Tibber-integrasjonen, men aner egentlig ikke hvorfor dette skjer…

Ellers fungerer det veldig bra med termostatstyring mot strømpris ved å lese inn setpunkter til globale variable, også kjøre delta fra disse mot strømpriskriterier hver timesstart. Bare spør hvis du lurer på noe her.

1 Like

Hei

Ja forsøkte først med array eg også, men fann ikkje dokumentasjon eller eksempler og etter nokre forsøk gav eg opp då eg ikkje fann ut korleis en gjorde dette med syntaxen.
Eg trur eg etterkvart bruker måten du beskriver her med å bruke $.val.last_e_import frå tibber pulse, god input. blir både meir nøyaktig og mindre lastbruk for automasjonen sammenligna med slik eg har det no.

har ikkje lagt merke til problema som du beskriver, men så har eg heller ikkje brukt dette så lenge. Skal sei ifrå om eg ser noko der.

Fekk til å lese temperatur ut frå termostater og trekke frå legge til og lage ny strMap for å endre temperatur. knytta det mot elbillader og strømpris også. Det fungerer supert. Kona var ikkje heilt fornøgd med standardautomasjonane der vi måtte innom 4 automasjoner for å endre else statement om vi skulle endre termostattemperaturer :laughing:

Fekk også i drift et zigbee 24V rele så eg får styrt ventilasjonen. Omsider er alt det viktigaste på stell.