Correctie op mijn doorrekening: de uurexport van DSMR-reader was 1,8% te laag
Naar aanleiding van de tip hierboven over
issue #1770 van DSMR-reader heb ik mijn eigen data nagelopen. Ik verwachtte een verwaarloosbaar verschil, maar dat viel tegen: de uurstatistieken (en dus de uurexport waarmee ik rekende) missen tot en met v5.12 structureel de laatste minuut van elk uur. Dat is 1/60, oftewel ruim 1,7%, op afname én teruglevering, in elk register. De dagtotalen klopten bij mij wel; die weken over vier jaar maar 0,1% af van de meterstanden.
Zo heb ik het gecontroleerd- Via de API van DSMR-reader de dagstatistieken opgehaald. Sinds 2023 staat daar per dag de meterstand om 00:00 bij. Het verschil tussen twee opeenvolgende meterstanden is het echte dagverbruik, per register.
- Dat vergeleken met de som van de 24 uurwaarden uit de export. Uitkomst over kalenderjaar 2025: uurexport 4.060 kWh afname, meterstanden 4.136 kWh. Teruglevering 4.390 tegenover 4.469 kWh. Op alle vier registers tussen de -1,7% en -2,1%.
- Ter verificatie één uur uit de ruwe metingen nagerekend: het uurtotaal is exact "rij 09:59 min rij 09:00" uit de per-minuut-tabel, de minuut 09:59-10:00 ontbreekt.
Oplossing
DSMR-reader v6.2 (augustus 2026) fixt dit voor nieuwe data én heeft een commando om het met terugwerkende kracht te herstellen uit de opgeslagen meterstanden. Het draait standaard als dry-run:
code:
1
2
3
4
5
| ./manage.py dsmr_stats_recalculate_from_meter_positions --analyze
./manage.py dsmr_stats_recalculate_from_meter_positions --days
./manage.py dsmr_stats_recalculate_from_meter_positions --hours
./manage.py dsmr_stats_recalculate_from_meter_positions --days --write
./manage.py dsmr_stats_recalculate_from_meter_positions --hours --write |
Bij mij: "1448 mismatches in 1448 days" bij de analyse, daarna 34.168 van de 34.667 uren bijgewerkt. Na de herberekening sluit de som van de uren op 0,00% aan bij de meterstanden. Wie de Docker-image van xirixiz gebruikt: het commando staat in de container op /app/manage.py, en let bij de upgrade naar v6 op de nieuwe CONTAINER_-variabelen en laat DJANGO_ALLOWED_HOSTS op * staan, anders faalt de healthcheck van de container.
Draai je nog v5 en wil je weten of het bij jou speelt: tel per dag de uurwaarden uit de export op en leg die naast de meterstanden in het archief. Als het verschil consequent rond de 1,7% zit, heb je hetzelfde. In de GitHub-thread zie je overigens ook gebruikers bij wie de dagtotalen afwijken, dus die zou ik meteen meenemen.
Gecorrigeerde cijfers
Mijn verbruik afgelopen 12 maanden is 4.561 kWh afname en 4.606 kWh teruglevering (was 4.478 / 4.524). De verdeling over de blokken verandert niet, alles schuift 1,8% op. Greenchoice rekende met 4.399 / 4.805 kWh, hun raming zat dus niet aan de hoge maar aan de lage kant.
| Scenario | Huidig | Nieuw | Verschil |
|---|
| 2026, met saldering | € 22 | € 26 | vrijwel gelijk |
| 2027, geen saldering, huidig contract blijft op €0,05 | € 1.142 | € 1.155 | huidig € 13 goedkoper |
| 2027, geen saldering, huidig contract naar wettelijk minimum (50% kaal tarief = €0,073 / €0,078), geen terugleverkosten | € 1.030 | € 1.155 | huidig € 125 goedkoper |
| 2027, als GC op het huidige contract óók de terugleverkosten van het nieuwe aanbod zou rekenen | € 1.351 | € 1.155 | huidig € 196 duurder |
Ook hier zit de €50 cashback niet in. De netto terugleververgoeding in het nieuwe aanbod komt op €108 over 4.606 kWh, nog steeds ruim 2 cent per kWh.
Conclusie
Inhoudelijk verandert er niets: alle bedragen gaan een paar euro omhoog, de verschillen tussen de contracten blijven binnen een paar euro hetzelfde, en blijven zitten wint in elk scenario behalve het onwaarschijnlijke. Maar wie met DSMR-reader-uurdata rekent, doet er goed aan eerst te upgraden en te herberekenen. Bij een vergelijking tussen contracten valt 1,8% grotendeels tegen elkaar weg, bij een absolute jaarafrekening of een salderingsberekening niet.