Capaciteitstarief maandpiek zichtbaar maken in home assistant

[NuKeM]

Ik zou graag (voorlopig nog zonder slimme meter) inzicht krijgen in mijn maand piek vermogen genomen over een window van een kwartier aan datapunten en eventueel een waarschuwing krijgen als we naar een nieuwe piekwaarde dreigen te gaan die x > huidige piek ofzo.

Volgens mij moet dit we mogelijk zijn in Home Assistant.

Met de weinige vrije tijd die ik had heb ik volgende virtuele statistiek sensoren al gemaakt op basis hardware vermogen sensor:

Code: Selecteer alles

sensor:
  - platform: statistics
    name: "Vermogen net 15min average"
    entity_id: sensor.naam_vermogen_sensor_net
    unique_id: grid_average_15min_window
    state_characteristic: average_linear
    max_age:
      minutes: 15
    sampling_size: 30 #groot genoeg zetten zodat alle samples genomen binnen kwartier genomen worden
    precision: 1  
  - platform: statistics
    name: "Max maand peak vermogen op basis van 15min average vermogen"
    entity_id: sensor.vermogen_net_15min_average
    unique_id: max_grid_peak_power_1month_window
    state_characteristic: value_max
    max_age:
      hours: 730 # 1 month 
    sampling_size: 50000  #groot genoeg zetten zodat alle samples genomen binnen maand genomen worden
    precision: 1    

Het probleem is dat deze laatste nog niet echt per kalender maand is, maar een moving window is.
Ik denk wel dat het eventueel met een statistics graph card op een dashboard moet kunnen, maar dan heb je de waarde niet in een variabele zitten zodat je een jaar berekening kan doen bv.:

Code: Selecteer alles

chart_type: bar
period: month
days_to_show: 365
type: statistics-graph
entities:
  - sensor.vermogen_net_15min_average
stat_types:
  - mean
  - min
  - max
title: Capaciteitsgebruik

Mogelijk moet je voor die graph wel al je metingen ook een jaar bijhouden, dat weet ik niet en doe ik ook niet (enkele weken ofzo).

Ik moet nog zien of bovenstaande code het gewenste effect heeft/werkt, want de berekeningen zijn nog maar net gestart (gaat niet terugrekenen helaas).
Verder zijn er nog statistiek functies denk ik die een stijging kunnen detecteren of kan je die zelf schrijven zodat er een notificatie ofzo kan volgen. Maar, daar ben ik nog niet toe gekomen.
Misschien heeft iemand hier deze oefening/implementatie al gedaan en kan die ze delen?

[benc]

Ik heb de influxdb/grafana data begin oktober ingeregeld in mijn hass installatie. Daarmee heb ik snel de volgende grafiek ineen geklikt:

De piek die ik hier zie komt grofweg overeen met wat in Fluvius staat:

[NuKeM]

Ik heb ook al zitten denken influxdb en grafana te installeren om de data wat langer bij te kunnen houden en visualiseren. Maar, ik denk (weet het niet) dat je die data in influx niet kan gebruiken in HA om bv. berekeningen op te doen?

[honda4life]

Euh, Node-Red een goede oplossing voor zo iets?

[benc]

Ik gebruik influxdb/grafana voor rapportage, ik denk niet dat je die gegevens weer in hass kan gebruiken om te sturen.

Dus een sensor heb je zeker nodig, het lijkt me een handige om in een automatisatie te gebruiken.

NodeRed ken ik niet zo goed, maar is volgens mij meer om data te capteren en om te zetten naar iets bruikbaar in hass. Dat kan je gebruiken om gegevens waarvoor geen hass plugin bestaat toch binnen te halen.

Ik heb je sensor toegevoegd aan mijn setup, samen met het gemiddelde wat InfluxDb berekent ziet dat er zo uit:

[devastator]

Ik heb de influxdb/grafana data begin oktober ingeregeld in mijn hass installatie. Daarmee heb ik snel de volgende grafiek ineen geklikt:

