⚠️ Docker only - Reading timestamp differences (1 or 2 hours off)

[8uurg]

Oplossing

Verwijder deze mount:

/etc/localtime:/etc/localtime:ro

Alternatief

Gebruik postgres:12.4-alpine

https://github.com/dsmrreader/dsmr-reader/issues/1282#issuecomment-778618994

---

Oorspronkelijk issue:

Server error tussen 23:00 en 00:00: LookupError: No electricity readings found for: 2021-02-11

Omgeving Ik draai DSMR reader in Docker, met een remote datalogger.

DSMR-READER
    App / Python / Database                                                       v4.11 / v3.9.1 / postgresql
    BE sleep / DL sleep / Retention / Override                                     1.0s / 5.0s / 672h / False
    Latest telegram version read / Parser settings                                                 "50" / "4"

DATA
    Telegrams total (est.)                                                                             209017
    Consumption records electricity / gas (est.)                                                 38752 / 8479

UNRESOLVED ISSUES
    Too many unprocessed readings: 1937                                                          a minute ago

(voor unprocessed readings heb ik de reportagesnelheid al op 5s gezet, ipv de standaardwaarde van 0.5s.)

Probleemomschrijving Na terugzetten van een backup probeert DSMR na opstarten herhaaldelijk rijen toe te voegen waarin waardes voorkomen met null:

dsmrdb_1  | 2021-02-10 22:29:00.344 CET [38] ERROR:  null value in column "delivered_1" violates not-null constraint
dsmrdb_1  | 2021-02-10 22:29:00.344 CET [38] DETAIL:  Failing row contains (70779, 2021-02-09 04:00:00+01, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).
dsmrdb_1  | 2021-02-10 22:29:00.344 CET [38] STATEMENT:  INSERT INTO "dsmr_consumption_electricityconsumption" ("read_at", "delivered_1", "returned_1", "delivered_2", "returned_2", "currently_delivered", "currently_returned", "phase_currently_delivered_l1", "phase_currently_delivered_l2", "phase_currently_delivered_l3", "phase_currently_returned_l1", "phase_currently_returned_l2", "phase_currently_returned_l3", "phase_voltage_l1", "phase_voltage_l2", "phase_voltage_l3", "phase_power_current_l1", "phase_power_current_l2", "phase_power_current_l3") VALUES ('2021-02-09T03:00:00+00:00'::timestamptz, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL) RETURNING "dsmr_consumption_electricityconsumption"."id"

Dit herhaalt zich zo ongeveer iedere 30s, ondertussen update de live grafiek niet.

Verder heb ik tussen 23:00 en 24:00 geen toegang tot het dashboard en krijg ik het volgende bericht (om 23:18):

Server Error
Sorry, something unexpected happened.
Exception:

LookupError: No electricity readings found for: 2021-02-11

