⚠️ Foutieve berekeningen in dagtotalen/Archief

[nickgr6]

Description

Beste,

Ik ben in het proces om mijn beeclear te vervangen door een device waarop ik dsmr reader ga draaien. Ter voorbereiding ben ik nu alle historische data aan het migreren mbv de api. Dit lijkt allemaal goed te zijn gegaan.

Toen ik echter de totalen vergeleek tussen beeclear (en vattenfall die gelijk zijn aan beeclear) en de dsmr interface, zag ik verschillen. Ook zie ik inconsistentie in de 'archive' pagina van totalen.

Het volgende toont in de archive voor 2 december:

De data view voor gasverbruik per uur toont:

 	Gas
0:00	0
1:00	0
2:00	0
3:00	0
4:00	0
5:00	0
6:00	0
7:00	0
8:00	0.019
9:00	0.219
10:00	0.598
11:00	0.485
12:00	0.149
13:00	0.112
14:00	0.279
15:00	0.007
16:00	0.044
17:00	0.076
18:00	0.07
19:00	0.026
20:00	0.02
21:00	0.136
22:00	0.083
23:00	0
0:00	0.475

Als ik die optel, kom ik uit op 2.798. Maar de interface toont 2.323. Het lijkt er dus op dat de laatste meting niet wordt meegenomen (0.475). Dus mijn aanname was dat dat uur wellicht bij de volgende dag hoort aangezien de data view 2x 0:00 toont. Als ik echter de volgende dag bekijk zie ik:

 	Gas
0:00	0.475
1:00	0
2:00	0
3:00	0
4:00	0
5:00	0
6:00	0
7:00	0
8:00	0.215
9:00	0.24
10:00	0.484
11:00	0.379
12:00	0.106
13:00	0
14:00	0.006
15:00	0.172
16:00	0.119
17:00	0
18:00	0.005
19:00	0.012
20:00	0.358
21:00	0.15
22:00	0.318
23:00	0.043
0:00	0

Hier komt het totaal van 2.607 echter wel overeen met mijn meting in beeclear/vattenfall en wordt 0.475 van de eerste 0:00 meting dus ook niet meegenomen in de optelsom. Het lijkt er dus op dat die meeting in beide dagen niet wordt meegenomen.

De dag rows in de dsmr_stats_hourstatistics db:
198069,2022-12-02 00:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198070,2022-12-02 01:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198071,2022-12-02 02:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198072,2022-12-02 03:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198073,2022-12-02 04:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198074,2022-12-02 05:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198075,2022-12-02 06:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198076,2022-12-02 07:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.019
198077,2022-12-02 08:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.219
198078,2022-12-02 09:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.598
198079,2022-12-02 10:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.485
198080,2022-12-02 11:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.149
198081,2022-12-02 12:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.112
198082,2022-12-02 13:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.279
198083,2022-12-02 14:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.007
198084,2022-12-02 15:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.044
198085,2022-12-02 16:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.076
198086,2022-12-02 17:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.070
198087,2022-12-02 18:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.026
198088,2022-12-02 19:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.020
198089,2022-12-02 20:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.136
198090,2022-12-02 21:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.083
198091,2022-12-02 22:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.000
198092,2022-12-02 23:00:00.000000 +00:00,0.000,0.000,0.000,0.000,0.475

De daystatistics waardes in de database lijken ook correct:

Ook het opnieuw runnen (en stats opschonen en weer runnen) van /app/manage.py dsmr_stats_reconstruct_missing_day_statistics blijft hetzelfde resultaat geven.

Gezien dsmr reader al zo'n volwassen product is (complimenten voor alle opties :)!), ga ik er vanuit dat er ergens een fout zit in de migratie oid. Echter lijkt de data in de db correct. Vandaar dat ik toch dit ticket heb aangemaakt. Aanvullend: er worden nog geen live metingen gedaan en verwerkt, dus dat kan niet in de weg zitten.

Enig idee waar het misgaat of wat ik zelf nog verder kan controleren om daar achter te komen?

Alvast bedankt!

DSMR-reader version

5.9

DSMR-reader platform

docker-compose (relevante config):

  postgres:
    image: postgres:15-alpine

  dsmr-reader:
    image: xirixiz/dsmr-reader-docker:latest
    environment:
      - TZ=Europe/Amsterdam
      - DJANGO_TIME_ZONE=Europe/Amsterdam
      
### Debug info dump

_No response_

[dennissiemensma]

Bedankt voor je melding en zeer uitgebreide beschrijving. De tijden van het gasverbruik zouden altijd het begin van het uur moeten aangeven. 23:00 betekent dan "tussen 23:00 en 0:00".
Echter is dat niet waterdicht, want gasmeters hebben soms wat minuten na de uurwisseling nodig voordat ze (of de slimme meter) bijwerken. Al zou DSMR-reader dat wel moeten afvangen.

• Heb je trouwens oude metingen geimporteerd en laten verwerken, of direct de uren en dagen geschreven?

• Ik denk dat het voor nu het makkelijkste is om te kijken of je dezelfde issues hebt wanneer je DSMR-reader wel live metingen laten verwerken.

[nickgr6]

Oude metingen heb ik via de api ingeschoten en laten verwerken. Die tabel miste nog in de omschrijving:
dsmr_datalogger_dsmrreading:

2022-12-02 22:00:00.000000 +00:00,6151.057
2022-12-02 23:00:00.000000 +00:00,6151.532

Nu ik nog eens naar de dates kijk, valt me wel iets op. Volgens mij is deze kolom een UTC timestamp. Als ik SHOW TIMEZONE; query run, krijg ik namelijk UTC. Aangezien de wintertijd in NL UTC + 1 is, zou dit wellicht betekenen dat als je een 'nederlandse dag' queried, 2022-12-02 23:00:00.000000 +00:00er buiten valt, aangezien dat in NL tijd neerkomt op 2022-12-03 00:00:00.000000 +01:00, toch..? Maar ook nadat ik daarmee speel komen de totalen nog niet helemaal overeen na migratie. Als ik het goed zie, valt nu consequent het eerste uur buiten de boot. Ik verwacht dus dat er ook nog ergens een mismatch is in mijn script mbt jou opmerking "De tijden van het gasverbruik zouden altijd het begin van het uur moeten aangeven. 23:00 betekent dan "tussen 23:00 en 0:00". Het is mijn eer eigenlijk te na, maar als ik er echt niet uitkom, negeer ik het probleem misschien wel. Het gaat namelijk niet om heel veel verbruik in die uren als ik de jaartotalen bekijk. Of ik los het met een hacky workaround op door 00:00 en 01:00 in de beeclear export op te tellen en als 1:00 op te slaan 😅..

Anyway, ik ben er weer even klaar mee voor vandaag. Ik hou je op de hoogte van de verdere ontwikkelingen.

De nieuwe hardware waar ik dsmr reader op ga runnen is helaas nog niet gereed, dus kan ik nog geen live metingen mee testen.

[dennissiemensma]

Als het goed is slaat Postgres altijd timezone aware datetimes op als UTC. Wat je daarna terugkrijgt bij ophalen hangt af van je sql client en of je een tijdzone opgeeft bij verbinden. Zie de queries in: #1217 (comment)

• Welke tijdzone gebruik je bij het inschieten via de API? DSMR-reader staat in principe alles toe, zolang ze relatief gezien maar kloppen (lokale tijd of UTC).

Verder kan het wel eens een edge-case zijn hoor, want als je de meterstanden uit je screenshot optelt, kom je op 6151.532 - 6148.734 = 2.798 van je sheet.

• Wat zijn de DB records in dsmr_consumption_gasconsumption rond middernacht tussen 2 en 3 december?

[nickgr6]

Ik converteer het naar een UTC timestamp voor ik het in de api inschiet. Waarbij er rekening gehouden wordt met zomer/wintertijd.

Aangezien ik merkte dat consequent alleen het laatste uur van de dag niet werd meegeteld in het totaal dagverbruik, heb ik nog een extra uur van de beeclear tijd afgehaald bij omzetten van de timestamp naar utc Dit lost het probleem op voor dagen met verbruik in het laatste uur (zelfde geldt voor elektra). Echter werden daarna juist de dagen weer met verbruik in het eerste uur incorrect (wat daarvoor nog goed ging).

vertalen gaan de dagen goed waarbij er geen gas (zelfde geldt overigens voor elektra) verbruikt is in het eerste uur, dus dat geldt voor bijv 2 december:

