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

[thoralex]

Den ser slik ut:
 

#derivert strømforbruk  denne time
  - platform: derivative
    source: sensor.stromforbruk_denne_time
    name: stromforbruk derivert effekt
    round: 1
    unit_time: "h"
    time_window: "00:05:00"

Men jeg tror feilen ligger i sensoren for estimert timeforbruk, for hvis jeg flytter den til et annet sted i dokumentet får jeg alltid samme feilmelding men med navnet som på sensoren som før den i dokumentet. Linje 16 er forresten en tekstlinje med # foran, så den har neppe noe med saken å gjøre. Derivative sensoren starter på linje 136, så jeg ser ikke helt sammenhengen med linje 16...

Endret 9. oktober 2022 av thoralex

[Kim123]

Linje 16 er nok hvor du linker til filen i configuration.yaml. 

 

Post gjerne mer av configen din, men helt klart så har du garantert en syntax feil et sted. 

[thoralex]

# Loads default set of integrations. Do not remove.
default_config:

# Text to speech
tts:
  - platform: google_translate

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

#Sensordel:
sensor:

#Nordpool sensor inkludert nettleie
  - platform: nordpool

    # Should the prices include vat? Default True
    VAT: True

    # What currency the api fetches the prices in
    # this is only need if you want a sensor in a non local currency
    currency: "NOK"
    
    # Option to show prices in cents (or the equivalent in local currency)
    price_in_cents: false

    # Helper so you can set your "low" price
    # low_price = hour_price < average * low_price_cutoff
    low_price_cutoff: 0.95

    # What power regions your are interested in.
    # Possible values: "DK1", "DK2", "FI", "LT", "LV", "Oslo", "Kr.sand", "Bergen", "Molde", "Tr.heim", "Tromsø", "SE1", "SE2", "SE3","SE4", "SYS", "EE"
    region: "Tr.heim"

    # How many decimals to use in the display of the price
    precision: 4

    # What the price should be displayed in default
    # Possible values: MWh, kWh and Wh
    # default: kWh
    price_type: kWh

    # This option allows the usage of a template to add a tariff.
    # now() always refers start of the hour of that price.
    # this way we can calculate the correct costs add that to graphs etc.
    # The price result of the additional_costs template expects this additional cost to be in kWh and not cents as a float
    # default {{0.0|float}}
    additional_costs: '{% set s = {
    "hourly_fixed_cost": 0.0,
    "winter_night": 0.3139,
    "winter_day": 0.4226,
    "summer_day": 0.4224,
    "summer_night": 0.3139,
    "cert": 0.00
}
%}
{% if now().month >= 5 and now().month <11 %}
    {% if now().hour >=6 and now().hour <22 %}
        {{s.summer_day+s.hourly_fixed_cost+s.cert|float}}
    {% else %}
        {{s.summer_night+s.hourly_fixed_cost+s.cert|float}}
    {% endif %}
{% else %}
    {% if now().hour >=6 and now().hour <22 %}
        {{s.winter_day+s.hourly_fixed_cost+s.cert|float}}
    {%else%}
        {{s.winter_night+s.hourly_fixed_cost+s.cert|float}}
    {% endif %}
{% endif %}'

#Nordpool sensor uten nettleie
  - platform: nordpool

    # Should the prices include vat? Default True
    VAT: True

    # What currency the api fetches the prices in
    # this is only need if you want a sensor in a non local currency
    currency: "NOK"
    
    # Option to show prices in cents (or the equivalent in local currency)
    price_in_cents: false

    # Helper so you can set your "low" price
    # low_price = hour_price < average * low_price_cutoff
    low_price_cutoff: 0.95

    # What power regions your are interested in.
    # Possible values: "DK1", "DK2", "FI", "LT", "LV", "Oslo", "Kr.sand", "Bergen", "Molde", "Tr.heim", "Tromsø", "SE1", "SE2", "SE3","SE4", "SYS", "EE"
    region: "Tr.heim"

    # How many decimals to use in the display of the price
    precision: 3

    # What the price should be displayed in default
    # Possible values: MWh, kWh and Wh
    # default: kWh
    price_type: kWh

    # This option allows the usage of a template to add a tariff.
    # now() always refers start of the hour of that price.
    # this way we can calculate the correct costs add that to graphs etc.
    # The price result of the additional_costs template expects this additional cost to be in kWh and not cents as a float
    # default {{0.0|float}}
    additional_costs: "{{0.0|float}}"

