België: Piekvermogen per dag/maand

[MathiasVDA]

De VREG (Belgisch opperhoofd van energie distributie) heeft beslist dat er vanaf 2022 netvergoeding betaalt moet worden op de gemiddelde maandvermogenpiek van de laatste 12 maanden.

De maandpiek is het maximaal kwartiervermogen.

En het kwartiervermogen is het gemiddelde vermogen gedurende 1 kwartier.

Wat voor mij nog onduidelijk is, is of het hier gaat over het totale vermogen (over de 3 fasen) of per fase.

Het zou interessant zijn om de kwartiervermogens of maandpieken ergens in grafiek of tabelvorm te kunnen raadplegen. Vandaar deze feature request.

[dennissiemensma]

Bedankt voor je verzoek. Om goed te beoordelen welke gegevens exact nodig zijn, zul je denk ik wat meer erover moeten aanleveren.
Wellicht dat er een grafiek voor nodig is of wellicht dat ik er simpelweg een query voor jullie voor kan maken waarmee je makkelijk het gemiddelde voor een jaar kunt zien. Daarnaast kan het dus zijn dat jullie in Belgie, voor een nauwkeurige nacalculatie daarvan, in DSMR-reader de (automatische) opschoning van metingen moeten uitschakelen. Dat heeft natuurlijk weer gevolgen voor de opslag en performance op den duur.

Dus wellicht kun je wat meer details hierover aanleveren. Anderzijds, als er landelijk nog geen details zijn, kun je ook overwegen om dit even te laten voor wat het is en er over een jaar of wat op terug te komen. En ondertussen kijken of je alle metingen vanaf 2021 wilt bewaren.

[MathiasVDA]

Dit gaat in België vrij bepalend worden voor de prijs van de netvergoeding te drukken. Maar daarnaast is het wellicht ook interessant voor mensen die overwegen om een thuisbatterij te plaatsen en/of volledig offgrid te gaan. Maximaal vermogen is heel relevant in die omstandigheden. Uiteraard kunnen we dat ook op 1 of andere manier uit de huidige database trekken met een query, maar als dat in realtime bekeken kan worden (en via domotica/smart devices/iot op ingespeeld kan worden om pieken te verkleinen), maakt dat de dsmr-reader zoveel waardevoller.

Wat ik in gedacht had was:

1. Onder "dashboard": extra regel voor max kwartierpiek zowel bij de dagsamenvatting als de maandsamenvatting
2. Onder "archive": extra grafiek met het piek kwartiervermogen en in de tabel een extra regel voor max kwartierpiek (indien dag/maand geselecteerd) of gemiddeld maandelijks max kwartierpiek (indien jaar geselecteerd)
3. Onder "compare", idem van "archive" maar dan enkel ivm de tabelvorm

En dan uiteraard soortgelijke aanpassingen bij de API en de MQTT.

Ik heb zelf al eens gekeken naar mijn eigen maandpieken. Een query die daarvoor werkt is deze:

with cal as
(
        SELECT ts AS t_begin, ts+ '15 minutes'::interval AS t_end
        FROM generate_series('2020-07-01 0:00'::timestamp, '2020-08-01 0:00', '15 minutes'::interval) ts
)
,avg_15min_gridpower as 
(
	select 
		cal.t_begin, 
		cal.t_end, 
		greatest(avg(dsmr.electricity_currently_delivered), avg(electricity_currently_returned)) as avg_15min_gridpower
	from cal
	left join public.dsmr_datalogger_dsmrreading dsmr on dsmr.timestamp >= cal.t_begin and dsmr.timestamp < cal.t_end
	group by cal.t_begin, cal.t_end
	order by cal.t_begin
)
,max_daily_gridpower as 
(
	select 
		date(t_begin) as date, 
		max(avg_15min_gridpower) as max_daily_gridpower
	from avg_15min_gridpower
	group by date(t_begin)
)
,max_monthly_gridpower as 
(
	select 
		date_trunc('month',date) as month, 
		max(max_daily_gridpower) as max_monthly_gridpower
	from max_daily_gridpower
	group by date_trunc('month',date)
),avg_yearly_gridpower as 
(
	select 
		date_trunc('year',month) as year, 
		avg(max_monthly_gridpower) as avg_yearly_gridpower
	from max_monthly_gridpower
	group by date_trunc('year',month)
)
select * from max_monthly_gridpower

Maar dit on demand berekenen is natuurlijk wel tijdrovend. Het zou beter zijn om de kwartierwaarden ergens weg te schrijven. Als de dsmr_consumption_electricityconsumption records gemiddelden bevatten van het opgenomen of verbruikt vermogen dan kan de query ook herschreven worden om deze tabel te gebruiken ipv dsmr_datalogger_dsmrreading.