De uur grafiek komt dan ook overeen met die van beeclear:

Nu gaat het dus bijv. weer mis op 4 december:

Hoewel ook hier de uur grafiek matched met die van beeclear:

Echter is de 'Meterstand bij eerste meting van de dag' anders dan in beeclear:

Hij pakt dus de 2e meterstand: 6.154,474 m3

Voorbeeld van conversie:

beeclear 03-12-2022 23:00
offset -120
result 2 2022-12-03T21:00:00.000Z
meter 6154.139

beeclear 04-12-2022 00:00
offset -120
result 2 2022-12-03T22:00:00.000Z
meter 6154.139

beeclear 04-12-2022 01:00
offset -120
result 2 2022-12-03T23:00:00.000Z
meter 6154.474

beeclear 04-12-2022 02:00
offset -120
result 2 2022-12-04T00:00:00.000Z
meter 6154.474
...

beeclear 05-12-2022 00:00
offset -120
result 2 2022-12-04T22:00:00.000Z
meter 6157.798

Bij deze even een export van de belangrijkste db tabellen:
db-export.zip

En de beeclear gas csv export wat de bron is voor de migratie:
gas.csv

Wellicht valt je iets op?

Het voelt voor mij echter niet als een edge case, omdat het consequent ofwel het laatste uur is wat niet meegeteld wordt dan wel het eerste uur 😅

[dennissiemensma]

Bedankt voor je aanvulling. Ik kan nu niet zo 1-2-3 in de data kijken.

Mijn vermoeden is nog steeds dat als er een optelling niet klopt, het een edge-case is qua bounds in DSMR-reader.
Daar is eerder ooit iets in gekomen wat niet hoorde. Dus dat is gerevert via 4a1d40d.

Voor de duidelijkheid, wat klopt er nunog steeds niet?

• Het gasverbruik per uur?
• Het gasverbruik per dag?
• De eerste (gas)meterstanden van de dag?
• Alle bovenstaande?

Is het mogelijk om zowel DSMR-reader als BeeClear de meter te laten uitlezen voor een paar dagen? Je kunt DSMR-reader immers makkelijk leeggooien totdat de oorzaak boven water is.

[nickgr6]

Het gasverbruik per uur gaat goed.

Wat er nog niet goed gaat in het vb. van 2 december:

1. Meterstanden bij eerste meting van de dag Gas: 6.154,474
   in beeclear matched dit met de 2e meting van de dag: 01:00 04-12-2022. Ik zou echter de eerste waarde zoals in beeclear verwachten: 00:00 04-12-2022 6.154,139 m3

2. Het totaal gasverbruik van deze dag toont 3,324 in dsmr. In beeclear is het totaal 3,659. Hier zit dus 0,335 verschil tussen. Dit is precies het verschil tussen 00:00 en 01:00 op die dag zoals wel weergegeven in de dsmr uur grafiek:

En de data view:

 	Gas
0:00	0.335
1:00	0
2:00	0.188
3:00	0.282
4:00	0.213
5:00	0.14
6:00	0
7:00	0.121
8:00	0.44
9:00	0.498
10:00	0.311
11:00	0.005
12:00	0.005
13:00	0.005
14:00	0.104
15:00	0.256
16:00	0.261
17:00	0.247
18:00	0
19:00	0.012
20:00	0.074
21:00	0
22:00	0.162
23:00	0
0:00	0

Als je alle waardes van de dataview optelt, kom je ook uit op 3,659.

Om beide te monitoren moet ik even een 2e P1 kabel en splitter kopen, maar dat zou een optie kunnen zijn.

[dennissiemensma]

Ik weet niet helemaal zeker of ik onderstaade goed intepreteer, maar als ik je SQL datadump goed lees dan komt de eerste meterstand op 4 december overeen met die 6.154,474.

Dat lijkt de waarde op 23:00 UTC de dag ervoor, dus middernacht onze tijd/CET. Dat uur 0,335 zou dan zelfs nog bij de vorige dag 3 december horen. van 23:00 - 00:00 CET (of 22:00 - 23:00 UTC).
Dan nog is het vreemd dat die in DSMR-reader op 4 december komt en niet 3 december.

---

Ik denk dat het goed is om dat extra uur er niet af te halen, zodat ze weer in lijn zijn. Anders is het sowieso niet te debuggen.
Mits beeclear CET/CEST is en niet UTC.

Links CET in beeclear CSV? Rechts is UTC in SQL dump.

---

Heb je ook al eens geprobeerd om de tijden gewoon als CET/CEST in te schieten en niet UTC? Dat maakt het wellicht makkelijker, tenzij de beeclear in UTC is.

Als het goed is kun je gewoon +01:00 en +02:00 opgeven aan de API ipv Z. #1771 (comment)

[nickgr6]

Net even via postman een testje gedaan. Als ik 2025-01-15T12:34:56+01:00 belandt dit in de DB gewoon in UTC format zonder offset: 2025-01-15 11:34:56.000000 +00:00. Heeft dus denk weinig nut om mijn migratiescript daarop aan te passen. Jammer, want als het in de database met +1:00 of +2:00 notatie zou blijven zou het makkelijker te vergelijken zijn ipv steeds UTC met CET te moeten vergelijken.

Beeclear is CET/CEST:

Als ik de extra offset eraf haal dan klopt idd het totaal van 4 dec, maar zoals eerder ook vermeld, gaat dan een dag met gasverbruik in het laatste uur weer fout 😅 :

Waarbij gas.csv de beeclear export betreft.
Volgens mij kloppen de waardes in deze tabel?

Maar je ziet dan echter in de uur grafiek, dat alles een uur 'verschoven' is en het laatste uur niet wordt meegeteld

Totaal verbruik in dsmr: 5,390 en in beeclear 5,977m3, wat dus precies het verschil is van de laatste waarde..

Als ik kijk naar tabel dsmr_stats_daystatistics zie ik:

Volgens mij klopt deze tabel niet: 6179.756 - 6173.779 = 5.977 en niet 5.390. Beeclear geeft ook 5.977 aan.

De meterstand van de dagen in de tabel komen wel overeen met beeclear:

Lijkt er dus op dat kolom gas incorrect berekend wordt?

[dennissiemensma]

Net even via postman een testje gedaan. Als ik 2025-01-15T12:34:56+01:00 belandt dit in de DB gewoon in UTC format zonder offset: 2025-01-15 11:34:56.000000 +00:00. Heeft dus denk weinig nut om mijn migratiescript daarop aan te passen. Jammer, want als het in de database met +1:00 of +2:00 notatie zou blijven zou het makkelijker te vergelijken zijn ipv steeds UTC met CET te moeten vergelijken.

Bedankt voor je aanvulling. Voor de duidelijkheid, het gaat er mij niet zozeer om wat de database opslaat, want dat is altijd UTC. Het gaat er vooral om dat je dan zelf niet de conversie hoeft te doen, als je brondata niet UTC is. Als dat het makkelijker voor jezelf maakt.

Je kunt zelf in postgres aangeven in welke tijdzone je de data terug wilt hebben, dat staat los van de UTC-opslag. Zie hieronder als voorbeeld dezelfde data in andere tijdzones.
Wellicht kun je je SQL client daarop instellen en anders handmatig via een query zoals hieronder.

dsmrreader=# SET TIMEZONE='Europe/Amsterdam';
SET
dsmrreader=# select id, timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;
    id    |       timestamp        
----------+------------------------
 19422064 | 2022-12-22 20:33:27+01
 19422063 | 2022-12-22 20:33:17+01
 19422062 | 2022-12-22 20:33:07+01
 19422061 | 2022-12-22 20:32:57+01
 19422060 | 2022-12-22 20:32:47+01
(5 rows)

dsmrreader=# SET TIMEZONE='UTC';
SET
dsmrreader=# select id, timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;
    id    |       timestamp        
----------+------------------------
 19422064 | 2022-12-22 19:33:27+00
 19422063 | 2022-12-22 19:33:17+00
 19422062 | 2022-12-22 19:33:07+00
 19422061 | 2022-12-22 19:32:57+00
 19422060 | 2022-12-22 19:32:47+00
(5 rows)

---

Lijkt er dus op dat kolom gas incorrect berekend wordt?