photo_2022-11-26 11.13.03.jpeg

De piek die ik hier zie komt grofweg overeen met wat in Fluvius staat:

photo_2022-11-26 11.14.43.jpeg

photo_2022-11-26 11.14.34.jpeg

Beter, nauwkeuriger en tevens ook de enige juiste manier om het te berekenen is de opgenomen energie (kWh) te berekenen en niet het gemiddelde van het vermogen (W).
Utility meters in HA kunnen iedere 15m gereset worden.

[liber!]

Ik heb vandaag wat geexperimenteerd en ben tot het volgende gekomen, zie blogpost:
https://nathan.gs/2022/11/27/flanders-c ... assistant/

Toegevoegd na 1 uur 17 minuten 35 seconden:

Beter, nauwkeuriger en tevens ook de enige juiste manier om het te berekenen is de opgenomen energie (kWh) te berekenen en niet het gemiddelde van het vermogen (W).
Utility meters in HA kunnen iedere 15m gereset worden.

Dat dacht ik ook, maar als je dan ziet naar hoe het wordt berekend lijkt het me toch op basis van vermogen (W) en niet energie (kWh), de vreg website is ondermaats op dat vlak.

[Joe de Mannen]

Ik kan me voorstellen dat dit kan, maar als beginner heb ik bij al de bovenstaande code toch een woordje uitleg nodig...

J.

[dupondje]

Ik heb vandaag wat geexperimenteerd en ben tot het volgende gekomen, zie blogpost:
https://nathan.gs/2022/11/27/flanders-c ... assistant/

Piekverbruik wordt toch niet rolling gemeten?

[devastator]

Ik heb vandaag wat geexperimenteerd en ben tot het volgende gekomen, zie blogpost:
https://nathan.gs/2022/11/27/flanders-c ... assistant/

Piekverbruik wordt toch niet rolling gemeten?

Ja, klopt helemaal niet. Waarom het toch zo moeilijk maken. Neem gewoon een utility meter die reset om de 15 minuten en steek dat in influxdb. Klaar is kees.

Hij heeft wel nog een andere sensor die op het kwartier update. Maar volgens mij zit die waarde er een factor 4 langs ? Met maar 30 samples (dus iedere 30 seconden) gaat de nauwkeurigheid al helemaal ver te zoeken zijn.

Code: Selecteer alles

utility_meter:
  elektriciteit_afname_kwartier:
    source: sensor.dsmr_reading_electricity_delivered_merged
    cycle: quarter-hourly

template:
  - sensor:
      - name: elektriciteit_kwartierpiek_huidig_kwartier
        unit_of_measurement: kW
        state: "{{states('sensor.elektriciteit_afname_kwartier')|float(0) * 4}}"

[benc]

https://www.fluvius.be/nl/thema/factuur ... -maandpiek

"Je digitale meter registreert namelijk elke 15 minuten je verbruik (in kWh) en geeft voor elk kwartier het gemiddelde vermogen door. Je netkosten worden bepaald op de hoogste piek die je gedurende een kwartier verbruikt binnen een maand."

[NuKeM]

Allereerst al bedankt voor de input, ik heb weer wat lees en denk voer

VREG

Uw digitale meter registreert de hele dag door uw verbruik, en berekent telkens het gemiddelde per kwartier. Dat is het kwartiervermogen (in kW).

Ik versta/verstond dit (‘de hele dag’ en ‘telkens’) als een average continu genomen over een moving window van een kwartier. Maar, blijkbaar is het bv. om 13u00 dan om 13u15 dan op 13u30 etc. ? Kunnen mensen met toegang tot deze piekwaardes met een digitale meter dit bevestigen?