Bonus:

• Onder "live charts": extra grafiek met de gemiddelde kwartierwaarden van de afgelopen 24u
• Onder "statistics": extra grafiek met hoogste kwartierpieken per tijdslot. Gelijkaardig aan de grafiek "AVERAGE ELECTRICITY CONSUMED EACH HOUR (IN %) WITHIN THE PAST 4 WEEKS"

[dennissiemensma]

Dank voor de uitgebreide toelichting.

Intepreteer ik het goed dat voor juli 2020 bij mij het hoogste gemiddelde verbruik binnen alle kwartieren 2,69 kW is geweest?

         month          | max_monthly_gridpower  
------------------------+------------------------
 2020-07-01 00:00:00+01 |     2.6930000000000000

En als ik voor een jaar kijk:

         month          | max_monthly_gridpower  
------------------------+------------------------
 2019-08-01 00:00:00+01 |     2.7340000000000000
 2019-09-01 00:00:00+01 |     2.3980000000000000
 2019-10-01 00:00:00+01 |     3.4080000000000000
 2019-11-01 00:00:00+00 |     3.1360000000000000
 2019-12-01 00:00:00+00 |     2.3810000000000000
 2020-01-01 00:00:00+00 |     3.1350000000000000
 2020-02-01 00:00:00+00 |     4.1980000000000000
 2020-03-01 00:00:00+00 |     3.2080000000000000
 2020-04-01 00:00:00+01 |     5.2400000000000000
 2020-05-01 00:00:00+01 |     4.0560000000000000
 2020-06-01 00:00:00+01 |     2.9030000000000000
 2020-07-01 00:00:00+01 |     2.6930000000000000

Dan zou ik (wanneer Belgisch) dus een vergoeding moeten betalen over het gemiddelde van bovenstaande? Los van of het over een kalenderjaar of contractjaar gaat.

En voor mijn beeld, niet nodig voor de feature, maar politiek gezien: Wat probeert men hiermee te belonen of af te straffen?

[MathiasVDA]

Dank voor de uitgebreide toelichting.

Intepreteer ik het goed dat voor juli 2020 bij mij het hoogste gemiddelde verbruik binnen alle kwartieren 2,69 kW is geweest?

         month          | max_monthly_gridpower  
------------------------+------------------------
 2020-07-01 00:00:00+01 |     2.6930000000000000

Dat is de correcte interpretatie ja. Je hoogste kwartiervermogen tijdens juli was 2,69 kW

En als ik voor een jaar kijk:

         month          | max_monthly_gridpower  
------------------------+------------------------
 2019-08-01 00:00:00+01 |     2.7340000000000000
 2019-09-01 00:00:00+01 |     2.3980000000000000
 2019-10-01 00:00:00+01 |     3.4080000000000000
 2019-11-01 00:00:00+00 |     3.1360000000000000
 2019-12-01 00:00:00+00 |     2.3810000000000000
 2020-01-01 00:00:00+00 |     3.1350000000000000
 2020-02-01 00:00:00+00 |     4.1980000000000000
 2020-03-01 00:00:00+00 |     3.2080000000000000
 2020-04-01 00:00:00+01 |     5.2400000000000000
 2020-05-01 00:00:00+01 |     4.0560000000000000
 2020-06-01 00:00:00+01 |     2.9030000000000000
 2020-07-01 00:00:00+01 |     2.6930000000000000

Dat lijkt mij een normaal verloop. Bij mij is het praktisch altijd 4kW - 500W. 4kW als het maximaal vermogen van de zonnepanelen en 500W wat zo ongeveer mijn standby verbruik is tijdens de dag. De VREG spreekt van een gemiddelde van 2,5kW voor een huishouden in België. Dat zal wel een gemiddeld gezin zonder zonnepanelen, een elektrische wagen of een groot inductievuur zijn.

Dan zou ik (wanneer Belgisch) dus een vergoeding moeten betalen over het gemiddelde van bovenstaande? Los van of het over een kalenderjaar of contractjaar gaat.

Dat klopt. Op dit moment betaal je in België een prijs per verbruikseenheid kWh, zowel voor de energie zelf (in zekere zin logisch) als voor de distributie van die energie (niet zo logisch). De VREG zegt nu dat de distributiekost geen verband houdt met de hoeveelheid energie (kWh) dat er doorgaat maar wel met het piekvermogen (de kW). Vanaf 2022 wordt de prijs die een consument zal betalen voor de distributie, berekend op basis van het maximaal vermogen en niet langer op basis van de kWh.