Traceback:

  File "/usr/local/lib/python3.9/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)

  File "/usr/local/lib/python3.9/site-packages/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)

  File "/dsmr/dsmr_frontend/mixins.py", line 11, in dispatch
    return super().dispatch(request, *args, **kwargs)

  File "/usr/local/lib/python3.9/site-packages/django/views/generic/base.py", line 98, in dispatch
    return handler(request, *args, **kwargs)

  File "/usr/local/lib/python3.9/site-packages/django/views/generic/base.py", line 159, in get
    context = self.get_context_data(**kwargs)

  File "/dsmr/dsmr_frontend/views/dashboard.py", line 31, in get_context_data
    context_data['consumption'] = dsmr_consumption.services.day_consumption(

  File "/dsmr/dsmr_consumption/services.py", line 248, in day_consumption
    raise LookupError("No electricity readings found for: {}".format(day))

Kanttekening Voor als iemand anders dit tegenkomt: Ik heb dit kort opgelost door de constraints uit de tabellen te verwijderen

START TRANSACTION;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_1 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_2 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_1 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_2 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_delivered DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_returned DROP NOT NULL;
COMMIT;

Om de rijen toegevoegd te laten worden, om ze vervolgens weer te verwijderen:

DELETE FROM dsmr_consumption_electricityconsumption WHERE delivered_1 IS NULL;

En de constraints weer teruggezet:

START TRANSACTION;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_1 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_2 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_1 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_2 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_delivered SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_returned SET NOT NULL;
COMMIT;

Voor het laatste probleem heb ik echter geen oplossing... De datum en tijd in de containers (dsmr en db) zijn correct.

[dennissiemensma]

Bedankt voor je melding. Toevallig had iemand soortgelijke issues in xirixiz/dsmr-reader-docker/issues/171, dus mogelijk helpt dat in het vinden van de oorzaak met die null-meldingen.

Wat betreft je andere issue over de foutmelding tussen 23:00 en 0:00, dat klinkt erg als een tijdzone issue en klinkt als een bug in DSMR-reader bij het bepalen van de datum aan de hand van de huidige tijd.

• Welke database image/versie gebruik je in Docker?
• Welke tijdzone-instellingen gebruik je in de Docker envvars voor DSMR-reader/DB?
• Wat voor soort backup heb je teruggezet? Een volledige of een partial?
• Weet je nog of de backup uit dezelfde DSMR-reader versie kwam als die je nu draait? Of heb je die tegelijkertijd geupgrade?

[8uurg]

Yep. Ik had precies hetzelfde probleem als de persoon waarnaar je refereert, database was corrupt omdat de datum en tijd van de alpine docker image niet meer werkte op de Raspberry Pi 4 na een update van de containers. Dus ook hier was sprake van een update.

Een korte serie van de stappen die ik heb gezet:

• Heb de image op postgres:12 zet
• Losse docker-compose.yml gemaakt die alleen de database opstart en de backup directory aan de container mount,
• Backup teruggezet (Ik heb een van de laatste 'daily' backups die de docker image automatisch maakt gebruik gemaakt, deze lijkt volledig te zijn: ik heb data van > 1 maand geleden in de interface.).
• Terug naar de originele docker-compose
• Na opstarten begon direct bovenstaande issue met null-waardes en met de tijd offset (en: ik realiseer me nu in de live grafiek ook).

Tijdzone in de containers, op de host, en op de remote datalogger is allemaal Europe/Amsterdam en loopt gelijk, maar ik heb bij de remote datalogger dit wel aan moeten passen (Was eerst London, dus dat verklaart 1 uur tijdsverschil). Ik heb deze ook via supervisor opnieuw opgestart, maar wellicht is een volledige reboot nodig? Update: reboot uitgevoerd op remote datalogger verhelpt het ook niet.

Ik heb trouwens sinds het volgen van mijn eigen stappen geen problemen meer ondervonden met de NULL-waardes: het was iets wat alleen voorkwam na het terugzetten van de backup.

[dennissiemensma]

@8uurg dank voor de uitgebreide toelichting. @Tralapo wellicht wil je dezelfde stappen volgen als onderin bovenstaande comment: https://github.com/dsmrreader/dsmr-reader/issues/1282#issue-805921399 voor het oplossen van de null-waardes.

Ondertussen zal ik even kijken of ik wat kan vinden mbt de andere datumfout.

[Tralapo]

Ik ben zowel met Docker als SQL geen enorme pro, dus eigenlijk twee losse vragen aan @8uurg:

• Wat doen die comments nou eigenlijk precies? Constraints zegt mij zo niets
• Hoe voer ik ze precies uit in de Docker?

[dennissiemensma]

Verder heb ik tussen 23:00 en 24:00 geen toegang tot het dashboard en krijg ik het volgende bericht (om 23:18):

Het lijkt erop dat de specifieke fout komt doordat DSMR-reader de datum gebruikt van het meest recente telegram. Dat kan wellicht botsen met een paar seconden als de meter voorloopt, maar ik ga er vanuit dat jullie meter niet heel toevallig een uur voor loopt.

Helaas zie ik niet zo 1-2-3 waarom dit op deze manier gedaan is. Het is een wijziging van november 2017, dus lang geleden, voor v1.11. ~Ik denk dat ik het wijzig zodat die gewoon de datum pakt volgens DSMR-reader, en niet volgens de meter, en zal ik de foutafhandeling wat beter doen.~

[Tralapo]

@dennissiemensma Ik weet niet of het relevant is, maar wat me wel opvalt wat tijden betreft:

Als ik in de Admin naar geplande processen ga en er een aanpas, kun je naast het vakje tijd op 'Nu' klikken. Dan vult hij de correcte, huidige, tijd in, maar zodra ik op opslaan druk springt hij een uur vooruit en staat er 'over 59 minuten'.

[dennissiemensma]

@Tralapo dank voor de aanvulling, des te meer vermoedens ik heb dat het iets met de tijdzone is, want ik krijg dat zelf niet voor elkaar. Wat krijg je te zien als je inlogt op de docker container en date typt?

[8uurg]

@dennissiemensma Ik heb zelf ook de vermoedens dat het iets met tijdzones te maken heeft gegeven het precieze uur verschil. Aangezien mijn remote datalogger de tijdzone Europe/London had toen ik hem voor het eerst weer aanzette. Als je deze tijdzone plakt achter nederlandse tijd heb je 1 uur verschil met de huidige tijd. Ik weet echter niet hoe DSMR Reader intern omgaat met tijdzones, dus is een hypothese gebaseerd op weinig informatie...

Desnoods kan ik kijken of het met het terugzetten van de backup te maken heeft/of het door iets wat al in de database staat, te maken heeft door een losse database en een schone installatie te bekijken.

[Tralapo]

Heb dit gecheckt met docker exec -t [container-id] date en DSMR loopt gelijk met de Pi zelf (18:34 CET) en Postgress zegt 06:34PM CET. Ook goed dus, maar andere vorm.

[dennissiemensma]

@8uurg wat krijg je te zien op de commandline in de docker container als je date typt?

De (standaard) remote datalogger stuurt verder gewoon het telegram door, met de datumtijd van de meter, dus daar verwacht ik ook geen afwijkingen.

[dennissiemensma]

Ik weet echter niet hoe DSMR Reader intern omgaat met tijdzones

DSMR-reader kan overweg met tijdzones, waarbij alle datetimes in de applicatie een tijdzone hebben. Dat zeggende hebben moet DSMR-reader op sommige momenten of (zoals hier) bij het bepalen van datums wel het omzetten naar de lokale tijdzone. De lokale tijdzone zou degene moeten zijn die ingesteld is als DJANGO_TIMEZONE, die ook default naar onze NL-tijdzone.

Maar het lijkt erop dat dit toch niet in alle gevallen werkt. Want jullie geven beiden aan DJANGO_TIMEZONE=Europe/Amsterdam te gebruiken, wat ook goed zou moeten zijn.

En als ik het zelf probeer met DJANGO_TIMEZONE=UTC zie ik ook een verschil in /admin/dsmr_backend/scheduledprocess/6/change/:

En met DJANGO_TIMEZONE=Europe/Amsterdam:

Dus ik zie niet in wat jullie situatie veroorzaakt. Ik zal het sowieso vanavond hier ook even proberen na 23:00, maar ik verwacht dat ik het niet kan reproduceren.

[dennissiemensma]

Wat krijgen jullie te zien als jullie in de database container dit doen? Ik weet overigens niet of het eerst command nodig is in Docker.

sudo su - postgres

psql dsmrreader -c 'select timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;'

Bij mij is het:

       timestamp        
------------------------
 2021-02-11 17:47:54+00
 2021-02-11 17:47:34+00
 2021-02-11 17:47:14+00
 2021-02-11 17:46:54+00
 2021-02-11 17:46:34+00

Wat klopt, in de zin dat het 1 uur achterloopt, maar dat dat gecompenseerd wordt met +00 (UTC). In jullie geval zou ik een afwijking kunnen verwachten.

[Tralapo]

Hier nog even in afbeeldingen wat er gebeurt als ik een gepland proces met de hand invul op nu + 2 minuten.

Zodra ik op opslaan heb gedrukt, schiet hij een uur vooruit:

@dennissiemensma Met sudo docker exec -i dsmrdb psql dsmrreader -c "select timestamp from dsmr_datalogger_dsmrreading order by timestamp desc limit 5;" -U dsmrreader krijg ik:

       timestamp
------------------------
 2021-02-11 18:57:22+01
 2021-02-11 18:57:19+01
 2021-02-11 18:57:16+01
 2021-02-11 18:57:13+01
 2021-02-11 18:57:10+01
(5 rows)

[8uurg]

@dennissiemensma Date:

In de container bestaat bij mij de postgres user niet, deze stap sla ik dus over. SQL:

[Tralapo]

@8uurg Het loopt hier allemaal wat (snel) door elkaar heen nu, maar zou jij mij nog even kunnen toelichten hoe je die acties toepast om de null fouten weg te krijgen? Ik zit nog steeds voornamelijk met dat probleem namelijk, maar begrijp niet helemaal waar/hoe ik de fix toepas.

[8uurg]

@Tralapo De NULL fouten komen -- mijn inziens -- door telegrams die om een onbekende reden na verwerking overal null voor hebben (behalve de timestamp). De database faalt ze te verwerken (ze voldoen niet aan de eisen voor een valide waarde in de database), maar de verwerkingsprocedure probeert het dan opnieuw: het bericht is nog niet verwerkt. Als je SQL kan invoeren (eg. via psql) zorgt

START TRANSACTION;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_1 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_2 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_1 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_2 DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_delivered DROP NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_returned DROP NOT NULL;
COMMIT;

ervoor dat deze eisen komen te vervallen, de database staat toe dat deze waardes worden toegevoegd. Ondertussen worden de berichten (incl met NULL) verwerkt en in de database gestopt. De berichten met NULL moeten echter weer verwijderd worden (zie volgende commando). (! PAS OP ! Dit commando verwijdert databaseinformatie, zorg dus dat je een backup hebt of niet om de data geeft!)

DELETE FROM dsmr_consumption_electricityconsumption WHERE delivered_1 IS NULL;

(Ik ga er van uit dat er, net zoals bij mij, er sprake is dat alle waardes null zijn, en dat dus een check for een enkele kolom die non-null is volstaat)

Vervolgens zet ik de eisen weer terug naar normaal:

START TRANSACTION;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_1 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_2 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_1 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_2 SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_delivered SET NOT NULL;
ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_returned SET NOT NULL;
COMMIT;

[Tralapo]

@8uurg Maar hoe kom ik 'in' docker om deze SQL acties in te voeren? Simpelweg sudo docker exec -i dsmrdb psql -U dsmrreader en dan daarachter één voor één al die regels? Ben zoals gezegd nog een redelijke beginner op zowel docker als sql vlak.

Wat bedoel je precies met het hebben van een backup? Ben ik na deze actie alle gegevens uit dsmr kwijt? Want dit probleem ontstond juist bij het terugzetten van zo'n backup, dus ben ik dan niet terug bij af?

[8uurg]

@8uurg Maar hoe kom ik 'in' docker om deze SQL acties in te voeren? Simpelweg sudo docker exec -i dsmrdb psql -U dsmrreader en dan daarachter één voor één al die regels? Ben zoals gezegd nog een redelijke beginner op zowel docker als sql vlak.

Klopt!

Wat bedoel je precies met het hebben van een backup? Ben ik na deze actie alle gegevens uit dsmr kwijt? Want dit probleem ontstond juist bij het terugzetten van zo'n backup, dus ben ik dan niet terug bij af?

Je raakt niet alle data kwijt, maar als je in een live database data gaat verwijderen word ik altijd nerveus. Ik zorg er altijd voor en raad aan dat er een backup is: een typefout kan wel alles verwijderen...

[Tralapo]

Volgens mij doe ik het niet goed:

pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "START TRANSACTION;"
START TRANSACTION
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_1 DROP NOT NULL;"
ALTER TABLE
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN delivered_2 DROP NOT NULL;"
ALTER TABLE
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_1 DROP NOT NULL;"
ALTER TABLE
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN returned_2 DROP NOT NULL;"
ALTER TABLE
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_delivered DROP NOT NULL;"
ALTER TABLE
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "ALTER TABLE dsmr_consumption_electricityconsumption ALTER COLUMN currently_returned DROP NOT NULL;"
ALTER TABLE
pi@raspberrypi:[~] sudo docker exec -i dsmrdb psql -U dsmrreader dsmrreader -c "COMMIT;"                             
WARNING:  there is no transaction in progress
COMMIT

[8uurg]

Uh. Hij heeft de aanpassingen in een keer succesvol doorgevoerd. De bedoeling was meer om

sudo docker exec -it dsmrdb psql -U dsmrreader dsmrreader 

te gebruiken om een command line te krijgen en ze daarin uit te voeren.

Het commando is correct uitgevoerd, dus je hoeft het niet opnieuw te doen...

[Tralapo]

Ah, bedankt. Heb voor de zekerheid de eerste reeks ALTER TABLE commando's nog een keer gedaan via die interface.

De DELETE actie lijkt alleen niet echt iets te doen daarna, klopt dat?

dsmrreader=# DELETE FROM dsmr_consumption_electricityconsumption WHERE delivered_1 IS NULL;
DELETE 0

[8uurg]

Als het goed zou zijn, zou hij alle NULLs verwijderd moeten zijn, of zijn ze nog niet toegevoegd. Je moet even wachten na het aanpassen van de tabel om het de tijd te geven.

[Tralapo]

Ik had natuurlijk weer veel te veel haast. Heb de boel even opnieuw opgestart en de eerste reeks ALTER TABLE nogmaals gedaan.

Inmiddels, een paar minuutjes later, zie ik voor het eerst de hoeveelheid onverwerkte telegrammen omlaag gaan in plaats van omhoog! Van ruim 26000 stuks naar ruim 22000 stuks nu. Nog even geduld dus, maar er lijkt iets te gebeuren.

Update: De DELETE leverde nu ook 5 resultaten op. En inmiddels worden de dagstatistieken ook verwerkt!

Dat probleem is dus uit de weg! Ik kan zelf nog niet bevestigen of ik tussen 23:00 en 00:00 ook niet in de interface kan (niet getest), maar kans lijkt groot omdat ik wel vergelijkebare tijd-afwijkingen lijk te hebben.

[dennissiemensma]

Dank voor jullie input, ik heb dan geen verdere ideeen meer waar het aan kan liggen qua 23:00-0:00.

Er is nu overigens een derde Docker-gebruiker die hetzelfde probleem heeft qua null-velden in #1288, dus ik ben heel benieuwd wat er in Docker of PostgreSQL gebeurd is met jullie dat dit plotseling speelt. Ik houdhet huidige issue wel voor "23:00-0:00" en zal de oplossing voor de null-velden in de andere zetten.

[8uurg]

Nog een aanvulling: bij mij loopt hij nu ~600 readings achter, wat ongeveer overeen komt met 1 uur. Dit aantal loopt ook niet meer verder terug... /admin/dsmr_datalogger/meterstatistics/ en /admin/dsmr_datalogger/dsmrreading/ geven (in tegenstelling tot de database) ook de verkeerde tijd aan.

[Tralapo]

Direct even ingelogd en verhip:

Te veel onverwerkte telegrammen: 1844 (50 minuten geleden)

Update Had hem weer even opnieuw opgestart een tijdje terug en bovenstaande teller loopt nog op nu. Waarschijnlijk inderdaad tot '1 uur geleden'

Meterstatistiek staat bij mij inderdaad ook een uur vooruit.

[dennissiemensma]

Oke helder. Alles wijst erop dat er iets niet goed gaat met de lokale tijd bij jullie, maar ik heb geen ideeen meer waar dat in kan zitten. Gezien zowel de systeemtijd als tijdzone als DB-records correct lijken.

[dennissiemensma]

Wat staat er bij jullie in het laatst ontvangen telegram qua tijd electra/gas, op /admin/dsmr_datalogger/meterstatistics/?

# Bij mij de derde regel
0-0:1.0.0(210211221910W)

# Bij mij een na laatste regel
0-1:24.2.1(210211220000W)(03826.428*m3)

[Tralapo]

0-0:1.0.0(210211222253W) Gas heb ik niet.

De onverwerkte telegrammen zijn inmiddels trouwens weer opgelopen naar Te veel onverwerkte telegrammen: 3395 (2 uur geleden). Schiet mij maar lek.

[8uurg]

Op deze regels?

# regel 3
0-0:1.0.0(210211222244W)
# een na laatste
0-1:24.2.1(210211222008W)(04009.690*m3)

[dennissiemensma]

Oke dank, dan weet ik genoeg! De tijd in de telegrammen klopt namelijk ook:

22:22:53W
22:22:44W
22:20:08W

Ik zie vast iets heel simpels over het hoofd dan.

[Tralapo]

Klopt, die tijd klopt, maar de timestamp die onder de telegram staat is dan een uur later. Heel vreemd allemaal.

[8uurg]

Het lijkt mis te gaan in Django, als ik via ./manage shell het volgende doe krijg ik dit:

>>> from dsmr_datalogger.models.reading import DsmrReading
>>> DsmrReading.objects.get(id=386226)
<DsmrReading: 386226 @ 2021-02-11 23:33:44+01:00>

Tijd is dus anders dan in de database?

[dennissiemensma]

@8uurg welke tijdzone-vars heb je ingesteld voor de docker containers?

Die van Trapalo is bijvoorbeeld:

  dsmrdb:
    environment:
      - TZ=Europe/Amsterdam
      - PG_TZ=Europe/Amsterdam

  dsmr:
    environment:
      - DJANGO_TIME_ZONE=Europe/Amsterdam

[8uurg]

Voor dsmr:

DJANGO_TIME_ZONE=Europe/Amsterdam

Voor db:

TZ=Europe/Amsterdam
PG_TZ=Europe/Amsterdam

[dennissiemensma]

En wat zie je in de DB-container als je dit doet?

grep timezone /etc/postgresql/12/main/postgresql.conf

[dennissiemensma]

En wat doet dit in de DSMR-container?

./manage.py shell

from django.utils import timezone
timezone.now()
timezone.localtime(timezone.now())

Bijvoorbeeld:

(dsmrreader) dsmr@rpi4:~/dsmr-reader $ ./manage.py shell
Python 3.7.3 (default, Dec 20 2019, 18:57:59) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)

