Dsmr-reader: Archief klopt niet

[gertjuhh]

Sinds een week maak ik gebruik van DSMR reader.
Gisteren (16-11) zag ik dat er nog geen data in het archief zat voor de dag ervoor (15-11).
Bleek op de status pagina dat er een hoop data nog niet verwerkt was.
Na een restart van de dsmr_backend werd ook de resterende data verwerkt.

Echter na dat alle data verwerkt was zag ik in het archief slechts ~3 uur aan data voor 15-11
Na wat zoeken kwam ik hier op uit: https://dsmr-reader.readthedocs.io/nl/latest/faq.html#recalculate-prices-retroactively
Dat leek me een simpele manier het even te corrigeren.

Helaas hebben nu al mijn dagen in het archief slecht data voor ~3 uur, zie screenshot.

Ik dacht ergens gelezen te hebben dat het soms voor komt dat de datalogger service het proces kan verstoren.
Dus ik heb de datalogger tijdelijk uitgezet en nogmaals een "./manage.py dsmr_backend_delete_aggregated_data" uitgevoerd.
Helaas bracht me dit tot hetzelfde resultaat.

Enig idee hoe ik dit recht kan trekken?

[dennissiemensma]

Dat is een bijzondere situatie die ik nog niet eerder gezien heb. Zou je eens willen kijken of de metingen/data wel compleet zijn van alle uren?

Metingen:

SELECT DATE_TRUNC('hour', "dsmr_datalogger_dsmrreading"."timestamp") AS "item_hour" FROM "dsmr_datalogger_dsmrreading" GROUP BY DATE_TRUNC('hour', "dsmr_datalogger_dsmrreading"."timestamp" ) ORDER BY "item_hour" ASC;

Data afgeleid van metingen:

SELECT DATE_TRUNC('hour', "dsmr_consumption_electricityconsumption"."read_at") AS "item_hour" FROM "dsmr_consumption_electricityconsumption" GROUP BY DATE_TRUNC('hour', "dsmr_consumption_electricityconsumption"."read_at" ) ORDER BY "item_hour" ASC ;

Edit: Je kunt de queries uitvoeren met:

• sudo su - postgres
• psql dsmrreader
• Je zit als het goed is nu in de postgresql client waar je queries kunt uitvoeren.

[gertjuhh]

Voor de initiële "./manage.py dsmr_backend_delete_aggregated_data" was in het achief per dag alle data netjes te zien.

Metingen:

...
2017-11-09 23:00:00+01
 2017-11-10 00:00:00+01
 2017-11-10 01:00:00+01
 2017-11-10 02:00:00+01
 2017-11-10 03:00:00+01
 2017-11-10 04:00:00+01
 2017-11-10 05:00:00+01
 2017-11-10 06:00:00+01
 2017-11-10 07:00:00+01
 2017-11-10 08:00:00+01
 2017-11-10 09:00:00+01
 2017-11-10 10:00:00+01
 2017-11-10 11:00:00+01
 2017-11-10 12:00:00+01
 2017-11-10 13:00:00+01
 2017-11-10 14:00:00+01
 2017-11-10 15:00:00+01
 2017-11-10 16:00:00+01
 2017-11-10 17:00:00+01
 2017-11-10 18:00:00+01
 2017-11-10 19:00:00+01
 2017-11-10 20:00:00+01
 2017-11-10 21:00:00+01
 2017-11-10 22:00:00+01
 2017-11-10 23:00:00+01
 2017-11-11 00:00:00+01
 2017-11-11 01:00:00+01
...

Data afgeleid van metingen:

...
2017-11-09 23:00:00+01
 2017-11-10 00:00:00+01
 2017-11-10 01:00:00+01
 2017-11-10 02:00:00+01
 2017-11-10 03:00:00+01
 2017-11-10 04:00:00+01
 2017-11-10 05:00:00+01
 2017-11-10 06:00:00+01
 2017-11-10 07:00:00+01
 2017-11-10 08:00:00+01
 2017-11-10 09:00:00+01
 2017-11-10 10:00:00+01
 2017-11-10 11:00:00+01
 2017-11-10 12:00:00+01
 2017-11-10 13:00:00+01
 2017-11-10 14:00:00+01
 2017-11-10 15:00:00+01
 2017-11-10 16:00:00+01
 2017-11-10 17:00:00+01
 2017-11-10 18:00:00+01
 2017-11-10 19:00:00+01
 2017-11-10 20:00:00+01
 2017-11-10 21:00:00+01
 2017-11-10 22:00:00+01
 2017-11-10 23:00:00+01
 2017-11-11 00:00:00+01
 2017-11-11 01:00:00+01
