Gå til innhold
  • Bli medlem

Prediktiv reduksjon av strømbruk - Effektariff nivå


kjetilsn
 Del

Anbefalte innlegg

Henger ikke regulatorene etter? 

 

Det er snakk om effekt tariff og ikke energi. Dvs bikker du over 5kW en eneste gang den måneden har du ny tariff.

 

Så hvis du bruker 10kW i en halvtime og deretter 0kW har du brukt 5kWh, men du har da gått over til ny effekt tariff på 10kW. 

 

Så det vil si, hvis vvb er på, du lager middag, og noen plugger på elbilen får du en peak på 12kW i 2 minutter og du er over på ny effekt tariff. 

Lenke til kommentar
Del på andre sider

Kim123 skrev (39 minutter siden):

Det er snakk om effekt tariff og ikke energi. Dvs bikker du over 5kW en eneste gang den måneden har du ny tariff.

 

Så hvis du bruker 10kW i en halvtime og deretter 0kW har du brukt 5kWh, men du har da gått over til ny effekt tariff på 10kW. 


Nei, den dataen har ikke netteier tilgang på. De får data hver hele klokketime og eneste data de kan bruke til dette er differansen i målerstand mellom hver rapportering (altså kWh på 1 time). Strømmåleren logger/sender ikke peak effekt. 

  • Like 2
Lenke til kommentar
Del på andre sider

Har testet litt med å endre på innstillingene for PID regulatoren da det er ganske stor treghet i mitt system, som førte til overkompensering. De fem nivåene for pådrag regulerer opp og ned settpunktemperatur på forskjellige termostater for forskjellige rom som igjen har forskjellig effekt, som gjerne allerede er av, så dette blir uansett aldri helt perfekt. På natta er det varmtvannstanken som er den store lasten, den går av om pådraget er under 2. elbil lader rusler og går på 6A uavhengig, den skal også styres av PID etter hvert. 

 

Første innstillinger (direkte fra stigvi sin konfigurasjon):

pid = PID(40.0, 1.0, 1600.0, setpoint=float(input_number.effekt_target)-0.15)

 

image.thumb.png.20eaaf7f4dbd9b539c12edefdd76f117.png

 

Nye innstillinger:

Redusert P og I, lagt D til 1 (lurer på det tilsvarer av eller D da skal stå til 0) Den største endringen skjedde ved redusering av I til 0.1.

pid = PID(20.0, 0.1, 1.0, setpoint=float(input_number.effekt_target)-0.15)

 

image.thumb.png.ad6b13c6fc11e619300bebc70c67384f.png

 

Er fornøyd med resultatet så langt, da det blir mindre av og på av laster, og det ser ut som den treffer målet ganske så bra.

Har også endre derivative sensor og satt time window ned fra 5 til 1 min. for å få den raskere, det fører til at den fort overskyter i starte av timen, men ser ut som at det går bra grunnet "treghet" som er lagt til i PID?..

 

Slik er da sensorer nå:

## Styring av effekt bassert på forbuk mot tariff ""


    ## integrere kWh fra AMS
  - platform: integration
    source: sensor.ams_forbruk
    name: AMS fastupdate
    unit_prefix: k
    round: 2

    ## Derivere fra kWh 
  - platform: derivative
    source: sensor.ams_fastupdate
    time_window: "00:01:00"

    ## Forutsi timesforbruk bassert på derivert og faktisk forbruk 
  - platform: template
    sensors:
      estimated_fast_hourly_consumption_unfiltered:
        unit_of_measurement: 'kWh'
        device_class: power
        value_template: "{{ (states('sensor.ams_fast_update_meter')|float(15)+states('sensor.sensor_ams_fastupdate_derivative')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"
        
    ## Filtrere vekk støy fra time overgang  
  - platform: filter
    name: "estimated_fast_hourly_consumption_filtered"
    entity_id: sensor.estimated_fast_hourly_consumption_unfiltered
    filters:
      - filter: outlier
        window_size: 4
        radius: 0.25
      - filter: lowpass
        time_constant: 10
        precision: 3

    ## Nivåer bassert på PID output 
  - platform: template
    sensors:
      energy_regulator_usage_step:
        friendly_name: 'Energy regulator usage step'
        icon_template: mdi:power-standby
        value_template: >-
          {%if states.sensor.regulator_energy_usage.state | float<=10 %}1
          {% elif states.sensor.regulator_energy_usage.state | float<=30 | float>10 %}2
          {% elif states.sensor.regulator_energy_usage.state | float<=60 | float>30 %}3
          {% elif states.sensor.regulator_energy_usage.state | float<=80 | float>60 %}4
          {% elif states.sensor.regulator_energy_usage.state | float<=100 | float>80 %}5
          {%- endif %}

 