Ik zou voor de piekvermogen berekening niet werken via een kWh meting, dat is een omweg die mogelijk tot verlies van (waarschijnlijk verwaarloosbare) precisie leidt.
Add: ik neem mijn woorden terug, mogelijk is werken via kWh-meting uitlezing toch nauwkeuriger aangezien die meting continu loopt en niet bv. zoals de vermogen meting in mijn geval eens om de 30s ofzo een vermogen meten (dat is meer een steekproef). Maar al bij al zullen ze waarschijnlijk aan elkaar gewaagd zijn mbt precisie voor dit doel.
Direct werken met een vermogen meting is in ieder geval gemakkelijker

[ygeffens]

Neem bvb dit: Shelly EM (of 3EM mocht je meer fases hebben)
Deze toestelletjes tonen, buiten het huidige verbruik ook de hoeveelheid kW verbruikt sinds je het toestel bent beginnen gebruiken. maw, die hebben een teller die alleen maar omhoog gaat.
Zo ben je 100% zeker dat je elk kwartier (xx:14:59:99, ...) de juiste waarde hebt. Daar hoef je niets voor te doen. Zoals hoger al aangegeven gebruik je hiervoor de utility_meter: van HA.

Voor de volledigheid, ik haal deze kwh gegevens uit mijn flukso, niet via de Shelly. Maar het principe is hetzelfde. Elke entity die een kWh meter is (strictly increasing), kan je gebruiken.

Code: Selecteer alles

sensor:
  - platform: template
    sensors:
      fluvius_verbruik_energy_kwartier_piek:
        value_template: "{{ states('sensor.fluvius_verbruik_energy_kwartier') | float(default=0) * 4 }}"
        unit_of_measurement: "kWh"
        device_class: energy
        icon_template: mdi:calculator
        friendly_name: "Huidige kwartier piek"

Code: Selecteer alles

utility_meter:
  fluvius_verbruik_energy_kwartier:
    source: sensor.fluvius_meterstand_gebruikt
    cycle: quarter-hourly

Ik heb dan nog het volgende toegevoegd om telkens de maandpiek te bewaren:

Code: Selecteer alles

input_number:
  piek_afname:
    name: Piek Fluvius afname
    min: 0
    max: 10.0
    step: 0.001
    mode: box
    unit_of_measurement: "kWh"

  piek_afname_01:
    name: Piek afname januari
    min: 0
    max: 10.0
    step: 0.001
    mode: box
    unit_of_measurement: "kWh"

  piek_afname_02:
    name: Piek afname februari
    min: 0
    max: 10.0
    step: 0.001
    mode: box
    unit_of_measurement: "kWh"

# herhaal tot 12

  piek_afname_12:
    name: Piek afname december
    min: 0
    max: 10.0
    step: 0.001
    mode: box
    unit_of_measurement: "kWh"

En de volgende automations om die input_numbers te vullen (rolling, dus na 1 jaar overschrijf je de oudste)

Code: Selecteer alles

automation:
  - alias: Piek15m hoogste van deze maand
    mode: parallel
    variables:
      maand: '{{ now().strftime("%m") }}'
      piek: '{{ states("sensor.fluvius_verbruik_energy_kwartier_piek") | float(0)}}'
    trigger:
      - platform: state
        entity_id: sensor.fluvius_verbruik_energy_kwartier_piek
    condition:
      - condition: template
        value_template: >
          {{  piek > states("input_number.piek_afname_"~maand) | float(0) }}
    action:
      - service: input_number.set_value
        target:
          entity_id: input_number.piek_afname_{{ maand }}
        data:
          value: '{{ piek }}'

  - alias: Maximum piek nieuwe maand op 0
    variables:
      maand: '{{ now().strftime("%m") }}'
    trigger:
      - platform: template
        value_template: '{{ (as_timestamp(now()))|timestamp_custom(''%d'', true) | int(0) == 1 }}'
    action:
      - service: input_number.set_value
        target:
          entity_id: input_number.piek_afname_{{ maand }}
        data:
          value: 0.1

en nog een stukje om het te visualiseren (very basic) (er staan ook enkele sensoren in die ik hierboven niet beschrijf, en niet relevant zijn voor dit voorbeeld)

Code: Selecteer alles