>>> from django.utils import timezone
>>> timezone.now()
datetime.datetime(2021, 2, 11, 21, 46, 0, 968261, tzinfo=<UTC>)

>>> timezone.localtime(timezone.now())
datetime.datetime(2021, 2, 11, 22, 46, 12, 152335, tzinfo=<DstTzInfo 'Europe/Amsterdam' CET+1:00:00 STD>)

[8uurg]

Dat bestand bestaat blijkbaar niet... Maar als ik de database vraag om de huidige tijd krijg ik de juiste waarde terug:

Container:

bash-5.0# ./manage.py shell
Python 3.9.1 (default, Dec 17 2020, 06:29:58)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.utils import timezone
>>> timezone.now()
datetime.datetime(2021, 2, 11, 21, 49, 15, 896985, tzinfo=<UTC>)
>>> timezone.localtime(timezone.now())
datetime.datetime(2021, 2, 11, 22, 49, 22, 243802, tzinfo=<DstTzInfo 'Europe/Amsterdam' CET+1:00:00 STD>)

[Tralapo]

Voor mij precies hetzelfde

bash-5.0# ./manage.py shell
Python 3.9.1 (default, Dec 17 2020, 06:29:58)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.utils import timezone
>>> timezone.now()
datetime.datetime(2021, 2, 11, 21, 51, 30, 835825, tzinfo=<UTC>)
>>> timezone.localtime(timezone.now())
datetime.datetime(2021, 2, 11, 22, 51, 35, 29750, tzinfo=<DstTzInfo 'Europe/Amsterdam' CET+1:00:00 STD>)