Og her er da døgnforbruk med scriptet til stigvi i bruk vs uten:

 

image.thumb.png.4196f6cdcc9171effcee5ca2c1112f85.png

 

image.thumb.png.0c5ffc1fa76ad7897062308333ff0e11.png

  • Like 1
Lenke til kommentar
Del på andre sider

stigvi skrev (På 18.11.2021 den 9.56):

Jeg har kuttet ut Tibber Pulse. Den hadde for mange utfall og da ble det umulig å holde seg under en kwh grense. Nå bruker jeg en enkel esp32 dings som kjører amstomqttbridge. Du finner tråder her på forumet om denne.

Nå har tibber vært nede hos meg i 1,5 time med "internal server error" så da må en kanskje vurdere å gå for en løsning du har! 

Lenke til kommentar
Del på andre sider

Jeg har laget til litt grunnlag for å justere effektforbruk, jeg regner ut hvor mye "ledig" effekt jeg har resten av timen uten å bryte grensen for høyeste time.
Tenkt brukt for å styre elbil-lader, til å "gi på" om det er ledig effekt...
Screenshot_20211123-185626_Teams.jpg

Sent fra min SM-G991B via Tapatalk

Lenke til kommentar
Del på andre sider

kjetilsn skrev (På 23.11.2021 den 8.48):

Redusert P og I, lagt D til 1 (lurer på det tilsvarer av eller D da skal stå til 0) Den største endringen skjedde ved redusering av I til 0.1.

Når du setter D til 1 så har du vel i praksis deaktivert denne. Tipper D-utgangen på regulatoren står på konstant null?
D vil motvirke raske endringer på utgangen, så jeg vil anbefale en høy nok verdi til at du ser at den bidrar. Den kan f.eks hindre at regulatoren øker pådraget så kraftig at forbruket passerer 5kwh for en kortere periode. Å redusere I og P vil gjøre regulatoren tregere, men du kan øke disse to og samtidig øke D for å hindre at det blir ustabilt.

  • Like 1
Lenke til kommentar
Del på andre sider

Hei stigvi,

 

Takk for tilbakemelding. Jeg skal forøke å øke D igjen for å få redusere raske endringer. Stemmer at denne har ligget til 0 siden endringene. Grunnen til endring var at jeg leste (wikipedia) at ofte var det ikke nødvendig med D funksjonen, derfor la jeg denne ned foreløpig for det da ble mindre å holde øye med under testing. Kan nok ha misforstått eller blandet med dempning ser jeg når jeg leser dette en gang til :)

Quote

Derivative term[edit]

320px-Change_with_Kd.png
 
Response of PV to step change of SP vs time, for three values of Kd (Kp and Ki held constant)

The derivative of the process error is calculated by determining the slope of the error over time and multiplying this rate of change by the derivative gain Kd. The magnitude of the contribution of the derivative term to the overall control action is termed the derivative gain, Kd.

The derivative term is given by

{\displaystyle D_{\text{out}}=K_{\text{d}}{\frac {de(t)}{dt}}.}{\displaystyle D_{\text{out}}=K_{\text{d}}{\frac {de(t)}{dt}}.}

Derivative action predicts system behavior and thus improves settling time and stability of the system.[17][18] An ideal derivative is not causal, so that implementations of PID controllers include an additional low-pass filtering for the derivative term to limit the high-frequency gain and noise. Derivative action is seldom used in practice though – by one estimate in only 25% of deployed controllers[citation needed] – because of its variable impact on system stability in real-world applications.

 

Ellers må jeg si at scriptet ditt fungerer jo som bare det, selv med ikke optimale innstillinger treffer det som regel meget bra.

 

Dette har motivert meg til å få integrert bedre min OpenEVSE i home assistant, slik at regulatoren kan sette laderstrømmen slik du har gjort på din lader. Legger ut konfigurasjonen  i en egen tråd i tilfelle noen andre her har eller kommer til å ha en OpenEVSE sammen med home assistant.

  • Like 1
Lenke til kommentar
Del på andre sider

Hei, er ny her.

 

PIDer etc er ikke min styrke for å si det mildt.

 

Har løst kapasitetsavgiftstrusselen på følgende måte - inntil videre med tall fra nettet som ikke er fra min netteier, men 'man tager hvad man haver':

 

Tibber med Pulse gir meg følgende realtidsverdier:

 

image.png.349fcacf67cad5be50317b73fd6b9c36.png

 