cards:
  - type: entities
    title: Verbruik
    show_header_toggle: false
    entities:
      - entity: sensor.fluvius_verbruik_energy_kwartier_piek
        type: custom:multiple-entity-row
        name: Piek 15m
        format: precision1 
        entities:
          - entity: sensor.fluvius_netto
            name: Netto
            format: precision0
          - entity: sensor.home_verbruik
            name: Verbruik
            format: precision0
          - entity: sensor.flukso_pv_vermogen
            name: PV
            format: precision0
            hide_if: 0
      - entity: sensor.fluvius_verbruik
      - entity: sensor.fluvius_levering
      - type: divider
      - entity: sensor.gemiddelde_piek_afname
        type: custom:multiple-entity-row
        format: precision1
      - type: divider
      - entity: input_number.piek_afname_01
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_02
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_03
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_04
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_05
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_06
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_07
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_08
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_09
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_10
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_11
        type: custom:multiple-entity-row
        format: precision1 
      - entity: input_number.piek_afname_12
        type: custom:multiple-entity-row
        format: precision1 

En uiteindelijk gebruik ik de huidige kwartierpiek om beslissingen te nemen. Mag de wasmachine starten, mag de warmtepomp ingeschakeld worden, ...

[NuKeM]

Bedankt, ik heb Shelly 3EMs en ga je code eens proberen

Add: Waar "fluvius_verbruik_energy_kwartier_piek" staat in de automations moet eigenlijk "fluvius_verbruik_energy_kwartier" staan.
Heb je code even bekeken en ook geïmplementeerd.

[ygeffens]

Installeer dan ook deze mee mocht je die nog niet hebben:
https://github.com/benct/lovelace-multiple-entity-row

Ik gebruik hem (in de code hierboven) enkel voor de waarden in input_number af te ronden in het dashboard. Maar handig voor veel meer uiteraard.
Issues, vraag maar. Ben er ondertussen al 2 jaar mee bezig (dikke merci aan @devastator)

[NuKeM]

Heb het nu al een half uurtje lopen.
Mijn lopend kwartier gemiddelde vermogen is ongeveer 450W gemeten. Dat klopt.
Bovenstaande code geeft een kwartiergemiddelde piek van 0.1kWh voor dat kwartier. Dus als ik de regel van 3 toepas (0.1kWh op 1/4h) dan kom ik op 0.4kW wat lijkt te kloppen.
Ik ga wel eens kijken om de automation en variabelen om te zetten naar kW ipv kWh, dat is meer waar het capaciteitstarief om gaat.

[liber!]

@ygeffens zou het kunnen dat je nog ergens *4 moet doen om van kWh per 15m naar kW piek te gaan?

[devastator]

@ygeffens zou het kunnen dat je nog ergens *4 moet doen om van kWh per 15m naar kW piek te gaan?

Ja, je moet nog x4 doen. Zie ook mijn code sample van een paar posts eerder.
Anders zou je continu 10 000W mogen trekken en nog steeds maar 2.5kW piek hebben.

[NuKeM]

Code: Selecteer alles

alias: Cap tarief - Piek15m hoogste van deze maand
description: ""
trigger:
  - platform: state
    entity_id: sensor.elek_energieverbruik_kwartier
condition:
  - condition: template
    value_template: |
      {{  piek > states("input_number.piek_elek_"~maand) | float(0) }}
action:
  - service: input_number.set_value
    target:
      entity_id: input_number.piek_elek_{{ maand }}
    data:
      value: "{{ piek }}"
mode: parallel
variables:
  maand: "{{ now().strftime(\"%m\") }}"
  piek: "{{ states(\"sensor.elek_energieverbruik_kwartier\")|float(0) * 4}}"

Zie laatste lijn voor *4. (bovenstaande bevat wat renames tov origineel hierboven)
Vergeet ook de eenheden niet aan te passen op de maandelijkse variables

Nu nog:

• elke maand optellen en / 12
• rekening houden met min 2.5kW dacht ik
• rekening houden met opstart (nu gaat jan waar doorwegen, volgende maande jan en febr, etc. dus niet 1/12)
• variabele met cap tarief van de regio => inschatting maken per maand?

[dupondje]

Dit is mijn code, werkt al bijna een jaar perfect
Alerts ingesteld als gemiddelde boven de 2 kWh zou eindigen, zodat je op voorhand kunt temperen indien nodig

Code: Selecteer alles

template:
    - sensor:
        - name: "peak_usage"
          unit_of_measurement: kWh
          state: >
                {% set time_passed = (now().second + now().minute * 60) % 900 %}
                {% set energy_usage = states('sensor.quarterly_energy') %}
                {% if time_passed|float > 0 and energy_usage|float > 0 %}
                        {{ (energy_usage|float / time_passed|float * 900 * 4)|round(2) }}
                {% endif %}
          device_class: energy

        - name: "month_peak_usage"
          unit_of_measurement: kWh
          state: "{{ states('input_number.max_peak_usage_month') }}"
          device_class: energy

input_number:
    max_peak_usage_month:
        name: Maximum piek Maand
        min: 0.00
        max: 40.00
        step: 0.01
        mode: box
        unit_of_measurement: "kWh"

automation:
  - alias: "Piekverbruik Alert"
    trigger:
      - platform: numeric_state
        entity_id: sensor.peak_usage
        value_template: "{{ states('sensor.peak_usage')|float(0) }}"
        above: 2.00
        for:
          seconds: 30
    action:
      - service: notify.mobile_app
        data:
          title: "Piekverbruik te hoog!"
          message: "Piekverbruik: {{ states('sensor.peak_usage') }}kWh"
          data:
            ttl: 0
            priority: high
  - alias: "Piekverbruik new max"
    trigger:
      - platform: state
        entity_id: sensor.quarterly_energy
    condition:
      - condition: template
        value_template: "{{ states('sensor.quarterly_energy')|float(0) * 4 > states('input_number.max_peak_usage_month')|float(0) }}"
    action:
      - service: input_number.set_value
        data_template:
          entity_id: input_number.max_peak_usage_month
          value: "{{ states('sensor.quarterly_energy')|float(0) * 4 }}"
  - alias: "Piekverbruik max change notification"
    trigger:
      - platform: state
        entity_id: input_number.max_peak_usage_month
    action:
      - service: notify.mobile_app
        data:
          title: "Piekverbruik max!"
          message: "Piekverbruik nieuw maximum: {{ states('input_number.max_peak_usage_month') }}kWh"
          data:
            ttl: 0
            priority: high
      - delay:
          seconds: 10
  - alias: "Reset max_peak_usage_month"
    trigger:
      platform: time
      at: '00:00:01'
    condition:
      condition: template
      value_template: "{{ now().day == 1 }}"
    action:
      - service: input_number.set_value
        data_template:
          entity_id: input_number.max_peak_usage_month
          value: 0

[ygeffens]

@ygeffens zou het kunnen dat je nog ergens *4 moet doen om van kWh per 15m naar kW piek te gaan?

Sorry, stukje code nog vergeten idd (ik heb het ook toegevoegd voor de volledigheid in mijn eerdere post):

Code: Selecteer alles

sensor:
  - platform: template
    sensors:
      fluvius_verbruik_energy_kwartier_piek:
        value_template: "{{ states('sensor.fluvius_verbruik_energy_kwartier') | float(default=0) * 4 }}"
        unit_of_measurement: "kWh"
        device_class: energy
        icon_template: mdi:calculator
        friendly_name: "Huidige kwartier piek"

[NuKeM]

Ik ben hier ook nog wat aan het spelen met de derivative helper om over een kwartier een trend te hebben en daarop voorspellingen goed te kunnen doen (om waarschuwingen te kunnen geven). Als dat goed werkt deel ik het ook even, eerst dagje testdraaien

[devastator]