#RPI 
#rpi system monitor
  - platform: systemmonitor
    resources:
      - type: disk_use_percent
        arg: /
      - type: disk_use
        arg: /
      - type: disk_free
        arg: /
      - type: memory_use_percent
      - type: processor_use
      - type: processor_temperature
      - type: disk_use_percent
        arg: /dev/mmcblk0p1

#Strøm:

#akkumulert strømforbruk denne time
  - platform: integration
    name: stromforbruk denne time
    unit_time: "h"
    unit_prefix: k
    source: sensor.ams_p
    round: 3
    
#derivert strømforbruk  denne time
  - platform: derivative
    source: sensor.stromforbruk_denne_time
    name: stromforbruk derivert effekt
    round: 1
    unit_time: "h"
    time_window: "00:05:00"

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

#utility meter setup
utility_meter: 
  hourly_energy: #testing?
    source: sensor.energy
    name: Hourly Energy
    cycle: hourly
    tariffs:
  daily_energy:
    source: sensor.energy
    name: Daily Energy
    cycle: daily
    tariffs:
  monthly_energy:
    source: sensor.energy
    name: Monthly Energy
    cycle: monthly
    tariffs:
  accumulated_energy_hourly:
    source: sensor.energy_per_hour
    cycle: hourly
template:
  - sensor:
    - name: 'Daily Energy Total'
      device_class: energy
      unit_of_measurement: kWh
      state: >
        {% if is_number(states('sensor.daily_energy_offpeak')) and is_number(states('sensor.daily_energy_peak')) %}
          {{ states('sensor.daily_energy_offpeak') | float + states('sensor.daily_energy_peak') | float }}
        {% else %}
          None
        {% endif %}
        
#Klimastyring:

#thermostat bad
climate:
  - platform: generic_thermostat
    name: Thermostat bad
    heater: switch.varme_bad_switch
    target_sensor: sensor.lumi_lumi_weather_temperature
    min_temp: 5
    max_temp: 20
    ac_mode: false
    # target_temp: 18
    cold_tolerance: 0.5
    hot_tolerance: 0
    min_cycle_duration:
      minutes: 2
    keep_alive:
      minutes: 5
    initial_hvac_mode: "heat"
    away_temp: 14
    comfort_temp: 18
    precision: 0.1

Her er alt fra start til slutten på sensordelen. Resten av dokumentet er en haug med binærsensorer som plukker billige strømtimer på forskjellige måter, så de er neppe av interesse...

[RVM]

Ser ut som du har plassert templaten for estimert timeforbruk under sensor-delen, men den må du flytte ned eller fjerne indentering, slik som Daily Energy Total-sensoren din.

[thoralex]

RVM skrev (1 time siden):

Ser ut som du har plassert templaten for estimert timeforbruk under sensor-delen, men den må du flytte ned eller fjerne indentering, slik som Daily Energy Total-sensoren din.

Takk, da ser jeg hvor jeg har rotet til ting!

[hjemmedude]

Hvordan ignorerer jeg pid_new_state fra loggboken?

[RVM]

hjemmedude skrev (2 minutter siden):

Hvordan ignorerer jeg pid_new_state fra loggboken?

Avhengig av hvordan du har satt opp configuration.yaml, så kan du ta bort default_config og administrere default-integrasjonene selv, inkludert logbook.

 

For logbook-integrasjonen kan du legge til en exclude avhengig av hva du vil ignorere (f.eks. enten en entity eller et helt domain)

[hjemmedude]

Ja forsøkte med logbook.yaml fil og innhold;

 

exclude:
  entities:
  - sensor.file_pid_new_state

 

Men så er vel ikke dette en sensor, og jeg vil ikke ta vekk hele pyscript dersom jeg kan ha bruk for noen meldinger til logbook.

 

edit:

exclude:
  domains:
    - pyscript