Eigenaars van zonnepanelen moeten nu al in België een extra bijdrage betalen om hun panelen aan het net te mogen aansluiten. Dat is ook een functie van het AC vermogen van de omvormer. Ongeveer 100€/kW. In mijn geval betaal ik dus 400€ per jaar voor mijn omvormer.

Meestal hebben mensen met zonnepanelen een netto nulverbruik, 0 kWh. Dus betalen ze geen energiekost noch een distributiekost (op uitzondering van het prosumententarief). Met de aanpassing van de VREG zal dat dus veranderen en zijn eigenaars van zonnepanelen dubbel gezien..

En voor mijn beeld, niet nodig voor de feature, maar politiek gezien: Wat probeert men hiermee te belonen of af te straffen?

Ha jah...
FYI: https://www.vreg.be/nl/toekomst-nettarieven-capaciteitstarief
Ik heb het hierboven al wat aangehaald. De officiële reden is dat ze mensen willen sensibiliseren dat het maximaal vermogen zo laag mogelijk moet zijn. Dus geen auto gaan opladen terwijl je frieten bakt. Of een thuisbatterij interessant maken.
Ik heb natuurlijk mijn eigen mening en veronderstellingen bij de nieuwe regeling. Het maakt bv niet uit hoevaak je een piek veroorzaakt (continue 5kW lijkt mij ergers dan 1x 5kW) of wanneer die juist optreedt (wat maakt het uit als je een piekafname doet wanneer er overschot is aan energie?). Volgens mij zien ze hun winsten dalen omdat er zoveel mensen zonnepanelen hebben en ze moeten hun inkomsten ergens vandaan halen... Soit, dat is mijn gedacht ...

Feit is wel dat niemand kaas heeft gegeten van kW's. De meesten begrijpen wel het principe van kWh en dat ze dit moeten betalen. Ik voorspel dat er veel verontwaardigde mensen gaan zijn als ze willen proberen hun energiefactuur te doen dalen. "Komaan, nu heb ik heel het jaar goed opgelet dat ik geen frieten bak en tegelijk de vaat doe en toch moet ik meer betalen dan vorig jaar". Terwijl het eigenlijk hun zonnepanelen zijn die meer kW's op het net zetten dan eender welk ander toestel dat ze in huis hebben kan verbruiken.

Door de kW's zichtbaar te maken (op de live grafiek van dsmr-reader is dit al zo, dus kudos!) worden die mensen geholpen.

[dennissiemensma]

Bedankt voor alle toelichting. Ik zal dit later nog eens rustig doornemen en kijken wat er mogelijk is. Ik vermoed dat er wel eea te regelen valt en ook wat toevoegt aan DSMR-reader, al weet ik nog niet exact in welke vorm (grafieken, tabellen, exports).

[MathiasVDA]

Correctie van wat ik hierboven heb vermeld. Het capaciteitstarief is enkel op afname, dus niet op injectie. De query wordt dan:

with cal as
(
        SELECT ts AS t_begin, ts+ '15 minutes'::interval AS t_end
        FROM generate_series('2020-07-01 0:00'::timestamp, '2020-08-01 0:00', '15 minutes'::interval) ts
)
,avg_15min_gridpower as 
(
	select 
		cal.t_begin, 
		cal.t_end, 
		avg(dsmr.electricity_currently_delivered) as avg_15min_gridpower
	from cal
	left join public.dsmr_datalogger_dsmrreading dsmr on dsmr.timestamp >= cal.t_begin and dsmr.timestamp < cal.t_end
	group by cal.t_begin, cal.t_end
	order by cal.t_begin
)
,max_daily_gridpower as 
(
	select 
		date(t_begin) as date, 
		max(avg_15min_gridpower) as max_daily_gridpower
	from avg_15min_gridpower
	group by date(t_begin)
)
,max_monthly_gridpower as 
(
	select 
		date_trunc('month',date) as month, 
		max(max_daily_gridpower) as max_monthly_gridpower
	from max_daily_gridpower
	group by date_trunc('month',date)
),avg_yearly_gridpower as 
(
	select 
		date_trunc('year',month) as year, 
		avg(max_monthly_gridpower) as avg_yearly_gridpower
	from max_monthly_gridpower
	group by date_trunc('year',month)
)
select * from max_monthly_gridpower

[dennissiemensma]

Dank voor de update! Ik kijk er meer in detail naar wanneer ik de feature inhoudelijk integreer.

[brainkiller]