Ik ben hier ook nog wat aan het spelen met de derivative helper om over een kwartier een trend te hebben en daarop voorspellingen goed te kunnen doen (om waarschuwingen te kunnen geven). Als dat goed werkt deel ik het ook even, eerst dagje testdraaien

Niet makkelijker om met een template gewoon wat tresholds in te stellen ? Aan een trend heb je denk ik niet zoveel, want die komt (meestal) te laat

[NuKeM]

Bwa ja, maar met een trend (die niet te laat komt) kan je steeds gewaarschuwd worden voor je huidige max overschreden dreigt te worden + geeft een indicatie van waar je naar toe gaat, als je dat OK vindt, kan je de waarschuwing negeren, dat heb je niet met enkel een notificatie bij overschrijden van thresholds.
Het is wat complexer, maar het is hier nu toch ver af denk ik

[devastator]

Mogelijk hebben we het over hetzelfde, maar dit zie ik niet als een trend:

Code: Selecteer alles

template:
  - sensor:
      - name: elektriciteit_kwartierpiek_huidig_kwartier
        unit_of_measurement: kW
        state: "{{states('sensor.elektriciteit_afname_kwartier')|float(0) * 4}}"
  - binary_sensor:
      - name: elektriciteit_kwartierpiek_hoog
        delay_on: 00:00:01
        state: >
          {% set input_entity = 'input_number.elektriciteit_kwartierpiek_' + as_timestamp(now())| timestamp_custom('%B', True) | lower %}
          {% set peak = states(input_entity)|float(2.5) %}
          {% set current = states('sensor.elektriciteit_kwartierpiek_huidig_kwartier')|float(0) %}
          {% set percentage = current * 100 / peak %}
          {% set minute = as_timestamp(now())  | timestamp_custom("%M") | int % 15 %}
          {% if minute <= 7 %}
            {{ percentage >= 50 }}
          {% elif is_state('binary_sensor.elektriciteit_kwartierpiek_hoog', 'off') %}
            {% if minute <= 11 %}
              {{ percentage >= 70 }}
            {% elif minute <= 13 %}
              {{ percentage >= 80 }}
            {% else %}
              {{ percentage >= 90 }}
            {% endif %}
          {% else %}
            true
          {% endif %}

Als die binary hier hoog wordt, dan gaat bv de warmtepomp op eco stand, standby killers aan, ventilatie uit, laders onderbroken, ...

[NuKeM]

Ik ga mijn code nog eerst even in de gaten houden, maar mijn implementatie is op basis van volgende principe:

• Derivative op basis van gemeten vermogen met time window van 15 minuten. Dit geeft een W/min waarde (de richtingscoëfficiënt/trend).
• Uitgemiddelde vermogen over 15min window
• Resterende aantal seconden in het 15min domein

Als de trend positief is (=stijgend):
Voorspelling [W] = Huidige waarde "uitgemiddelde vermogen over 15min window" [W] + Aantal minuten remaining in 15min domein (op basis van seconden) [min] * trend [W/min]

Die voorspelling kan je dan aftoetsen tegen de huidige piekwaarde om eventueel actie te ondernemen.
Moest bovenstaande geen steek houden hoor ik het graag
Voorlopig ziet de voorspelling er wel goed uit, maar ik wil nog wat extremen testen of zien passeren.

Bovenstaande is nog niet mijn ideale situatie, maar dat zou het te complex maken denk ik. Bv. niet gemiddelde of trend nemen over kwartier, maar effectief vanaf begin nieuwe kwartier.
Daarnaast kunnen dan kleine pieken in begin van het kwartier al voor paniek zorgen in de voorspelling, dan moet je dus pas gaan voorspellen enkele minuten ver in het kwartier en dan nog..

[Tomsworld]

Krijgen jullie dat dan goed voor elkaar om geen sliding 15 minuten window te hebben maar echt ieder kwartier. Want als ik het goed begrijp is het per vast kwartier dat het geteld zal worden.

[NuKeM]

