⚠️ 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.