Ik geloof je helemaal dat er ergens iets niet klopt, maar voor het debuggen van dit issue zoek ik daarom naar de SQL export van je DSMR-reader-variant waar je ze in hebt geschoten als hoe ze ook in Beeclear staan, zonder verschil in uren.
Ongeacht of je ze zelf omzet naar UTC of de lokale tijdzone gebruikt.

Ik hoef alleen de dsmr_datalogger_dsmrreading export. Want dan kan ik inhoudelijk voor je kijken waar het misgaat.

[dennissiemensma]

Mocht je trouwens DataGrip gebruiken (lijkt het op) dan kun je de tijdzone instellen in de optie van je DB-verbinding. Ik moest zelf wel even de verbinding verbreken en tabel sluiten voordat het effect had.

[nickgr6]

Fair point, had je verkeerd begrepen, maar inderdaad het query'en met Amsterdam timezone maakt het een stuk makkelijker vergelijken. Ik gebruik IntelliJ dus kon idd bij options de timezone configureren 👍.

Export:
dsmr-export.txt

En voor de volledigheid nog een keer de beeclear export:
gas.csv

[dennissiemensma]

De meterstanden in de dagstatistieken-tabel worden niet gebruikt voor berekeningen. Deze zijn later toegevoegd puur ter historie.

De dataflow binnen DSMR-reader is:

dsmr_datalogger_dsmrreading  ->-> dsmr_consumption_electricityconsumption  ->-> dsmr_stats_daystatistics
                            \->-> dsmr_consumption_gasconsumption          ->-/

De twee tussentabellen voeren eventuele groepering uit. Als het ergens mis gaat, zit het vermoedelijk in dsmr_consumption_gasconsumption.

[dennissiemensma]

De records voor 10 december in dsmr_consumption_gasconsumption komen inderdaad uit op 5,39

,128+,226+,219+,141+,114+,450+,878+,331+,113+,006+,042+,020+,205+,524+,742+,451+,800

Dus ergens zit daar iets wat niet meegenomen wordt.

[nickgr6]

Verschil met beeclear is de meting tussen 23:00 en 00:00 de volgende dag:

Ook goed zichtbaar in deze grafiek, dat het eerste verbruik in beeclear in het vierde uur is en in de database van dsmr de 5e regel:

Ik weet natuurlijk niet hoe dat verder gequeried wordt, dus wellicht klopt dat gewoon

[dennissiemensma]

Wat geeft deze query bij jou?

select dsmr_version from dsmr_datalogger_meterstatistics

[dennissiemensma]

Als die leeg is, kun je deze eens proberen:

UPDATE dsmr_datalogger_meterstatistics SET dsmr_version = '42' WHERE true;

En dan de import/verwerking opnieuw doen.

[dennissiemensma]

dsmr_version = '42'

---

dsmr_version = '50' (of leeg)

[dennissiemensma]

Het is een ontzettend edge-case die ik zelf nog niet eerder had gezien (of vergeten was).

Omdat de telegramversie onbekend is totdat je een echt telegram stuurt, trekt DSMR-reader geen uur af van de data en krijg je dus die verspringing.

• https://github.com/dsmrreader/dsmr-reader/blob/v5/dsmr_consumption/services.py#L330-L334

Ik denk dat de meeste gebruikers eerst DSMR-reader aan de slimme meter aansluiten en daarna pas de import doen. Want dit zit er al een eeuwigheid in en het is niet eerder opgevallen:

• https://github.com/dsmrreader/dsmr-reader/blame/cc089aba112149538c8990b4dc9cbc79e189a8fd/dsmr_consumption/services.py#L291-L295

Omdat het er zolang in zit, ga ik het ook niet aanpassen omdat de kans groot is dat het effect heeft op andere dingen. Desnietemin is het wel een soort van bug of uitzondering die iemand wellicht nog vaker tegen gaat komen. Dus mooi dat het nu een keertje helder is. Dank!

[nickgr6]

select dsmr_version from dsmr_datalogger_meterstatisticszgeeft 50

Als die leeg is, kun je deze eens proberen:

UPDATE dsmr_datalogger_meterstatistics SET dsmr_version = '42' WHERE true;

En dan de import/verwerking opnieuw doen.

Gedaan en dat fixed inderdaad 1-12-2022, maar nu gebeurd hetzelfde als toen ik een extra uur van de offset had afgehaald: op 4-12-2022 wordt het eerste uur niet meer meegerekend.

Data in dsmr_consumption_gasconsumption table:

