kjetilsn

Den trigger på endringer, så når attributt "hvac_action" forsvinner grunnet oppdatering fra hass så kjører den og pusher tilbake denne attributten. 

Hei,

Endelig har mine TF016 termostater tilstandsinfo i climate entity:

For å få "heating" og "idle" kommer fra attribute "hvac_action". Fant et script som setter attribute basert på andre entities:

https://community.home-assistant.io/t/how-to-manually-set-state-value-of-sensor/43975/2

Automasjon som setter input_boolean bassert på releets tistand fra number entity: 

(grunnen til at jeg ikke bruker number entity direkte i neste automasjon er at den veksler mellom '0' som er av, '99' som jeg ikke hvet hva betyr, og '255' som betyr på.)

## Stue 
- alias: Ovens on stue
  trigger:
    entity_id: number.stue_basic
    platform: numeric_state
    above: '200'
  action:
    service: input_boolean.turn_on
    target:
      entity_id: input_boolean.heating_stue
  id: b2481b651f2d4e22a53dbf787ba61dd9

- alias: Ovens off stue
  trigger:
    entity_id: number.stue_basic
    platform: numeric_state
    below: '10'
  action:
    service: input_boolean.turn_off
    target:
      entity_id: input_boolean.heating_stue
  id: f1f928cac90a4573878d5344a0de716f

Og så automasjon som setter attribute ved hjelp av scriptet:

## Heating_stue
- id: set attribute thermostat stue
  alias: 'set attribute thermostat stue'
  trigger:
    platform: state
    entity_id:
      - climate.stue
      - input_boolean.heating_stue
  condition:
    condition: template
    value_template: >-
      {% if state_attr('climate.stue', 'hvac_action') == none %}
         true
      {% elif "input_boolean" in trigger.entity_id %}
         true
      {% else %}
         false
      {% endif %}

  action:
    service: python_script.set_state
    data_template:
      entity_id: 'climate.stue'
      hvac_action: >- 
        {% if is_state('input_boolean.heating_stue', 'on') %}heating{% else %}idle{% endif %}

Hei,

Noen som bruker TF016 termostatene med FW1.92 og zwavejs integrasjonen her?

Jeg endte med å gå tilbake til FW1.8 på disse da det var en dårlig kombo med ozwave integrasjonen. Vurdere å flashe en av de til FW1.92 for å teste.

Utålmodig som jeg er så postet jeg samme spørsmålet på Home Assistant forumet, og som det ofte er så viste det seg at dette er enklere en først antatt.

Viser seg at det blir generert en disablet number entity for hver climate entity. denne enity korresponderer med 'Basic set' og gir info som trengs direkte.

https://community.home-assistant.io/t/zwavejs-automation-trigger-on-node-event/376267

Så da er alt i orden.

Det hadde vert veldig kjekt å få denne tilstandsinformasjonen inn i climate entity slik at den kan rapportere 'heating' og 'idle' samt endre farge bassert på tilstand slik som andre termostater som faktisk rapportere dette tilbake eller for eksempel generic thermostat gjør. Noen som vet hvordan dette kan gjøres? Første tanke er å modifisere zwave config fil i zwavejs.

Hei,

Da var tiden inne for zwavejs

Siden jeg kjører Home Assistant i docker gikk jeg for zwavejs2mqtt docker installasjon. Deaktivert MQTT delen og snakker med home assistant over Z-Wave JS websocket server.

Har prøvd å lytte etter "zwave_js_notification", "zwave_js_value_notification" og " zwave_js_value_updated" gjennom "devtools" -> "Events" uten å få noe som helst.

Har sjekket i logge til zwave2mqtt at info blir motatt:

2022-01-06T19:37:52.574Z DRIVER « [Node 005] [REQ] [ApplicationCommand]
                                  └─[BasicCCSet]
                                      target value: 0
2022-01-06T19:37:52.577Z CNTRLR   [Node 005] treating BasicCC::Set as a report
2022-01-06T19:37:52.577Z CNTRLR   [Node 005] [~] [Basic] currentValue: 255 => 0                     [Endpoint 0]


2022-01-06T19:37:07.831Z DRIVER « [Node 005] [REQ] [ApplicationCommand]
                                  └─[BasicCCSet]
                                      target value: 255