Venstre instrument er så å si direkte fra Tibber

  • {{ states.sensor.accumulated_consumption_current_hour_.....state | round(2) }}

mens høyre instrument beregner og viser forventet forbruk den pågående timen basert på historien av timen så langt - og ikke noe mer

  • {{ ((states.sensor.accumulated_consumption_current_hour_......state | float * 60) / (now().minute+1)) | round(2) }}

Når verdien til høyre overstiger 4.8 (for sikkerhets skyld styrer jeg mot 4.8 kWh/h, ikke 5) kutter jeg ut noen laster. Har ikke så mye som er lett å kutte, men så langt - noen få døgn - holdt det. Når verdien synker under 4.7 slår jeg lastene på igjen.

 

"(now().minute+1))" er jo 'å jukse litt' - jeg bytter litt unøyaktighet i beregningen mot at jeg ikke får delt-på-null-feil det første minutt i timen.

 

Jeg venter med på/av-prosedyren inntil den første kWh har blitt forbrukt fordi svært lavt forbruk (kWh) delt på svært kort tid (0..1 minutt) gir resultater i den første tiden som spriker lett i alle retninger. Når timen nærmer seg slutten viser begge instrumentene det samme.

Endret av elZorro
Hadde med feil bilde: før 1 kWh var inne
  • Like 1
Lenke til kommentar
Del på andre sider

elZorro skrev (6 minutter siden):

Når verdien til høyre overstiger 4.8 (for sikkerhets skyld styrer jeg mot 4.8 kWh/h, ikke 5) kutter jeg ut noen laster (har ikke så mye som er lett å kutte), men så langt - noen få døgn - holdt det. Når verdien synker under 4.7 slår jeg lastene på igjen.

Dette er egentlig en P-regulator. Etterhvert tror jeg du vil få mer og mer lyst på integrasjondelen også 😉 Og det er ikke veldig vanskelig. Du kan løse det med en template sensor i tillegg til det du har eller bare utvide den du har.

 

elZorro skrev (14 minutter siden):

Jeg venter med på/av-prosedyren inntil den første kWh har blitt forbrukt fordi svært lavt forbruk (kWh) delt på svært kort tid (0..1 minutt) gir resultater i den første tiden som spriker lett i alle retninger. Når timen nærmer seg slutten viser begge instrumentene det samme.

Et godt tips. Vurdere noe av det samme, enten som dette eller at andre parametre endrer seg avhengig av hvor langt i timen en er kommet.

  • Like 1
Lenke til kommentar
Del på andre sider

kjetilsn skrev (23 timer siden):

Jeg skal forøke å øke D igjen for å få redusere raske endringer

Her er eksempel på det jeg prøver å oppnå. Klokken 11 var det timeskifte og mitt forbruk som lå på ca 5.5kW gjorde som forventet at forbruk økte umiddelbart i den nye timen.

image.png.bd3b648b61a16370a516df7bf56bd18f.png

Men allerede en god stund før forbruket mitt passerer min grense så regulerer pid regulatoren ned til et pådrag på 75%

image.png.017644365b0185cc677ef5be8d883790.png

Så jeg unngår at forbruket kommer langt over 100%. Dette er med en D = 2500

Her er kurver med samme tidsakse. Blir litt lettere å se hva som skjer da


image.png.f5c45704b1a1023c4633f823fa5eeac2.png

image.png.aed2d91c703023dc8f3e046b75c9dded.png

Det sentrale her er altså rett etter kl 11 der regulatoren går ned til 75% før forbruket har nådd 100%

  • Like 2
Lenke til kommentar
Del på andre sider

hjemmedude skrev (51 minutter siden):

Jeg har ikke bayesian sensor for varmekabler. Disse putrer og går på normaltemperatur hele døgnet minus to som er på nattsenking..

Trenger jeg bayesian eller et oppsett for prioritering av varmekilder for at pid-regulatoren/alt skal fungere?

Nei, helt klart ikke. Du må bare kunne slå de av / på alt etter om regulatoren er over eller under en grense som du setter. Løses lett med automasjon i HA eller du kan bruke samme skript som kjører regulatoren.

Edit: Men du bør prioritere de og slå de av/på en etter en. Regulatoren får en stor jobb hvis du slår av / på alle på en gang, men det skal i prinsippet virke det også.

Endret av stigvi
Lenke til kommentar
Del på andre sider

Kan anbefale å sjekke ut Schedy for styring av varmekildene, kan enkelt brukes sammen med scriptet til stigvi.