Correctie van wat ik hierboven heb vermeld. Het capaciteitstarief is enkel op afname, dus niet op injectie.

Mag ik vragen waar je deze info gevonden hebt ? Ik kan geen verschil vinden tussen afnamen en injectie tijdens al mijn google searches.
Ik zou ook voorstellen om het configureerbaar te maken, ik zie de VREG nog hun beslissing herzien in de toekomst.

[MathiasVDA]

Correctie van wat ik hierboven heb vermeld. Het capaciteitstarief is enkel op afname, dus niet op injectie.

Mag ik vragen waar je deze info gevonden hebt ? Ik kan geen verschil vinden tussen afnamen en injectie tijdens al mijn google searches.
Ik zou ook voorstellen om het configureerbaar te maken, ik zie de VREG nog hun beslissing herzien in de toekomst.

Inderdaad, in de publieke communicatie van de vreg zag ik ook niets staan over of het nu ging over afname of injectie. Maar aangezien er het prosumententarief eigenlijk al een capaciteitstarief is op injectie was ik wat achterdochtig en heb ik de vraag aan de vreg gesteld. Dit waren mijn vragen:

1. ik het 3x220V aansluiting. Geldt het piekvermogen voor 1 fase of voor de drie fases samen?

2. wordt de kwartier piek bepaalt op enkel verbruik of ook op injectie?

3. Indien het piekvermogen bepaald wordt op beide, als er tijdens een kwartier zowel een hoog piekverbruik als een hoge piekinjectie is, niet tegelijkertijd, wordt dan de maximalepiek genomen of neutraliseren beide zich in dat kwartier?

4. zijn het vaste kwartieren over de dag? Bv 0u00 tot 0u15 enzovoort of zijn het vlottende kwartieren ifv pieken?

En dit was het antwoord:

Het capaciteitstarief zal aangerekend worden op basis van de ‘gemiddelde maandpiek (kW)’. Deze maandpiek staat los van het aansluitingsvermogen. Het maakt dus niet uit of u een eenfasige of driefasige aansluiting heeft.

Deze gemiddelde maandpiek zal berekend worden als het gemiddelde van uw 12 laatste ‘maandpieken’. De maandpiek is het hoogste kwartiervermogen (ofwel ‘piekvermogen’) dat u in een maand hebt gebruikt. Het wordt geregistreerd door de digitale meter. Het maakt hierbij niet uit hoe vaak (tijdens 1 kwartier of tijdens meerdere kwartieren) u dit piekvermogen heeft gebruikt. Als er nog geen meetgegevens van 12 maanden beschikbaar zijn, bv. na de vervanging van een klassieke meter door een digitale meter, zal de gemiddelde maandpiek berekend worden op basis van alle beschikbare maandpieken.

Wanneer een maandpiek kleiner is dan 2,5 kW, zal voor die maand een minimumwaarde van 2,5 kW worden verondersteld. Hierdoor zal élke netgebruiker een minimale jaarlijkse bijdrage betalen in de netkosten. Deze bijdrage zal gelijk zijn aan 2,5 kW vermenigvuldigd met het tarief voor de gemiddelde maandpiek.

De andere kosten opgenomen in de distributienettarieven, met name de kosten voor openbaredienstverplichtingen, de toeslagen en de overige transmissiekosten, zullen blijven  aangerekend worden op basis van de afgenomen kWh. 

Het capaciteitstarief is een afnametarief: het wordt aangerekend o.b.v. uw maandelijkse afnamepieken; injectiepieken worden niet in rekening genomen.

Het zijn vaste kwartieren. Dus tussen 18:00 en 18:15, tussen 0:00 en 0:15,…

De kwartierwaarden (kWh) die de digitale meter registreert zijn per ‘vast’ kwartier.

Ook voor de volledige marktwerking (allocatie van energiehoeveelheden, evenwichtsverantwoordelijkheid naar Elia toe, e.d.) wordt met deze vaste kwartieren gewerkt.

Op mijn eerste vraag is niet echt een antwoord gekomen. Maar ik ga ervan uit dat de som van de drie fasen van toepassing is.

[gigatexel]

