stigvi

ottob skrev (15 minutter siden):

Definisjon gjennomsnittelige maksforbruket
Jeg er ny her på forumet og har kikket litt rundt. Har planlagt og lage en strømstyrings boks. En ting jeg lurer på med dette gjennomsnittelige maksforbruket pr time, er om det faktisk er målt over en klokketime, feks mellom 09:00 og 10:00.
Eller om det er rullerende time. Dvs, en ny time starter feks hvert minutt.   Dvs, et moving average som det gjerne kalles.
Har ikke sett noen definisjon på dette.

Istedenfor å kalle det gjennomsnittlig maksforbruk pr time så er det like greit å kalle det for hva det er, energi i løpet av en time (kWh/h) og det måles i en hel klokketime. Måleren sender inn tellerstanden hver hele klokketime til netteier.

Finn først ut om du vil bruke deconz, zha eller zigbee2mqtt. Deretter kan en finne ut hvilken zigbee dings en må kjøpe

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.



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



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






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

mroek skrev (8 minutter siden):

Det som er merkelig, er at sensoren noen ganger kan bli "hengende" i feil tilstand.

Dette er nok en svakhet med Aqara sensoren som ikke får med seg alt. Men den vil hente seg inn igjen. Det kan justeres i zigbee oppsettet for sensoren, men mener at standardverdien er at den skal sende status hver time og da vil korrekt verdi bli sendt. Mulig du kan løse dette med en kondensator i parallell med reed kontakten.........
 

Tjakabov skrev (10 minutter siden):

Tenkte på support som i støtte for deres API i fremtiden

Etter at du har kjøpt det så vil jo utstyret stå uforandret hos deg. Integrasjonen mellom Home Assistant og Nobø sin hub ligger på github og blir vedlikehold av noen her.

Det som kan skje er at Nobø går konk og det blir umulig å få erstattet en termostat eller ovn. Men en kan ikke bekymre seg for alt som kan skje.........

Prizm78 skrev (1 time siden):

Så den dagen, med det høyeste snittet (over 24 timer)) er den som danner grunnlaget prisingen av  leddet for resten av måneden.

Nå er det opp til hver netteier og hvordan det er hos deg der du bor er ikke godt for meg å vite. Men mange netteiere har gått for en modell der den timen i løpet av en måned med størst forbruk setter prisen. De bruker ikke snitt over 24 timer.

Hvilken netteier er det der du bor?

Tjakabov skrev (10 minutter siden):

usikker på om Nobø har abo kostnader

Nei, det har de ikke

Tjakabov skrev (11 minutter siden):

stor usikkerhet mtp fremtidig support

Det er en ovn eller termostat - hvor mye support trenger en?

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.

Moskus skrev (23 minutter siden):

@stigvi vil sikkert anbefale Nobø til kabler og panelovner, og jeg er tilbøyelig til å være enig (iallfall hvis du ikke skal smartifisere resten av hytta). Et astrour kan man jo alltids få installert utenom.

 

 

Nobø sitt system er slikt som bare virker uten dilldall. Og en har mulighet til å integrere det i et smarthus senere hvis en vil det. De har dokumentert hub sitt api og en integrasjon er laget til Home Assistant. Tilgang i så fall er lokal slik at en ikke er avhengig av internett. Nobø har en app og den krever at Nobø hub i hus er på internett hvis du skal fjernstyre varmen. Men er mobiltelefon på samme wifi-nett som hub, vil det gå på lokalt nett.

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.

xibriz skrev (2 timer siden):

 

Her om dagen så var alle garasjeportåpnerene ute på tur å jeg kom meg ikke inn i garasjen  Jeg presenterer versjon 3 av garasjeportåpneren.

 

 

En NodeMCU, ett relè og to DHT22 for temperatur og fukt.

 

 

Fuktighet på 13 og 18% er jo spesielt. Er det din egen skala du bruker?

mroek skrev (12 minutter siden):

Elektroimportøren hevder at Aqara-dingsene er Zigbee 3.0 sertifisert.

De nye fra Aqara er sertifiserte. De eldre fra Aqara fungere helt fint. De eldre enn det igjen er litt umulige, men fungerer allikevel.

aarpi3 skrev (12 minutter siden):

Hva er beste måten å overvåke temperaturen til en dum vvb? Smart implant med ds18b20 godt isolert mot varmtvannsrøret?

Nei, det er ikke beste metoden. Jeg måler temperatur oppe og nede i tanken og klarer ikke med de to å si så mye om tilstanden. Temperaturen oppe synker ikke pga av vannforbruk, men kun pga varmetap. Du kan ikke bruke den til noe annet enn å måle at nå er det helt tomt for varmtvann og da er det for sent. Den nede påvirkes i veldig stor grad av vannforbruk, men den sier lite om hvor skillet mellom kaldt og varmt vann er. Det ideelle ville vært en måler ca midt på tanken. Det er vanskelig å få til, men høyest opp i luken der termostaten sitter vil nok gi deg mest nyttig info.

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.

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?

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.

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)

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?

Trådstarter kunne jo vært litt mer informativ og fortalt hva en ønsker å oppnå. I utgangspunktet klarer jo varmtvannstanken å styre seg selv.

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


Utgangen gikk ned til ca 40% for så å stige igjen


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.

Det blir jo en økt fare. Men dersom du en gang i uka sjekker stikkontakt, støpsel og fjernstyrt bryter for misfarging pga av varme så er du rimelig trygg. Det er ikke slik at dette plutselig en dag sier poff. Varmgang pga stor strøm til VVB er noe som vanligvis utvikler seg over lang tid og de aller fleste sjekker ikke tilstand på noe som gjerne står stuet vekk innerst under trappa eller noe annet ufremkommelig sted.

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

Her står det litt om legionella: Behandlingsmetoder - FHI

Dusjhodet har stort sett optimal temperatur hele tiden. Men det er sjelden en hører om bekymringer ang. dette. På meg virker det som om massemedia har klart å skape et aldri så lite hysteri når det gjelder VVB 🙄

Tn37 skrev (10 minutter siden):

Jeg ser for meg at jeg vil stille inn bryter slik at vvb er avskrudd omtrent mellom kl 0800-1000 og kl 1500-1700. Vil dette da kunne skape noe fare for legionella? Hvor mange timer kan en vvb stå utkoblet for å unngå fare? Gitt at temperaturen er satt vanlig i utgangspunktet.

Definitivt ingen fare for legionella. Temperaturen synker omtrent 0,4 grader i timen hvis du ikke tapper vann av den. Fra 70 til 45 grader kan den stå strømløs i ca 60 timer. 45 grader er fortsatt varmt nok til en dusj.

rhesusminus skrev (21 minutter siden):

F.eks. er den en største "ukjente" hos meg komfyren. Den trekker mye effekt og jeg vil helst kunne bruke den akkurat når jeg vil og smarthuset skal håndtere det.

Jeg løser det med at jeg sikter meg inn på 4,8kWh istedenfor 5. Da kan jeg bruke 2kW ekstra de siste 5 minutt uten å komme over grensen og systemet mitt bruker omtrent den tiden på å få slått av alt annet.

rhesusminus skrev (1 time siden):

Det er vanskelig å vite hva strømforbruket vil bli i løpet av neste time

Det er ikke så vanskelig og det blir også lettere og lettere etterhvert som timen nærmer seg slutten.

Klokken 10:35 er estimatet 1,78kWh og timen som sluttet kl 10 var på 1,75kWh. Men en vet jo ikke hva som skjer. Plutselig settes bilen på lading og forstyrrer.