⚠️ 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: https://github.com/dsmrreader/dsmr-reader/issues/1217#issuecomment-981156657

• 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 4a1d40d3592d84c5dfb16fe47e071d88b9ce7c06.

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. https://github.com/dsmrreader/dsmr-reader/issues/1771#issuecomment-1360028032

[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.

[nickgr6]

Top, laat maar weten wanneer ik kan helpen met testen.

[dennissiemensma]

Nu ik er weer wat dieper in graaf, zie ik waarom gas sowieso al afwijkt. De eerste meting van de dag bevat (bij oude meters) sowieso niet perse de nieuwe gasstand.

Mijn gasmeter update de slimme meter elk uur, maar dat is niet om klokslag middernacht. Vanochtend duurde het bijna 5 minuten voordat de gasupdate geregistreerd was:

Ik denk dat o.a. dat de reden is zoals het nu werkt. Ik zal het meenemen in ieder geval, want anders klopt de gasstand nog steeds niet om middernacht. Die moet dus uit twee verschillende metingen komen, omdat anders de elektrastand ook niet klopt.

[dennissiemensma]

Een deel heb ik kunnen fixen, want voortaan logt DSMR-reader ook per dag het tijdstip van de meterstanden. Daarbij is bij verschillende varianten ook goed te zien waar het euvel o.a. zit: om middernacht is de gasstand niet bijgewerkt.

Wat situaties voor terugwerkende kracht fixen. Het gaat telkens om het tijdstip rechtsonderin:

1. Gastijdstip gebaseerd op alle beschikbare recente metingen (tijdstip ELEKTRA telegram)

Voor installaties waarbij automatische opschoning nog niet gedaan is, is dat niet erg. Zoals bij deze zijn alle metingen beschikbaar en zit de nieuwe gasstand in het telegram van 8 over 12.

---

2. Gastijdstip gebaseerd op uurlijkse metingen na opschoning (tijdstip ELEKTRA telegram)

Deze situatie is lastiger en geldt standaard voor alle gebruikers met standaardinstellingen. Na X periode worden alleen de eerste en laatste (elektra)meting per uur bewaard.

Dus hier zijn maar 2 telegrammen per uur beschikbaar en omdat de kans nihil is dat binnen 10 seconden na middernacht de gasstand is bijgewerkt, is hier te zien dat de gasstand na een uur wordt gepakt.

Dat is dus niet erg, gezien 3. hieronder.

---

3. Gastijdstip gebaseerd op uurlijkse metingen na opschoning (tijdstip GAS telegram)

Idem als bij 2. hierboven, maar nu gebaseerd op het tijdstip dat de gasmeter telkens meestuurt. Hetzelfde telegram als hierboven, dus bijna een uur na middernacht. Echter, omdat om ~1 uur 's nachts de gasstand van dat tijdstip ook niet bekend is, is het niet erg.

---

Deze fix wordt automatisch geprobeerd bij de volgende release, maar werkt dus alleen voor gebruikers die ook de (opgeschoonde) metingen nog hebben.

Situaties 1 en 2 zijn puur ter indicatie, de fix wordt nummer 3. Voor v4-meters is dat exact op het uur, voor v5 meters vermoedelijk een tijdstip tussen 0:00 en 0:05.

[dennissiemensma]

Ik heb nu ook een mogelijke fix voor de totalen per dag met terugwerkende kracht.

Er vanuitgaande dat de uurtotalen dus wel lijken te kloppen, krijg ik zoiets als resultaat over ~7 jaar aan data:

Difference by year:
2015:   3.971 m³
2016:   22.317 m³
2017:   12.948 m³
2018:   3.167 m³
2019:   3.573 m³
2020:   0.563 m³
2021:   8.278 m³
2022:   10.989 m³

Occurrences by year:
2015:   19 x
2016:   129 x
2017:   52 x
2018:   64 x
2019:   12 x
2020:   4 x
2021:   24 x
2022:   48 x

Total gas difference:   65.806 m³   (352 x)

[dennissiemensma]

Ik ga het iets simpeler oplossen. Bovenstaande fixes + herberekenen prijzen (waar van toepassing) wordt automatisch gedaan.

De output van het script zal ik dan als Dashboard-notificatie zetten. Zodat het ook altijd terug te zien is:

---

[dennissiemensma]

Ik draai de fix nu zelf een tijdje en het lijkt goed. De totalen komen overeen met de meterstanden, die door de fix ook betrouwbaarder zijn.

De volgende stap is nog even alles langslopen en wat docs/toelichting.

[nickgr6]

Klinkt goed! Ik wacht het rustig af!

[dennissiemensma]

Ik heb het nu een tijdje draaien en het lijkt beter.

Echter kan ik het niet makkelijk laten previewen voor Docker-gebruikers, omdat die niet makkelijk van branch kunnen wisselen. Wellicht dat ik Xirixiz kan vragen of er een experimentele build gemaakt kan worden op basis van de development branch hier.

[dennissiemensma]

Bij 1 gebruiker levert de datamigratie wijzigingen op waarvan nog niet duidelijk is of dat klopt of niet. Ik zal nog een tweede hotfix uitbrengen die de datamigratie skipt, voor nu. Dan kan het later handmatig/optioneel.

[dennissiemensma]

@FutureCow kan jij wellicht ergens een dump van (een deel van) je database delen zodat ik kan zien waar die grote verschillen vandaan komen?

https://github.com/dsmrreader/dsmr-reader/issues/1795#issuecomment-1407704731

[FutureCow]

2017-03-11 | Before: 4.569 m³ - Recalculated: 1289.238 m³ | Difference: 1284.669 m³ 2017-03-12 | Before: 2.677 m³ - Recalculated: 2121.984 m³ | Difference: 2119.307 m³ 2017-03-13 | Before: 3.802 m³ - Recalculated: 2194.978 m³ | Difference: 2191.176 m³ 2017-03-14 | Before: 2.903 m³ - Recalculated: 2282.002 m³ | Difference: 2279.099 m³ 2017-03-15 | Before: 2.287 m³ - Recalculated: 1839.808 m³ | Difference: 1837.521 m³ 2017-04-09 | Before: 2.229 m³ - Recalculated: 2.315 m³ | Difference: 0.086 m³ 2017-04-10 | Before: 2.168 m³ - Recalculated: 29.986 m³ | Difference: 27.818 m³ 2017-04-11 | Before: 2.192 m³ - Recalculated: 89.646 m³ | Difference: 87.454 m³ 2017-04-12 | Before: 3.274 m³ - Recalculated: 141.726 m³ | Difference: 138.452 m³ 2017-04-13 | Before: 2.966 m³ - Recalculated: 230.300 m³ | Difference: 227.334 m³ 2017-04-14 | Before: 4.143 m³ - Recalculated: 307.467 m³ | Difference: 303.324 m³ 2017-04-15 | Before: 2.905 m³ - Recalculated: 170.091 m³ | Difference: 167.186 m³ 2017-04-30 | Before: 1.806 m³ - Recalculated: 20.250 m³ | Difference: 18.444 m³ 2017-05-01 | Before: 3.202 m³ - Recalculated: 30.243 m³ | Difference: 27.041 m³ 2017-07-08 | Before: 0.392 m³ - Recalculated: 8.534 m³ | Difference: 8.142 m³ 2017-09-23 | Before: 0.027 m³ - Recalculated: 0.132 m³ | Difference: 0.105 m³

Ik wil eventueel wel helpen om te debuggen. Data in mijn database is nu natuurlijk aangepast met de nieuwe (verkeerde) gegevens. Ik heb wel eens iets met de hand toegevoegd, geen idee meer of dat deze data zijn? Zit in de backup (van gister) ook de oude database?

[dennissiemensma]

Een van beiden is goed. Een backup van gisteren zou helemaal top zijn, omdat ik het dan relatief makkelijk kan laten "naspelen".

[dennissiemensma]

Thanks, ik heb hem binnengehaald!

[dennissiemensma]

@FutureCow als ik in het Archief kijk naar de data van 9 april 2017 tot 15 april 2017 (nav die meldingen in migratie) dan lijkt het gasverbruik per uur absurd veel.

Het begint de 9e heel laag:

De dag erna al op 2+ per uur:

Rond de 14e al 11+ kuub per uur:

En de 15e stopt het opeens:

Het is natuurlijk bijna 6 jaar geleden, maar zegt die week jou uberhaupt wat qua speciale dingen? Of wellicht een bug in DSMR-reader rond die tijd? Er staat me zelf niets bij.

---

De migratie telt namelijk al het uurverbruik op om (doorgaans kleine) afwijkingen recht te trekken. Strikt gezien klopt de fix bij jou, maar de brondata is uiteraard heel gek, waardoor de fix ook heel gek wordt.

[dennissiemensma]

@FutureCow als ik trouwens naar de meterstanden kijk (is toevallig een andere fix in een andere migratie van dezelfde release), dan lijken die wel aannemelijk, namelijk 2 tot 6 kuub per dag verbruikt.

Verder lijkt het sowieso af te wijken qua gas per uur in die maand. Ook de week ervoor zou het een paar kuub per dag zijn, maar op zo'n dag komen de uren bij elkaar opgeteld niet eens op 1 kuub uit.

Ik denk overigens ook niet dat we dan achter de oorzaak gaan komen, tenzij je zelf nog iets kan heugen. ~Wellicht dat ik de migratie voor nu dan laat voor wat het is, en nog wat andere gebruikers afwacht.~ Omdat de meterstanden nu ook rechtgetrokken zijn (waar mogelijk), kan ik altijd nog een keer een migratie maken die ook het verbruik per uur opnieuw berekent.

[dennissiemensma]

In v5.10.2 is de migratie voor nu even uitgeschakeld. Ik denk dat ik voor een volgende release iets maak waardoor het toch met de hand te dry-runnen en uit te voeren is.

Samen met een nog-te-maken migratie die gewoon naar de meterstanden kijkt en het (eventuele foute) uurverbruik negeert, zoals bij @FutureCow. Voor nu hoef je daar niets mee te doen, je lijkt immers nog de oude meterstanden te hebben.

[FutureCow]

Zal dan idd een n=1 fout zijn. Geen idee meer waar de vreemde uur waarden vandaan komen, 15 m3 krijg ik er zelfs met een uur douchen er niet doorheen. Makkelijkste voor mij om de waarden via de admin interface even aan te passen?

[spiralshapeturtle]

In v5.10.2 is de migratie voor nu even uitgeschakeld. Ik denk dat ik voor een volgende release iets maak waardoor het toch met de hand te dry-runnen en uit te voeren is.

Samen met een nog-te-maken migratie die gewoon naar de meterstanden kijkt en het (eventuele foute) uurverbruik negeert, zoals bij @FutureCow. Voor nu hoef je daar niets mee te doen, je lijkt immers nog de oude meterstanden te hebben.

Tnx, en voor mensen die nu op 5.10.1 zitten, gaat dat goed of is het verstandiger een VM restore uit te voeren en 12 uur terug in de tijd te gaan?

[dennissiemensma]

Zal dan idd een n=1 fout zijn. Geen idee meer waar de vreemde uur waarden vandaan komen, 15 m3 krijg ik er zelfs met een uur douchen er niet doorheen. Makkelijkste voor mij om de waarden via de admin interface even aan te passen?

@FutureCow je kunt ze handmatig aanpassen op /admin/dsmr_stats/daystatistics/ of wachten tot er een nieuwe fix voor komt waarbij het automatisch kan.

[dennissiemensma]

Tnx, en voor mensen die nu op 5.10.1 zitten, gaat dat goed of is het verstandiger een VM restore uit te voeren en 12 uur terug in de tijd te gaan?

@rodeho de migratie/fix zelf is goed, dus je kunt daar op blijven. Alleen wil ik nog een tweede maken en daarna ze via een knop of iets handmatig laten uitvoeren, ipv automatisch voor iedereen. De belangrijkste fix is overigens de release zelf, die vanaf nu beter en meer bijhoudt.

Kwamen er bij jou nog (grote) meldingen uit qua afwijkingen nav de migratie?

[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.