Op basis van de Vlaamse digitale meter, uitlezing via DSMR in Home Assistant, is dit de query die je de piek van de afgelopen maand geeft.
Bij nieuwe maand dient de oude steeds opgeslagen te worden omdat deze impact heeft op de verrekening van die specifieke maand.
Opgelet! De kwartierpiek geldt niet voor injectie!

      - name: Maandpiek
        column: 'Maandpiek'
        unit_of_measurement: "kW"
        query: "
        select Round((a.verschil+b.verschil)*4,2) as Maandpiek, a.time as time FROM 
        (SELECT
        FROM_UNIXTIME((UNIX_TIMESTAMP(created) DIV 900 * 900)+3600, '%d-%c-%Y %H:%i:%s') AS time,
        entity_id AS metric,
        (state - lag(state) over (order by created)) as verschil
        FROM states
        WHERE
        MONTH(created) = MONTH(CURRENT_DATE()) AND YEAR(created) = YEAR(CURRENT_DATE()) AND entity_id = 'sensor.energy_consumption_tarif_1' AND state != 'unknown'
        GROUP BY 1 ORDER BY created DESC) as a
        inner JOIN
        (SELECT
        FROM_UNIXTIME((UNIX_TIMESTAMP(created) DIV 900 * 900)+3600, '%d-%c-%Y %H:%i:%s') AS time,
        entity_id AS metric,
        (state - lag(state) over (order by created)) as verschil
        FROM states
        WHERE
        MONTH(created) = MONTH(CURRENT_DATE()) AND YEAR(created) = YEAR(CURRENT_DATE()) AND entity_id = 'sensor.energy_consumption_tarif_2' AND state != 'unknown'
        GROUP BY 1 ORDER BY created DESC) as b
        on a.time = b.time
        ORDER BY Maandpiek DESC 
        LIMIT 1"```

[dennissiemensma]

@VBP8501 @gigatexel zijn hier nog ontwikkelingen in geweest bij de invoering dit jaar, tov wat jullie tzt geprojecteerd hadden?

Deze feature is helaas afgelopen jaar flink vertraagd door andere issues in DSMR-reader, maar het staat nog wel op de planning. Mits het enigszins te behappen is uiteraard.

[gigatexel]

@VBP8501 @gigatexel zijn hier nog ontwikkelingen in geweest bij de invoering dit jaar, tov wat jullie tzt geprojecteerd hadden?

Deze feature is helaas afgelopen jaar flink vertraagd door andere issues in DSMR-reader, maar het staat nog wel op de planning. Mits het enigszins te behappen is uiteraard.

Als alles volgens plan gaat - wat in gepolitiseerde dossiers geen zekerheid is - gaat het capaciteitstarief van start op 01/07/2022

Ik heb ondertussen bovenstaande query nog wat geoptimaliseerd en ook specifieke indexen gemaakt in MariaDB omdat het soms langer dan 10 seconden duurder om te draaien.

[MathiasVDA]

Inderdaad.. De huidige hoge elektriciteitsprijzen spreken niet in het voordeel van het capaciteitstarief. Ik acht de kans op aanpassingen wel vrij klein, de terugdraaiende teller is uiteindelijk ook afgeschaft, ongeacht wat de politiek ervan dacht. Er zijn op dit moment in België enkele studies die aantonen dat het capaciteitstarief aanleiding geeft tot een hogere factuur bij kleinverbruikers (wat logisch is) en een lagere bij grootverbruikers. En dat komt natuurlijk niet zo goed over.

Ik heb de query zelf ook verder geoptimaliseerd door periodiek het kwartiervermogen weg te schrijven. In dsmr zou je dat kunnen opnemen in de dagsamenvatting. Een analyse doen op de dag zelf (welk kwartier exact de piek plaatsvond) is wel te doen qua snelheid met een query op de minuutgemiddelden. Maar voor de meeste use cases te dekken zullen dag, maand en jaar resultaten wel voldoende zijn

[gigatexel]

Kan je jouw query ook delen?

[MathiasVDA]

Kan je jouw query ook delen?

Jazeker, wel pas deze avond

[MathiasVDA]

Kan je jouw query ook delen?

Ik heb uiteindelijk twee views gemaakt die ik via grafana benut:

create view own.kwartiervermogens as (
with cal as (
	SELECT ts AS t_begin, ts+ '15 minutes'::interval AS t_end
	FROM generate_series('2019-11-01 0:00'::timestamp, now()-interval '15 minutes', '15 minutes'::interval) ts
)

	select 
		cal.t_begin, 
		cal.t_end, 
		avg(dsmr.currently_delivered) as avg_15min_gridpower
	from cal
	left join public.dsmr_consumption_electricityconsumption dsmr on dsmr.read_at >= cal.t_begin and dsmr.read_at < cal.t_end
	group by cal.t_begin, cal.t_end
	order by cal.t_begin
)

UPDATE: bovenstaande query kan beter, zie hieronder