id,read_at,delivered,currently_delivered
250828,2022-11-30 23:00:00.000000 +01:00,6142.308,0.000
250829,2022-12-01 00:00:00.000000 +01:00,6142.308,0.000
250830,2022-12-01 01:00:00.000000 +01:00,6142.308,0.000
250831,2022-12-01 02:00:00.000000 +01:00,6142.308,0.000
250832,2022-12-01 03:00:00.000000 +01:00,6142.308,0.000
250833,2022-12-01 04:00:00.000000 +01:00,6142.308,0.000
250834,2022-12-01 05:00:00.000000 +01:00,6142.308,0.000
250835,2022-12-01 06:00:00.000000 +01:00,6142.354,0.046
250836,2022-12-01 07:00:00.000000 +01:00,6142.954,0.600
250837,2022-12-01 08:00:00.000000 +01:00,6143.800,0.846
250838,2022-12-01 09:00:00.000000 +01:00,6144.554,0.754
250839,2022-12-01 10:00:00.000000 +01:00,6145.216,0.662
250840,2022-12-01 11:00:00.000000 +01:00,6145.489,0.273
250841,2022-12-01 12:00:00.000000 +01:00,6145.641,0.152
250842,2022-12-01 13:00:00.000000 +01:00,6146.095,0.454
250843,2022-12-01 14:00:00.000000 +01:00,6146.095,0.000
250844,2022-12-01 15:00:00.000000 +01:00,6146.203,0.108
250845,2022-12-01 16:00:00.000000 +01:00,6147.090,0.887
250846,2022-12-01 17:00:00.000000 +01:00,6147.870,0.780
250847,2022-12-01 18:00:00.000000 +01:00,6147.999,0.129
250848,2022-12-01 19:00:00.000000 +01:00,6148.004,0.005
250849,2022-12-01 20:00:00.000000 +01:00,6148.510,0.506
250850,2022-12-01 21:00:00.000000 +01:00,6148.734,0.224
250851,2022-12-01 22:00:00.000000 +01:00,6148.734,0.000
250852,2022-12-01 23:00:00.000000 +01:00,6148.734,0.000
250853,2022-12-02 00:00:00.000000 +01:00,6148.734,0.000
250854,2022-12-02 01:00:00.000000 +01:00,6148.734,0.000
250855,2022-12-02 02:00:00.000000 +01:00,6148.734,0.000
250856,2022-12-02 03:00:00.000000 +01:00,6148.734,0.000
250857,2022-12-02 04:00:00.000000 +01:00,6148.734,0.000
250858,2022-12-02 05:00:00.000000 +01:00,6148.734,0.000
250859,2022-12-02 06:00:00.000000 +01:00,6148.753,0.019
250860,2022-12-02 07:00:00.000000 +01:00,6148.972,0.219
250861,2022-12-02 08:00:00.000000 +01:00,6149.570,0.598
250862,2022-12-02 09:00:00.000000 +01:00,6150.055,0.485
250863,2022-12-02 10:00:00.000000 +01:00,6150.204,0.149
250864,2022-12-02 11:00:00.000000 +01:00,6150.316,0.112
250865,2022-12-02 12:00:00.000000 +01:00,6150.595,0.279
250866,2022-12-02 13:00:00.000000 +01:00,6150.602,0.007
250867,2022-12-02 14:00:00.000000 +01:00,6150.646,0.044
250868,2022-12-02 15:00:00.000000 +01:00,6150.722,0.076
250869,2022-12-02 16:00:00.000000 +01:00,6150.792,0.070
250870,2022-12-02 17:00:00.000000 +01:00,6150.818,0.026
250871,2022-12-02 18:00:00.000000 +01:00,6150.838,0.020
250872,2022-12-02 19:00:00.000000 +01:00,6150.974,0.136
250873,2022-12-02 20:00:00.000000 +01:00,6151.057,0.083
250874,2022-12-02 21:00:00.000000 +01:00,6151.057,0.000
250875,2022-12-02 22:00:00.000000 +01:00,6151.532,0.475
250876,2022-12-02 23:00:00.000000 +01:00,6151.532,0.000
250877,2022-12-03 00:00:00.000000 +01:00,6151.532,0.000
250878,2022-12-03 01:00:00.000000 +01:00,6151.532,0.000
250879,2022-12-03 02:00:00.000000 +01:00,6151.532,0.000
250880,2022-12-03 03:00:00.000000 +01:00,6151.532,0.000
250881,2022-12-03 04:00:00.000000 +01:00,6151.532,0.000
250882,2022-12-03 05:00:00.000000 +01:00,6151.532,0.000
250883,2022-12-03 06:00:00.000000 +01:00,6151.747,0.215
250884,2022-12-03 07:00:00.000000 +01:00,6151.987,0.240
250885,2022-12-03 08:00:00.000000 +01:00,6152.471,0.484
250886,2022-12-03 09:00:00.000000 +01:00,6152.850,0.379
250887,2022-12-03 10:00:00.000000 +01:00,6152.956,0.106
250888,2022-12-03 11:00:00.000000 +01:00,6152.956,0.000
250889,2022-12-03 12:00:00.000000 +01:00,6152.962,0.006
250890,2022-12-03 13:00:00.000000 +01:00,6153.134,0.172
250891,2022-12-03 14:00:00.000000 +01:00,6153.253,0.119
250892,2022-12-03 15:00:00.000000 +01:00,6153.253,0.000
250893,2022-12-03 16:00:00.000000 +01:00,6153.258,0.005
250894,2022-12-03 17:00:00.000000 +01:00,6153.270,0.012
250895,2022-12-03 18:00:00.000000 +01:00,6153.628,0.358
250896,2022-12-03 19:00:00.000000 +01:00,6153.778,0.150
250897,2022-12-03 20:00:00.000000 +01:00,6154.096,0.318
250898,2022-12-03 21:00:00.000000 +01:00,6154.139,0.043
250899,2022-12-03 22:00:00.000000 +01:00,6154.139,0.000
250900,2022-12-03 23:00:00.000000 +01:00,6154.139,0.000
250901,2022-12-04 00:00:00.000000 +01:00,6154.474,0.335
250902,2022-12-04 01:00:00.000000 +01:00,6154.474,0.000
250903,2022-12-04 02:00:00.000000 +01:00,6154.662,0.188
250904,2022-12-04 03:00:00.000000 +01:00,6154.944,0.282
250905,2022-12-04 04:00:00.000000 +01:00,6155.157,0.213
250906,2022-12-04 05:00:00.000000 +01:00,6155.297,0.140
250907,2022-12-04 06:00:00.000000 +01:00,6155.297,0.000
250908,2022-12-04 07:00:00.000000 +01:00,6155.418,0.121
250909,2022-12-04 08:00:00.000000 +01:00,6155.858,0.440
250910,2022-12-04 09:00:00.000000 +01:00,6156.356,0.498
250911,2022-12-04 10:00:00.000000 +01:00,6156.667,0.311
250912,2022-12-04 11:00:00.000000 +01:00,6156.672,0.005
250913,2022-12-04 12:00:00.000000 +01:00,6156.677,0.005
250914,2022-12-04 13:00:00.000000 +01:00,6156.682,0.005
250915,2022-12-04 14:00:00.000000 +01:00,6156.786,0.104
250916,2022-12-04 15:00:00.000000 +01:00,6157.042,0.256
250917,2022-12-04 16:00:00.000000 +01:00,6157.303,0.261
250918,2022-12-04 17:00:00.000000 +01:00,6157.550,0.247
250919,2022-12-04 18:00:00.000000 +01:00,6157.550,0.000
250920,2022-12-04 19:00:00.000000 +01:00,6157.562,0.012
250921,2022-12-04 20:00:00.000000 +01:00,6157.636,0.074
250922,2022-12-04 21:00:00.000000 +01:00,6157.636,0.000
250923,2022-12-04 22:00:00.000000 +01:00,6157.798,0.162
250924,2022-12-04 23:00:00.000000 +01:00,6157.798,0.000
250925,2022-12-05 00:00:00.000000 +01:00,6157.798,0.000
250926,2022-12-05 01:00:00.000000 +01:00,6157.798,0.000
250927,2022-12-05 02:00:00.000000 +01:00,6157.798,0.000
250928,2022-12-05 03:00:00.000000 +01:00,6157.798,0.000
250929,2022-12-05 04:00:00.000000 +01:00,6157.860,0.062
250930,2022-12-05 05:00:00.000000 +01:00,6158.090,0.230
250931,2022-12-05 06:00:00.000000 +01:00,6158.344,0.254
250932,2022-12-05 07:00:00.000000 +01:00,6158.845,0.501
250933,2022-12-05 08:00:00.000000 +01:00,6159.217,0.372
250934,2022-12-05 09:00:00.000000 +01:00,6159.383,0.166
250935,2022-12-05 10:00:00.000000 +01:00,6159.388,0.005
250936,2022-12-05 11:00:00.000000 +01:00,6159.388,0.000
250937,2022-12-05 12:00:00.000000 +01:00,6159.393,0.005
250938,2022-12-05 13:00:00.000000 +01:00,6159.398,0.005
250939,2022-12-05 14:00:00.000000 +01:00,6159.452,0.054
250940,2022-12-05 15:00:00.000000 +01:00,6159.679,0.227
250941,2022-12-05 16:00:00.000000 +01:00,6159.994,0.315
250942,2022-12-05 17:00:00.000000 +01:00,6160.280,0.286
250943,2022-12-05 18:00:00.000000 +01:00,6160.464,0.184
250944,2022-12-05 19:00:00.000000 +01:00,6160.627,0.163
250945,2022-12-05 20:00:00.000000 +01:00,6161.071,0.444
250946,2022-12-05 21:00:00.000000 +01:00,6161.143,0.072
250947,2022-12-05 22:00:00.000000 +01:00,6161.376,0.233
250948,2022-12-05 23:00:00.000000 +01:00,6161.376,0.000
250949,2022-12-06 00:00:00.000000 +01:00,6161.376,0.000
250950,2022-12-06 01:00:00.000000 +01:00,6161.376,0.000
250951,2022-12-06 02:00:00.000000 +01:00,6161.376,0.000
250952,2022-12-06 03:00:00.000000 +01:00,6161.376,0.000
250953,2022-12-06 04:00:00.000000 +01:00,6161.376,0.000
250954,2022-12-06 05:00:00.000000 +01:00,6161.376,0.000
250955,2022-12-06 06:00:00.000000 +01:00,6161.611,0.235
250956,2022-12-06 07:00:00.000000 +01:00,6162.165,0.554
250957,2022-12-06 08:00:00.000000 +01:00,6162.601,0.436
250958,2022-12-06 09:00:00.000000 +01:00,6162.861,0.260
250959,2022-12-06 10:00:00.000000 +01:00,6162.868,0.007
250960,2022-12-06 11:00:00.000000 +01:00,6162.873,0.005
250961,2022-12-06 12:00:00.000000 +01:00,6162.878,0.005
250962,2022-12-06 13:00:00.000000 +01:00,6162.901,0.023
250963,2022-12-06 14:00:00.000000 +01:00,6162.901,0.000
250964,2022-12-06 15:00:00.000000 +01:00,6162.906,0.005
250965,2022-12-06 16:00:00.000000 +01:00,6163.105,0.199
250966,2022-12-06 17:00:00.000000 +01:00,6163.390,0.285
250967,2022-12-06 18:00:00.000000 +01:00,6163.519,0.129
250968,2022-12-06 19:00:00.000000 +01:00,6163.519,0.000
250969,2022-12-06 20:00:00.000000 +01:00,6163.525,0.006
250970,2022-12-06 21:00:00.000000 +01:00,6163.701,0.176
250971,2022-12-06 22:00:00.000000 +01:00,6164.055,0.354
250972,2022-12-06 23:00:00.000000 +01:00,6164.055,0.000
250973,2022-12-07 00:00:00.000000 +01:00,6164.055,0.000
250974,2022-12-07 01:00:00.000000 +01:00,6164.055,0.000
250975,2022-12-07 02:00:00.000000 +01:00,6164.055,0.000
250976,2022-12-07 03:00:00.000000 +01:00,6164.055,0.000
250977,2022-12-07 04:00:00.000000 +01:00,6164.055,0.000
250978,2022-12-07 05:00:00.000000 +01:00,6164.183,0.128
250979,2022-12-07 06:00:00.000000 +01:00,6164.528,0.345
250980,2022-12-07 07:00:00.000000 +01:00,6165.061,0.533
250981,2022-12-07 08:00:00.000000 +01:00,6165.437,0.376
250982,2022-12-07 09:00:00.000000 +01:00,6165.639,0.202
250983,2022-12-07 10:00:00.000000 +01:00,6165.650,0.011
250984,2022-12-07 11:00:00.000000 +01:00,6165.652,0.002
250985,2022-12-07 12:00:00.000000 +01:00,6165.659,0.007
250986,2022-12-07 13:00:00.000000 +01:00,6165.659,0.000
250987,2022-12-07 14:00:00.000000 +01:00,6165.664,0.005
250988,2022-12-07 15:00:00.000000 +01:00,6165.669,0.005
250989,2022-12-07 16:00:00.000000 +01:00,6165.736,0.067
250990,2022-12-07 17:00:00.000000 +01:00,6166.064,0.328
250991,2022-12-07 18:00:00.000000 +01:00,6166.378,0.314
250992,2022-12-07 19:00:00.000000 +01:00,6166.509,0.131
250993,2022-12-07 20:00:00.000000 +01:00,6166.517,0.008
250994,2022-12-07 21:00:00.000000 +01:00,6166.867,0.350
250995,2022-12-07 22:00:00.000000 +01:00,6167.215,0.348
250996,2022-12-07 23:00:00.000000 +01:00,6167.215,0.000
250997,2022-12-08 00:00:00.000000 +01:00,6167.215,0.000
250998,2022-12-08 01:00:00.000000 +01:00,6167.215,0.000
250999,2022-12-08 02:00:00.000000 +01:00,6167.215,0.000
251000,2022-12-08 03:00:00.000000 +01:00,6167.215,0.000
251001,2022-12-08 04:00:00.000000 +01:00,6167.215,0.000
251002,2022-12-08 05:00:00.000000 +01:00,6167.344,0.129
251003,2022-12-08 06:00:00.000000 +01:00,6167.727,0.383
251004,2022-12-08 07:00:00.000000 +01:00,6168.247,0.520
251005,2022-12-08 08:00:00.000000 +01:00,6168.655,0.408
251006,2022-12-08 09:00:00.000000 +01:00,6168.716,0.061
251007,2022-12-08 10:00:00.000000 +01:00,6168.721,0.005
251008,2022-12-08 11:00:00.000000 +01:00,6168.733,0.012
251009,2022-12-08 12:00:00.000000 +01:00,6168.733,0.000
251010,2022-12-08 13:00:00.000000 +01:00,6168.850,0.117
251011,2022-12-08 14:00:00.000000 +01:00,6169.112,0.262
251012,2022-12-08 15:00:00.000000 +01:00,6169.510,0.398
251013,2022-12-08 16:00:00.000000 +01:00,6169.917,0.407
251014,2022-12-08 17:00:00.000000 +01:00,6170.162,0.245
251015,2022-12-08 18:00:00.000000 +01:00,6170.185,0.023
251016,2022-12-08 19:00:00.000000 +01:00,6170.185,0.000
251017,2022-12-08 20:00:00.000000 +01:00,6170.429,0.244
251018,2022-12-08 21:00:00.000000 +01:00,6170.657,0.228
251019,2022-12-08 22:00:00.000000 +01:00,6170.657,0.000
251020,2022-12-08 23:00:00.000000 +01:00,6170.657,0.000
251021,2022-12-09 00:00:00.000000 +01:00,6170.657,0.000
251022,2022-12-09 01:00:00.000000 +01:00,6170.657,0.000
251023,2022-12-09 02:00:00.000000 +01:00,6170.657,0.000
251024,2022-12-09 03:00:00.000000 +01:00,6170.657,0.000
251025,2022-12-09 04:00:00.000000 +01:00,6170.657,0.000
251026,2022-12-09 05:00:00.000000 +01:00,6170.657,0.000
251027,2022-12-09 06:00:00.000000 +01:00,6170.841,0.184
251028,2022-12-09 07:00:00.000000 +01:00,6171.581,0.740
251029,2022-12-09 08:00:00.000000 +01:00,6172.199,0.618
251030,2022-12-09 09:00:00.000000 +01:00,6172.572,0.373
251031,2022-12-09 10:00:00.000000 +01:00,6172.651,0.079
251032,2022-12-09 11:00:00.000000 +01:00,6172.657,0.006
251033,2022-12-09 12:00:00.000000 +01:00,6172.657,0.000
251034,2022-12-09 13:00:00.000000 +01:00,6172.662,0.005
251035,2022-12-09 14:00:00.000000 +01:00,6172.667,0.005
251036,2022-12-09 15:00:00.000000 +01:00,6172.815,0.148
251037,2022-12-09 16:00:00.000000 +01:00,6173.216,0.401
251038,2022-12-09 17:00:00.000000 +01:00,6173.609,0.393
251039,2022-12-09 18:00:00.000000 +01:00,6173.772,0.163
251040,2022-12-09 19:00:00.000000 +01:00,6173.774,0.002
251041,2022-12-09 20:00:00.000000 +01:00,6173.779,0.005
251042,2022-12-09 21:00:00.000000 +01:00,6173.779,0.000
251043,2022-12-09 22:00:00.000000 +01:00,6173.779,0.000
251044,2022-12-09 23:00:00.000000 +01:00,6173.779,0.000
251045,2022-12-10 00:00:00.000000 +01:00,6173.779,0.000
251046,2022-12-10 01:00:00.000000 +01:00,6173.779,0.000
251047,2022-12-10 02:00:00.000000 +01:00,6173.779,0.000
251048,2022-12-10 03:00:00.000000 +01:00,6173.907,0.128
251049,2022-12-10 04:00:00.000000 +01:00,6174.133,0.226
251050,2022-12-10 05:00:00.000000 +01:00,6174.352,0.219
251051,2022-12-10 06:00:00.000000 +01:00,6174.493,0.141
251052,2022-12-10 07:00:00.000000 +01:00,6174.607,0.114
251053,2022-12-10 08:00:00.000000 +01:00,6175.057,0.450
251054,2022-12-10 09:00:00.000000 +01:00,6175.935,0.878
251055,2022-12-10 10:00:00.000000 +01:00,6176.266,0.331
251056,2022-12-10 11:00:00.000000 +01:00,6176.379,0.113
251057,2022-12-10 12:00:00.000000 +01:00,6176.385,0.006
251058,2022-12-10 13:00:00.000000 +01:00,6176.427,0.042
251059,2022-12-10 14:00:00.000000 +01:00,6176.427,0.000
251060,2022-12-10 15:00:00.000000 +01:00,6176.447,0.020
251061,2022-12-10 16:00:00.000000 +01:00,6176.447,0.000
251062,2022-12-10 17:00:00.000000 +01:00,6176.652,0.205
251063,2022-12-10 18:00:00.000000 +01:00,6177.176,0.524
251064,2022-12-10 19:00:00.000000 +01:00,6177.918,0.742
251065,2022-12-10 20:00:00.000000 +01:00,6178.369,0.451
251066,2022-12-10 21:00:00.000000 +01:00,6179.169,0.800
251067,2022-12-10 22:00:00.000000 +01:00,6179.169,0.000
251068,2022-12-10 23:00:00.000000 +01:00,6179.756,0.587
251069,2022-12-11 00:00:00.000000 +01:00,6179.756,0.000
251070,2022-12-11 01:00:00.000000 +01:00,6179.756,0.000
251071,2022-12-11 02:00:00.000000 +01:00,6179.756,0.000
251072,2022-12-11 03:00:00.000000 +01:00,6179.756,0.000
251073,2022-12-11 04:00:00.000000 +01:00,6179.756,0.000
251074,2022-12-11 05:00:00.000000 +01:00,6179.756,0.000
251075,2022-12-11 06:00:00.000000 +01:00,6179.756,0.000
251076,2022-12-11 07:00:00.000000 +01:00,6179.769,0.013
251077,2022-12-11 08:00:00.000000 +01:00,6179.996,0.227
251078,2022-12-11 09:00:00.000000 +01:00,6180.476,0.480
251079,2022-12-11 10:00:00.000000 +01:00,6180.934,0.458
251080,2022-12-11 11:00:00.000000 +01:00,6181.080,0.146
251081,2022-12-11 12:00:00.000000 +01:00,6181.115,0.035
251082,2022-12-11 13:00:00.000000 +01:00,6181.117,0.002
251083,2022-12-11 14:00:00.000000 +01:00,6181.513,0.396
251084,2022-12-11 15:00:00.000000 +01:00,6181.564,0.051
251085,2022-12-11 16:00:00.000000 +01:00,6181.809,0.245
251086,2022-12-11 17:00:00.000000 +01:00,6182.140,0.331
251087,2022-12-11 18:00:00.000000 +01:00,6182.315,0.175
251088,2022-12-11 19:00:00.000000 +01:00,6182.315,0.000
251089,2022-12-11 20:00:00.000000 +01:00,6182.320,0.005
251090,2022-12-11 21:00:00.000000 +01:00,6182.320,0.000
251091,2022-12-11 22:00:00.000000 +01:00,6182.348,0.028
251092,2022-12-11 23:00:00.000000 +01:00,6182.348,0.000
251093,2022-12-12 00:00:00.000000 +01:00,6182.348,0.000
251094,2022-12-12 01:00:00.000000 +01:00,6182.348,0.000
251095,2022-12-12 02:00:00.000000 +01:00,6182.348,0.000
251096,2022-12-12 03:00:00.000000 +01:00,6182.348,0.000
251097,2022-12-12 04:00:00.000000 +01:00,6182.348,0.000
251098,2022-12-12 05:00:00.000000 +01:00,6182.394,0.046
251099,2022-12-12 06:00:00.000000 +01:00,6183.098,0.704
251100,2022-12-12 07:00:00.000000 +01:00,6183.850,0.752
251101,2022-12-12 08:00:00.000000 +01:00,6184.676,0.826
251102,2022-12-12 09:00:00.000000 +01:00,6185.019,0.343
251103,2022-12-12 10:00:00.000000 +01:00,6185.025,0.006
251104,2022-12-12 11:00:00.000000 +01:00,6185.030,0.005
251105,2022-12-12 12:00:00.000000 +01:00,6185.034,0.004
251106,2022-12-12 13:00:00.000000 +01:00,6185.034,0.000
251107,2022-12-12 14:00:00.000000 +01:00,6185.160,0.126
251108,2022-12-12 15:00:00.000000 +01:00,6185.436,0.276
251109,2022-12-12 16:00:00.000000 +01:00,6185.830,0.394
251110,2022-12-12 17:00:00.000000 +01:00,6186.228,0.398
251111,2022-12-12 18:00:00.000000 +01:00,6186.555,0.327
251112,2022-12-12 19:00:00.000000 +01:00,6186.710,0.155
251113,2022-12-12 20:00:00.000000 +01:00,6186.710,0.000
251114,2022-12-12 21:00:00.000000 +01:00,6186.761,0.051
251115,2022-12-12 22:00:00.000000 +01:00,6187.051,0.290
251116,2022-12-12 23:00:00.000000 +01:00,6187.051,0.000
251117,2022-12-13 00:00:00.000000 +01:00,6187.051,0.000
251118,2022-12-13 01:00:00.000000 +01:00,6187.051,0.000
251119,2022-12-13 02:00:00.000000 +01:00,6187.051,0.000
251120,2022-12-13 03:00:00.000000 +01:00,6187.051,0.000
251121,2022-12-13 04:00:00.000000 +01:00,6187.112,0.061
251122,2022-12-13 05:00:00.000000 +01:00,6187.382,0.270
251123,2022-12-13 06:00:00.000000 +01:00,6188.149,0.767
251124,2022-12-13 07:00:00.000000 +01:00,6189.088,0.939
251125,2022-12-13 08:00:00.000000 +01:00,6189.848,0.760
251126,2022-12-13 09:00:00.000000 +01:00,6190.009,0.161
251127,2022-12-13 10:00:00.000000 +01:00,6190.014,0.005
251128,2022-12-13 11:00:00.000000 +01:00,6190.014,0.000
251129,2022-12-13 12:00:00.000000 +01:00,6190.019,0.005
251130,2022-12-13 13:00:00.000000 +01:00,6190.024,0.005
251131,2022-12-13 14:00:00.000000 +01:00,6190.172,0.148
251132,2022-12-13 15:00:00.000000 +01:00,6190.586,0.414
251133,2022-12-13 16:00:00.000000 +01:00,6191.044,0.458
251134,2022-12-13 17:00:00.000000 +01:00,6191.420,0.376
251135,2022-12-13 18:00:00.000000 +01:00,6191.676,0.256
251136,2022-12-13 19:00:00.000000 +01:00,6191.792,0.116
251137,2022-12-13 20:00:00.000000 +01:00,6191.803,0.011
251138,2022-12-13 21:00:00.000000 +01:00,6192.148,0.345
251139,2022-12-13 22:00:00.000000 +01:00,6192.148,0.000
251140,2022-12-13 23:00:00.000000 +01:00,6192.148,0.000
251141,2022-12-14 00:00:00.000000 +01:00,6192.148,0.000
251142,2022-12-14 01:00:00.000000 +01:00,6192.148,0.000
251143,2022-12-14 02:00:00.000000 +01:00,6192.148,0.000
251144,2022-12-14 03:00:00.000000 +01:00,6192.148,0.000
251145,2022-12-14 04:00:00.000000 +01:00,6192.291,0.143
251146,2022-12-14 05:00:00.000000 +01:00,6192.588,0.297
251147,2022-12-14 06:00:00.000000 +01:00,6193.341,0.753
251148,2022-12-14 07:00:00.000000 +01:00,6194.369,1.028
251149,2022-12-14 08:00:00.000000 +01:00,6195.119,0.750
251150,2022-12-14 09:00:00.000000 +01:00,6195.449,0.330
251151,2022-12-14 10:00:00.000000 +01:00,6195.504,0.055
251152,2022-12-14 11:00:00.000000 +01:00,6195.509,0.005
251153,2022-12-14 12:00:00.000000 +01:00,6195.509,0.000
251154,2022-12-14 13:00:00.000000 +01:00,6195.514,0.005
251155,2022-12-14 14:00:00.000000 +01:00,6195.634,0.120
251156,2022-12-14 15:00:00.000000 +01:00,6195.932,0.298
251157,2022-12-14 16:00:00.000000 +01:00,6196.374,0.442
251158,2022-12-14 17:00:00.000000 +01:00,6196.817,0.443
251159,2022-12-14 18:00:00.000000 +01:00,6197.169,0.352
251160,2022-12-14 19:00:00.000000 +01:00,6197.316,0.147
251161,2022-12-14 20:00:00.000000 +01:00,6197.325,0.009
251162,2022-12-14 21:00:00.000000 +01:00,6197.666,0.341
251163,2022-12-14 22:00:00.000000 +01:00,6198.027,0.361
251164,2022-12-14 23:00:00.000000 +01:00,6198.027,0.000
251165,2022-12-15 00:00:00.000000 +01:00,6198.027,0.000
251166,2022-12-15 01:00:00.000000 +01:00,6198.027,0.000
251167,2022-12-15 02:00:00.000000 +01:00,6198.027,0.000
251168,2022-12-15 03:00:00.000000 +01:00,6198.027,0.000
251169,2022-12-15 04:00:00.000000 +01:00,6198.027,0.000
251170,2022-12-15 05:00:00.000000 +01:00,6198.027,0.000
251171,2022-12-15 06:00:00.000000 +01:00,6198.675,0.648
251172,2022-12-15 07:00:00.000000 +01:00,6199.519,0.844
251173,2022-12-15 08:00:00.000000 +01:00,6200.171,0.652
251174,2022-12-15 09:00:00.000000 +01:00,6200.432,0.261
251175,2022-12-15 10:00:00.000000 +01:00,6200.432,0.000
251176,2022-12-15 11:00:00.000000 +01:00,6200.437,0.005
251177,2022-12-15 12:00:00.000000 +01:00,6200.442,0.005
251178,2022-12-15 13:00:00.000000 +01:00,6200.442,0.000
251179,2022-12-15 14:00:00.000000 +01:00,6200.447,0.005
251180,2022-12-15 15:00:00.000000 +01:00,6200.451,0.004
251181,2022-12-15 16:00:00.000000 +01:00,6200.609,0.158
251182,2022-12-15 17:00:00.000000 +01:00,6200.945,0.336
251183,2022-12-15 18:00:00.000000 +01:00,6201.249,0.304
251184,2022-12-15 19:00:00.000000 +01:00,6201.377,0.128
251185,2022-12-15 20:00:00.000000 +01:00,6201.382,0.005
251186,2022-12-15 21:00:00.000000 +01:00,6202.122,0.740
251187,2022-12-15 22:00:00.000000 +01:00,6202.213,0.091
251188,2022-12-15 23:00:00.000000 +01:00,6202.213,0.000
251189,2022-12-16 00:00:00.000000 +01:00,6202.213,0.000
251190,2022-12-16 01:00:00.000000 +01:00,6202.213,0.000
251191,2022-12-16 02:00:00.000000 +01:00,6202.213,0.000
251192,2022-12-16 03:00:00.000000 +01:00,6202.213,0.000
251193,2022-12-16 04:00:00.000000 +01:00,6202.213,0.000
251194,2022-12-16 05:00:00.000000 +01:00,6202.213,0.000
251195,2022-12-16 06:00:00.000000 +01:00,6202.766,0.553
251196,2022-12-16 07:00:00.000000 +01:00,6203.761,0.995
251197,2022-12-16 08:00:00.000000 +01:00,6204.291,0.530
251198,2022-12-16 09:00:00.000000 +01:00,6204.396,0.105
251199,2022-12-16 10:00:00.000000 +01:00,6204.401,0.005
251200,2022-12-16 11:00:00.000000 +01:00,6204.401,0.000
251201,2022-12-16 12:00:00.000000 +01:00,6204.406,0.005
251202,2022-12-16 13:00:00.000000 +01:00,6204.411,0.005
251203,2022-12-16 14:00:00.000000 +01:00,6204.411,0.000
251204,2022-12-16 15:00:00.000000 +01:00,6204.560,0.149
251205,2022-12-16 16:00:00.000000 +01:00,6204.866,0.306
251206,2022-12-16 17:00:00.000000 +01:00,6205.177,0.311
251207,2022-12-16 18:00:00.000000 +01:00,6205.226,0.049
251208,2022-12-16 19:00:00.000000 +01:00,6205.231,0.005
251209,2022-12-16 20:00:00.000000 +01:00,6205.231,0.000
251210,2022-12-16 21:00:00.000000 +01:00,6205.236,0.005
251211,2022-12-16 22:00:00.000000 +01:00,6205.236,0.000
251212,2022-12-16 23:00:00.000000 +01:00,6205.236,0.000
251213,2022-12-17 00:00:00.000000 +01:00,6205.265,0.029
251214,2022-12-17 01:00:00.000000 +01:00,6205.265,0.000
251215,2022-12-17 02:00:00.000000 +01:00,6205.265,0.000
251216,2022-12-17 03:00:00.000000 +01:00,6205.377,0.112
251217,2022-12-17 04:00:00.000000 +01:00,6205.670,0.293
251218,2022-12-17 05:00:00.000000 +01:00,6205.965,0.295
251219,2022-12-17 06:00:00.000000 +01:00,6206.158,0.193
251220,2022-12-17 07:00:00.000000 +01:00,6206.543,0.385
251221,2022-12-17 08:00:00.000000 +01:00,6207.309,0.766
251222,2022-12-17 09:00:00.000000 +01:00,6208.445,1.136
251223,2022-12-17 10:00:00.000000 +01:00,6208.794,0.349
251224,2022-12-17 11:00:00.000000 +01:00,6208.794,0.000
251225,2022-12-17 12:00:00.000000 +01:00,6208.799,0.005

