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

Prediktiv reduksjon av strømbruk - Effektariff nivå


kjetilsn

Anbefalte innlegg

  

 

 

 

On 16/12/2020 at 17:13, stigvi said:

Jeg bruker ikke HomeSeer, men Home Assistant. Så jeg skal heller forklare på generelt vis hva jeg har gjort.

Forutsetningen er at en kan måle total effekt ofte (kort tid mellom målingene). Jeg bruker Tibber sin Pulse til dette. Og så må en ha strømforbrukere som en kan slå av og på uten at det forstyrrer for mye. Jeg bruker varmekabler og panelovner til dette, men også elbil.

Hele sulamitten er bygd opp rundt en PID-regulator. Les litt på Wikipedia for mer info om dette. Konkret har jeg brukt denne, simple-pid · PyPI

Den har en utgang som går fra 0 til 100% og 2 innganger. Den ene er maks forbruk en ikke ønsker å overskride. Hos meg er dette et input-felt jeg skriver en tallverdi i som f.eks 7kWh. Den andre inngangen er forventet forbruk i inneværende time. Denne er det som skaper utfordring. 

Jeg tar effekt fra Tibber Pulse som kommer hvert 2,5s og integrerer denne opp for å få Wh. Jeg bruker denne, Integration - Riemann sum integral - Home Assistant (home-assistant.io) til det.

Så deriverer jeg dette for å finne hvor fort integralet endrer seg for å få Wh/h. Jeg bruker denne, Derivative - Home Assistant (home-assistant.io) til det. Tidsvindu er satt til 5 min.

Dette jeg får etter derivasjonen tar jeg en andel av ut i fra hvor langt ut i en time en er kommet. Er jeg 30m ut i fra en hel time så deles denne på 2. Og så legger jeg til faktisk forbruk i denne timen. Faktisk forbruk starter på 0 hver hele time og teller oppover. Det kan komme i fra integrasjonen ovenfor.
Formelen er altså:
Estimert=Faktisk+derivert*(3600-sekunder ut i timen)/3600

Jeg opplevde av og til at estimert hoppet / gjorde for store byks ved timeskifte så jeg filtrerte dette igjen med et lavpassfilter som dette, Filter - Home Assistant (home-assistant.io). Parametre for dette er 

 

filters:
  - filter: outlier
    window_size: 4
    radius: 0.25
  - filter: lowpass
    time_constant: 3
    precision: 3


Da har jeg estimert timeforbruket som har den egenskapen at den blir mer og mer nøyaktig etterhvert som en kommer ut i timen. Det er fordi den mer og mer tar hensyn til faktisk forbruk.

Dette gis til PID regulatoren og denne har parametre som 

 

self.pid = PID(30, 0.3, 0.4, setpoint=float(self.get_state("input_number.max_energy_usage"))-0.1)
self.pid.sample_time = 2.0
self.pid.output_limits = (0, 100)
self.pid.proportional_on_measurement = False
self.pid.auto_mode = True



 

c = self.pid(float(self.get_state("sensor.estimated_hourly_consumption")))


Resultatet, c, er 0 til 100% og der har jeg brukt enkel logikk for å styre ovner og kabler. Er verdien over 90% så er alt på og i normal drift.

Er verdien mellom 80 og 90% så er varmekabel på vaskerom avslått, mens resten er på.
Så slås en og en varmekabel av for hver 10% verdien synker. På 30% slår jeg av en panelovn, på 20% enda en panelovn og til slutt, ved 10% settes elbil-lading på pause.

Grunnen til å starte med varmekabler først er at disse har minst konsekvens å slå av. Etter hvert som PID regulatoren finner ut at en må sette alle kluter til så skrus det som er mer synlig av, som varme i stue og elbil.

Å sette en grense for hver 10% passer greit hvis en har 10 strømforbukere av betydning. Har en ferre eller fler så deler en opp 0-100% sånn at en får en jevn reduksjon av effekt når regulatoren går fra 100 til 0.