Dette hjalp.

Endret 13. desember 2022 av hjemmedude

[hjemmedude]

Så nærmer det seg spotprisavtale og jeg må ha billigste timer til elbil og vvb. Kanskje også til varmekabler slik at disse øker på lav(ere) strømpris.

Har knotet og kopiert meg til laveste strømpris i offpeak perioder og døgnest laveste timer gitt input_number.billigstetimer. Om jeg bruker begge to vet jeg ikke ennå. Men greit å ha der.

 

- platform: template
  sensors:
    billigste_timer_via_input:
      friendly_name: 'Billigste timer basert på input'
      value_template: >-
        {% set l=state_attr('sensor.nordpool_kwh_bergen_nok_3_10_025', 'raw_today')|sort(attribute='value') %}
        {% set ns = namespace(out=false) %}
        {% set n = states('input_number.billigstetimer')|int %}
        {% for i in range(n) %}
        {% if (now() >= l[i].start and now() <= l[i].end) %}
        {% set ns.out = true %}
        {% endif %}
        {% endfor %}
        {{ns.out}}
    
#plukke billigste 6 timer 0000-0600, 0900-1500, 2000-0000
- platform: template
  sensors:
    billigste_6_timer_offpeak:
      value_template: >-
        {% set x = states("sensor.time") %}
         {% set l =  
            (state_attr('sensor.nordpool_kwh_bergen_nok_3_10_025', 'raw_today')
                      |selectattr('start', '<', now().replace(hour=6,minute=0,second=0,microsecond=0))
                      |list
          + state_attr('sensor.nordpool_kwh_bergen_nok_3_10_025', 'raw_today')
                      |selectattr('start', '>=', now().replace(hour=9,minute=0,second=0,microsecond=0))
                      |selectattr('start', '<', now().replace(hour=15,minute=0,second=0,microsecond=0))
                      | list
          + state_attr('sensor.nordpool_kwh_bergen_nok_3_10_025', 'raw_today')
                      |selectattr('start', '>=', now().replace(hour=20,minute=0,second=0,microsecond=0))
                      | list)
          | sort(attribute='value')
        %}
          {{ (now() >= l[0].start and now() <= l[0].end)
          or (now() >= l[1].start and now() <= l[1].end)
          or (now() >= l[2].start and now() <= l[2].end)
          or (now() >= l[3].start and now() <= l[3].end)
          or (now() >= l[4].start and now() <= l[4].end)
          or (now() >= l[5].start and now() <= l[5].end) }}

 

Nå skal dette i Schedy, og tenker som moskus at oppvarming av vvb skal skje 3t på natt og 3t på dagtid (definitivt mest oppvarming på natt)

 

Lagt til linjer

watched entities: sensor.biligste_6_timer_offpeak
- x: "Next() if state('sensor.billigste_6_timer_offpeak') == 'false' else Break()"

 

 

schedy_switch:  # This is our app instance name.
  module: hass_apps_loader
  class: SchedyApp

  actor_type: switch

  watched_entities:
  - sensor.energy_regulator_usage_step
  - sensor.billigste_6_timer_offpeak
  
  schedule_append:
    - v: 'off'
  
  rooms:
    vvb:
      actors:
        switch.vvb_heavy_duty_switch:
      schedule:
      - v: 'off'
        rules:
        - weekdays: 1-5
          rules:
          - x: "Next() if int((state('sensor.energy_regulator_usage_step'))) < 2 else Break()"
          - x: "Next() if state('sensor.billigste_6_timer_offpeak') == 'False' else Break()"  
          - { v: 'ON', start: "22:00", end: "06:00" }
          - { v: 'ON', start: "09:00", end: "15:00" }
        - weekdays: 6-7
          rules:  
          - x: "Next() if int((state('sensor.energy_regulator_usage_step'))) < 2 else Break()"
          - x: "Next() if state('sensor.billigste_6_timer_offpeak') == 'False' else Break()"  
          - { v: 'on', start: "22:00", end: "06:00" }
          - { v: 'on', start: "09:00", end: "15:00" }

 