PS: hetzelfde lijkt te gebeuren voor elektra.

[dennissiemensma]

Bedankt voor het checken! Ik ben er inmiddels ook achter waar het in zit, en dat is die tussentabel.

Alleen heb ik er geen makkelijke fix voor, omdat het e.e.a. raakt. Uiteindelijk had ik al wel plannen om DSMR-reader te versimpelen en alles te baseren op de metingen-tabel, wellicht in combinatie met een timeseries-database, die er iets lekkerder voor werkt.
Alleen was dat zeker niet iets voor de korte termijn, dus ik zal komende tijd overwegen wat een goede fix is en niet alles direct op de schop gooit.

[dennissiemensma]

Voor de korte termijn zal ik een fix maken die:

• voortaan de eerste meterstanden van de dag gewoon uit de metingen-tabel haalt
• voortaan voor het totale gasverbruik van een dag de individuele uren optelt (die wel lijken te kloppen)
• een script maken dit bovenstaande met terugwerkende kracht rechttrekt, mits de gegevens nog bestaan

Want niet iedereen heeft alle brongegevens meer, vandaar die meterstanden in de dagstatistieken-tabel als last-resort. Daarnaast zal ik het script niet automatisch uitvoeren, maar optioneel maken, zowel met een dry-run modus als "echte" modus zodat gebruikers eerst zien of het ze raakt en wat er verandert.