...

De afgelopen paar dagen zijn nu ook goed gearchiveerd:

Ben nu aan het wachten tot alle data weer opnieuw verwerkt is om te zien wat het resultaat is...

[dennissiemensma]

Hmm vreemd. Laat maar weten of het zichzelf uiteindelijk heeft opgelost.

[gertjuhh]

Helaas :-1:

[dennissiemensma]

Je bent helaas de eerste die dit vreemde gedrag heeft gemeld en ik heb er ook niet echt een verklaring voor.

Ben je toevallig in de gelegenheid om een database-dump te maken en dat ergens te hosten/op te sturen? Dan kan ik hier in mijn ontwikkelomgeving uitzoeken wat er precies gebeurt.

[gertjuhh]

Het betreft een nieuwe Ubuntu 16.04 64bit server installatie op een Intel NUC (dus geen Rpi).

geert@batgirl:~$ uname -a
Linux batgirl 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

geert@batgirl:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"



md5-25d297e2604dceea7e3ab737edf14aa9



dsmr@batgirl:~/dsmr-reader$ python --version
Python 3.5.2



md5-25d297e2604dceea7e3ab737edf14aa9



dsmr@batgirl:~/dsmr-reader$ pg_config --version
PostgreSQL 9.5.10

[dennissiemensma]

Bedankt, je mag hem weer offline halen. Ik heb een kopie en zal er later voor je naar kijken.

[dennissiemensma]

Ik heb de bug al gevonden.

Voor het genereren van de uur/dagstatistieken kijkt de applicatie of de betreffende dag al voorbij is (< vandaag). Zo ja, dan pas genereert hij alle statistieken van die dag. Dat werkt voor een lopende applicatie prima.

In het geval van alles verwerken met terugwerkende kracht, werkt die check natuurlijk niet meer. De applicatie verwerkt batches van maximaal ~1000 onverwerkte telegrammen. Dus als hij niet in één run de complete dag verwerkt, gaat die alvast de statistieken van die dag genereren.

Ik heb nu een fix gemaakt die ervoor zorgt dat de statistieken alleen gegenereerd worden wanneer zowel de dag voorbij is én er geen onverwerkte telegrammen voor die dag meer zijn.

[gertjuhh]

Dat is snel!
Als ik iets kan testen hoor ik het graag.

[dennissiemensma]

Je zou trouwens nog kunnen kijken of het weggooien van alle uur- en dagstatistieken het ook (voor nu) oplost. Let op, hiervoor moeten wel eerst alle metingen weer bij zijn qua verwerking.

Je kunt deze query uitvoeren:
truncate table dsmr_stats_daystatistics, dsmr_stats_hourstatistics;

Als het goed is zie je dan in dsmr_backend in Supervisor dat hij alsnog de uren/dagen hergenereert. Wellicht pakt die dan wel 24 uur per dag.

[dennissiemensma]

De fix is klaar en gaat mee met de volgende release.

[gertjuhh]

Wellicht een stomme vraag, maar kan ik deze fix al testen voor dat 1.11 uit komt?

[dennissiemensma]

• sudo su - dsmr
• git fetch
• git checkout -b development origin/development
• ./deploy.sh

Als het goed is zit je daarna op iets als versie v1.11b7.

[gertjuhh]

Je bent een held!

Werkt als een trein, alle dagen laten nu netjes de juiste waarden zien.
Ook fijn dat je nu alleen de statistics kan verwijderen, was nu binnen een paar seconden klaar met opnieuw opbouwen.

Nog een stomme vraag, hoe switch ik nu straks terug naar stable wanneer 1.11 uit is?
Ben niet zo bekend met git :blush:

[dennissiemensma]

Bedankt voor het melden en tevens uitproberen. Je kunt na release terug met:

• sudo su - dsmr
• git fetch
• git checkout master
• ./deploy.sh

[dennissiemensma]

v1.11 is gereleased, inclusief dit ticket.