Met de utility meter en quarter-hourly optie zoals hierboven geschreven lukt dat. Voor mij is het ook nog niet 100% duidelijk hoe Fluvius dit zal doen, maar beiden (sliding of de klok kwartdelen) kunnen dus.

[Joe de Mannen]

Maar dat is toch pas juist als je kwartieren gelijk met die van fluvius beginnen ?
J.

[honda4life]

Je kan altijd de klok verifiëren in de telegram van de digitale meter, of deze gebruiken.
Ik ben er vrij zeker van dat dit op 0, 15, 30, 45 min is. Hoe kan je anders de balans maken tussen bovenstaande reminrichtingen om allerhande verliezen (of illegaal afgetapt voor de teller) op te sporen.

Toegevoegd na 6 minuten 49 seconden:
Ik vind het werkelijk interessant, maar wat is het besparingspotentieel tov. het opgeven van comfort?

Als je kerstavond of oudejaar viert met vrienden/familie en het gebraad staat in de oven, de groenten op het kookvuur en de kroketten in de frietpot en het is op zeep.
Ja de groenten zijn koud... Capaciteitstarief?!

[NuKeM]

Mij gaat het meer om niet kritische zaken aan/uit te kunnen schakelen of hun verbruik bij te kunnen sturen zonder comfort te verliezen. Bv. EV lader of batterij elektrische fiets laden of iets met klimaatcontrole ofzo.

Daarnaast vang je eventuele extremen op door een eenmalige onoplettendheid die je best wat kunnen kosten.

[tizzen33]

Ik vind het werkelijk interessant, maar wat is het besparingspotentieel tov. het opgeven van comfort?

Als je kerstavond of oudejaar viert met vrienden/familie en het gebraad staat in de oven, de groenten op het kookvuur en de kroketten in de frietpot en het is op zeep.
Ja de groenten zijn koud... Capaciteitstarief?!

Ik heb exact hetzelfde gevoel. Die ene dag kan/zal alle inspanningen van een hele maand teniet doen.


Kan zijn dat ik er over lees, maar wat is dan de maximum piek die men zou willen halen? Ik zat bijvoorbeeld op 4,2kW gisterenavond en rond de 4 tijdens meerdere kwartieren.

[NuKeM]

Dat maximum kan je zelf bepalen afhankelijk van je situatie. Ik kan bv. zeggen dat 6kW aanvaardbaar/normaal is. Daar (veel) boven gaan zou een rode vlag moeten laten opgaan.

[Joe de Mannen]

Op dit moment gaat het toch vooral om inzicht krijgen in wat je nu doet en het resultaat daarvan.
Of je het gaat kunnen verbeteren is een volgend hoofdstuk.
J.

[ivob]

Daarnaast vang je eventuele extremen op door een eenmalige onoplettendheid die je best wat kunnen kosten.

Is dat niet wat overdreven?
Je hebt tenslotte maar één piek per maand die weerhouden wordt en die piek wordt dan nog maar eens voor 1/12 meergerekend op de totale jaarfactuur.
En je nettarief bestaat ook niet alleen uit de berekening op vermogen (kW) . Er is nog altijd een deel dat berekend wordt op het verbruik (kWh).
Gezien er ook een maximumfactuur is van 0,203548 €/kWh is dat voor verbruikers met een laag verbruik soms belangrijker dan de gemiddelde maandpiek van 2,5 kW als ondergrens. Bij mij ligt om die reden (max. factuur ligt lager dan nettarief berekend op kW en kWh) de piek niet op 2,5 kW maar op 3 kW (berekend op de gegevens over 2022, in 2023 dus waarschijnlijk nog een iets hogere piek om hetzelfde af te rekenen).

Je moet natuurlijk (of het moest louter hobby zijn) niet van alles gaan loggen en instellen om uiteindelijk juist hetzelfde te gaan betalen.

Toegevoegd na 4 minuten 29 seconden:

Kan zijn dat ik er over lees, maar wat is dan de maximum piek die men zou willen halen? Ik zat bijvoorbeeld op 4,2kW gisterenavond en rond de 4 tijdens meerdere kwartieren.