For eks i dag vil ikke vvb fyre mer enn 1t på dagtid med sensor.billigste_6_timer_offpeak såvidt jeg ser. Billigste timer er 4,5,3,2,14.

Kanskje best å bryte opp til to sensorer? Og er det et problem at dagens formel ikke ser på raw_tomorrow mtp natten (kl 22 til 06)?
Jeg ønsker meg de 6 billigste timene fra 22-06 , det inkluderer 2 siste timene i raw_today og 6 første timene i raw_tomorrow sånn jeg forstår. Men det blir kanskje feil når man bikker over 0000 å hente raw_tomorrow - de timene eksisterer vel ikke.

Så jeg må kanskje endre til to sensorer, finner billigste 6t (eller 3t) på dagtid og en som finner 6 (eller 3t) billigste timer på natten.. Uten at det burde bli så veldig komplisert da. 🙂

 

edit: oppdater schedy, det var mye kreativt der.

Endret 13. desember 2022 av hjemmedude

[hjemmedude]

La til (now() + timedelta(1)) i kodesnippen for å ta morgendagens timer med i listen.

 

     {% set l =
            (state_attr('sensor.nordpool_kwh_bergen_nok_3_10_025', 'raw_today')
                      |selectattr('start', '>=', now().replace(hour=19,minute=0,second=0,microsecond=0))
                      |selectattr('start', '<', now().replace(hour=23))
                      | list
            +state_attr('sensor.nordpool_kwh_bergen_nok_3_10_025', 'raw_tomorrow')
                      |selectattr('start', '>=', (now() + timedelta(1)).replace(hour=0,minute=0,second=0,microsecond=0))
                      |selectattr('start', '<', (now() + timedelta(1)).replace(hour=7))
                      |list)
          | sort(attribute='value')
        %}
{{ l }}

 