Alle andere zaken neem ik wel mee bij de versimpeling van DSMR-reader later.

[dennissiemensma]

@nickgr6 je zou de v5.10.3 release kunnen proberen om te zien of het inmiddels al beter gaat of nog wat rework nodig heeft.

[nickgr6]

Bedankt voor de update! Vanwege vakantie ga ik hier echter pas na 15 maart naar kunnen kijken. Ik hou je op de hoogte nadien.

[Roukie686868]

Ik kijk in de dsmr_consumption_gasconsumption tabel en zie dat precies een maand terug alleen nog de waarden op het hele en 5 minuten voor het hele uur gemeld staan. Alle andere tussen waarden zijn weg. Is er een manier om het werkelijke (correcte) verbruik nog terug te halen uit de database? In het plaatje zie je boven de streek waarden elke 5 minuten daaronder nog maar 2 waarden per uur.

[Roukie686868]

Ik realiseer me dat met de “delivered” waarden het allemaal per uur en dag terug te rekenen is dus kan ik het probleem zelf oplossen

[dennissiemensma]

@Roukie686868 dsmr_consumption_gasconsumption is een tussentabel die niet helemaal klopt (waar dit issue over gaat), de bronmetingen in dsmr_datalogger_dsmrreading kloppen wel. Gas heet daarin extra_device_*