create view own.kwartiervermogen_monthly as (
with avg_15min_gridpower as (select * from own.kwartiervermogens)
,max_daily_gridpower as 
(
	select 
		date(t_begin) as date, 
		max(avg_15min_gridpower) as max_daily_gridpower
	from avg_15min_gridpower
	group by date(t_begin)
)
,max_monthly_gridpower as 
(
	select 
		date_trunc('month',date) as month, 
		max(max_daily_gridpower) as max_monthly_gridpower
	from max_daily_gridpower
	group by date_trunc('month',date)
),avg_yearly_gridpower as 
(
	select 
		date_trunc('year',month) as year, 
		avg(max_monthly_gridpower) as avg_yearly_gridpower
	from max_monthly_gridpower
	group by date_trunc('year',month)
)
select * from max_monthly_gridpower)

("own" is een eigen schema naast public)

De berekening waar ik naar verwijs is eigenlijk een download van mijn data in pvoutput.org. Omdat dsmrreader de gegevens van mijn pv omvormers niet benut, moet ik die nog op een andere manier samenbrengen om bv analyses te kunnen doen naar een thuisbatterij. Pvoutput heeft maar datapunten iedere 5minuten dus de berekeningen voor kwartierpieken (gelijkaardig aan bovenstaande views) gaan heel vlot.

[dennissiemensma]

Bedankt voor jullie aanvulling! Betekent dit dat een lagere frequentie van telegrammen in DSMR-reader ook een grote invloed heeft op de nauwkeurigheid van bovenstaande? Dus in het geval dat iemand de meter slechts elke 5 a 10 seconden uitleest, ipv elke seconde.
In principe zal teruglevering en grootverbruik (wasmachine, oven, etc) niet om de 5 a 10 seconden wisselen van piekbelasting, maar ze wisselen wel en dat lijkt me nog wel een uitdaging dan.

Aan de andere kant zullen de meeste gebruikers wel een DSMR-5 meter hebben die elke seconden uitleest, dus misschien is het wat minder een issue als ik de standaard datalogger-sleep wat verlaag. Inmiddels schoont DSMR-reader later wel de metingen op en als ik ervoor zorg dat ik voor die tijd de kwartiervermogens heb berekend en apart opsla (wat sowieso al het plan was), dan is dat misschien afdoende.

[dennissiemensma]

@VBP8501 zie de bovenste screenshot van #1084 (comment)

Wat moet de berekening zijn als de gemeten periode niet exact 15 minuten is? Het komt niet op een seconde aan, maar ik kan me voorstellen dat in sommige situaties gebruikers bijvoorbeeld 10 seconden na start/voor einde de eerste/laatste telegrammen krijgen (is reeel met niet-v5-meters of met datalogger delay/sleep).

Dus een ideale gemeten periode van 15 minuten is 900 seconden. Maar als die periode bijvoorbeeld 800 seconden is, moet ik dan alsnog gewoon x4 doen voor het uur en de onnauwkeurigheid voor lief nemen?
Of moet ik de berekening relativeren op het uur? Dus het kwartiergemiddelde delen door die (bijvoorbeeld) 800 seconden, x 3600 voor het uur?

Het kan overigens ook gewoon een kwestie van afwachten zijn of het uberhaupt een probleem is. Doordat ik de lengte van de gemeten periode log/bereken, is het opzich ook weer duidelijk voor de gebruiker als daar een verschil in zit.

[dennissiemensma]

Ik heb de weergave nog iets aangepast. Verder zit de huidige opzet alvast inde v5.2 branch, zodat ik hem zelf ook al kan draaien.

Het mechanisme voor terugwerkende kracht werkt goed, want tot aan het punt van verwijderde data (bij mij staat retentie op een week) is goed te zien vanaf welk punt er weer genoeg metingen zijn:

[dennissiemensma]

Verder heb ik nu ook mn recent verbruik bekeken en ik heb alvast mn mobiele airco aangezet voor het slapen, dus dat is ook goed te zien.

Laatste X uur

Tot aan 21:45 een constant verbruik van 100 a 300 Watt, daarna schiet het omhoog en in de 3 a 4 kwartieren daarna is het goed te zien en zit het rond de 800 a 900 watt en dat komt het in gemiddelde ook goed naar voren.

Bijbehorende grafiek

---

Hoogste kwartiergemiddelde deze maand

Hoogste pieken vooral rond etentijd (ik kook inductie) maar soms ook de close-in boiler vermoed ik overdag.

[dennissiemensma]

Tot slot is goed te zien dat ik nog een v4 meter heb. Ik heb telkens meetperiodes van 14:40 lang, door de 10 seconde interval aan telegrammen.

