Gå til innhold
  • Bli medlem
Støtt hjemmeautomasjon.no!

Mitt forsøk på "Prediktiv reduksjon av strømbruk"


Anbefalte innlegg

Hei,

ville ikke kidnappe andre lignende tråder her inne så lager ny.

 

Utstyr jeg har;
AMS leser fra amsleser.no - modell POW-U.

Home Assistant på en gammel mini server/pc.

Termostater på z-wave, en mill ovn på wifi.

 

Fremtidig: 3kw vvb på heavy duty switch, elbil.

 

Planen er å følge Stigvi sitt oppsett man kan lese mer om her:

 

Jeg må begynne i det små slik som alle andre har gjort en gang. Amsleseren er på wifi og mqtt er satt opp.

MQTT broker installert under supervisor, mqtt konfigurasjonen installert under konfigurasjon. Data sendes til HA i JSON format.

{
    "data": {
        "P": 4509,
        "Q": 0,
        "PO": 0,
        "QO": 411,
        "I1": 12.52,
        "I2": 9.98,
        "I3": 12.38,
        "U1": 226.7,
        "U2": 0,
        "U3": 228
    }
}

 

 

Så til utfordringen, jeg må ha ut P: verdien. Har knotet litt, men tror jeg bommer på hvordan man skal bruke platform: mqtt og platform: template og når man skal bruke de. So beer with me.

 

- platform: mqtt
  name: amsleser_kwh
  state_topic: amsleser
  unit_of_measurement: "kw"
  value_template: "{{ value.json.data.P }}"

 

Lenke til kommentar
Del på andre sider

Jeg bruker dette:

image.png.0caaea636ac6f9cd30ec1f3712adc891.png

 

  - platform: mqtt
    name: Klepp Energi Spenning L1
    unit_of_measurement: V
    expire_after: 30
    state_topic: "power/meter/l1/voltage"
    value_template: "{{ value_json | float(0) | round(0) }}"
  
  - platform: mqtt
    name: Klepp Energi Spenning L2
    unit_of_measurement: V
    expire_after: 30
    state_topic: "power/meter/l2/voltage"
    value_template: "{{ value_json | float(0) | round(0) }}"

  - platform: mqtt
    name: Klepp Energi Spenning L3
    unit_of_measurement: V
    expire_after: 30
    state_topic: "power/meter/l3/voltage"
    value_template: "{{ value_json | float(0) | round(0) }}"
  
  - platform: mqtt
    name: Klepp Energi Strøm L1
    unit_of_measurement: A
    expire_after: 30
    state_topic: "power/meter/l1/current"
    value_template: "{{ value_json | float(0) | round(1) }}"
  
  - platform: mqtt
    name: Klepp Energi Strøm L2
    unit_of_measurement: A
    expire_after: 30
    state_topic: "power/meter/l2/current"
    value_template: "{{ value_json | float(0) | round(1) }}"

  - platform: mqtt
    name: Klepp Energi Strøm L3
    unit_of_measurement: A
    expire_after: 30
    state_topic: "power/meter/l3/current"
    value_template: "{{ value_json | float(0) | round(1) }}"

  - platform: mqtt
    name: Klepp Energi Effekt
    unit_of_measurement: W
    expire_after: 10
    force_update: true
    state_topic: "power/meter/import/active"

  - platform: mqtt
    name: Klepp Energi Total Energi
    unit_of_measurement: kWh
    expire_after: 4000
    state_topic: "power/meter/import/active/accumulated"
    state_class: total_increasing
    device_class: energy

 

Lenke til kommentar
Del på andre sider

xibriz skrev (11 minutter siden):

Tok en kjapp kikk på dokumentasjonen: https://www.home-assistant.io/integrations/sensor.mqtt/ og https://www.home-assistant.io/docs/configuration/templating/#attributes

 

Og det ser ut som det skal være `value__json` og ikke  `value.json`.

 

Og der er verdien på plass 🙂 Takk!

 