2022-01-06T19:37:07.834Z CNTRLR   [Node 005] treating BasicCC::Set as a report
2022-01-06T19:37:07.834Z CNTRLR   [Node 005] [~] [Basic] currentValue: 0 => 255                     [Endpoint 0]

CurrentValue til 0 er rele av og 255 er rele på.

Lurer på om dett blir sendt som event delen i home assistant i det hele tatt?.

Hei,

emonEVSE er OpenEVSE i EU utgave, har selv et kit av OpenEVSE og er godt fornøyd med det. 

Lett å integrere da det har eget API og også MQTT støtte. Kildekode er selvfølgelig åpen, så her kan du da også gjøre endringer om du vil det.

Nå er det vel bare WIFI støtte på disse, men du kan installere eget kort for å få Ethernet:

https://shop.openenergymonitor.com/openevse-etherent-gateway-esp32/

Noen som har oversikt på hvor mye tap det er i disse kablene? Vil tro det er betydelig mengde energi som går tapt over dammen, ca. 30% kanskje?

I dag handler jo ting om å være kortreist, det gjelder jo for energi også. Lurt med solceller på taket osv, problemet er da lagring, der det ikke finnes noen god løsning (og nei litium batteripakker er ikke løsningen). Med vannkraft er ikke dette et problem, dammene er batterier som vi kan bruke til å "lagre strøm" til den kalde vinteren kommer, men ikke når dammene begynner å bli tomme på vei in i vinteren for noen har solgt strømmen. Helt enig med deg SveinHa, dette er forkastelig. At vi finner oss i det uten kamp er også nesten litt uforståelig, men vi som folk har det vel kanskje litt for godt, og finner oss i det meste. Noen mener det er helt ok at vi skal ha en strømpris lik den i EU, det er feil. Vi kan ikke som resten av EU velge om vi skal varme opp med gass eller elektrisitet, de aller fleste av oss er låst på sistnevnte, mange har ikke engang mulighet til å fyre med ved. 

11 minutes ago, Garegaupa said:

 

Ikkje så dumt det. 😉 Som lukkelege eigarar av ein slik som dette tenkjer me svært lite på straumprisar heime hjå oss: http://www.etanorge.no/produkter/vedkjele-eta/

 

Me brukar ikring 600 kWh med straum per månad på eit hus med cirka 235 m² bruksareal.

Ikke dumt, tenker du selv eier en del skog også da:)?

Vi lurer på å gå for denne:

https://www.hetastoves.com/scanlineaqua

Sammen med en 600 - 1000 liter tank og radiatorer, slik det er i dag ville det fort ha lønnet seg, selv med kjøpt ved.

Ble nesten litt skuffet nå..

Men men, tror ikke det i praksis var så mye en hadde klart å spare i forhold til dagens tariff.

Det som er helt sikkert er at det skal hogges mye ved fremover:)

Takk stigvi,

Det er supert, da slipper jeg tydeligvis å bruke første delen av templaten som "sjekker" om state er "unknown"

Hei,

Bruker i dag noen enkle men "stygge" templates, og noen gir meg nå feilmelding. Det er nok template syntax som er i endring og som da ikke lenger vil støttes i neste versjon. I tillegg kan nok template skrives på en mer ryddig måte? Noen som har anbefalinger?

Feilmelding:

Template warning: 'float' got invalid input '<template TemplateState
(<state sensor.kwh_kjellerbad_today=1.5; unit_of_measurement=kWh, friendly_name=Kwh Kjellerbad Today @ 2021-12-14T01:44:14.262309+01:00>)>'
when rendering template 
'{%- if not (is_state("sensor.kwh_bad_1etg_today","unknown") or is_state("sensor.kwh_bad_2etg_today","unknown") or 
is_state("sensor.kwh_kg_today","unknown") or is_state("sensor.kwh_ks_today","unknown") or is_state("sensor.kwh_n_today","unknown") or 
is_state("sensor.kwh_stue_today","unknown") or is_state("sensor.kwh_a_today","unknown") or is_state("sensor.kwh_drivhus_today","unknown") or 
is_state("sensor.kwh_s_today","unknown") or is_state("sensor.kwh_masterbedroom_today","unknown") or is_state("sensor.kwh_t_today","unknown") or 
is_state("sensor.kwh_kjellerbad_today","unknown") or is_state("sensor.kwh_vr_today","unknown") )-%} {{ ((states.sensor.kwh_bad_1etg_today.state | float) + 
(states.sensor.kwh_bad_2etg_today.state | float) + (states.sensor.kwh_kg_today.state | float) + (states.sensor.kwh_ks_today.state | float) + 
(states.sensor.kwh_n_today.state | float) + (states.sensor.kwh_stue_today.state | float) + (states.sensor.kwh_a_today.state | float) + 
(states.sensor.kwh_drivhus_today.state | float) + (states.sensor.kwh_s_today.state | float) + (states.sensor.kwh_masterbedroom_today.state | float) + 
(states.sensor.kwh_t_today.state | float) + (states.sensor.kwh_kjellerbad_today | float) + (states.sensor.kwh_vr_today.state | float)) |default(0)|round }}
{%- endif -%}' 