Edit: Ik was vergeten dat ik een datalogger-sleep van 10 seconden gebruik, dus dat kan soms bijten. Ik zal hem een tijdje lager zetten.

[dennissiemensma]

Follow-up via #1635. Eerst maar eens een tijdje draaien om te zien of het goed werkt. Verder ook geen idee hoeveel gebruikers dit daadwerkelijk nodig hebben, gezien ik verwacht dat het gros zich in NL bevindt.

[dennissiemensma]

Als alles meezit dan morgenavond v5.2 releasen.

[MathiasVDA]

@VBP8501 zie de bovenste screenshot van #1084 (comment)

Wat moet de berekening zijn als de gemeten periode niet exact 15 minuten is? Het komt niet op een seconde aan, maar ik kan me voorstellen dat in sommige situaties gebruikers bijvoorbeeld 10 seconden na start/voor einde de eerste/laatste telegrammen krijgen (is reeel met niet-v5-meters of met datalogger delay/sleep).

Dus een ideale gemeten periode van 15 minuten is 900 seconden. Maar als die periode bijvoorbeeld 800 seconden is, moet ik dan alsnog gewoon x4 doen voor het uur en de onnauwkeurigheid voor lief nemen? Of moet ik de berekening relativeren op het uur? Dus het kwartiergemiddelde delen door die (bijvoorbeeld) 800 seconden, x 3600 voor het uur?

Het kan overigens ook gewoon een kwestie van afwachten zijn of het uberhaupt een probleem is. Doordat ik de lengte van de gemeten periode log/bereken, is het opzich ook weer duidelijk voor de gebruiker als daar een verschil in zit.

idealiter ga je inderdaad de effectieve seconden gebruiken om de vermeningvuldigingsfactor te bepalen. Als het dus exact 15 min of 900s is dan doe je maal 4 (want 3600/900=4). Bij een afwijkende waarde moet je inderdaad 3600/echte_seconden doen. Dus in jouw voorbeeld 3600/800=4,5

[MathiasVDA]

Follow-up via #1635. Eerst maar eens een tijdje draaien om te zien of het goed werkt. Verder ook geen idee hoeveel gebruikers dit daadwerkelijk nodig hebben, gezien ik verwacht dat het gros zich in NL bevindt.

Alvast 2 gebruikers bevinden zich in België :)
En aan de opmerkingen van anderen in deze thread te zien, zijn het er precies wel meer ^^

[verstrepeng]

Hier nog een Belg ;-)
Ik gebruik de HA add-on, dus wachten tot deze geupdate is naar 5.2 ?

[dennissiemensma]

Bedankt voor jullie aanvulling!

Ik heb zojuist v5.2 getagged. Voor de docker images hangt het af van o.a. Xirixiz, maar die zijn meestal wel redelijk vlot.

[dennissiemensma]

Follow-up dus via #1635. De versie die in v5.2 zit is een begin en ik verwacht echt nog wel wat nodige aanpassingen, maar dan wordt er nu al "iets" berekend.

En bij toekomstige wijzigingen is het vrij makkelijk om het te laten herberekenen door DSMR-reader (zolang de metingen er zijn), gezien deze data over piekvermogens naast de bestaande data draait en dus verder ook niets anders raakt. Het is meer verrijking van bestaande data.

Een ander punt is bijvoorbeeld de rotatie van deze data. Opzich valt de grootte wel mee, want bij een gemiddelde maand van 30 dagen maal 96 kwartieren in een dag, zijn < 3000 records per maand. Op lange termijn kost dat wel wat opslag, maar het gaat (gelukkig) uiteraard lang niet zo snel als elke seconde een meting opslaan.

[qbushome]

Zeker nog 1 Belg extra hier.
Dennis, bedankt dat je dit wil uitwerken/toevoegen.

Bereken je ook de piek van het huidige kwartier?
Waarom is dat nuttig? Wel, je hebt een grote verbruiker die je kan in/uitschakelen (dus geen wasmachine maar bvb een elektrische boiler).
Stel: die verbruik 3kw en je wil dat je pieken nooit boven de 3kwh uitkomen. Wanneer je (zoals in mijn geval in Home Assistant) dan zou weten dat de huidige kwartierpiek bvb 2,5kwh is (na ongeveer 10 minuten), dan zou je die boiler kunnen uitschakelen. Zo blijft er nog over voor andere verbruikers zonder dat je die 3kwh passeert.
Gewoon de boiler 10 minuten aan, en 5 minuten uit is risicovoller, want je weet niet of je in dat specifieke kwartier een andere grote verbruiker hebt (bvb 5 minuten een haardroger).