Har brukt det selv i lang tid for nattesenking, senking ved dyr strøm, etc. støtter også vindu/dør sensor som direkte kan slå av varme i det tilhørende rommet etc.

Her er et par eksempler:

 

  rooms:

    living:
      actors:
        climate.stue:
      schedule:
      - v: 20
        rules:
          - rules:
            - x: "Add(-10) if state('sensor.energy_regulator_usage_step') < '5' else Next()"
            - x: "Add(-1) if is_on ('input_boolean.energy_cost_high') else Next()"
            - x: "Add(-5) if is_on ('input_boolean.varmt_ute') else Next()"
            - x: "Add(-10) if is_on ('input_boolean.ferie') else Next()"
          - rules:
            - x: "Next() if state('input_boolean.fri') == 'off' else Break()"  
            - { start: "14:00", end: "22:00", weekdays: 1-4 }
            - { start: "14:00", end: "23:00", weekdays: 5 }
            - { start: "08:00", end: "23:00", weekdays: 6 }
            - { start: "08:00", end: "23:00", weekdays: 7 }
            - { v: 19 }

          - rules:
            - x: "Next() if state('input_boolean.fri') == 'on' else Break()"  
            - { start: "06:00", end: "22:00", weekdays: 1-4 }
            - { start: "06:00", end: "23:00", weekdays: 5 }
            - { start: "08:00", end: "23:00", weekdays: 6 }
            - { start: "08:00", end: "23:00", weekdays: 7 }
            - { v: 19 }
    
              
    Bad:
      actors:
        climate.bad:
      schedule:
       - x: "Add(-10) if state('sensor.energy_regulator_usage_step') < '9' else Next()"
       - x: "Add(-1) if is_on ('input_boolean.energy_cost_high') else Next()"
       - x: "Add(-4) if is_on ('input_boolean.ferie') else Next()"       
       - { v: 24, start: "23:00", end: "06:00", weekdays: 1-4 }
       - { v: 24, start: "23:00", end: "06:00", weekdays: 5 }
       - { v: 24, start: "23:00", end: "06:00", weekdays: 6 }
       - { v: 24, start: "23:00", end: "06:00", weekdays: 7 }
       - { v: 22 }

 

Lenke til kommentar
Del på andre sider

Ok takk - skal sjekke ut schedy. Har ikke satt meg inn i appdaemon vs pyscript, så kikker på det også. :)

Vil den/de minst prioriterte varmekablene ha flest av/på ergo størst slitasje på bryter? Om det skal ha noe å si for levetid. En slags round-robin av termostater der man fordeler av/på belastningen hadde vært pent? :)

Lenke til kommentar
Del på andre sider

hjemmedude skrev (4 minutter siden):

Ok takk - skal sjekke ut schedy. Har ikke satt meg inn i appdaemon vs pyscript, så kikker på det også. :)

Vil den/de minst prioriterte varmekablene ha flest av/på ergo størst slitasje på bryter? Om det skal ha noe å si for levetid. En slags round-robin av termostater der man fordeler av/på belastningen hadde vært pent? :)

Du kan få mange av/på på varmekablene. Jeg har løst det med at det er null forsinkelse på å slå de av, men 5 minutt på å slå de på. 5 minutt er periodetid på mine termostater så da antar jeg at mitt system ikke sliter mer enn normal bruk.

  • Like 1