Dat staat in verhouding tot je individueel verbruik. Want, zoals gezegd, het nettarief wordt niet uitsluitend bepaald op de pieken maar op de pieken + verbruik. Bv. 40 € per piek van 1 kW en 4 c€ per afgenomen kWh.
En daar zijn dan nog eens grenzen aan: minimaal 2,5 kW (2,5 x de prijs van 1 kW) en maximaal 20,3548 c€ per verbruikte kWh (gelijk voor elk subnetgebied).

[NuKeM]

We spreken hier over 3-4€ op jaarbasis per kW die we elke maand kunnen uitsparen. Dus ja, het is voor de hobby
Moest je door dit systeem bv. elke maand 2kW lager kunnen uitvallen dan bespaart je dat ongeveer 80€ ofzo op jaarbasis.

[ivob]

Hoeveel je op jaarbasis zou besparen hangt niet alleen af van louter het afgenomen vermogen maar ook van de verbruikte kWh.
Dat is een wisselwerking en bepaalt het individuele optimum om een zo laag mogelijk nettarief te betalen. En uiteraard is dat ook een hobby en geen verdienmodel.
Zoals ik reeds schreef, in 2022 bedraagt mijn gemiddelde maandpiek over de laatste 12 maanden 3 kW. Door in 2023 naar een lagere piek te streven zou ik op het nieuwe nettarief niets besparen. Maar dat is voor iedereen anders.
Ik meet bv. met een ET 112 in de automatenkast (waarvan de resultaten ook zichtbaar kunnen gemaakt worden in HA).

[lacer]

@ivob heb jij maar een 10 - 15 W sluipverbruik volgens deze grafiek, of hoe moet ik ze interpreteren ?

[ivob]

Dat is geen sluipverbruik maar het rollend vermogen dat er afgenomen (boven de 0-waarde op de Y-axis) wordt van het net of geïnjecteerd richting net (onder de 0-waarde op de Y-axis).
Mijn sluipverbruik (wat de AC-verbruikers in rust verbruiken en dat niet kan afgeschakeld worden zonder aan comfort in te boeten) schommelt meestal tussen de 40W en 90W met om de paar dagen een piek tot 150W - wanneer de diepvries in defrost modus gaat).

Dat is omdat de thuisaccu sinds midden november in herfstmodus staat.
Ipv -30 W (zomermodus) staat deze in de herfst op 0W en in de wintermaanden (december en januari) op +10W.
Gezien er meerdere factoren invloed hebben op het bereiken van de stabilisatiewaarde (plots hoge AC-afnemers, productiepieken door afwisselend heldere hemel en donkere wolken,....) krijg je in realiteit nooit een perfecte ingestelde waarde maar heb je in de zomer altijd een kleine teruglevering, in de herfst schommelt dat tussen miniem terugleveren en afnemen en in de winter in een kleine constante afname.

Wat je hiervoor ziet is de curve die de afname en injectie van het net weergeeft. Want deze heeft invloed op het capacitetstarief.
De curve met betrekking tot het real time AC verbruik ziet er uiteraard anders uit. Maar zolang de batterij niet onder 10% SOC daalt en kan bijspringen (of alle verruik leveren) heeft dat geen invloed op het afgenomen netvermogen.

Wat je op de vorige curve ziet is dus eigenlijk een totale overzichtsdetailweergave van wat je in het onderstaande overzicht in het groen omlijnd (real time weergave) ziet:
Het real time AC-verbruik is wat je blauw omlijnd ziet. Het totale detail overzicht van die box zie je daaronder.

Real time systeem meting:

Detail overzicht werkelijk AC-verbruik (blauw in voorgaande box):

Detail overzicht netafname (groen in voorgaande box):

[Joe de Mannen]

Ik heb het er ook ingezet, ik zie nu kwartierpieken onder de 0.5kWh in 'rust', geen idee of dat normaal is.
J.