Finne døgnets X billigste eller dyreste timer, en mulig løsning

[tmars]

Har søkt rundt etter dette tidligere, men aldri funnet en grei løsning. Hatt litt ledig tid nå, så tittet litt i message stream i dataene fra energy guard (publiseres hver hele klokketime). Ser at følgende data publiseres:

{
“serv”: “energy_price”,
“type”: “evt.energy_price.report”,
“val_t”: “object”,
“val”: {
“price”: 121,
“from”: “2023-12-01T00:00:00+01:00”,
“to”: “2023-12-01T01:00:00+01:00”,
“currency”: “NOK”,
“scale”: 100,
“energy_unit”: “kWh”,
“percentile”: 21,
“average”: 178,
“classification”: “low”
},
“props”: null,
“tags”: null,
“src”: “energy_guard”,
“ver”: “1”,
“uid”: “7cdf574a-3bb6-4c7d-94f2-63c46d9dbb7b”,
“topic”: “pt:j1/mt:evt/rt:app/rn:energy_guard/ad:1”
}

Her ligger jo “percentile”!!!

Så, ved en vanlig strømprisautomasjon hentes pris ($.price) og snitt ($.average):

Har nå lagt til percentil ($.percentile), og deretter regnet om slik at jeg får en variabel, N_cheapest, som er et tall mellom 1 og 24. 1 er døgnets billigste time, og 24 er døgnets dyreste time. Dersom du ønsker å la noe være på i de X billigste timer brukes da følgende kriterie:

appliance ON if N_cheapest<X+1

Jeg har ikke brukt dette lenge, så vet ikke hvordan det virker. Men jeg skjønner ikke hvorfor det ikke skal virke!

Første transform setter lokal variabel “percentile”. Andre transform gjør om til time (med desimaler), og lagrer til en midlertidig, lokal variabel “temp3”. Tredje transform fjerner desimaler (temp3-temp3%1) og legger til 1, slik at du får den N billigste timen. Denne lagres i global variabel “N_cheapest”.

Det er fortsatt et problem at man ikke “ser” over til neste døgn/natt, men får tenke mer på det senere. Innspill?

Flow:

[tmars]

Kan melde at dette fungerer utmerket. Forresten kan man jo selvfølgelig bare bruke persentilen direkte, uten å gå omveien til en “N-billigste time”-variabel…

Har sett at det er to ting å være obs på:

1. Virker som rapportert energipris er rundet OPP til nærmeste hele øre. Så du kan få samme persentil rapportert to eller flere timer dersom det skiller mindre en ett øre på prisen (selv om prisen er ulik). For alle praktiske formål vil jo prisen være tilnærmet lik, så det er ikke så farlig…
2. For timen med lavest pris, altså “0-persentilen”, så rapporteres ingen verdi for “perscentile” fra evt.energy_price.report. Ergo så bør det legges til en error node etter første transform, slik at global variabel current_percentile settes til 0 når dette skjer.

En enkel flow blir da:

Persentil til N-billigste time følger:

…slik at:
De 5 billigste timer blir current_percentile<21
De 8 billigste timer blir current_percentile<34
osv

[Brommen]

Interessant. Blir imponert over kva du finn ut av.

Bruker no standard prisstyringen med x% over daglig snitt, men timeantall her kan variere veldig og ikkje alltid slå så heldig ut. tenker eg på sikt går over til å bruke denne. Flyttbare laster kan då vere av/senket dei x antall dyraste timane i døgnet, varmekabler og varmtvannstank ivertfall.
F.eks Skru av når percentile > 71 (av 6 dyraste timer), samt noko logikk at laster er av maks 3 sammenhengande timer eller noko slikt. Kanskje også med en kombinasjon av standard prisstyringen. Om det er flat pris denne dagen og kun er få % det er snakk om er det ikkje så mykje poeng å skru av laster.
Konemor blir svært lite begeistret når det kun er kaldt vatn i dusjen når eg har leika med varmtvann styringa igjen. Har for husfreden sin del laga en virtuell bryter ho kan skru på som overstyrer alle automasjonane mot varmtvannsbereder.

For elbillading er jo billigste timer i døgnet gull, men kan vere litt bingo når en først har info om neste døgn over midnatt. Blir gjerne å ha prisstyring for elbil i egen automasjon som en skrur av når en skal kjøre langt dagen etter.

Då var det bare å få tid å sett på dette