Lenke til kommentar
Del på andre sider

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

 Del

  • Lignende innhold

    • Av Kristian
      Har søkt og lest bl.a. på home assistant-forumet i ukesvis, men finner lite svar, så prøver en diskusjon her.
       
      Er i ferd med å migrere fra Indigo til Home Assistant og den største frustrasjonen så langt er rundt navngivning av devices, entiteter etc. Så søker råd og tips for evt. å gjøre det enklere.
       
      Først; Det jeg er vant til fra Indigo:
      Skal du legge til noe legger du manuelt til en ny device, uavhengig av plug-in etc. Deretter kan du koble devicen mot en plugin (tilsvarende integrasjon). Devicen har sin unike ID som aldri endres Navnet har ingenting å si annet enn for visning, ikke kobling mot automasjoner etc. Du kan legge til notes og sortere i "mapper" som kan være rom, soner eller type device f.eks. Det er ingenting som eksponeres tilsvarende entiteter, hver device har dette som attributter og kan ha flere states. Resultat;
      F.eks. å ekskludere og inkludere en z-wave-enhet betyr ingenting for automasjoner etc., du tar bare eksisterende device og syncer mot ny node En kan f.eks. bytte et lys fra Z-wave til hue uten at det påvirker device, script, automasjoner eller noen ting.  
      Så over til Home Assistant... Har fått over en del av Z-wave nettverket. Er nå oppe i 619 entiteter for Z-wave JS. Bruker zwaveJS2MQTT.
      Jeg skal komme mer i gang med automasjoner osv. Og har forstått det sånn at det er en dårlig deal å automatisere mot device. Må en parre en Z-wave enhet på nytt vil den få ny device ID og dermed fungerer ikke automasjoner. Så det må gjøres mot entitet. Og da bør jeg ta jobben med å angi fornuftige entitets-IDer. 
       
      Så begynner jeg på node 2. Dette er en Fibaro Dimmer 2 som har 21 entiteter. Den vil jeg skal hete "Kjøkken taklys". Så renamer device i UI og får spørsmål om å endre ID for alle entiteter, hvilket jeg takker ja til.
      Resultat:
      De to switch-entitetene har fått switch.kjokken_taklys og switch.kjokken_taklys_2 Mange har fått oppdatert friendly name men entitets ID er enten sensor.node_2_XX eller sensor.dimmer_2_XX Noen har ikke fått oppdatert friendly name  
      Så over til en Heatit Z-TRM2FX med 39 (!) entiteter. Der blir kaoset komplett når jeg forsøker å rename device, samme random mønster som over.
       
      Så leser jeg på HA-forumet og det virker som det er konsensus om at det skal være slik (?). Entity registry etc. er vel ikke mulig å bruke lenger? 
      Har forsøkt å søke etter script som kan gjøre det, men ikke funnet noe.
      Finner også masse issues på github, men de fleste ser ut til å bli sendt frem og tilbake mellom core, frontend, diverse integrasjoner etc.
       
      Er det virkelig ikke enklere måter å håndtere dette på, eller er det jeg som overser noe vitalt?
       
       
       
    • Av Toremick
      Har laget en mulighet for å integrere varmepumpen min direkte inn i home assistant via MQTT.
      https://github.com/toremick/shorai-esp32
       
      Sikkert kjekt for de som har varmepumpe av denne typen.
       
    • Av Offpiste
      Hei
       
      Noe av det jeg har:
       
      Home Assistant i Proxmox på Intel NUC.
       
      Lys:
      Fibaro dimmer 2
      Fibaro singel switch 2
      Fibaro double switch 2
      Fibaro wall plug
      Ikea Trådfri Adapter
      Ikea Trådfri pærer
      WLED
       
      Varme:
      Mill ovner
      Varmekabler - Elko
       
      Strømmåling:
      AMS-måler
      Shelly 
       
      Div sensorer fra :
      Netatmo
      Fibaro 
      Xiaomi mijia/Aqara/CGG1
       
       
       
       
       
    • Av Sleepy81
      Jeg har vært Homeseer bruker i litt over 10 år, og har vært fornøyd med det. 
      Ventet spent på HS4, men ser at utviklingen går ganske tregt, og utvalget i plugins tilgjengelig er nå dårligere enn for eksempel Home Assistant. 
       
      Har derfor testet Home Assistant litt, mest for å se på plugins foreløpig. Veldig fornøyd, selv om det er mer oppsett. 
       
      Har dog lest at Home Assistant sin Z-wave styring har vært ganske dårlig, så spent på hvordan det fungere i mitt oppsett med nesten 100 Z-wave enheter. 
       
      Så kommer spørsmålet mitt: Kan man plugge Z-sticken jeg har i HS3 maskinen rett i en Home assistent installasjonen, importere alle Z-wave devicene, og teste ut hvordan det fungerer? Og vil det gjøre noe med Z-wave devicene som ligger på Z-sticken slik at jeg får problemer hvis jeg ikke liker Home Assistant og vil plugge den tilbake i HS3 maskinen?
       
      Jeg antar svaret er at det går fint sånn jeg har skjønt Z-wave systemet, men aldri testet dette selv (de gangene jeg har byttet system før har jeg alltid startet fra scratch med Z-wave), så ville bare dobbeltsjekke før jeg kjører igang.
    • Av Auda
      Hei 
      Jeg har et system som består av både en server med hassio i en bocker kontainer samt en på raspberry pi. 
      Program for integrasjoner Zigbee Home Automation. 
       
      Jeg har ca 40 ikea enheter men er ikke fornøyd med stabiliteten til ikea's gateway, og har prøvd andre zigbee gateway'er. 
       
       
       
      Er det noen som har greid å parre ikea bryter så bruke bryteren til å videre parre andre enheter hvor de blir sett av ZHA? 
       
×
×
  • Opprett ny...