I tillegg har jeg gjort en del andre ting, men dette påvirker ikke selve systemet som det er forklart her. Jeg har blant annet lagd det slik at varmekabler ikke slås av og på for ofte, men at det må minst gå 5 minutt mellom hver endring. Det er for å spare releene i termostatene. Panelovnene har ikke dette da de er triac styrt av termostat i ovn.

Og slik har jeg lagd UI.

 

Maks effekt er satt til 30kWh fordi jeg i praksis ikke har stort bruk for dette nå i og med at effekttariff er lagt på is av min netteier.
 

image.png

 

 

Hei @stigvi,

 

Dumt spørsmål:

 

Har lagt til integral og prediktiv sensorer som du beskriver over, lurer på hvordan du har satt det opp til å resette til 0 hver time. Kjører du en "automation" som setter den til 0 eller bruker du time_window funksjon? Har andre sensorer som er på timebase, døgn, osv. Men det er gjort relativt tungvint med å publisere til mqtt broker hver time for så å bruke en sensor som trekker fra.

 

## Rask kWh teller 

  - platform: integration
    source: sensor.ams_forbruk
    name: AMS fastupdate
    unit_prefix: k
    round: 2


  - platform: derivative
    source: sensor.ams_fastupdate
    time_window: "00:5:00"

 

Lenke til kommentar
Del på andre sider

Her er bil på lading og VVB påslått og da har PID regulator etterhvert havnet på 68% og to varmekabler i gulv avslått for å holde det under 4,8kWh denne timen.

Jeg fant ut jeg kunne liste opp hver av komponentene P, I og D og hvor mye de bidrar på utgangens 68%. Det gjør det mye lettere å "tune" den inn.

image.png.c4d621bec463bcb326b880c7bd39f71f.png

 

 

c = 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))

 

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

- platform: derivative
  source: sensor.sensor_klepp_energi_effekt_integral
  name: real_time_consumption_gabriel_edlands_veg_16_integral_derivative
  round: 3
  unit_time: h
  time_window: "00:02:30"


Jeg har mange varmekabler som slår seg av og på innenfor 5 minutters intervaller og derfor hadde jeg tidsvindu på denne satt til 5 minutt. Men det gir en tregere respons når en større forbruker slås på så her må du se hva som passer for deg. Jeg tester litt med kortere intervall og ser om det gir bedre resultat hos meg.

  • Like 1
Lenke til kommentar
Del på andre sider

Dette ser jo veldig bra ut.
Hadde egentlig tenkt å bare skru av diverse laster, for det meste varmekabler og panelovner, basert på hvor nærme for eksempel 5Kw jeg var kommet etter feks 30 minutter ut i timen, men etter litt fundering så skjønner jeg at det ikke er en god nok løsning. Takk for at du deler det du har gjort, det er en veldig fin løsning. Håpet er å klare meg innenfor trinn 1 (0-5Kw) mesteparten av året, ser at det gjerne blir vanskelig i jan, feb, og mars, men ikke umulig.

Lenke til kommentar
Del på andre sider

Takk for en fin gjennomgang, uten spesiell kunnskap om dette så tror jeg 60% er forstått og det er ikke gale. Leser at LEDE og BKK nå vil innføre nye modeller, publisert her;

https://www.europower-energi.no/forbruker/de-forste-tallene-er-klare-slik-blir-den-nye-nettleien/2-1-1098798

 

Nå har jeg ikke begynt å installere pluginene du linker til, men jeg antar at tibber pulse er et must? Og da også Tibber abo.?

Trengs det noe mer kode i bakgrunn som du ikke har lagt ut? Det er ingen unnskyldning for å være lat, men jeg setter stor pris på alt som kan legges inn raskt da timene her ikke strekker til. Selv om det er mye å be om, setter alltid stor pris på arbeid og hjelp som utføres her på forumet.  🙂

 

Litt om mitt oppsett;

VVB (3000w). Vurderer en Heavy Duty switch på denne.   https://www.hoiax.no/produkter/titanium-express-eco

Jeg har 7 varmekabler og 1 panelovn styrt med HA nå.

Luft-luft-varmpepumpe kjører på 23 gr hele døgnet.

Flexit balansert ventilasjon kjører 21 gr hele døgnet.
 