Takk Stigvi!

Lenke til kommentar
Del på andre sider

Kopierte inn alt fra mqtt seksjonen over her, endra amsleser til raw(full) og ikke json.

 

Gikk videre med integrasjon- og derivasjonsdelen. Forventa  å kunne finne en sensor.integrert.effekt og sensor.derivert.effekt nå (i mangel på bedre ting å kalle disse), men det gjør jeg ikke.

Joda, de er der. And it continues. 🙂

 

- platform: mqtt
  name: BKK Effekt
  unit_of_measurement: W
  expire_after: 10
  force_update: true
  state_topic: "power/meter/import/active"

- platform: mqtt
  name: BKK Total Energi
  unit_of_measurement: kWh
  expire_after: 4000
  state_topic: "power/meter/import/active/accumulated"
  state_class: total_increasing
  device_class: energy

- platform: integration
  source: sensor.bkk_effekt
  name: Integrert effekt
  unit_prefix: k
  round: 2

- platform: derivative
  source: sensor.integrert_effekt
  name: Derivert effekt
  round: 1
  unit_time: "h"
  time_window: "00:05:00"

 

Stigvi har kommentert i flere tråder og fant tilfeldigvis hans formel og kode for estimert forbruk, så da blir det å legge til dette og forstå hva som skjer her.

Formelen er altså:
Estimert=Faktisk+derivert*(3600-sekunder ut i timen)/3600

 

- platform: template
  sensors:
    unique_id: estimert_timeforbruk_ufiltrert
    name: "estimert timeforbruk ufiltrert"
    unit_of_measurement: 'kWh'
    device_class: power
    state: "{{ (states('sensor.energy')|float(15)+states('sensor.real_time_consumption_gabriel_edlands_veg_16_integral_derivative')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"

  

 

Littegrann endring på koden fra originalt for at yaml skal bli fornøyd (håpes det).

Endret av hjemmedude
Lenke til kommentar
Del på andre sider

Har forsøkt legge denne til som template. Men kommer ikke videre. Klager på state: attributtet. 

 

- platform: template
  sensors:
    name: "estimert timeforbruk ufiltrert"
    unit_of_measurement: "kWh"
    device_class: power
    state: "{{ (states('sensor.energy')|float(15)+states('sensor.derivert_effekt')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"
 

 

Original klipp fra s. 7 Ny effekt-tariff. 

- unique_id: estimated_hourly_consumption_unfiltered
  name: "estimated_hourly_consumption_unfiltered"
  unit_of_measurement: 'kWh'
  device_class: power
  state: "{{ (states('sensor.energy')|float(15)+states('sensor.real_time_consumption_gabriel_edlands_veg_16_integral_derivative')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"      

 

Config checker:

Invalid config for [sensor.template]: expected dictionary for dictionary value @ data['sensors']['device_class']. Got 'power'
expected dictionary for dictionary value @ data['sensors']['name']. Got 'estimert timeforbruk ufiltrert'
expected dictionary for dictionary value @ data['sensors']['state']. Got "{{ (states('sensor.energy')|float(15)+states('sensor.derivert_effekt')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"
expected dictionary for dictionary value @ data['sensors']['unit_of_measurement']. Got 'kWh'. (See ?, line ?). 

 

Lenke til kommentar
Del på andre sider

Hva med dette:

 

- platform: template
  sensors:
    - name: "estimert timeforbruk ufiltrert"
      unit_of_measurement: "kWh"
      device_class: power
      state: "{{ (states('sensor.energy')|float(15)+states('sensor.derivert_effekt')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"



Altså, sjekk opp syntax. Et annet tips: HA har en helt ny måte å definere template sensorer på. I de gamle innleggene på forumet er det gjort på gamle måten. I dokumentasjon hos HA er det vist på nye måten.

 