but no default was specified. Currently 'float' will return '0', however this template will fail to render in Home Assistant core 2022.1

Template Sensor:

      total_kwh_heating_today:
        value_template: '{%- if not (is_state("sensor.kwh_bad_1etg_today","unknown")
or is_state("sensor.kwh_bad_2etg_today","unknown")
or is_state("sensor.kwh_kg_today","unknown")
or is_state("sensor.kwh_ks_today","unknown")
or is_state("sensor.kwh_n_today","unknown")
or is_state("sensor.kwh_stue_today","unknown")
or is_state("sensor.kwh_a_today","unknown")
or is_state("sensor.kwh_drivhus_today","unknown")
or is_state("sensor.kwh_s_today","unknown")
or is_state("sensor.kwh_masterbedroom_today","unknown")
or is_state("sensor.kwh_t_today","unknown")
or is_state("sensor.kwh_kjellerbad_today","unknown")
or is_state("sensor.kwh_vr_today","unknown") 
)-%}
{{ ((states.sensor.kwh_bad_1etg_today.state | float) +
        (states.sensor.kwh_bad_2etg_today.state | float) +
        (states.sensor.kwh_kg_today.state | float) +
        (states.sensor.kwh_ks_today.state | float) +
        (states.sensor.kwh_n_today.state | float) +
        (states.sensor.kwh_stue_today.state | float) +
        (states.sensor.kwh_a_today.state | float) +
        (states.sensor.kwh_drivhus_today.state | float) +
        (states.sensor.kwh_s_today.state | float) +
        (states.sensor.kwh_masterbedroom_today.state | float) +
        (states.sensor.kwh_t_today.state | float) +
        (states.sensor.kwh_kjellerbad_today | float) +
        (states.sensor.kwh_vr_today.state | float)) |default(0)|round }}
{%- endif -%}'
        friendly_name: "Kwh Oppvarming i dag"
        unit_of_measurement: 'Kwh'

Takk, det var egentlig det jeg lurte på.

Da ligger jo alt til rette for å starte migrering. 

Takk for svar haraldov,

Det var en fin oversikt. Godt å høre at z-trm3 fungerer bra, det gjør den ikke med openzwave integrasjonen som jeg kjører i dag, og er motivasjon 

Jeg har ca 10 stk TF016 (første generasjon) og 2 stk Z-TRM3. Siden TF016 ikke måler energi, så bruker jeg assosiering gr0 og node automasjoner basert på node event som kommer når releet slår, det er dette jeg ikke vet om vil fungere i z-wave js, men det finner jeg ut når jeg prøver. 

- alias: Ovens on stue
  trigger:
    platform: event
    event_type: zwave.node_event
    event_data:
      entity_id: zwave.stue_thermostat
      basic_level: 255
  action:
    service: homeassistant.turn_on
    entity_id: input_boolean.heating_stue
  id: b2481b651f2d4e22a53dbf787ba61dd9

Hei,

Tenker det er på tide å migrere til z-wave JS.  Kjører fremdeles på "gamle" openzwave integrasjonen.

Har en god del førstegenerasjon heatit termostater som er assosiert på gruppe 0 tilbake til kontroller der jeg bruker "node event" for å vite om termostaten varmer eller ei, slik at det er mulig å regne ut hvor mye energi det går på hver termostat. Spørsmålet blir da, er det noen som vet om det også støtte for det i Z-wave JS? Har søket litt rundt men finner ingen helt direkte svar.  Har også et par heatit v3 som jeg ikke har fått integrert i den "gamle openzwave", antar de er bedre støttet i z-wave js? Jeg vet det er bare å sette i gang, går det gale så er det bare å gå tilbake til config som virker, men ville bare sjekke om noen har erfaring. Takk.

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.