Lenke til kommentar
Del på andre sider

hjemmedude skrev (56 minutter siden):

Nå har jeg ikke begynt å installere pluginene du linker til, men jeg antar at tibber pulse er et must? Og da også Tibber abo.?

Trengs det noe mer kode i bakgrunn som du ikke har lagt ut? Det er ingen unnskyldning for å være lat, men jeg setter stor pris på alt som kan legges inn raskt da timene her ikke strekker til. Selv om det er mye å be om, setter alltid stor pris på arbeid og hjelp som utføres her på forumet. 

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.

Men så lenge du får ditt effektbruk inn i Home Assistant på faste 2,5s intervall så er det samme hva du bruker.

Det eneste jeg har brukt som ikke er standard med i Home Assistant er pyscript. Denne er lastet inn ved hjelp av HACS. Appdaemon kan også brukes.

Endret av stigvi
Lenke til kommentar
Del på andre sider

stigvi skrev (1 time siden):
- platform: derivative
  source: sensor.sensor_klepp_energi_effekt_integral
  name: real_time_consumption_gabriel_edlands_veg_16_integral_derivative
  round: 3
  unit_time: h
  time_window: "00:02:30"


Jeg har mange varmekabler som slår seg av og på innenfor 5 minutters intervaller og derfor hadde jeg tidsvindu på denne satt til 5 minutt. Men det gir en tregere respons når en større forbruker slås på så her må du se hva som passer for deg. Jeg tester litt med kortere intervall og ser om det gir bedre resultat hos meg.

Jeg var snar med å sette denne tilbake til 5 minutter. Når varmekablene slår seg av og på i 5 minutters intervaller så ender jeg opp med å ha et rolig og fint strømforbruk hvis jeg ser på snittet de siste 5 minutt. Men på kortere intervall går strømforbruket opp og ned som en jojo. Å prøve å estimere timesforbruket med et tidsvindu kortere enn 5 minutt ble håpløst for min del, men dere må jo se hva som passer best i deres hus. Jeg satte meg på en krakk ved siden av en termostat og tok tiden med stoppeklokke mellom klikkene i releet på termostaten. Total periodetid var på sekundet 5 minutt.

Lenke til kommentar
Del på andre sider

Da var PID på plass og skriptet ditt minus elbil og terassevarmer delen.

 

Kjører du  automasjoner for å skru av og på lastene basert på sensor.regulator_energy_usage eller har bruker du eget script til det?

Vurderer å sette opp en liten RGB pære en plass som kan gi Grøn/gul/rød type trafikklys basert på sensor.regulator_energy_usage for enkel indikator på hvor nær settpunkt en er kommet.

Lenke til kommentar
Del på andre sider

Jeg har et veldig spesielt system for å styre ovner som er basert på Home Assistant sine bayesian sensor. En bayesian sensor styrer en varmekabel eller panelovn og hver av disse sensorene har en drøss innganger som er relatert varmestyring. En av inngangene er om pid regulatoren er under en grenseverdi. Nedenfor er en slik og den slår av ovn når pid regulator er under 32%. Du må se hva du gjør i ditt system. Det fikses jo lett med noen automasjoner eller i skriptet som jeg har gjort for bil.

 

    - platform: bayesian
      name: 'Panelovner stue'
      prior: 0.35
      probability_threshold: 0.5
      observations:
        - platform: 'numeric_state'
          entity_id: 'sensor.regulator_energy_usage'
          prob_given_true: 0.001
          below: 32
        - entity_id: input_boolean.travel_enabled
          prob_given_true: 0.001
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.vindu_2_etg_a
          prob_given_true: 0.001
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.vindu_2_etg_b
          prob_given_true: 0.001
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.noen_er_hjemme
          prob_given_true: 0.7
          platform: 'state'
          to_state: 'on'
        - entity_id: input_boolean.sleeptime
          prob_given_true: 0.32
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.soonsleeptime
          prob_given_true: 0.32
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.preheat_day
          prob_given_true: 0.66
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.preheat_night_weekend
          prob_given_true: 0.64
          platform: 'state'
          to_state: 'on'
        - entity_id: binary_sensor.heatlimit_morning
          prob_given_true: 0.4
          platform: 'state'
          to_state: 'on'
        - entity_id: input_boolean.soonhome
          prob_given_true: 0.66
          platform: 'state'
          to_state: 'on'
        - entity_id: input_boolean.visitors_comfort_temp
          prob_given_true: 0.64
          platform: 'state'
          to_state: 'on'
        - entity_id: sensor.pricelevel
          prob_given_true: 0.48
          platform: 'state'
          to_state: 'EXPENSIVE'
        - entity_id: sensor.pricelevel
          prob_given_true: 0.3
          platform: 'state'
          to_state: 'VERY_EXPENSIVE'
        - entity_id: sensor.pricelevel
          prob_given_true: 0.3
          platform: 'state'
          to_state: 'EXTREMELY_EXPENSIVE'
        - entity_id: binary_sensor.preheat_night_home_office
          prob_given_true: 0.64
          platform: 'state'
          to_state: 'on'

 