[8uurg]

Als ik de tabel opvraag via dsmrreader krijg ik het volgende:

dsmrreader=# \d dsmr_datalogger_dsmrreading
                                                 Table "public.dsmr_datalogger_dsmrreading"
             Column              |           Type           | Collation | Nullable |                         Default

---------------------------------+--------------------------+-----------+----------+------------------------------------
---------------------
 id                              | integer                  |           | not null | nextval('dsmr_datalogger_dsmrreadin
g_id_seq'::regclass)
 timestamp                       | timestamp with time zone |           | not null |
 electricity_delivered_1         | numeric(9,3)             |           | not null |
 electricity_returned_1          | numeric(9,3)             |           | not null |
 electricity_delivered_2         | numeric(9,3)             |           | not null |
 electricity_returned_2          | numeric(9,3)             |           | not null |
 electricity_currently_delivered | numeric(9,3)             |           | not null |
 electricity_currently_returned  | numeric(9,3)             |           | not null |
 extra_device_timestamp          | timestamp with time zone |           |          |
 extra_device_delivered          | numeric(9,3)             |           |          |
 processed                       | boolean                  |           | not null |
 phase_currently_delivered_l1    | numeric(9,3)             |           |          |
 phase_currently_delivered_l2    | numeric(9,3)             |           |          |
 phase_currently_delivered_l3    | numeric(9,3)             |           |          |
 phase_currently_returned_l1     | numeric(9,3)             |           |          |
 phase_currently_returned_l2     | numeric(9,3)             |           |          |
 phase_currently_returned_l3     | numeric(9,3)             |           |          |
 phase_voltage_l1                | numeric(4,1)             |           |          |
 phase_voltage_l2                | numeric(4,1)             |           |          |
 phase_voltage_l3                | numeric(4,1)             |           |          |
 phase_power_current_l1          | integer                  |           |          |
 phase_power_current_l2          | integer                  |           |          |
 phase_power_current_l3          | integer                  |           |          |
Indexes:
    "dsmr_datalogger_dsmrreading_pkey" PRIMARY KEY, btree (id)
    "dsmr_datalogger_dsmrreading_processed_add8a852" btree (processed)
    "dsmr_datalogger_dsmrreading_timestamp_1f7020d1" btree ("timestamp")

Komt dit overeen met het schema aan jouw kant @dennissiemensma ?

[Tralapo]

Logisch gezien het brede probleem, maar zie het nu pas: op admin/dsmr_datalogger/dsmrreading/ zijn alle tijden dus ook een uur uit de pas:

En inmiddels is inderdaad ook bij mij de interface onbereikbaar geworden na 23:00, omdat hij naar 12-02 wil, maar dat is het nog niet:

[dennissiemensma]

Oke dank. Voor alle info. Die tijden op de Django shell en de DB-velden lijken goed.

@8uurg kun je deze eens proberen? Andere locatie nu:

grep timezone /var/lib/postgresql/data/postgresql.conf

[8uurg]

Niet bijzonders in ieder geval:

postgres@cda1f52c88c9:/$ grep timezone /var/lib/postgresql/data/postgresql.conf
log_timezone = 'Europe/Amsterdam'
timezone = 'Europe/Amsterdam'
#timezone_abbreviations = 'Default'     # Select the set of available time zone
                                        # share/timezonesets/.

[Tralapo]

Ik heb de DSMR container nu ingesteld op - DJANGO_TIME_ZONE=Europe/London en dan wordt 'ie weer bereikbaar en kloppen alle tijden in de interface wel.

Een timestamp op admin/dsmr_datalogger/meterstatistics/ komt dan ook weer overeen met de tijd in de telegram zelf.

[8uurg]

@Tralapo Enige probleem is dat de processing bij mij nog wel achter bleef lopen met 1h, dus er gaat nog iets niet goed... Wellicht een goede tijdelijke fix...

[dennissiemensma]

Je zou het ook nog eens andersom kunnen proberen, door de database op UTC te zetten en te kijken of dat het ook oplost. Hoe dan ook wel vreemd.

[dennissiemensma]

Want op mijn Pi staat het wel op UTC (= London) en dat is het enige verschil met jullie. Los van dat ik zelf geen Docker gebruik dan.

grep timezone /etc/postgresql/11/main/postgresql.conf 
log_timezone = 'Europe/London'
timezone = 'Europe/London'

[Tralapo]

Processing blijft bij mij telkens rond de 1200 onverwerkte telegrammen hangen. Een uurtje geleden zat hij weer op 3000+ en heb ik de SQL reeks weer toegepast en heeft hij 14 null's verwijderd.

@dennissiemensma heb nu zowel de DSMR als DSMR-database container op London gezet, maar zie geen verschil. Hij blijft rond die 1200 onverwerkte telegrammen hangen.

[dennissiemensma]

Je moet ze niet beiden op London zetten. Alleen de DB. DSMR-reader hoort in onze tijdzone te staan. Kun je dat eens proberen?

[Tralapo]

Was ik net aan het doen. Met DSMR op Amsterdam en de DB op London wordt de interface weer onbereikbaar omdat hij 12-02-2021 wil pakken.