template:
  - sensor:
    - unique_id: estimated_hourly_consumption_unfiltered
      name: "estimated_hourly_consumption_unfiltered"
      unit_of_measurement: 'kWh'
      device_class: power
      state: "{{ (states('sensor.energy')|float(15)+states('sensor.real_time_consumption_gabriel_edlands_veg_16_integral_derivative')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"

 

Lenke til kommentar
Del på andre sider

 

Første du sendte gir feil på - name: , fjerner - og indentering så gir den beskjed om feil indentering på resten. Ordner dette så gir den config checker feilmelding som nevnt over.

 

Forslag nr 2 klager studio code server på. I tillegg har jeg to ganger klart å ramme HA så hardt at den starter i safe mode, pga feil i .yaml koden. Dette er kun ved å skrive i studio code server og bytte fane internt. 😐 Tok ca 30 min før den var responsiv i safe mode igjen..

Lenke til kommentar
Del på andre sider

hjemmedude skrev (1 time siden):

Første du sendte gir feil på - name: , fjerner - og indentering så gir den beskjed om feil indentering på resten. Ordner dette så gir den config checker feilmelding som nevnt over.

Hvilken versjon av HA er det du har?

Lenke til kommentar
Del på andre sider

Tror frys av HA har med recorder å gjøre. Har ikke brukt dette aktivt, men ekskluderte automation og sensor for å se hvordan ting oppfører seg. Minne og cpu har skutt i taket før HA ikke responderer lenger, mange har hatt lignede problem ser jeg. 
 

Bytta ut state med value_template og resten av koden inne i bracketene er lik. Får da ut data som vises i lovelace. 
 

Men hvorfor state ikke fungerer vet jeg ikke

Lenke til kommentar
Del på andre sider

hjemmedude skrev (13 minutter siden):

Men hvorfor state ikke fungerer vet jeg ikke

state er den nye måten å definere det på og value_template den gamle. Anbefaler å skifte over til nytt format da de tar vekk støtte for det gamle i 2022 en gang.

Ellers er jeg selv en smule frustrert over dette. Det skaper arbeid med å endre konfigurasjonen og det fører til feil og misforståelser.

Lenke til kommentar
Del på andre sider

Ok, konverteringsarbeid en kveld det da 🙂 Takk for info!

Hvordan bør man angripe recorder, jeg tenker nå ekskluder alt og ta vare på det som er viktig. Og da tenker jeg en del av sensorene i bruk for for strømforbruket, men ikke allverdens mer.
Jeg bruker ikke grafana ennå men må kanskje se på det. Er vel bedre enn den innebygde.

Lenke til kommentar
Del på andre sider

  • 5 måneder senere...

Hei igjen,

straks er vvb koblet til heavy duty (tok sin tid å få fatt i denne) og straks er nettleia ny.

Så jeg må nesten fortsette der jeg slapp! Det var visual studio som knakk serveren min tidligere, ingen problem med HA siden sist (ingen endringer heller).

 

Jeg er kommet til PID-regulatoren, mener du @stigvi la ut koden din på forumet her i  kjetilsn tråd. Kunne jeg be "siste versjon" på denne? Evt burde jeg se på hacs integrasjonen for pid-regulator?

 

Jeg ønsker å redusere last på varmekabler i første omgang.

Underetasje (6 stk) + vvb

Overetasje (1 stk) + mill panelovn.

Har fastavtale på strømpris, så bryr meg ikke noe om variasjon ila døgnet.

 

Nettleien ser slik ut.

Vil forsøke å holde oss innenfor 2-5 kw, til vinteren 5-10 kw.

 

BKK fra 1. juli 2022.

 

 

Trinn

Kapasitetsledd inkl. mva

 

kW

Kr/mnd

Kr/år

Trinn 1

0-2

125

1500

Trinn 2

2-5

206

2475

Trinn 3

5-10

350

4200

Trinn 4

10-15

494

5925

Trinn 5

15-20

638

7650

Trinn 6

20-25

781

9375

 

Natt (2200 - 0600)

 

Energiledd øre/kWh
uten avgifter og mva

Energiledd øre/kWh
inkl. avgifter og mva

Dag

Natt og helg

Dag

Natt og helg

23,51

15,51

49,90

39,90

Lenke til kommentar
Del på andre sider

hjemmedude skrev (21 timer siden):

Kunne jeg be "siste versjon" på denne? Evt burde jeg se på hacs integrasjonen for pid-regulator?

Her er den. Merk at jeg har en VVB jeg kan sette effekten trinnløst på og det blir brukt i koden nedenfor. Så ta det som et eksempel. Du må gjøre endringer uansett.

Om pid regulatoren på hacs er brukbar, kan jeg ikke svare på. Men den er kanskje verd et forsøk?

Jeg har hatt min i drift i mai og maks forbruk da ble 4,823kWh som er bra. Som du ser så regulerer jeg etter 0,2kWh under 5kWh så 4,8kWh er målet. Den 15. mai ble all varme slått på i huset etter en ferie. Da ble det 10 timer sammenhengende regulering under 100% for å ligge under 4,8kWh. Litt svingninger ble det de første 40 minuttene, men deretter fungerte det veldig stabilt.

image.png.de99ebed3e2a00815df96c8f72cabaa9.png


I hele mai har det vært 4 tilfeller der regulatoren har gått ned til ca 0% og slått av all varme. Det er 2 biler som skal lades så jeg innser at 5kWh/h blir for vanskelig for meg når behovet for oppvarming øker. I mai har det vært lett. Hvis en ser vekk i fra 15. mai så ville jeg vært under grensen uten å gjøre noe som helst. Alle disse "dippene" en ser i kurven nedenfor er i starten på en time der det estimerte forbruket er mest usikkert. Jeg kunne unngått nesten alle av de hvis en ikke regulerte ned de første 5 minuttene på hver time. Så kanskje det blir neste endring - noe som setter settpunkt til 10kWh i starten på hver time. Samtidig er det heller ingen heft med at varmekablene settes på lav temperatur i noen minutter.......
image.png.39398df7f5c4cde1390fe68dbd816c4c.png

from simple_pid import PID

pid = PID(40.0, 0.4, 2500.0, setpoint=float(input_select.nettleie_pristrinn) - 0.2)
pid.set_auto_mode(False)
pid.sample_time = 1.9
pid.output_limits = (0, 100)
pid.proportional_on_measurement = False
pid.set_auto_mode(True, last_output=100.0)
last_c = 100.0
turned_off_all = False
turned_off_car = False

@state_trigger("sensor.energy")
def new_state():
    global pid
    global last_c
    global turned_off_all
    global turned_off_car
    
    c = (0.9 * last_c) + (0.1 * pid(float(sensor.estimated_hourly_consumption)))
    #p, i, d = pid.components
    #state.set("sensor.regulator_p", round(p,1))
    #state.set("sensor.regulator_i", round(i,1))
    #state.set("sensor.regulator_d", round(d,1))
    
    if round(last_c, 0) != round(c, 0):
        sensor.regulator_energy_usage = round(c, 0)
        
        v = max(5 * round(c, 0) - 400, 0.0)
        number.effekt_varmtvannsbereder.set_value(round(v,1))

    last_c = c

    if c < 10 and turned_off_car == False:
        easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "0")
        turned_off_car = True

    if c > 30 and turned_off_car == True:
        easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "16")
        turned_off_car = False

    if c < 2 and turned_off_all == False:
        esphome.terrassevarmer_pause()
        switch.heru_electric_heater_connected.turn_off()
        persistent_notification.create(title = "Strøm", message = "Effektbegrensing slo av alt.")

        turned_off_all = True
    
    if c > 5 and turned_off_all == True:
        esphome.terrassevarmer_resume()
        switch.heru_electric_heater_connected.turn_on()
        turned_off_all = False
    
@state_trigger("input_select.nettleie_pristrinn")
def setpoint(value=None):
    pid.setpoint = float(value) - 0.2