Skriptet mitt ang pid regulator er pr i dag som dette:

 

from simple_pid import PID

pid = PID(40.0, 1.0, 1600.0, setpoint=float(input_number.max_energy_usage))
pid.sample_time = 1.9
pid.output_limits = (0, 100)
pid.proportional_on_measurement = False
pid.auto_mode = True
last_c = 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 = 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 last_c != c:
        sensor.regulator_energy_usage = int(c)  #, attributes = {"unit_of_measurement": "%", "friendly_name": "Pådrag varme"})

    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 > 12 and turned_off_car == True:
        easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "6")
        turned_off_car = False

    if c < 2 and turned_off_all == False:
        esphome.terrassevarmer_pause()
        esphome.varmtvannstank_pause()
        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()
        esphome.varmtvannstank_resume()
        turned_off_all = False
    
@state_trigger("input_number.max_energy_usage")
def setpoint(value=None):
    pid.setpoint = float(value)

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

 

  • Like 1
Lenke til kommentar
Del på andre sider

Husker nå at jeg har lest en tidligere post fra deg ang disse bayesian sensorene. Er nå på listen over ting jeg må studere nermere:)

Bruker for det meste heatit termostater her, også på noen panelovner der termostaten styrer et zwave rele direkte. Bruker så schedy i appdaemon for å senke og heve temp settpunkt basert på tidspunkt, ute temp, og strømpris. Tenker jeg prøver med dette først, da med å redusere en grad på termostatene en etter et basert på PID nivå.

Igjen, takk for at du deler! 

Lenke til kommentar
Del på andre sider

Foreløpig løsning:

 

Template sensor som deler opp i fem nivåer:

    ## 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<=20 %}1
          {% elif states.sensor.regulator_energy_usage.state | float<=40 | float>20 %}2
          {% elif states.sensor.regulator_energy_usage.state | float<=60 | float>40 %}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 %}

 

Så Endringer i Schedy:

 

  watched_entities:
  - sensor.energy_regulator_usage_step
  - input_boolean.fri
  - input_boolean.varmt_ute
  - input_boolean.ferie
  - input_boolean.energy_cost_high

  rooms:
    living:
      actors:
        climate.stue:
      schedule:
      - v: 20
        rules:
          - rules:
            - x: "Add(-6) if state ('sensor.energy_regulator_usage_step') < '3' 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 }

 

 

image.png.3901589c48b732eb4d641f0440e26500.png

 

Ser foreløpig bra ut. Skal legge til varmtvannstank og elbil etterhvert, har jo en måned på å teste.

  • Like 1
Lenke til kommentar
Del på andre sider

Jeg jobber litt mer med å få timeskifte til å fungere bedre. Problemet oppstår når en har hatt et lite forbruk helt til slutten av timen og ligger langt under grensen. Så settes på en stor forbruker. Fram mot timeslutt vil forbruket ikke passere grensen, men akkurat i det en kommer inn i ny time så vil estimert forbruk gjøre et hopp oppover. Og da gjelder det å begrense utgangen på pid-regulatoren så den ikke går rett ned på null. Jeg løser det med et lavpassfilter på estimert forbruk og pr i dag ser det slik ut.

 

