Dagstatistieken lopen achter (/etc/localtime:/etc/localtime:ro)

[poudenes]

Oplossing: heb de regel: /etc/localtime:/etc/localtime:ro verwijderd uit mijn docker-compose file

Description

Hoi Allen,

Ik heb mijn backup van DSMR (gemaakt in postgres/timescale) in een postgres dB terug gezet.
Alles ging goed. DSMR gestart en alle oude waardes en archief waren terug.

Echter zie ik nu een heleboel telegram regels die niet verwerkt zijn:

Processed: False
Geeft aan of deze meting al verwerkt is in het samenvoegen van statistieken

Timegap van de backup en start nieuwe dB

[14 juni 2022 11:31] - False	7281.856	7717.392	     2453.176
[13 juni 2022 15:12] - True	7279.459	7713.720.    2452.711

DSMR-reader version

v5.2

DSMR-reader platform

Docker

Simular issue

#1619

Debug info dump

DSMR-READER
    App / Python / Database                                                       v5.2 / v3.10.4 / postgresql
    BE sleep / DL sleep / Retention / Override                                     1.0s / 5.0s / 168h / False
    Latest telegram version read / Parser settings                                                 "50" / "4"

DATA
    Telegrams total (est.)                                                                             136299
    Consumption records electricity / gas (est.)                                                46508 / 38466

UNRESOLVED ISSUES
    Dagstatistieken lopen achter                                                         1 dag, 9 uur geleden

[dennissiemensma]

@poudenes wat is je debug info dump? Niet te verwarren met de debug log. Deze kun je inzien op de "Over & ondersteuning" pagina.

Bijvoorbeeld:

DSMR-READER
    App / Python / Database                                                        v5.3 / v3.9.9 / postgresql
    BE sleep / DL sleep / Retention / Override                                     5.0s / 0.5s / 168h / False
    Latest telegram version read / Parser settings                                                 "42" / "4"

DATA
    Telegrams total (est.)                                                                             176472
    Consumption records electricity / gas (est.)                                               122267 / 49233

[poudenes]

Sorry bij deze:

DSMR-READER
    App / Python / Database                                                       v5.2 / v3.10.4 / postgresql
    BE sleep / DL sleep / Retention / Override                                     1.0s / 5.0s / 168h / False
    Latest telegram version read / Parser settings                                                 "50" / "4"

DATA
    Telegrams total (est.)                                                                             136299
    Consumption records electricity / gas (est.)                                                46508 / 38466

UNRESOLVED ISSUES
    Dagstatistieken lopen achter                                                         1 dag, 9 uur geleden

[dennissiemensma]

Ik zag in je logs niet zo snel de melding null value in column, vanwaar dat je bij #1619 uit kwam?

Daarnaast zie ik ook niet bij je dump een melding als Too many unprocessed readings. Kan het zijn dat de achterstand inmiddels is ingelopen?

Anders zul je in de DB moeten kijken vanaf welk moment de verwerking gestopt is.

Bijvoorbeeld met deze query:

SELECT id, timestamp, electricity_delivered_1, electricity_delivered_2 FROM dsmr_datalogger_dsmrreading WHERE processed = false ORDER BY timestamp ASC;

[poudenes]

In dashboard zie ik nu dit staan:

   Te veel onverwerkte telegrammen: 162   (over een uur)
   Dagstatistieken lopen achter   (1 dag, 10 uur geleden)

Heb deze morgen de backup terug gezet. Dus alle data is ongeveer een uur oud.

Ik kwam uit op die issue denk vanwege een zoek optie die wellicht niet de juiste was.

[dennissiemensma]

Ik vermoed dat je issues hebt met de systeemtijd of iets. De melding "(over een uur)" zou moeten aangeven wanneer voor het laatst een telegram is verwerkt. Die zou eigenlijk nooit in de toekomst moeten staan.

Draaide je hiervoor dezelfde Docker setup/versies van de DB/DSMR-reader?

[poudenes]

Oude systeem is RPi4 nieuwe systeem is Synology NAS

Rpi4: Tue Jun 14 10:26:38 CEST 2022

NAS: Tue Jun 14 10:26:50 CEST 2022

command DATE op command line geeft op beide systemen hetzelfde weer

[dennissiemensma]

Was je Docker-setup daar hetzelfde? Want dit neigt naar iets als #1282

[poudenes]

NAS:

postgres@postgres:/$ date
Tue 14 Jun 2022 10:35:50 AM CEST

postgres@postgres:/$ psql dsmr -c 'select timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;'
       timestamp        
------------------------
 2022-06-14 10:32:13+02
 2022-06-14 10:32:07+02
 2022-06-14 10:32:01+02
 2022-06-14 10:31:55+02
 2022-06-14 10:31:49+02
(5 rows)

RPi4:

postgres@77b2833f-timescaledb:/$ date
Tue Jun 14 10:36:25 CEST 2022

postgres@77b2833f-timescaledb:/$ psql dsmr -c 'select timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;'
       timestamp        
------------------------
 2022-06-14 07:47:06+00
 2022-06-14 07:47:00+00
 2022-06-14 07:46:54+00
 2022-06-14 07:46:48+00
 2022-06-14 07:46:42+00
(5 rows)

Ik zie wel een verschil in timestamp in de 2 dockers zelf

RPi4

postgres@77b2833f-timescaledb:/$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.15.1
PRETTY_NAME="Alpine Linux v3.15"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

NAS

postgres@postgres:/$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[dennissiemensma]

Het hangt er vanaf wat je met elkaar vergelijkt. Die +02 en +00 is erg belangrijk, want die moet je erbij nemen.

Bij de +2 zul je dat in aantal uren eraf moeten trekken om in de UTC (+00) tijdzone te zitten. Of andersom, bij de +00's twee uur optellen om in onze zomertijd te komen.

Je kunt de oplossing in #1282 checken of je van hetzelfde last hebt.

[poudenes]

Wat ik heb gedaan is

/etc/localtime:/etc/localtime:ro

verwijderd uit docker-compose nu is NAS gelijk aan RPi alleen tijd klopt niet meer

root@postgres:/# date
Tue 14 Jun 2022 10:42:40 AM CEST
root@postgres:/# su postgres
postgres@postgres:/$ psql dsmr -c 'select timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;'
       timestamp        
------------------------
 2022-06-14 08:42:31+00
 2022-06-14 08:42:25+00
 2022-06-14 08:42:19+00
 2022-06-14 08:42:13+00
 2022-06-14 08:42:07+00
(5 rows)

[poudenes]

Ik open Dashboard en zie wel ineens dat alle errors weg zijn.

[dennissiemensma]

Dat is gegarandeerd door je wijziging.

Deze tijden zijn overigens hetzelfde:

Tue 14 Jun 2022 10:42:40 AM CEST
2022-06-14 08:42:31+00

CEST = zomertijd, in Nederland +2 tov UTC (+00)

[poudenes]

Ja ik zie onverwerkte telegrams maar op gegeven moment verdwijnen ze.

DANK voor de support !!!

[dennissiemensma]

Als je de (standaard) "groeperen per minuut" aan hebt staan, worden ze pas de volgende minuut verwerkt.