Mener at 6A er laveste definert av J1772, men at noen biler kan gå under dette, men at de da er utenfor standard.

se mer her fra slide 11 og utover:

https://www.fveaa.org/fb/J1772_386.pdf

Hei,
Har fått bygget, montert og integrert et OpenEVSE kit mot Home Assistant.  Eksisterende Home Assistant integrasjon er utdatert og fungerer kun delvis.

Valgte å bruke MQTT for integrering, HTTP støttes også, mer info her

 Sensors:

  - platform: mqtt
    state_topic: 'openevse/amp'
    name: 'openevse_amp'
    expire_after: 300
    value_template: "{{ value | multiply(0.001) | round(2) }}"
    unit_of_measurement: 'A'
    unique_id: 'openevse001'

  - platform: mqtt
    state_topic: 'openevse/pilot'
    expire_after: 300
    name: 'openevse_pilot'
    unit_of_measurement: 'A'
    unique_id: 'openevse002'

  - platform: mqtt
    state_topic: 'openevse/wh'
    name: 'openevse_wh'
    expire_after: 300
    unit_of_measurement: 'Wh'
    unique_id: 'openevse003'

  - platform: mqtt
    state_topic: 'openevse/state'
    name: 'openevse_state'
    expire_after: 300
    value_template: >-
      {% set values = { '1':'Klar', '2':'Tilkoblet' ,'3':'Lader','4':'Feil', '254':'Klar - Bil tilkoblet', '255':'Klar - Bil ikke tilkoblet' } %}
      {{ values[value] if value in values.keys() else 'Unknown' }}
    unique_id: 'openevse004'

  - platform: mqtt
    state_topic: 'openevse/vehicle'
    name: 'openevse_vehicle'
    expire_after: 300
    unique_id: 'openevse005'

  - platform: mqtt
    state_topic: 'openevse/colour'
    name: 'openevse_colour'
    expire_after: 300
    value_template: >-
      {% set values = { '0':'Off', '1':'Red' ,'2':'Green','3':'Yellow', '4':'Blue', '5':'Violet', '6':'Teal', '7':'White' } %}
      {{ values[value] if value in values.keys() else 'Unknown' }}
    unique_id: 'openevse006'

  - platform: mqtt
    state_topic: 'openevse/manual_override'
    name: 'openevse_manual_override'
    expire_after: 300
    unique_id: 'openevse007'

Automation:

# Read charge level from MQTT
- alias: OpenEVSE Set slider
  trigger:
    platform: mqtt
    topic: openevse/set_pilot
  action:
    service: input_number.set_value
    target:
      entity_id: input_number.openevse_capasity
    data:
      value: '{{ trigger.payload }}'
  id: 56a6f9d542174f8bbd5dbb6633fe1342

# Publish MQTT charge level
- alias: OpenEVSE slider moved
  trigger:
    platform: state
    entity_id: input_number.openevse_capasity
  action:
    service: mqtt.publish
    data:
      topic: openevse/rapi/in/$SC
      retain: true
      payload: '{{ states(''input_number.openevse_capasity'') | int }}'
  id: c15be7f0051244839beef00a1ae32343


# Publish MQTT charge state on
- alias: OpenEVSE charge on
  trigger:
    entity_id: input_boolean.openevse_state
    platform: state
    to: 'on'
  action:
    service: mqtt.publish
    data:
      topic: openevse/rapi/in/$FE
      retain: true
#      payload: ''
  id: c15be7f0051244839beef00a1a324324

# Publish MQTT charge state off
- alias: OpenEVSE charge off
  trigger:
    entity_id: input_boolean.openevse_state
    platform: state
    to: 'off'
  action:
    service: mqtt.publish
    data:
      topic: openevse/rapi/in/$FD
      retain: true
#      payload: ''
  id: c15be7f0051244839beef00a1a345332


# Read back charge status and set input boleean
- alias: OpenEVSE charge set on
  trigger:
    entity_id: sensor.openevse_state
    platform: state
    to: 'Lader'
  action:
    service: input_boolean.turn_on
    target:
      entity_id: input_boolean.openevse_state
  id: 56a6f9d542174f8bbd5dbb66334352