Maar dan moet die huidige (voorlopige) piek wel ook beschikbaar zijn via MQTT uiteraard.

Is dat haalbaar denk je?

• huidige piek berekenen
• beschikbaar maken via mqtt

Bedankt!

[dennissiemensma]

Bedankt voor je suggestie! Ik denk dat het handiger is om dat zelf in HA te berekenen, zodat je zelf de controle hebt over de intervallen/updates/triggers. Je kunt het op meerdere manieren en punten berekenen, want wellicht wil je altijd live de piek van de laatste 5, 10 en 15 minuten berekenen, zodat je op basis daarvan beslissingen kan nemen.

Daarnaast lijkt HA me daar ook een wat logischere plek voor, helemaal omdat DSMR-reader slechts "een" manier is om meterstanden in HA te krijgen, maar zeker niet de meest efficiente. Idem voor gerelateerde data.

DSMR-reader richt zich vooral op de analyse van gegevens achteraf, waarbij het nooit een vereiste is (of is geweest) dat het realtime verwerking moet zijn. Hoewel DSMR-reader dat in het gunstigste geval wel doet, kan ik dat nooit garanderen. De MQTT-integratie is meer ter deling van de beschikbare gegevens, maar niet een einddoel.
En ik denk dat je bij zo'n belangrijke monitor voor je use-case hierboven je eigenlijk zo dicht mogelijk bij de data moet zitten en ook zelf vrij moet zijn in wat je in de gaten wilt houden en op welke momenten.

[MathiasVDA]

Ik gebruik openhab en doe de berekening van het kwartiervermogen daarin. Een bijkomend voordeel, naast wat Dennis al aanhaalt, is dat je ook rekening kunt houden met de huidige maximale piek van de lopende maand. Als je standaard schakelt bij om onder 3kW gemiddeld uit te komen en je gaat er toch nog eens over, bijvoorbeeld je hebt al eens 4kW kwartiervermogen bereikt, dan is het logischer om verder te werken met de nieuwe piek, 4kW, om te schakelen.

[dennissiemensma]

@VBP8501 zijn de (lijstweergaves) in DSMR-reader v5.2 representatief voor wat je zelf al registreerde? Afgezien van de afwijking doordat DSMR-reader (nu nog) 15 minuten gebruikt als periode om te rekenen ipv de exact gemeten periode.

[FredericMa]

Ik heb tot nu toe ook eigen metingen gemaakt in HA en de waarden in HA matchen met de geregistreerde waarden in DSMR-reader.

[dennissiemensma]

Dank voor het checken!

[MathiasVDA]

@VBP8501 zijn de (lijstweergaves) in DSMR-reader v5.2 representatief voor wat je zelf al registreerde? Afgezien van de afwijking doordat DSMR-reader (nu nog) 15 minuten gebruikt als periode om te rekenen ipv de exact gemeten periode.

Sorry, ik heb al 2 weken performantie problemen met dsmr-reader. (cpu van mijn rapi gaat naar 100% en de docker container van dsmr crasht daardoor). Sinds de stroom in de straat is uit gezet omwille van een brand. Geen idee of de omstandigheden iets te maken hebben met de problemen maar daardoor kan ik niet verifiëren of de berekening OK is. Nadat ik had geupgrade naar 5.2 heb ik wel eens vlug gekeken en de getallen waren in grote orde wel correct. Van zodra ik mijn systeem terug stabiel krijg dan post ik hier het resultaat

[dennissiemensma]

Mocht je nog wat hulp nodig hebben met het debuggen van de performance-problemen, maak dan vooral even een los issue aan.

[MathiasVDA]

@dennissiemensma : performantieproblemen waren te wijten aan een andere container die op dezelfde pi draaide. Heel vreemd maar toen ik die op een andere pi opstartte werkte alles in dsmr reader weer normaal.

De berekende waarden van dsmr reader zijn correct. Ik heb de waarden van de afgelopen dag vergeleken met wat ik zou berekenen en zie een minimaal verschil (gemiddeld 0,5W).

Ik heb wel een paar opmerkingen over de eenheden:

De waarde die je berekend is in kW (dus niet in kWh of kW/h). In de screenshot zouden de rode vakjes "kW" moeten worden en de blauwe "kWh/15m".

[dennissiemensma]

Bedankt voor je update! Ik voeg het toe aan #1635

[Milithor]

Nog een belg hier, die even een bedankje wil uitbrengen aan degene die de moeite doen om dit erin te krijgen!
Ook die MQTT ontsluiting naar HomeAssistant lijkt me zeer interessant!

[dennissiemensma]

Follow-up via #1635