[dennissiemensma]

@Roukie686868 en aanvullend daarop, de data wordt na verloop van tijd (standaard een maand) uitgedund voor performance. De eerste en laatste meting van elk uur worden bewaard, waardoor het altijd terug te rekenen moet zijn.

DSMR-reader zal dat ook doen wanneer ik een fix heb voor het huidige issue.

[Roukie686868]

Perfect dat de data ook in dsmr_datalogger_dsmrreading staat. Dan is het mogelijk om echt alles weer perfect terug te rekenen.
Ik hoop dat je de fix snel voorelkaar krijgt.

[Roukie686868]

Dennis nog bedankt voor het wijzen naar de juiste kolom. Ik haal deze data binnen in PowerBI en met de volgende query krijg ik precies wat ik zocht. Ik gebruik wel de set met de gereduceerde regels, Hier krijg ik ook wat er per uur verbruikt is zonder de database onnodig te belasten.

SELECT read_at, (delivered - lag(delivered,1) over (order by read_at)) as verbruik
FROM public.dsmr_consumption_gasconsumption

[hcombee]

Ik kwam toevallig deze thread tegen toen ik zocht naar een verklaring voor mijn probleem.
Tussen het overzicht van de maand maart van Vattenval en DSMR reader zat 15 m3 verschil in het gasverbruik. Het stroomverbruik klopte wel.

Toen ik verder ging kijken zag ik dat het overzicht in Homeassistant en Mindergas.nl wel klopt met het overzicht van Vattenval. Beide krijgen de meterstanden door van DSMR reader.

Ik gebruik versie v5.10.3. In de screenshot van het gasverbruik van gisteren zie je het verschill tussen HAS en DSMR.

[StevenM1]

Ik heb hetzelfde probleem ervaren. Bij het vergelijken van de jaarstatistieken zoals geregistreerd in DSMR reader, met handmatig bijgehouden meterstanden, bleek dat er een aanzienlijk verschil was in stroom- en gasverbruik (~10% minder gasverbruik in DSMR reader dan op de meterstanden).
Hier wordt ook geen gebruik gemaakt van de standaard datalogger met live readings, maar in plaats daarvan injecteer ik zelf de telegramdata in de readings table van de database.