[{'start': datetime.datetime(2022, 12, 14, 2, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'end': datetime.datetime(2022, 12, 14, 3, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'value': 3.516},
 {'start': datetime.datetime(2022, 12, 14, 1, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'end': datetime.datetime(2022, 12, 14, 2, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'value': 3.539},
 {'start': datetime.datetime(2022, 12, 14, 0, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'end': datetime.datetime(2022, 12, 14, 1, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'value': 3.557},
 {'start': datetime.datetime(2022, 12, 14, 4, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'end': datetime.datetime(2022, 12, 14, 5, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'value': 3.597},
 {'start': datetime.datetime(2022, 12, 14, 3, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'end': datetime.datetime(2022, 12, 14, 4, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'value': 3.625},
 {'start': datetime.datetime(2022, 12, 13, 23, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'end': datetime.datetime(2022, 12, 14, 0, 0, tzinfo=zoneinfo.ZoneInfo(key='Europe/Oslo')), 'value': 3.738},

 

Så var det faktisk billigere i morgen midnatt enn kveldstid i dag. Men hvordan kan jeg unngå at data blir null etter midnatt? En automasjon som kjører sjekken en gang i døgnet kl 14 kanskje?

[hjemmedude]

Hvordan setter dere modus på heatit termostater?
Jeg har de eldste, og på termostat står det Eco og Comfort, i HA ser jeg Off, Heat, Cool og presets None og Energy Heat.

Har så langt brukt 'off' men det blinker litt når PID regulatoren stopper en termostat, så vil heller bruke Cool for eks.

Problemet jeg har med cool er at avlest temperatur er 16,5 gr - hvor den får denne verdien fra vet jeg ikke.

Termostat bruker gulvføler og viser korrekt i Heat modus.

[RVM]

hjemmedude skrev (1 time siden):

Hvordan setter dere modus på heatit termostater?
Jeg har de eldste, og på termostat står det Eco og Comfort, i HA ser jeg Off, Heat, Cool og presets None og Energy Heat.

Har så langt brukt 'off' men det blinker litt når PID regulatoren stopper en termostat, så vil heller bruke Cool for eks.

Problemet jeg har med cool er at avlest temperatur er 16,5 gr - hvor den får denne verdien fra vet jeg ikke.

Termostat bruker gulvføler og viser korrekt i Heat modus.

Jeg bruker alltid Heat, og justerer ned settpunktet 3 grader når PID/pris/nattsenk dikterer at de ikke skal trekke strøm.

[hjemmedude]

Ok, det funker nok her også.

 

 

 

  schedule_snippets:
    bad:
    - v: 26
      rules:
        - x: "Break() if state('sensor.billigste_timer_offpeak') == 'false' else Add(3)"
        - weekdays: 1-7
          rules:
            - rules:
                - {start: "00:00", end: "23:59" }
    - v: 26 

Fjernes siste - v: 26 så går termostat i off, pga   schedule_append:
    - v: "OFF"

 

    bad:
      actors:
        climate.bad:
      watched_entities:
        - sensor.billigste_timer_offpeak
      schedule:
        - x: "IncludeSchedule(schedule_snippets['bad'])"

Vet ikke om det er riktig måte å gjøre dette på. Det funker men..

Jeg kunne ønske å bare legge til Add(3) uten å spesifisere temperatur, men funker det og. Bare litt flytting av informasjon fra rooms delen av schedy.. Kan sikkert fjerne weekdays, start osv..

 

https://community.home-assistant.io/t/heaty-will-die-schedy-be-born/71276/1236

https://hass-apps.readthedocs.io/en/stable/apps/schedy/schedules/expressions/examples.html

[hjemmedude]

Måtte bare teste openai chat, eksempel her: jeg stilte spørsmålet og resten et generert av openai; 

 

To use Schedy and binary sensors to delay a Schedy task for 5 minutes in Home Assistant, you can follow these steps:

1. First, make sure you have installed Schedy and the binary sensor you want to use. You can do this by adding the schedy and binary_sensor components to your configuration.yaml file and configuring them according to the documentation.

2. Next, create a binary sensor that will trigger the Schedy task. This can be any sensor that can be turned on or off, such as a motion sensor or a switch.

3. In your configuration.yaml file, define a new Schedy task that will be triggered by the binary sensor. You can do this using the schedy: section of the file. For example:

Copy code

schedy: - name: "Delay Schedy Task" trigger: platform: state entity_id:binary_sensor.my_sensor to: "on" action: - service: schedy.delay_task data: task_id:schedy.my_task delay: 300

This will create a Schedy task that is triggered when the binary sensor's state changes to "on". When the task is triggered, it will delay the execution of the Schedy task with the ID schedy.my_task for 5 minutes (300 seconds).

4. Test your setup by triggering the binary sensor and checking that the Schedy task is delayed by the appropriate amount of time.

I hope this helps! Let me know if you have any questions

[hjemmedude]

@stigvi du styrer lading av elbil direkte i pid.py koden; hvorfor? 
Jeg har nettopp fått easee-lader integrert i HA - så jeg kommer til å gjøre det samme.
Har du en filosofi på hva du nedjusterer først/sist du vil dele? 

Lurer selv på hvordan jeg skal dele inn 10 termostater, vvb 3000w, elbil-lader i 0-100 skalaen.
VVB må ha høg pri på natt siden den varmer i billige timer. Elbil er ikke like kritisk med mindre batteriet er under 30%.

[stigvi]

hjemmedude skrev (42 minutter siden):

@stigvi du styrer lading av elbil direkte i pid.py koden; hvorfor? 

Ikke nå lenger. Jeg har laget et helt nytt system for dette.
Skriver mer i morgen. Nå er jeg trøtt........

[stigvi]

hjemmedude skrev (11 timer siden):

@stigvi du styrer lading av elbil direkte i pid.py koden; hvorfor? 
Jeg har nettopp fått easee-lader integrert i HA - så jeg kommer til å gjøre det samme.
Har du en filosofi på hva du nedjusterer først/sist du vil dele? 

Lurer selv på hvordan jeg skal dele inn 10 termostater, vvb 3000w, elbil-lader i 0-100 skalaen.
VVB må ha høg pri på natt siden den varmer i billige timer. Elbil er ikke like kritisk med mindre batteriet er under 30%.

Elbil lading har skapt litt hodebry hos meg, men er landet på noe nå som virker greit. Jeg har 2 biler som krever lading. En Passat GTE som er en hybrid og en e-Golf. Begge krever lading hver natt. Og de står på samme 16A kurs så jeg lader Golf med halv strømstyrke hvis Passat lades. Og Golf lades med 1/4 strømstyrke hvis jeg har satt systemet til å holde seg under 5kWt/t pga nettleie. Så det har vært en del hensyn å ta.

I forhold til pid regulator har jeg VVB bereder som lavest prioritet. Men jeg slipper den ikke under 50 grader så det er ikke superviktig å varme opp vann hver natt. Men i praksis gjør den stort sett det. Det blir litt knapt når to biler skal lades sammen med VVB og jeg har en begrensing på 5kWt/t, men det går i 8 av årets 12 måneder. VVB kobler jeg ut allerede når pid utgang er på 95%

Deretter kobler jeg ut varmekabler en etter en mellom 95% og 50%
Så stopper jeg lading ved ca 50% på pid utgang. Men ikke de første 20 minutt i hver time. Da lades biler uansett. Og deretter oppvarming i rom mellom 50% og 0. Da tar jeg også rom for rom og stue har høyest prioritet. Det som da skjer ved høyt forbruk er at oppvarming i rom slås av istedenfor billading hvis en er innenfor de første 20 minutter. På en måte kan en si at en veksler litt på prioriteten og så unngår en å slå av lading i start på hver time da estimatet er unøyaktig.

Hvitevarer, platetopp og stekeovn gjør jeg ingenting med. De kan ikke slås av eller settes på pause uten konsekvenser.
 

[hjemmedude]

Takk for oppdatering @stigvi - det er bra å høre hvordan andre prioriterer laster.
Jeg har en blanding av priceanalyzer og schedy for øyeblikket, men har et ønske om å samle alt i HA automasjoner etterhvert.

For elbil så tenker jeg lav effekt og lad ofte (kl 22 - 06) også i helgene. Har fortsatt en utfordring med å begrense antal av/på med schedy som er hovedgrunnen til at jeg vil over på HA automasjoner.

[OlavT]

Ser ut til at Elvia setter ned prisen på effekt-leddene snart.

 

Da var det vel ikke så viktig å unngå å belaste nettet alikevel da?

Endret 23. januar 2023 av OlavT

[haraldov]

Quote

Så kan en bare lage automasjoner som trigges ved endring av input_text.effektbegrenser_pri

@Kim123, kan du delt en av dine automatiseringer hvor du trigger ved endringer av input_text.effektbegrenser_pri?

 

Jeg kunne tenkt meg å prøve ditt forslag på effektregulering som du skrev om her:

 

[Kim123]

Ja, helt klart! 

 

Jeg har laget en github sånn at det er litt lettere å lese koden riktig.

Det er noen endringer som er gjort i effektbegrenser automasjonene også. 

Sensorene som er brukt er også lagt ved.

 

https://github.com/kimmilde/home-assistant

[haraldov]

Quote

automation.easee_juster_ladefart_kontinuerlig

 

@Kim123, kunne du delte denne automasjonen også?

[Kim123]

Da er den lagt ut 🙂 

[hjemmedude]

Justerte effektledd til 5kwh i mai, men i følge nettleie så har jeg 3 dager med 5,6 og nedover i forbruk. 
Har ikke endret på noe spesielt og HA rapporterer ca 4,8 kwh forbruk på de timene BKK melder 5,6.

Hvor begynner man feilsøke dette mon tro? 

[RVM]

8 minutes ago, hjemmedude said:

Justerte effektledd til 5kwh i mai, men i følge nettleie så har jeg 3 dager med 5,6 og nedover i forbruk. 
Har ikke endret på noe spesielt og HA rapporterer ca 4,8 kwh forbruk på de timene BKK melder 5,6.

Hvor begynner man feilsøke dette mon tro? 

 

Hvis det fortsatt er en POW-U fra AMS-leser du har, ville jeg sjekket om den rebooter i blant (f.eks. pga lav spenning). Da resettes timesforbruket på 0 kWh igjen, dvs. at den rapporterer feil forbruk. Jeg opplevde det med min, og måtte massere måledataene litt før jeg flyttet den innendørs til bedre WiFi-dekning.