- platform: filter
  name: "estimated_hourly_consumption"
  entity_id: sensor.estimated_hourly_consumption_unfiltered
  filters:
    - filter: outlier
      window_size: 4
      radius: 0.25
    - filter: lowpass
      time_constant: 10
      precision: 3



At det virker ser en på denne kurven der estimert forbruk øker sakte fra 0900 til 0901
image.thumb.png.faade70d1ce734f1c44c0942c0f64fb7.png

Utgangen gikk ned til ca 40% for så å stige igjen
image.png.6e914423a18d8f3cbdab7323f5b87590.png

Kanskje er det lurt med et filter på utgangen også? Det ser jeg på etterhvert, i så fall. Men jeg ser også at nå bruker pid-regulatoren omtrent 1-2 minutt på å redusere forbruket og det er helt ok. Dette var i starten på en time og da vil estimert forbruk fluktuere en del, men samtidig har en god tid på å regulere seg inn. I slutten av timen vil estimert forbruk være mer stabil og dermed blir utgangen på pid-regulatoren også mer stabil.

Lenke til kommentar
Del på andre sider

Ja, jeg vil svært gjerne ha en tabell som inneholder dette og neste døgns strømpriser sånn at jeg kan kutte ut å hente dette fra Nordpool.

Men de to du nevner er et bra tiltak. Hva med klokkeslett og dato som en attributt på den siste av de to?

  • Like 1
Lenke til kommentar
Del på andre sider

stigvi skrev (5 timer siden):

Kanskje er det lurt med et filter på utgangen også? Det ser jeg på etterhvert, i så fall.

Det hjalp veldig å lavpassfiltrere regulatorutgangen: 

 

c = (0.9 * last_c) + (0.1 * pid(float(sensor.estimated_hourly_consumption)))



Og så har jeg endret dette fra å konvertere til int til heller å bruke round for å få en bedre avrunding.

 

if round(last_c, 0) != round(c, 0):
    sensor.regulator_energy_usage = round(c, 0)

 

  • Like 1
Lenke til kommentar
Del på andre sider

stigvi skrev (9 timer siden):

Ja, jeg vil svært gjerne ha en tabell som inneholder dette og neste døgns strømpriser sånn at jeg kan kutte ut å hente dette fra Nordpool.
 


Om du ønsker det som attributes, så skjer nok ikke det.

Bruker ikke du mye python til dine automasjoner?
Da har du tilgang til alle prisene: https://github.com/Danielhiversen/home_assistant_tibber_custom/blob/main/custom_components/tibber_custom/camera.py#L20

  • Like 1
Lenke til kommentar
Del på andre sider

daniel.h.iversen skrev (26 minutter siden):


Om du ønsker det som attributes, så skjer nok ikke det.

Bruker ikke du mye python til dine automasjoner?
Da har du tilgang til alle prisene: https://github.com/Danielhiversen/home_assistant_tibber_custom/blob/main/custom_components/tibber_custom/camera.py#L20

Jeg har hele tiden siden sist dette ble diskutert (for ca 1 år siden, kanskje) tenkt at jeg burde lagd en integrasjon som tilgjengeliggjør disse prisene. Integrasjonen kunne vært lagt inn i HACS. Men jeg har ikke noe utviklingsmiljø satt opp for Home Assistant og det er begrenset hvor mye jeg vil fikle med den som styrer huset. Så det ender opp med noe ala dørstokkmila, jeg kommer ikke i gang med å sette opp et miljø fordi det er så mye annet jeg også skal ha tid til.

Lenke til kommentar
Del på andre sider

Hei stigvi,

 

Set at scriptet logger til logbook. Har prøvd å ekskludere "sensor_ams_fast_update_meter" men hjelper ikke.
Finner ikke noe i scriptet som kaller på logbook funksjonen, så det er litt merkelig. Ser du det samme?

 

file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.41
12:29:34 - 4 seconds ago
file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.40
12:29:24 - 14 seconds ago
file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.39
12:29:13 - 24 seconds ago
file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.38
12:29:06 - 32 seconds ago
file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.37
12:28:56 - 42 seconds ago
file_effektariff_new_state has been triggered by state change sensor.ams_fast_update_meter == 1.36

 

Lenke til kommentar
Del på andre sider

Jeg ekskluderer de i exclude seksjonen til recorder

 

recorder:
  db_url: mysql://xxxxx:[email protected]/homeassistant?charset=utf8
  purge_keep_days: 60
  exclude:
    event_types:
      - call_service
      - pyscript_running
    domains:
      - media_player
    entities:
      - sensor.klepp_energi_effekt
      - sensor.real_time_consumption_gabriel_edlands_veg_16kw
      - sensor.sensor_klepp_energi_effekt_integral
      - sensor.energy
      - sensor.real_time_consumption_gabriel_edlands_veg_16_integral_derivative
      - sensor.estimated_hourly_consumption
      - sensor.estimated_hourly_consumption_unfiltered
osv

 



Edit: Kanskje det er pyscript_running du må ekskludere?

Endret av stigvi
Lenke til kommentar
Del på andre sider

Mange takk stigvi,

 

Det var 

      - pyscript_running

som skulle til.

 

Valgte å teste nå med å skru av vvs i stedet for elbil om natta så får vi se hvordan det går utover uken. Lader med kun 12A og tanken er på 2Kw så det blir nok ikke lange perioder der tanken skrues av. Vurderer å lage til noe for å senke temp på varmepumpa også, kanskje en ESP home med ir? Men så har jeg forstått at varmpumper er mest effektiv om de får lov til å stå på en temperatur. Blir litt prøving og feiling fremover:)

 

# VVS av om morgen
- alias: Varmtvann av
  trigger:
    platform: time
    at: 08:00:00
  action:
    service: switch.turn_off
    entity_id: switch.vvs
  id: 2f2b26a9d0244258a0d09b93c7016b47

  # VVS på om temp under 4 grader
- alias: Varmtvann på under 40c
  trigger:
    platform: numeric_state
    entity_id: sensor.varmtvann_temp_temperature
    below: '40'
  action:
    service: switch.turn_on
    entity_id: switch.vvs
  id: a09951c6a043492e87507faa6eab44b8


# VVS av ved effektregulator nivå 1
- alias: Varmtvann av effektregulator
  trigger:
    platform: numeric_state
    entity_id: sensor.energy_regulator_usage_step
    below: '2'
  condition:
    condition: state
    entity_id: switch.vvs
    state: 'on'
  action:
    service: switch.turn_off
    entity_id: switch.vvs
  id: 2f2b26a9d0244258a0d09b93c7016b46

# VVS på ved effektregulator nivå over 1 og tidsvindu
- alias: Varmtvann på effektregulator og tid
  trigger:
    platform: numeric_state
    entity_id: sensor.energy_regulator_usage_step
    above: '1'
  condition:
    condition: and
    conditions:
    - condition: state
      entity_id: switch.vvs
      state: 'off'
    - condition: time
      after: '00:23:00'
      before: '08:00:00'
  action:
    service: switch.turn_on
    entity_id: switch.vvs
  id: 2f2b26a9d0244258a0d09b93c7016b45
  • Like 1
Lenke til kommentar
Del på andre sider

kjetilsn skrev (21 minutter siden):

Blir litt prøving og feiling fremover:)

Så lenge det er morsomt og ikke et ork er jo prøving og feiling helt ok. Jeg synes selv det er morsomt å perfeksjonere systemet, men samtidig er jeg bevisst på at det kommer til å ha svakheter. Men den store testen blir jo om forbruket klarer å holde seg under 5kWh pr time i desember og januar.

Jeg har foreldre på besøk denne helgen og har av den grunn skrudd opp varmen i hele huset. Med 5kWh som grense har en maks 120kWh tilgjengelig pr døgn. I går var forbruket hos meg 100kWh og innimellom var det lading av bil, oppvarming av vann og middagslaging. Ikke en eneste gang var jeg der at nå ryker jeg over 5kWh.

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

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