Volgens mij gaat het mis in het berekenen van de consumptions, en specifiek in de manier waarop een tijdsrange wordt gequery'd in consumption_by_range() in dsmr-reader/dsmr_stats/services.py:

    electricity_readings = ElectricityConsumption.objects.filter(
        read_at__gte=start,
        read_at__lt=end,
    ).order_by("read_at")

    gas_readings = GasConsumption.objects.filter(
        read_at__gte=start,
        read_at__lt=end,
    ).order_by("read_at")

Hier query't DSMR alles binnen een tijdsrange, waarbij de eerste reading wordt afgetrokken van de laatste reading om te bepalen wat de consumptie was binnen die range. end en day verschillen 1 uur of 1 dag, afhankelijk van of er een uur- of dagstatistiek wordt berekend. Maar dit kan misgaan:
Stel dat je eerste reading van de dag op 00:00 (middernacht) is, en de laatste reading om 23:55, dan wordt dus de reading van 00:00 afgetrokken van de reading van 23:55 om te bepalen hoeveel gas/elektriciteit er is verbruikt op deze dag. En dus worden de laatste 5 minuten van die dag niet meegerekend. Aangezien de jaarstatistieken een optelsom zijn van de day statistieken, kan dit behoorlijk oplopen.

In plaats daarvan werkt het bij mij om de readings binnen consumption_by_range() simpelweg te query'en op read_at__lte in plaats van read_at__lt. Dan neem je ook het laatste interval van de range mee in je metingen. Hiermee komt mijn jaarverbruik zoals geregistreerd in DSMR reader exact overeen met de handmatig bijgehouden meterstanden.

Overigens laat ik create_daily_statistics (dsmr-reader/dsmr_stats/services.py) gewoon de gasmetingen uit consumption returnen (en niet de nieuwe hours_gas_sum; waarom deze daar wordt berekend in plaats van de consumption['gas'] is me niet helemaal duidelijk)

[dennissiemensma]

@StevenM1 bedankt voor je uitgebreide aanvulling. Het specifieke stukje code is al meerdere maken aangepast en weer teruggezet (#1385):

• @ 2019 lt -> lte: 2ff6350#diff-79b655a9839c8d926e6778808d4f0ffe7a31f9d6038143b972023d3dd9f5c56d
• @ 2021 lte -> le: 4a1d40d#diff-79b655a9839c8d926e6778808d4f0ffe7a31f9d6038143b972023d3dd9f5c56d

De kern van het hele probleem is uberhaupt die tussentabel in DSMR-reader, de consumption.

Er is sowieso geen garantie dat er een meting is tussen 23:55 en middernacht, wat de huidige opzet in DSMR-reader per definitie dus kan laten "lekken".
Eigenlijk wil ik daar van af en die complete tussentabel er uit hebben en alles direct berekenen op de metingen. Hoewel dat niet alles oplost, zou ik dat wel kunnen gebruiken voor de dag/maand/jaar-totalen. En zou het dan in ieder geval beter moeten werken.

Alleen is dat niet te doen qua werkgrootte. Plus dat de huidige situatie onder (unit)tests staat die niet kloppen (want het klopt immers niet), dus die moeten ook over de kop. Het liefste naar een integratietest die meer naar het eindresultaat kijkt, voor DSMR v3, v4 en v5 meters.

En hoewel ik wel neig om weer terug te gaan van de situatie van 2019-2021 (dus jouw voorstel), voor nu, weet ik niet wat de gevolgen daarvan zijn.
Een verbetering tov toen is wel dat er in de laatste DSMR-reader versies bij de dagtotalen ook de meterstanden opgeslagen worden. Zodat die altijd gebruikt kunnen worden voor ofwel een fix met terugwerkende kracht of gewoon als "waarheid".

Dus veel keuzes en veel wegen.

[StevenM1]

Ik snap je overwegingen, en ben het er helemaal mee eens dat de beste oplossing (maar waarschijnlijk wel veel werk) zou zijn om gewoon direct de readings te query'en en aan de hand daarvan de consumption te berekenen.

Wat ik niet helemaal begrijp is wat de reden is geweest om van lte naar lt te gaan; ik kan iig zelf niet zo goed bedenken in welke situatie dat een betere benadering zou opleveren dan lte. Maar ik heb niet de hele commit history gelezen en ken de situatie van 2021 niet, allicht was er een goede reden voor.

Zonder direct de tussentabellen eruit te gooien, lijkt het mij dat de meeste accurate benadering is om een range te pakken (zeg, 24 uur), en dan de eerste meting ná die range te gebruiken als eindpunt. Dat is iets complexer dan de lte die ik eerder voorstelde, omdat het vermoedelijk echt een tweede query nodig heeft, inderdaad voor de situatie dat geen reading voldoet aan de 'equal' conditie (dus dat er bijv. geen reading is van middernacht de volgende dag). Bij mij lijkt het goed te gaan omdat er altijd wel een reading is die exact overeenkomt met het eindpunt v/d range (ook omdat de timestamps van de readings in de database iets te lijken zijn opgeschoond t.o.v. de ruwe metingen in de telegrams), maar dat hoeft niet altijd het geval te zijn.

Indien er géén reading is op exact het eind van de range, lijkt het me dat de eerstvolgende reading de meest accurate benadering daarvan is. Het kan dan wel zijn dat die reading een tijdje na de gespecificeerde range is (hypothetisch, als je slechts om het uur een meting hebt, kan het zo zijn dat er op dag t een laatste meting is om 23:00, en op dag t+1 pas een om 01:00). In dat geval moet er hoe dan ook een keuze worden gemaakt waaraan de consumptie in het interval 23:00-01:00 moet worden toebedeeld (tenzij je gaat interpoleren o.i.d. maar dat lijkt me het onnodig complex maken). Altijd de eerstvolgende reading pakken is in ieder geval consistent.

Maar goed - ik weet niet alles van de structuur van DSMR reader, en weet dat dit soort aanpassingen riskant zijn dus dat ik het begrijp dat je voorzichtig bent in het aanpassen van dit soort dingen. Maar misschien heb je iets aan wat ruggespraak.

[dennissiemensma]

Bedankt voor je aanvulling. Het nadeel is dat ik ook niet meer exact weet welke wijziging waarvoor is, ondanks dat ik redelijk probeer om referenties in de commit messages te zetten. Alleen weet ik niet de echte achterliggende reden.

Wat betreft de edge-cases bij missende data, daar kan DSMR-reader sowieso niets in betekenen, dus ik ben het met je eens dat buiten de scope blijft.

Inmiddels is wel duidelijk dat de wijziging hoe dan ook ingrijpend gaat worden, dus dat scheelt wat in de voorzichtigheid. Ook omdat er inmiddels ook weer qya Python/Django versies gebumped moeten worden, dus er komt sowieso een nieuwe major DSMR-reader versie uit, die mag afwijken van de vorige 5.x versie (mits data forward compatible, maar dat is zelden een issue).

Ik denk dat uiteindelijk het slopen van de tussentabellen een hoop code scheelt, maar ook wel aardig wat kan raken qua API, MQTT, GUI, etc. Als in dat die data er straks niet meer is. Maar dat is dan maar zo.
Helemaal omdat het verschil dusdanig groot is (icm hoge prijzen) dat het niet meer een goede benadering is van wat men verbruikt. Een kleine afwijking vond ik nog acceptabel, maar klein is het niet meer helaas.

[Rudios81]

Allereest moet ik toegeven dat ik niet de gehele historie van gesprek hier gelezen heb, maar ik stuit ook op verschillen in dagelijks gas verbruik.
Wat mij met name opvalt is dat het dagelijkse gebruik binnen DSMR berekend wordt dmv de uurgetallen die uit de meter komen.
Vanuit DSMR maak ik gebruik van de mogelijkheid om data naar een influxDB te pushen. Daarin wordt alleen het cumulatieve getal van de gasmeter doorgestuurd, en dus in influxDB bewaard.
Nu, als ik vanuit die cumulatieve getallen een dagelijks getal bereken, komt dat niet overeen met hetgeen er door DSMR wordt berekend. Dat zou er dus eigenlijk op neer komen dat de uurgetallen die de meter afgeeft niet accuraat zijn???
Uiteindelijk zijn de € die er mee gemoeid gaan afhankelijk van de cumulatieve teller van de meter, daar wordt immers op afgerekend.

[dennissiemensma]

@Rudios81 je kunt er van uitgaan dat de gegevens uit de meter kloppen. De bug zit in de manier van berekenen in DSMR-reader