Dsmr-reader: remote Datalogger (rpi 3) in docker loopt na random tijd vast en stuurt niks door :(

[muiterz]

Jouw omgeving

(Indien van toepassing)

• DSMR-reader versie (rechtsbovenin applicatie zichtbaar): `nieuwste
• Hardware (RaspberryPi 2, 3 of iets anders): RaspberryPi 3
• DSMR-protocol versie van slimme meter (v2, v4 of v5): v5.

raspberry pi gebruikt wifi network.

Ik heb de DSMR reader op mijn nas (synology) in een docker draaien en werkt perfect. De datalogger draait remote op mijn raspberry pi in een docker container. Deze werkt vaak goed alleen soms (bv na random 15 uur) doet hij niks.

Ik kan de pi via SSH gewoon benaderen en ik zie dat de docker container draait. Met een sudo reboot command doet hij het weer. Ik heb echt geen idee waar het aan ligt? Ik kan de pi altijd gewoon goed benaderen met SSH dus netwerk lijkt goed.

Als ik de docker container handmatig restart dan werkt het weer. Dus mss gaat er iets mis de de docker zelf? Ik heb hem automatisch laten erboot met dit run script:

sudo docker run --restart=always -d --device=/dev/ttyUSB0 -e DSMR_USB_PORT=/dev/ttyUSB0 -e DSMR_API_URL=http://192.168.1.100:7777/api/v1/datalogger/dsmrreading -e DSMR_API_KEY={key} trizz/dsmr-remote-datalogger:latest
{key}

{key} uiteraard even weggelaten

wat kan ik doen?

[dennissiemensma]

Heb je toevallig de mogelijkheid om in de logs te kijken? Wellicht staat er iets in de log van de datalogger, maar ik weet niet zo 1-2-3 hoe/waar je dat kunt vinden met Docker.

Misschien dat @trizz je hier inhoudelijk mee kan helpen. Normaal gesproken kan ik je hiermee in de goede richting sturen, maar Docker werkt net wat anders vermoed ik: https://dsmr-reader.readthedocs.io/en/latest/troubleshooting.html

[muiterz]

Heb je toevallig de mogelijkheid om in de logs te kijken? Wellicht staat er iets in de log van de datalogger, maar ik weet niet zo 1-2-3 hoe/waar je dat kunt vinden met Docker.

Misschien dat @trizz je hier inhoudelijk mee kan helpen. Normaal gesproken kan ik je hiermee in de goede richting sturen, maar Docker werkt net wat anders vermoed ik: https://dsmr-reader.readthedocs.io/en/latest/troubleshooting.html

Tnx! Net kapte hij weer toen ik internet problemen had intern. Lijkt daar iets mee te maken hebben, moet even uitzoeken hoe ik bij logs kan komen op pi/docker.

[trizz]

Ik zal er eens induiken of ik wat kan vinden in het script. Het is in feite gewoon het voorbeeld uit de docs, maar dan iets aangepast voor gebruik in een Docker container. Wellicht dat ik er iets meer failsafe dingen in kan bouwen, of tenminste iets van logging.

[muiterz]

Ik zal er eens induiken of ik wat kan vinden in het script. Het is in feite gewoon het voorbeeld uit de docs, maar dan iets aangepast voor gebruik in een Docker container. Wellicht dat ik er iets meer failsafe dingen in kan bouwen, of tenminste iets van logging.

Kan je ook de remote datalogger gewoon native op de pi runnen? Dus niet in de docker?

[helmo]

Heb je het datalogger script recent nog geupdate? Dit zou wel eens opgelost kunnen zijn door https://github.com/dennissiemensma/dsmr-reader/pull/660

[dennissiemensma]

@Muit1980 je kan het ook zonder docker draaier, maar ik denk dat @helmo wel een goed punt heeft!

@trizz je zou kunnen kijken of je je script kan bijwerken met een nieuwere versie.

• Je huidige versie: https://github.com/trizz/dsmr-remote-datalogger/blob/master/dsmr_datalogger_api_client.py#L84
• De versie met de fix waar helmo op doelt: https://github.com/dennissiemensma/dsmr-reader/blob/master/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py#L100

[dennissiemensma]

@trizz in principe hoef je dan alleen timeout=60, als extra parameter aan de requests.post() toe te voegen.

Een andere wijziging die ik recent heb gedaan, is de sleep verlagen van 1 naar 0.5, maar als niemand daar last van heeft zou ik dat lekker in je script laten voor wat het is.

[trizz]

@helmo @dennissiemensma Nee ik heb al een poos niet meer naar dat script gekeken. Ik hoop dat ik vanavond wat tijd kan vinden om het script bij te werken en een nieuwe image te bouwen, eventueel met wat extra logging mogelijkheden. Als er dan iets verkeerd gaat, is het niet zo tasten in het duister.

[muiterz]

@helmo @dennissiemensma Nee ik heb al een poos niet meer naar dat script gekeken. Ik hoop dat ik vanavond wat tijd kan vinden om het script bij te werken en een nieuwe image te bouwen, eventueel met wat extra logging mogelijkheden. Als er dan iets verkeerd gaat, is het niet zo tasten in het duister.

Ok dank! Dan wacht ik tot hij klaar is.

[trizz]

@Muit1980 Zojuist heb ik een nieuwe test-versie gepushed naar Docker, zou je eens kunnen kijken of dit je problemen oplost? Hier zit de timeout in verwerkt plus wat logging. Er worden maximaal 10 logbestanden van 1MB gemaakt, waarna de oudste weer verwijderd zal worden. Er komen alleen items in te staan in het geval van API errors of wanneer er geen data gelezen kan worden.

De tag die ik gebruikt heb is develop, dus je moet trizz/dsmr-remote-datalogger:develop gebruiken i.p.v. trizz/dsmr-remote-datalogger:latest. Om de logbestanden makkelijk in te kunnen zien, kun je het beste een mapje maken (mkdir logs) en -v $(pwd)/logs:/etc/dsmr_logs toevoegen aan je run command. Dit zou dan zoiets worden, waarbij je {key} weer even moet vervangen:

sudo docker run --restart=always -d --device=/dev/ttyUSB0 -e DSMR_USB_PORT=/dev/ttyUSB0 -e DSMR_API_URL=http://192.168.1.100:7777/api/v1/datalogger/dsmrreading -e DSMR_API_KEY={key} -v $(pwd)/logs:/etc/dsmr_logs trizz/dsmr-remote-datalogger:develop

Ik hoor graag van je of je hiermee wat verder komt. Als de nieuwe image goed werkt, zal ik deze pushen met de 'latest' tag. Zie voor de volledige lijst met dingen die ik veranderd heb de changelog.

@dennissiemensma Ik zie nu pas je comment betreffende de sleep interval. Wat is de reden voor deze verandering? Uiteraard kan ik het ook aanpassen, maar ik wil voorkomen dat de betreffende server gebombardeerd wordt met requests. Vooral ook omdat dit, in het geval van een remote datalogger, vaak een externe server is (waarbij de request langer duurt dan naar een interne host).

Wat natuurlijk ook nog een mogelijkheid is, is dat ik het ook een (optionele) environment variabele van maak, zodat de (geavanceerde) gebruiker dit zelf in kan stellen.

[muiterz]

@Muit1980 Zojuist heb ik een nieuwe test-versie gepushed naar Docker, zou je eens kunnen kijken of dit je problemen oplost? Hier zit de timeout in verwerkt plus wat logging. Er worden maximaal 10 logbestanden van 1MB gemaakt, waarna de oudste weer verwijderd zal worden. Er komen alleen items in te staan in het geval van API errors of wanneer er geen data gelezen kan worden.

De tag die ik gebruikt heb is develop, dus je moet trizz/dsmr-remote-datalogger:develop gebruiken i.p.v. trizz/dsmr-remote-datalogger:latest. Om de logbestanden makkelijk in te kunnen zien, kun je het beste een mapje maken (mkdir logs) en -v $(pwd)/logs:/etc/dsmr_logs toevoegen aan je run command. Dit zou dan zoiets worden, waarbij je {key} weer even moet vervangen:

sudo docker run --restart=always -d --device=/dev/ttyUSB0 -e DSMR_USB_PORT=/dev/ttyUSB0 -e DSMR_API_URL=http://192.168.1.100:7777/api/v1/datalogger/dsmrreading -e DSMR_API_KEY={key} -v $(pwd)/logs:/etc/dsmr_logs trizz/dsmr-remote-datalogger:develop

Ik hoor graag van je of je hiermee wat verder komt. Als de nieuwe image goed werkt, zal ik deze pushen met de 'latest' tag. Zie voor de volledige lijst met dingen die ik veranderd heb de changelog.

@dennissiemensma Ik zie nu pas je comment betreffende de sleep interval. Wat is de reden voor deze verandering? Uiteraard kan ik het ook aanpassen, maar ik wil voorkomen dat de betreffende server gebombardeerd wordt met requests. Vooral ook omdat dit, in het geval van een remote datalogger, vaak een externe server is (waarbij de request langer duurt dan naar een interne host).

Wat natuurlijk ook nog een mogelijkheid is, is dat ik het ook een (optionele) environment variabele van maak, zodat de (geavanceerde) gebruiker dit zelf in kan stellen.

Dank!!! Hij draait nu en logs folder werkt ook. Nu afwachten of hij blijft werken, kan langer dan een dag duren soms.

Ben benieuwd :) Dank ook voor je uitgebreide uitleg.

[muiterz]

@trizz Hij werkt nog steeds goed, nu dag 1.5. Alleen is er iets raar in de logs. Ik ging eens kijken wat erin stond maar ik krijg dit:

[2019-09-25 12:04:27,058 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:05:47,947 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:08:08,883 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:08:37,892 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:09:24,901 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:09:52,876 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:10:47,170 - ERROR] API error: Failed to parse telegram
[2019-09-25 12:11:37,133 - ERROR] API error: Failed to parse telegram

Kennelijk gaat er iets met parsen mis? Klopt dit? Ik krijg wel gewoon data in de site? en status ook prima.

[dennissiemensma]

Het kan zijn dat je af en toe een fout telegram doorkrijgt. De rest valideert wel goed.

Het komt doordat de data via de seriele poort onbetrouwbaar is en soms flipt er een bitje, waardoor je een ander teken of getal krijgt. Aangezien dat desastreus kan zijn voor meterstand, zit er een checksum bij het telegram. Als die niet overeenkomt, weigert DSMR-reader het telegram.

Per meter/kabel verschilt het hoeveel foute telegrammen er komen, maar ik zie wel dat je ze niet elke seconde krijgt en dat is opzich prima.

[muiterz]

Het kan zijn dat je af en toe een fout telegram doorkrijgt. De rest valideert wel goed.

Het komt doordat de data via de seriele poort onbetrouwbaar is en soms flipt er een bitje, waardoor je een ander teken of getal krijgt. Aangezien dat desastreus kan zijn voor meterstand, zit er een checksum bij het telegram. Als die niet overeenkomt, weigert DSMR-reader het telegram.

Per meter/kabel verschilt het hoeveel foute telegrammen er komen, maar ik zie wel dat je ze niet elke seconde krijgt en dat is opzich prima.

@trizz

Heren het lijkt erop dat het probleem opgelost is :D. Ik heb geen problemen met meer de beta versie, dus hij kan naar latest lijkt me?

Thanks!

[dennissiemensma]

@trizz zie bovenstaande.

Beiden bedankt voor jullie hulp

[trizz]

@Muit1980 Zojuist heb ik de 'develop' versie een release gegeven, je kunt nu ook de latest of v1 tag gebruiken. Zie de readme voor meer informatie betreffende de te gebruiken tags.

[ghost]

Top! Hij werkt nog steeds goed!! Dank!