- alias: OpenEVSE charge set off
  trigger:    
    - platform: template
      value_template: "{{ not is_state('sensor.openevse_state', 'Lader') or (is_state('sensor.openevse_vehicle', '0'))}}"
  action:
    service: input_boolean.turn_off
    target:
      entity_id: input_boolean.openevse_state
  id: 56a6f9d542174f8bbd5dbb663324342

# Overstyringsflagg på
- alias: OpenEVSE charge override on
  trigger:
    entity_id: sensor.openevse_manual_override
    platform: state
    to: '1'
  condition:
    condition: time
    before: '22:00'
    after: '10:00'
  action:
    service: input_boolean.turn_on
    target:
      entity_id: input_boolean.openevse_override
  id: 56a6f9d542174f8bbd54324324258

# Overstyringsflagg av
- alias: OpenEVSE charge override off
  trigger:
    entity_id: sensor.openevse_vehicle
    platform: state
    to: '0'
  action:
    service: input_boolean.turn_off
    target:
      entity_id: input_boolean.openevse_override
  id: 56a6f9d542174f8bbd5898654442

configuration:

input_number:
# OpenEVSE Kapasitet
  openevse_capasity:
    name: Ladestrøm
    min: 6
    max: 16
    step: 1
    unit_of_measurement: 'A'
    icon: mdi:target

input_boolean:
  openevse_state:
    name: Lading
    icon: mdi:car-battery
    initial: off 
  openevse_override:
    name: Overstyring
    icon: mdi:car-battery
    initial: off 

Du kan jo sjekke ut OpenEVSE, da har du full kontroll direkte, uten skyløsning.

Her kan du kjøpe som byggesett om du liker denslags, eller du kan kjøpe ferdig for EU som er CE godkjent.

Den har ESP32 ombord som du kan styre via eget web interface, eller via RAPI kommandoer over MQTT eller HTTP. Du kan også modifisere litt og sette in ethernet om det er ønskelig. Min erfaring har vert at ESP32 er meget stabil, har ikke hatt problemer med drop out, etc.

Har fått den integrert ganske så greit mot Home Assistant:

Ladestrøm kan settes i steg på 1A fra 6A. Bruker nå scriptet til stigvi for strømregulering som også nå styrer ladestrømmen i disse stegene. Det som var kjekt her var at utviklerene har tenkt på ofte endringer i ladestrøm, og har lagt opp for forskjellige kommandoer for endring av ladestrøm med og uten lagring til flash, slik at med for eksempel laderegulering så lagres da ikke innstillingene for å spare flash.

Eneste minus er vel at den ser litt kjip ut om du bryr deg om det. Et annet spennede alternativ kan være PRISM, men tror ikke den kan kjøpes ferdig bygget.

God ide!

Kanskje også ha en slags automatisk override som da sørger for at det ikke strupes ned ved dyr strøm når husets behov for energi blir større en det som blir gjort tilgjengelig?

Har etter du anbefalte å bruke D satt den til 3000 og testet litt, øket etterhvert I. Av og til gikk forbruket over 5, tyisk 5.0 eller 5.1, så jeg øket også til -0.2 etter det så har den truffet mellom 4,75 og 4,9. Kanskje den vil treffe enda mer eksakt med å øke P igjen, men er egentlig fornøyd slik:

Før:

Så ble det kaldt her og 5kWh ble for lite selv med vedfyring, har satt den opp til 10kWh, redd det er det som blir gjeldende for Jan, feb, og kanskje mars. 

Får vel til å isolere taket:)

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 }

Hei,

Mulig et sidespor, men relevant:

Snublet over dette:

https://github.com/digin-energi/API-nettleie-for-styring

En del nyttig info kanskje?, men sier ikke noe om hva de forskjellige strømselskapene innfører, men eksempler for hvordan de kan velge / valgt å gjøre det. 

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]

 

Response of PV to step change of SP vs time, for three values of K_d (K_p and K_i 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 K_d. The magnitude of the contribution of the derivative term to the overall control action is termed the derivative gain, K_d.

The derivative term is given by

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

Det stemmer nok,

Den første er fra 17.11 og siste er fra forrige natt , og da var det ganske kaldt ute.

Men så er skalaen også 8kW på den ene og 6kW på den andre.

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)

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)

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: