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

[hjemmedude]

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 }}"

 

[xibriz]

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`.

[stigvi]

Jeg bruker dette:



 

  - 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

 

[hjemmedude]

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!

[hjemmedude]

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 8. desember 2021 av hjemmedude

[stigvi]

En slik som dette er det lurt å ta med. Den nullstiller integrert effekt hver hele time

 

utility_meter:
  energy:
    source: sensor.sensor_klepp_energi_effekt_integral
    cycle: hourly

 

[hjemmedude]

Ja den er akkurat kopiert inn 🙂 Henter god inspo fra kjetilsn tråd også, så da blir det en slags driv!

[hjemmedude]

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 ?). 

 

[stigvi]

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) }}"

 

[hjemmedude]

 

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..

[stigvi]

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?

[hjemmedude]

HA Os 6.6

Core 2021.11.5

[hjemmedude]

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

[stigvi]

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.

[hjemmedude]

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.

[kjetilsn]

Hei,
Kan anbefale å kjøre en separat mysql eller mariadb på en maskin / docker med ssd disk, da kan du også her kjøre feks influxdb på samme maskinen om du vil bruke grafana.

[hjemmedude]

Takk for tips.

Ang frys av HA så er nok problemet Windows, VMware, Nextcloud, HomeAssistant som alle deler 4GB RAM. Det er vel det samme de fleste har på RPI4 🙂

Jeg er kommet til PID-regulatoren og kikker litt på det etterhvert. 🙂

 

[hjemmedude]

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

[stigvi]

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.




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.......

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'})

 

[stigvi]

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.

Endret 3. juni 2022 av stigvi

[hjemmedude]

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. 🙂

 

[stigvi]

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.

[hjemmedude]

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 🙂

 

[RVM]

@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.

[OlavT]

Styrer dere for å holde timesforbruket under x kWh for en gitt time eller for å holde effekten under x Watt til enhver tid?