@state_trigger("input_number.consumption_lasthour")
def hourly_usage(value=None):
    if float(value) >= float(input_select.nettleie_pristrinn):
        script.turn_on(entity_id = "script.send_melding", variables = {'message': 'Strømforbruk var større enn grense', 'title': 'Strøm', 'channel': 'Info'})

 

  • Like 2
Lenke til kommentar
Del på andre sider

Nedenfor er målingene som netteier har på 15. mai. 4,82kW er det høyeste og det ligger 0,02kW over det jeg regulerer etter. Årsaken til at jeg endte opp med 4,8kW er at jeg i en testperiode i fjor så at jeg kunne komme over grensen hvis jeg gikk inn for det og skrudde på koketopp på maks når det var nesten slutt på en time. Da nyttet det ikke å slå av alle varmekabler. Men nå lemper de litt på kravet og det er snittet av maks forbruk på 3 forskjellige dager som skal gjelde. Da går det kanskje å legge seg enda nærmere grensen på 5kW så mulig jeg øker det til 4,9kW istedenfor 4,8kW.
image.png.d786f12e7788cedcd061998583dce0e6.png

Endret av stigvi
  • Like 2
Lenke til kommentar
Del på andre sider

Litt fremgang, appdaemon og schedy installert. Har fått på plass noen småting som nattsenking og om vi har gjester styres temperatur på rommet litt ulikt, fungerer overraskende bra.

Jeg må ha på plass noe borte-regler før jeg hopper på PID-en og finner ut hvordan den sender informasjon til schedy. 🙂

 

  • Like 1
Lenke til kommentar
Del på andre sider

hjemmedude skrev (39 minutter siden):

Litt fremgang, appdaemon og schedy installert. Har fått på plass noen småting som nattsenking og om vi har gjester styres temperatur på rommet litt ulikt, fungerer overraskende bra.

Jeg må ha på plass noe borte-regler før jeg hopper på PID-en og finner ut hvordan den sender informasjon til schedy. 🙂

 

Hvis du har lagt inn appdaemon så passer det nok bedre å kjøre pid regulatoren der enn i pyscript.

Lenke til kommentar
Del på andre sider

Ja prøver det :)

 

Noen som bruker schedy og som kan hjelpe litt? Har et ventilasjonsaggregat i en climate.flexit sensor.

Integrasjonen bruker preset_modes:

preset_modes:
  - home
  - away
  - boost
  - Boost Temporary
  - Fireplace

 

Jeg leser i schedy dokumentasjon at man bare kan bruke hvac_mode i thermostat (https://hass-apps.readthedocs.io/en/stable/apps/schedy/actors/thermostat/index.html ), så jeg lurer på hvordan kalle preset_mode: 'away'

Kjører nå en automasjon på siden av Schedy ( i HA)  som sjekker input.select.varme_modus == Borte og setter preset_mode. Funker jo, men ikke akkurat sånn jeg vil ha det 🙂

 

Lenke til kommentar
Del på andre sider

@stigvi, jeg gikk i gang med å skamløst kopiere pyscript-koden din over, men har ikke lagt inn terskelverdier for å slå av forbrukere ennå. Ser umiddelbart at PID-regulatoren kommer til å reagere litt vel hardt for min smak, og tipper det er på grunn av verdien for derivatleddet. Alle kontrollerbare laster kommer til å slå seg av hver gang VVB slår inn (hopp på 3 kW). Hvordan gikk du fram for å stille inn gains til PID-regulatoren din? Tror jeg kommer til å gå for en mykere PI-regulator (uten D-ledd). Husker du har en SSR-løsning til din VVB, så du får nok styrt det mer trinnløst enn meg.

 

Liker heller ikke hoppene i estimert timesforbruk fra Tibber når man trekker mye strøm akkurat i timeskiftet, så jeg legger også på en lineært økende glattekonstant av estimatet de første 15 minuttene hver time. Da får jeg en nokså myk overgang i estimert timesforbruk mellom hver time.

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.

×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.