Dsmr-reader: hulp by docker-containers

Created on 15 Dec 2019  ·  108Comments  ·  Source: dsmrreader/dsmr-reader

Hoi Dennis, ik ben > 20 uur aan het uitzoeken hie ik mijn meter uit kan lezen. Ik werk sinds 3 weken met HA en heb al veel werkend gekregen (nest thermostaat), xiaomi stozuiger, lampen camera, samsung tv ..) maar de dsmr lijkt en brug te ver.

ik heb een zotac pc, draai met docker en heb die dsmr reader en dsmr docker denk ik draaiende maar nog steeds geen waardes die ik kan lezen. bij het stoppen van het proces via ssh krij ik

Named volume "

/db:/var/lib/postgresql/data:rw" is used in service "db-dsmr" but no declaration was found in the volumes section.

ik heb in docker compose (yaml) het voorbeeld geplaatst van: ualex73/dsmr-reader-docker.
dus docker run en compose uitgevoerd.
mijn configure yaml in HA aangepast.. maar helaas..

ik begin wat radeloos te worden. Ben een newbee die heel wat leercurvers heeft doorlopen over mqtt, containers, ssh comands , portainer, ubuntu, phyton etc etc (ben geen ict-er :-) . ) maar loop nu toch echt vast. Kan je evt meekijken via teamview?

hoor graag van je.

Groet vanuit een winderig Zwolle.

Most helpful comment

@Erik050572 @dennissiemensma - De nieuwe 2.12.1 versie is geüpload naar hub.docker.com, en de volgende environment variabele zou de datalogger moeten uitschakelen (default is 'SERVER'):
DSMR_MODE=SERVER-NO-DATALOGGER

All 108 comments

Goedemorgen @ronniebee ,

Helaas heb ik hetzelfde probleem.
Ik was van plan dit probleem dan ook zelf in te schieten.

Net zoals jij ben ik een newbee op het gebied van docker, alleen mijn situatie is anders in details:
Standalone op een Raspberry Pi 3B+ lukt het het me redelijk om de DSMR reader te installeren. Maar omdat die standalone pi dan gemiddeld 1 keer per maand, bij mij, vastloopt, wil ik het gaan proberen met een cluster van 3 Pi's. Daartoe heb ik docker geinstalleerd en vervolgens portainer.

De docker compose van @ualex73 geeft mij dezelfde fout. Als ik vervolgens een nieuwe image aanmaakt met als naam ""db-dsmr" krijg ik de foutmelding niet meer. En zo probeer ik in die richting te zoeken naar een mogelijke oplossing. Maar dit heeft me nog steeds niet het gewenste resultaat opgeleverd: Een werkende webpagina op poort 8888.
En met de dockerfile van @xirixiz krijg ik ook niet het het gewenste resultaat (op poort 7777).

Daarom wil ik jouw vraag breder stellen:
Zou iemand een werkinstructie kunnen schrijven over hoe je DSMR reader op docker / portainer aan de praat kan krijgen?

Met vriendelijke groet,
Erik

@ronniebee - zou je je volledige docker file kunnen copy-pasten? En klopt het dat de directory "/db" bestaat met voldoende schrijfrechten?

@Erik050572 loopt de boel vast door/bij DSMR of zijn er andere mogelijke oorzaken?

Goedemorgen @ualex73,

Op de standalone pi draait niets anders dan alleen de DSMR-reader.
Mijn vermoeden waarom hij maandelijks vastloopt is, omdat de load en daardoor de temperaturen erg hoog zijn.
Daarom wil ik het via docker, op de cluster, gaan proberen om load te verdelen en dus de algehele temperatuur te verlagen en zo het vastlopen te vermijden.

Ik kan jullie inhoudelijk niet helpen met Docker, maar ik zie dat ualex73 er ook al is. : ]

@ronniebee - zou je je volledige docker file kunnen copy-pasten? En klopt het dat de directory "/db" bestaat met voldoende schrijfrechten?

@Erik050572 loopt de boel vast door/bij DSMR of zijn er andere mogelijke oorzaken?

Bijgaand mijn compose.yml

GNU nano 2.9.3 /home/ronniexxx/docker/docker-compose.yml
version: "3.6"
services:
db-dsmr:
image: postgres
container_name: db-dsmr
volumes:
-

/db:/var/lib/postgresql/data
restart: unless-stopped
environment:
- POSTGRES_USER=dsmrreader
- POSTGRES_PASSWORD=dsmrreader
- POSTGRES_DB=dsmrreader
networks:
- net-dsmr
dsmr:
container_name: dsmr
image: ualex73/dsmr-reader-docker
container_name: dsmr
restart: unless-stopped
- POSTGRES_PASSWORD=dsmrreader
- POSTGRES_DB=dsmrreader
networks:
- net-dsmr
dsmr:
container_name: dsmr
image: ualex73/dsmr-reader-docker
container_name: dsmr
restart: unless-stopped
volumes:
- ./dsmr/backups:/home/dsmr/app/backups
- /dev:/dev
environment:
- DB_HOST=db-dsmr
- DSMR_USER=admin
- DSMR_EMAIL=root@localhost
- DSMR_PASSWORD=admin
- VIRTUAL_HOST=localhost
ports:
- 8888:80
devices:
- /dev/ttyUSB0:/dev/ttyUSB0
networks:
- net-dsmr
networks:
net-dsmr:
driver: bridge

Je vraag mbt de dir db ... net gemaakt.

ronniexxx@ronald:~/docker:
drwxrwxr-x 2 ronniexxx ronniexxx 4,0K dec 15 11:27 db

NB voor de zekerheid gemaakt in

Ik kan service stoppen via ssh maar als ik start dan zegt systeem:

ronniexxx@ronald:~/docker$ sudo docker-compose start dsmr
Starting dsmr ... done
ERROR: No containers to start

Er gaat dan ws nog iets niet goed maar wat? kan met mijn ip
192.168.x.xxx:8888 of 80 geen pagina openen. Wat doe ik niet goed?

NB ik heb docker run gedraaid met mijn eigen ip.

docker run -d \
--name dsmr \
--restart unless-stopped \
-p 8888:80 \
*-e DB_HOST=192.168.1.XXX *
-e DSMR_USER=dsmrreader \
-e DSMR_PASSWORD=dsmrreader \
-e DSMR_EMAIL=root@localhost \
-v /dev:/dev \
--device /dev/ttyUSB0:/dev/ttyUSB0 \
ualex73/dsmr-reader-docker

en portainer:

image

Dennis, inmiddels draait de reader.. maar nog geen data. kan je mij hiermee verder helpen? Giel heeft me vandaag TOP geholpen maar ik blijf nu steken..

image

Bij mij werkt het nog niet...
Betekent het nou dat je "<"dir">" in het voorbeeld van docker-compose.yaml Example moet vervangen door de directory waarin /db staat?

@Erik050572 hieronder een voorbeeldje ... De data van je postgresql staat dan in de "/docker/db" directory op je hoofd systeem. In de docker container wordt deze data dan in de "/var/lib/postgresql/data" directory gemount.
Het is heel belangrijk dat je de spaties goed zet, want yaml vereist dit. Als je je configuratie post, moet je 3x een "`" gebruiken om te starten en 3x om af te sluiten.

version: '3'
services:
  db-dsmr:
    image: postgres
    container_name: db-dsmr
    volumes:
      - /docker/db:/var/lib/postgresql/data
    restart: unless-stopped
    environment:
      - POSTGRES_USER=dsmrreader
      - POSTGRES_PASSWORD=dsmrreader
      - POSTGRES_DB=dsmrreader
    networks:
      - net-dsmr

Bedankt @ualex73 ,
Ik zag trouwens ook dat er andere versie op Github staat.
Ik ga deze vanavond even proberen, nu weet ik in ieder geval waar ik op moet letten. :)

Ok, die is iets anders dan de github (vs de hub.docker.com). Enige
belangrijke verschil is dat er 2 volumes zijn ipv 1 ... Maar dat maakt niet
uit.

Op ma 16 dec. 2019 om 15:10 schreef Erik050572 notifications@github.com:

Bedankt @ualex73 https://github.com/ualex73 ,
Ik zag trouwens ook dat er andere versie op Github
https://github.com/ualex73/dsmr-reader-docker/blob/master/docker-compose.yaml
staat.
Ik ga deze vanavond even proberen, nu weet ik in ieder geval waar ik op
moet letten. :)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dennissiemensma/dsmr-reader/issues/797?email_source=notifications&email_token=ABQASXGWQTCECJNV6AWOKLDQY6D4RA5CNFSM4J2642UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG62L6A#issuecomment-566076920,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQASXEIW2MKIYIEQKPFHEDQY6D4RANCNFSM4J2642UA
.

Als ik in mijn docker kijk heb een db map en compose yml ( de db map zie ik in het paars staan en de compose,yml in wit.. reden??) , dien ik met mkdir de var, lib, postgresqlr en data aan te maken vanuit de db map?

Ik zie naast db een " : " staan. wat impliceert dit

( ja ben echt een newbee :-))

Hoor graag.

@ronniebee ik wil je graag helpen, nav je reactie op het HA-topic, maar ik heb helaas niet de nodige ervaring met Docker daarvoor. Mijn kennis is puur gebaseerd op een simpele installatie op een enkel systeem, zonder containers.

Dit lijkt op dat de database zomaar een poweroff heeft gehad, maar lijkt verder geen issue te hebben.

2019-12-15 21:05:06.410 CET [20] LOG: database system was not properly shut down; automatic recovery in progress

2019-12-15 21:05:06.434 CET [20] LOG: redo starts at 0/17FF808
2019-12-15 21:05:06.435 CET [20] LOG: invalid record length at 0/17FF8F0: wanted 24, got 0
2019-12-15 21:05:06.435 CET [20] LOG: redo done at 0/17FF8B8
2019-12-15 21:05:06.524 CET [1] LOG: database system is ready to accept connections

Dit is prima en kun je negeren:

2019-12-15 21:05:06,347 INFO spawned: 'dsmr_mqtt' with pid 457
2019-12-15 21:05:07,352 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

Wat je nog kunt doet is kijken of je op je host met cu handmatig de slimme meter kan uitlezen: https://dsmr-reader.readthedocs.io/en/latest/installation/explained.html#your-first-reading-optional

Alleen zul je daarvoor deels de normale installatiestappen moeten volgen en dat is denk ik minder handig in combinatie met Docker.

Als alternatief zou je ook nog je vraagstuk op het forum van Tweakers kunnen zetten, om niet te veel afhankelijk te zijn van mij en/of ualex.

Deze newbee is nu echt de wanhoop nabij:
Ik heb een docker directory aangemaakt, met daarin een weer een db directory

Als ik dan vanuit de docker directory een "docker stack up --compose-file docker-compose.yaml dsmr' opdracht geef, krijg ik de volgende uitkomst.

Aantekening 2019-12-16 211632

Mijn docker-compose bestand ziet er zo uit:

version: '3'
services:
db-dsmr:
image: postgres
container_name: db-dsmr
volumes:
- /docker/db:/var/lib/postgresql/data
restart: unless-stopped
environment:
- POSTGRES_USER=dsmrreader
- POSTGRES_PASSWORD=dsmrreader
- POSTGRES_DB=dsmrreader
networks:
- net-dsmr
dsmr:
container_name: dsmr
image: ualex73/dsmr-reader-docker
restart: unless-stopped
volumes:
- ./dsmr/backups:/home/dsmr/app/backups
- /dev:/dev
environment:
- DB_HOST=db-dsmr
- DSMR_USER=admin
- DSMR_EMAIL=root@localhost
- DSMR_PASSWORD=admin
- VIRTUAL_HOST=localhost
ports:
- 8888:80
devices:
- /dev/ttyUSB0:/dev/ttyUSB0
networks:
- net-dsmr
networks:
net-dsmr:
driver: bridge

Je moet geen swarm gebruiken, ik zal morgen de docker compose commando
doorgeven

Op ma 16 dec. 2019 om 21:23 schreef Erik050572 notifications@github.com

Deze newbee is nu echt de wanhoop nabij:
Ik heb een docker directory aangemaakt, met daarin een weer een db
directory

Als ik dan vanuit de docker directory een "docker stack up --compose-file
docker-compose.yaml dsmr' opdracht geef, krijg ik de volgende uitkomst.

[image: Aantekening 2019-12-16 211632]
https://user-images.githubusercontent.com/53637915/70939842-63f62a80-2049-11ea-898d-d70666bac66a.png

Mijn docker-compose bestand ziet er zo uit:

version: '3'
services:
db-dsmr:
image: postgres
container_name: db-dsmr
volumes:

  • /docker/db:/var/lib/postgresql/data
    restart: unless-stopped
    environment:
  • POSTGRES_USER=dsmrreader
  • POSTGRES_PASSWORD=dsmrreader
  • POSTGRES_DB=dsmrreader
    networks:
  • net-dsmr
    dsmr:
    container_name: dsmr
    image: ualex73/dsmr-reader-docker
    restart: unless-stopped
    volumes:
  • ./dsmr/backups:/home/dsmr/app/backups
  • /dev:/dev
    environment:
  • DB_HOST=db-dsmr
  • DSMR_USER=admin
  • DSMR_EMAIL=root@localhost
  • DSMR_PASSWORD=admin
  • VIRTUAL_HOST=localhost
    ports:
  • 8888:80
    devices:
  • /dev/ttyUSB0:/dev/ttyUSB0
    networks:
  • net-dsmr
    networks:
    net-dsmr:
    driver: bridge


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dennissiemensma/dsmr-reader/issues/797?email_source=notifications&email_token=ABQASXEIONWGYEL4YHQ2MT3QY7PUTA5CNFSM4J2642UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG77FPY#issuecomment-566227647,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQASXASUNBMLVXLRHWC6D3QY7PUTANCNFSM4J2642UA
.

Als je je je docker-compose.yaml heb aangepast, dan kan je via de volgende commando's de boel online brengen:

docker-compose -f docker-compose.yaml up -d db-dsmr
docker-compose -f docker-compose.yaml up -d dsmr

De "-d" betekent dat het daemonized gaat, dus in de achtergrond. De "up" start een nieuwe container of als de docker-compose is gewijzigd, de oude weggooien en de nieuwe opstarten. De swarm optie is alleen interessant als je in een cluster gaat draaien.

Goedemiddag Alexander,

Bedankt voor deze oplossing, maar ik ben bang dat deze niet gaat werken.
Zoals je hierboven kan lezen, wil ik het _juist_ in een cluster gebruiken om de "load te balancen"

Net zoals jij ben ik een newbee op het gebied van docker, alleen mijn situatie is anders in details:
Standalone op een Raspberry Pi 3B+ lukt het het me redelijk om de DSMR reader te installeren. Maar omdat die standalone pi dan gemiddeld 1 keer per maand, bij mij, vastloopt, wil ik het gaan proberen met een cluster van 3 Pi's. Daartoe heb ik docker geinstalleerd en vervolgens portainer.

Op de standalone pi draait niets anders dan alleen de DSMR-reader.
Mijn vermoeden waarom hij maandelijks vastloopt is, omdat de load en daardoor de temperaturen erg hoog zijn.
Daarom wil ik het via docker, op de cluster, gaan proberen om load te verdelen en dus de algehele temperatuur te verlagen en zo het vastlopen te vermijden.

Docker-compose komt dan ook terug met de mededeling dat ik swarm moet gebruiken.
Heb je daar misschien een oplossing voor?

Alvast bedankt
Greetz,
Erik

Ik heb eigenlijk geen ervaring met de Swarm mogelijkheid.

Ik kan alleen adviseren om de DSMR en de DB-DSMR te verdelen over de 2 Pi 3B+'s, dat zou dan de load moeten verdelen.

Voor mijn gevoel is een "echt" cluster niet geschikt (of lastig) voor DSMR, want je moet de P1 kabel omprikken en je moet de database ook synchronizeren? Als het echt de Pi is, dan zou ik een Intel NUC (celeron) adviseren, die is vele krachtiger en heeft bij mij bijna een jaar gedraaid zonder problemen (draai nu op een NUC i5 - omdat het 'kan' ;-)).

Dat is nou jammer. :(

Het verdelen van de DSMR, DB-DSMR processen (en eigenlijk ook het python process) is eigenlijk waar ik op gehoopt had:
Want dan heb je 1 pi die belast is met de verwerking van de telegrammen, 1 pi die belast is met de opslag van de gegevens & 1 pi die als webserver dient.
Als er dan eentje omklapt, start die container weer opnieuw op en is het verlies van data geminimaliseerd......

@Erik050572 heb je ook al een ander SD-kaartje geprobeerd?

Een rPi3 moet meer dan snel genoeg zijn om DSMR-reader te draaien, zonder problemen. Slechte performance komt vaak door slechte I/O met een bepaald of oud SD-kaartje.

Een andere mogelijke oorzaak kan missende indexes in de database zijn. In theorie is het onmogelijk dat die indexes missen, want er zijn migraties voor. Echter heb ik dit jaar al bij twee mensen gezien dat ze toch misten en daardoor slechte performance hebben. Als de database te traag is, gaat de load wellicht ook omhoog.


Wat betreft het loadbalancen. De applicatie is er niet perse voor gemaakt en het kan je setup wat complexer maken. Ook bij updates en debugging.
Ik sluit me wat dat betreft aan bij ualex dat je evt wel je database in een losse container op een aparte Pi kan zetten.

Het dataverlies bij het crashen van processen (behalve de DB) is minimaal. Voor de datalogger gaat een telegram of goed of niet. De webinterface doet amper wat met data schrijven. Het backend proces zou misschien nog wat meer met DB-transacties kunnen doen, maar tot zover heb ik eigenlijk nog nooit meegemaakt of gehoord dat een crasht het systeem in een staat brengt waardoor het niet verder kan.

Het belangrijkste is je database. Als je die op een Pi met SD-kaart draait, is het zaak om er vooral voor te zorgen dat daar goede backups van zijn dagelijks.

Goedenavond Dennis,
Ik heb al meerder SD-kaarten gebruikt, met telkens hetzelfde resultaat.

Wat betreft de load:
Het lijkt er op dat die, bij de laatste paar updates, drastisch omlaag is gegaan.
Van bijna 100% naar nu zo'n 57%. Ook valt het me op dat de webpagina sneller laadt.
De temperatuur is daardoor ook gedaald van ruim 80 (tot zelfs 90) graden naar nu 56 graden. Hierdoor is de kans dat de data, op de SD-kaart, minder snel corrupt raakt, aanzienliijk gestegen.

Maar ik blijf nog wel wat sceptisch en wil me wel blijven beschermen tegen ongewilde vastlopers.
Want als ik elke maand een vastloper heb, is het niet de moeite om een backup terug te zetten.
En ik wil nu wel iets van een archief opbouwen. Dus het principe om docker te gebruiken, staat me wel aan.

Dus ik zou jullie hulp heel erg waarderen om dit voor mekaar te krijgen.

Goedenavond Alexander,
Als ik jouw commando's gebruik, krijg ik helaas nog niet het gewenste resultaat:
ik krijg de volgende foutmelding:
\
Aantekening 2019-12-16 211632

Volgens mij ontbreekt er nog wat in de commando's.
Heb je misschien nog een voorstel?

Alvast bedankt
Erik

@Erik050572 ik denk dat er iets anders aan de hand is, want DSMR-reader zou niet zoveel load moeten trekken. Hier pakt die ongeveer een tot een halve CPU core, want voor een Pi3+ geen probleem zou moeten zijn met multicores.
Mocht je een keer in de gelegenheid zijn, dan ben ik erg benieuwd welk proces de hoge load veroorzaakt.

Ik vermoed dat ik weet waaraan het ligt...

(NB: De update van gisteren heeft er voor gezorgd dat de load daalde naar 18%)

De enige wijziging die ik vandaag heb gedaan, is de gebruikersconfiguratie aangepast...

Dit is per minuut:
Screenshot_20191218-083305__01__01

Dit is per meting:
Screenshot_20191218-210718__01__01

Bedankt voor het delen. De update van gisteren was vrij insignificant op gebied van performance eerlijk gezegd, in tegenstelling tot de voorgaande updates. Dus ik denk nog steeds dat er iets anders speelt/speelde.

De load komt nu overeen met wat ik zelf ook ervaar, al is die doorgaans rustiger. Ik vind het RAM-gebruik nog wel aan de hoge kant, al zegt het mij percentueel niet zoveel zonder harde getallen.

Ter vergelijking, ik draai hier Raspbian 10 op een Pi 4. Na 90 dagen uptime gebruikt het hele systeem zo'n 500 MB aan geheugen. CPU load is naar schatting zo'n 12,5% gemiddeld. Screenshot:
Selection_005

Dat komt redelijk overeen....

Screenshot_20191218-213638__01

Ik zie dat je SWAP memory op 100% (usage?) zit. Dat is geen goed teken en kan vaak ook een oorzaak zijn van slechte performance.
Het vreemde is wel dat je uptime nog geen 2 uur is, dus in die tijd heeft je RAM al een keertje volgezeten. Enig idee hoe dat komt?

ik heb net een apt-get update & upgrade gedaan
daarna doe ik altijd een reboot

Maar waarom het SWAP geheugen zo hoog staat weet ik niet.

Mocht je straks nog steeds performance issues hebben: Je kunt eventueel nog kijken naar atop om die je systeem te laten loggen (soort van htop, met logging): https://haydenjames.io/use-atop-linux-server-performance-analysis/

Dan kun je wellicht na een volgende restart zien welke processen het meeste geheugen vreten en zorgen dat die (tijdelijk) op de swap over gaat.

Ik zal het in de gaten houden
Op dit moment ziet, het er zo uit:
Aantekening 2019-12-18 220455

@ronniebee ik wil je graag helpen, nav je reactie op het HA-topic, maar ik heb helaas niet de nodige ervaring met Docker daarvoor. Mijn kennis is puur gebaseerd op een simpele installatie op een enkel systeem, zonder containers.

Dit lijkt op dat de database zomaar een poweroff heeft gehad, maar lijkt verder geen issue te hebben.

2019-12-15 21:05:06.410 CET [20] LOG: database system was not properly shut down; automatic recovery in progress

2019-12-15 21:05:06.434 CET [20] LOG: redo starts at 0/17FF808
2019-12-15 21:05:06.435 CET [20] LOG: invalid record length at 0/17FF8F0: wanted 24, got 0
2019-12-15 21:05:06.435 CET [20] LOG: redo done at 0/17FF8B8
2019-12-15 21:05:06.524 CET [1] LOG: database system is ready to accept connections

Dit is prima en kun je negeren:

2019-12-15 21:05:06,347 INFO spawned: 'dsmr_mqtt' with pid 457
2019-12-15 21:05:07,352 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

Wat je nog kunt doet is kijken of je op je host met cu handmatig de slimme meter kan uitlezen: https://dsmr-reader.readthedocs.io/en/latest/installation/explained.html#your-first-reading-optional

Alleen zul je daarvoor deels de normale installatiestappen moeten volgen en dat is denk ik minder handig in combinatie met Docker.

Als alternatief zou je ook nog je vraagstuk op het forum van Tweakers kunnen zetten, om niet te veel afhankelijk te zijn van mij en/of ualex.

Hoi Dennis, vandaag weer een paar uur aan het stoeien geweest, CU gedraaid en ik kan aan en uit loggen (connected / disconnected bij dsmr). Dus de verbinding wordt gevonden. Alleen helaas nog geen data. Ook de baudrate aangepast (9600) maar ik heb een esmr 5.0 meter in huis dus alleen de hogere rate werkt. als ik met de lagere rate draai loopt mijn ssh vast ..

wie kan mij verder helpen?

Goedenavond Dennis,
Ik heb al meerder SD-kaarten gebruikt, met telkens hetzelfde resultaat.

Wat betreft de load:
Het lijkt er op dat die, bij de laatste paar updates, drastisch omlaag is gegaan.
Van bijna 100% naar nu zo'n 57%. Ook valt het me op dat de webpagina sneller laadt.
De temperatuur is daardoor ook gedaald van ruim 80 (tot zelfs 90) graden naar nu 56 graden. Hierdoor is de kans dat de data, op de SD-kaart, minder snel corrupt raakt, aanzienliijk gestegen.

Maar ik blijf nog wel wat sceptisch en wil me wel blijven beschermen tegen ongewilde vastlopers.
Want als ik elke maand een vastloper heb, is het niet de moeite om een backup terug te zetten.
En ik wil nu wel iets van een archief opbouwen. Dus het principe om docker te gebruiken, staat me wel aan.

Dus ik zou jullie hulp heel erg waarderen om dit voor mekaar te krijgen.

Goedenavond Alexander,
Als ik jouw commando's gebruik, krijg ik helaas nog niet het gewenste resultaat:
ik krijg de volgende foutmelding:

Aantekening 2019-12-16 211632

Volgens mij ontbreekt er nog wat in de commando's.
Heb je misschien nog een voorstel?

Alvast bedankt
Erik

Sorry, ik draaide een parameter om, de "up" moet als eerste. Dus het is echt als volgt:

docker-compose -f docker-compose.yaml up -d db-dsmr
docker-compose -f docker-compose.yaml up -d dsmr

@ronniebee als je het handmatig met cu werkend hebt, kom je al een heel eind. Zie je ook telegrammen of kun je alleen de verbinding openen en meer niet?

Hoi Dennis, ik kan alleen de verbinding openen ( en sluiten). De telegrammen blijven uit.

Ik vermoed dat je sowieso de hogere baud rate nodig hebt. Zie http://domoticx.com/p1-poort-slimme-meter-hardware/

ESMR 5.0 | 115200 | 8N1 | Geinverteerd

Ik zou verwachten dat deze dan werkt:

cu -l /dev/ttyUSB0 -s 115200 --parity=none -E q

Hoi Dennis,

als ik ssh:

dsmr@ronald:~$ cu -l /dev/ttyUSB0 -s 115200 --parity=none -E q
Connected.

vervolgens blijft het leeg...
en met q.

Disconnected.
dsmr@ronald:~$

had al een nieuwe kabel gekocht maar helaas..

Wellicht kun je dan op Tweakers om hints vragen. Ik heb zelf alleen DSMR v4 om te testen en geen ervaring met ESMR v5.

Hier is wellicht een topic waar je terecht kunt: https://gathering.tweakers.net/forum/list_messages/1578510

Dank je Dennis. Zeer gewaardeerd.

Ik draai met DSMR v5 en dit werkt out-of-the-box.

Ik draai met DSMR v5 en dit werkt out-of-the-box.

Hoi alexander, ik heb met docker eea erop gezet. De compose van xirirz gebruikt. Hoe ziet jouw compose eruit? Wil je die posten?

Ik gebruik mijn eigen image/docker: https://hub.docker.com/r/ualex73/dsmr-reader-docker (welke in principe identiek is aan die van xirirz)

Enige wat ik kan bedenken dat je "devices", dus de "/dev/ttyUSB0" niet goed staat.

Devices staan goed, net nog gecheckt. USB0

opnieuw begonnen.

ik krijg nu:
ronniebee@ronald:~/docker$ docker-compose -f docker-compose.yaml up -d db-dsmr
ERROR: Named volume "

/db:/var/lib/postgresql/data:rw" is used in service "db-dsmr" but no declaration was found in the volumes section.
ronniebee@ronald:~/docker$ docker-compose -f docker-compose.yaml up -d dsmr
ERROR: Named volume "/db:/var/lib/postgresql/data:rw" is used in service "db-dsmr" but no declaration was found in the volumes section.
ronniebee@ronald:~/docker$

ik denk dat ik er bijna ben maar dat laatste stapje.. Wil je me verder helpen?

net een container aangemaakt maar dsmr-db is weer gestopt. dit zegt de log:

2019-12-19 20:42:31
Start DSMR Reader - Mode=SERVER

...........................................................

image

en zo ziet mijn docker dir eruit.

image

docker-compose -f docker-compose.yaml up -d db-dsmr
docker-compose -f docker-compose.yaml up -d dsmr

Hoi Alexander,

Dat commando werkte, maar nu heb ik nog geen poort om te benaderen
Aantekening 2019-12-22 110701
Als ik ook de dsmr container wil bekijken, krijg ik de mededeling dat hij continue aan het herstarten is.
In het log staat deze mededeling:
standard_init_linux.go:211: exec user process caused "exec format error"

Enige ideeën?

@Erik050572 heb je je vraagstuk ook al op het Tweakers forum gelegd? Dan ben je niet afhankelijk van 1 persoon.

@Erik050572 zo te zien heb je geen port mapping aanstaan voor de container. In je docker-compose.yaml mist mogelijk:

    ports:
      - 8888:80

Dat herstarten komt denk ik doordat je de verkeerde image hebt gedownload. Er bestaan:

amd64 - x86_64/intel based
arm32v6 - Pi1
arm64v8 - Pi2 of hoger

Als je de "latest" pakt, dan is het de "amd64" ... die draait dus niet op een Pi.

SUCCES!!!!!

Begrijpen doe ik het nog niet:
ik moet ondanks dat het een rPi 3 is, de versie 32 bits versie installeren.
(Voor de veiligheid heb ik het nog even gecontroleerd :) )

Ik krijg nu dezelfde foutmelding als @ronniebee dat er geen data binnenkomt.
Daarom zit ik nu aan de volgende workaround te denken om de API te gebruiken, want de standalone (de niet docker versie) werkt ook nog.
(maar daarmee kan ik wel mijn doel (data veiligstellen) bereiken.)

Kan het zijn dat de stand alone versie en de docker versie een conflict geven en dat daarom geen data naar de docker versie gaat?

Update:
Ik ben er inmiddels ook al achter dat ze beide een conflict hebben op poort 80
Dus ik moet sowieso vaarwel zeggen tegen de standalone versie
Toen deze laatste namelijk in error schoot, kwam de docker versie online
Is er eenvoudige manier om de data van de een naar de ander te krijgen?

Je kunt er altijd nog voor kiezen om verschillende poortnummers te gebruiken. Poort 80 is aan te passen in de Nginx config. Zie #169 voor een howto.

Handig!
Maar.... Dat heeft, voor mij, niet het gewenste resultaat:
De standalone versie gaat dan naar bijvoorbeeld poort 8080
En in de docker versie blijft hij actief op poort 8888

Bijkomend nadeel: ze bijten mekaar nog steeds:
Ik ga nu gokken en dat is nooit verstandig: Luisteren beide versies misschien alletwee naar de USB-poort? Zolang de stand alone versie niet in error schiet, komt de docker versie niet online.
Dus zou ik de standalone versie evengoed moeten deinstalleren

Er zijn wel mogelijkheden om meerdere applicaties te laten luisteren naar die poort, maar daarvoor moet je wel eea instellen. Zie #741.

Dat is, denk ik, precies wat ik zoek:
Als ik de uitleg van de derde optie goed interpreteer, zou de standalone in mijn meterkast kunnen draaien en de docker versie ergens anders in mijn netwerk als backup kunnen fungeren. En stel dat de pi in de meterkast vastloopt, dan installeer je die opnieuw en de data op de dockerversie blijft dan in takt en wordt daarna gewoon weer aangevuld?

Je kunt ook alleen de datalogger in je meterkast doen. Die is dan ook makkelijk te herinstalleren. Het belangrijkste is dat, waar je de database ook draait, dat het betrouwbare storage is, zoals een HDD of SSD of vergelijkbaars.

@Erik050572 Je kan maar 1 versie actief hebben om de USB poort uit te lezen, dus als beide actief zijn - gaat het niet werken. Ook voor de docker versie moet je het USB device goed doorgeven, anders werkt het ook niet (dus als je bv /dev/ttyUSB0 gebruikt, zou dit na een reboot kunnen veranderen). Als eerste zou ik voor standalone OF docker gaan en vanaf daar verder gaan.

Heren,
Ik begin jullie geduld toch echt te waarderen.
Dit begint echt een dummies guide to docker installatie te worden :)

Ik heb de docker-versie van de de "meterkast-pi" verwijderd en dus die draait weer in de uitgangssituatie met alleen de standalone versie.

Op een andere pi heb ik, een docker, db-dsmr & dsmr geinstalleerd.

  • db-dsmr draait zonder problemen.
  • dsmr wil niet op start want die geeft een mededeling dat de USB-poort niet aangesloten is.
    Deze melding zou toch niet moeten komen? Want ik heb de plug-in toegevoegd in de "/home/dsmr/dsmr-reader/dsmr_plugins/modules" directory , en in "/home/dsmr/dsmr-reader/dsmrreadersetting.py" heb ik de verwijzing naar de plug-in toegevoegd.

@Erik050572 Je zou geen code hoeven te wijzigen (in de reguliere DSMR). Gewoon de seriële poort doorgeven in docker en in de GUI de poort configureren en dan werkt het.

@Erik050572 ik denk dat je helder moet specificeren over welk systeem het gaat. Welke dsmr wil niet opstarten? En waar heb je de plugin ingesteld?

Er is alleen een datalogger nodig in de DSMR die direct aan de meter hangt. En daar moet ook de plugin geinstalleerd worden.
Op de DSMR die niet aan de meter hangt, kun je de datalogger negeren of uitschakelen.

De standalone (meterkast) werkt zoals het altijd doet

De dockerversie is op een ander pi, elders in het netwerk, geïnstalleerd. Hier heb ik ook de plug-in op ingesteld. En hierop krijg ik dus de foutmelding.

Exact, dus daar kun je de datalogger uitschakelen of negeren. En die heeft geen plugin nodig. Zie hierboven.

Hoi Dennis, hij doet het!!!! na 40 uur proberen, opnieuw beginnen, uithuilen en nog een keer alles doorlopen..

HA draait ook, alleen is de uitlees frequentie erg vreemd. Als ik de site bekijk zie ik:

image

de ene keer is het en paar minuten en de andere keer een half uur en dan draait hij weer. Wat kan ik hieraan doen?

en ik maak back ups via dropbox maar krijg:

image

kan je me hierbij ook nog adviseren?

Je zult moeten specificeren over welke installatie het gaat. Ik kan je alleen helpen bij de stand-alone versie, want ik weet niet waar Docker de logfiles heen schrijft.

Hoi Dennis, ik draai iid onder docker. Weet jij wie me hier mee verder kan helpen? Ik heb al contact met xirixz (bram).

nb ik gebruik portainer en kan de log files inzien.

dsmr-db:

image

dsmr:

image

Wat zegt docker log ?

Op za 28 dec. 2019 om 10:59 schreef ronniebee notifications@github.com

Hoi Dennis, ik draai iid onder docker. Weet jij wie me hier mee verder kan
helpen? Ik heb al contact met xirixz (bram).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dennissiemensma/dsmr-reader/issues/797?email_source=notifications&email_token=ABQASXADIHYIKA2G3KPOEQTQ24POXA5CNFSM4J2642UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHYGPSQ#issuecomment-569403338,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQASXHWIRPSCI64LDBUDX3Q24POXANCNFSM4J2642UA
.

Hoi Dennis, ik heb het opgelost. Ik haalde 2 zaken door elkaar... jouw reader en de parser voor HA. ik snap nu pas hoe het werkt... dank voor je snelle reacties!

Er is alleen een datalogger nodig in de DSMR die direct aan de meter hangt. En daar moet ook de plugin geinstalleerd worden.
Op de DSMR die niet aan de meter hangt, kun je de datalogger negeren of uitschakelen.

Goedenavond Dennis & Alexander,
Hoe schakel ik de datalogger dan uit pre-install?
Ik kan dat niet terugvinden en als ik de foutmelding goed begrijp start die container niet op als de datalogger nog steeds op de USB-poort staat

Is het genoeg om het onderstaande weg te laten uit de docker-compose.yaml?
devices: - /dev/ttyUSB0:/dev/ttyUSB0

@Erik050572 normaal zou je daar de Supervisor config voor aanpassen en de datalogger uitcommenten. Waar je dat exact kunt vinden in de Docker install weet ualex het beste.

@Erik050572 @dennissiemensma in de docker container staat de supervisor configuratie in "/etc/supervisor.d/supervisord.ini", alleen die is niet makkelijk aan te passen in een container. Ik ga een nieuwe image aanmaken met een environment optie om de juiste versie te kiezen (eentje met logger en eentje zonder).

@Erik050572 @dennissiemensma - De nieuwe 2.12.1 versie is geüpload naar hub.docker.com, en de volgende environment variabele zou de datalogger moeten uitschakelen (default is 'SERVER'):
DSMR_MODE=SERVER-NO-DATALOGGER

Goedenavond Alexander,
Ik nam aan dat dat in de docker-compose file moet worden toegevoegd.
Die ziet er nu ongeveer zo uit (voor wat betreft DSMR):

dsmr:
container_name: dsmr
image: ualex73/dsmr-reader-docker:arm32v6
restart: unless-stopped
volumes:
- ./dsmr/backups:/home/dsmr/app/backups
- /dev:/dev
environment:
- DB_HOST=db-dsmr
- DSMR_USER=admin
- DSMR_EMAIL=root@localhost
- DSMR_PASSWORD=admin
- VIRTUAL_HOST=localhost
- DSMR_MODE=SERVER-NO-DATALOGGER
ports:
- 8888:80
networks:
- net-dsmr

Ik ben dan ook een stap verder gekomen en krijg hetzelfde scherm zoals @ronniebee die al eerder had.
https://github.com/dennissiemensma/dsmr-reader/issues/797#issuecomment-565846573

Dennis, inmiddels draait de reader.. maar nog geen data. kan je mij hiermee verder helpen? Giel heeft me vandaag TOP geholpen maar ik blijf nu steken..

image

Misschien lees ik er overheen, maar wat is nu hiervoor de oplossing?

N.B.: Ik heb deze stappen al gevolgd:
Voorbeeld #3: Doorsturen van ruwe telegram-gegevens naar een andere instantie van DSMR-reader, via de API

@Erik050572 je kunt het beste eerst zoeken in de logs van de DSMR-reader die aan de meter hangt: https://dsmr-reader.readthedocs.io/nl/latest/troubleshooting.html#supervisor
Ik vermoed dat je de log van de datalogger moet hebben, gezien die de plugin triggert.

Ik ga er vanuit dat je in diezelfde installatie (DSMR-reader aan de meter) die plugin hebt geinstalleerd. Als er foutmeldingen zijn, zouden die o.a. moeten beginnen met Server Error forwarding telegram ..., zoals in de plugin zelf af te leiden is. Maar het kan ook een verbindingsfout zijn, zonder die exacte tekst.

@Erik050572 wat je ook nog kunt doen is kijken of deze voorbeelden werken: https://dsmr-reader.readthedocs.io/nl/latest/api.html#examples

Doe dit vanuit de Pi die aan je meter hangt. Vul daar nog wel de juiste URL en API-token in. Het telegram mag op xxx blijven staan, want je wil alleen testen of de verbinding en het token werkt.

Vermoedelijke foutmeldingen:

  • curl: (6) Could not resolve host: YOUR-DSMR-URL
  • Invalid auth key
  • Failed to parse telegram (<-- die wil je zien)

@Erik050572 Je DSMR Reader draait nu zonder de datalogger. Je kan ook dezelfde image gebruiken met de volgende environment variabelen om alleen de datalogger aan te zetten:

MODE=CLIENT
DSMR_SERIALPORT - The serialport, default is '/dev/ttyUSB0'
DSMR_HOST - The DSMR server host, default is '127.0.0.1'
DSMR_APIKEY - The API key to connect to the DSMR server, no default
DSMR_DSMVER - The DSMR Version used, default is '4'

Ikzelf draai gewoon in server mode, want mijn Intel NUC staat naast mijn P1 meter.

Ik ga daar na Nieuwjaar even rustig naar kijken.
Voor nu wens ik jullie een fijne jaarwisseling!

Heren,

Alle beste wensen voor 2020.

Even zodat ik de de theorie snap:
De standalone versie, in mijn meterkast, is de SERVER, die het API-signaal verstuurd.
In de configuratie, onder het kopje API-configuratie, zet je deze server aan en uit door middel van het vinkje en de autorisatiesleutel.

De docker versie elders in mijn netwerk is de CLIENT.
Deze ontvangt geen gegevens als ik de plug-in niet juist heb ingesteld.
Omdat in de instructie gesuggereerd wordt dat alleen de client ingesteld dient te worden, met de juiste parameters, heb ik hier de plug-in ingesteld.

Klopt het nu dat jullie impliceren dat de server nog op een andere manier ingesteld dient te worden?
(Die is toch al actief?)

Ook de beste wensen voor 2020!

De "SERVER" is waar de DSMR backend, data-logger, MQTT, etc draait. De backend connect naar de PostgreSQL database om de data te bewaren.
De data-logger is het element welke de P1 telegrammen leest en doorstuurt naar de backend. In mijn docker noem ik de data-logger only de "CLIENT".

Dus als je de dingen splitst (bv. je P1 meter is te ver van je server vandaan), moet je beide hebben. De data-logger om de P1 telegrammen te lezen en de backend om het te verwerken.

Dan neem ik aan dat ik nog instellingen dien te wijzigen als ik wil 'schaduwdraaien"?
(Dus zowel de CLIENT als de SERVER verwerken de P1 telegrammen van de de frontend)

@Erik050572 heb je dit nog geprobeerd? https://github.com/dennissiemensma/dsmr-reader/issues/797#issuecomment-569897253

Failed to parse telegram

Oke dus dan is de verbinding tussen die twee verder wel goed. Er vanuitgaande dat je dezelfde URL en API key in de plugin hebt gezet.

ik heb het net aan gepast
de plug in ziet er nu zo uit

Aantekening 2020-01-06 201640

Maar er komt nog steeds geen data binnen.

Heb je de applicatie helemaal herstart na aanpassingen in de plugin? Zo nee, dan kan dat een reden zijn.

sudo supervisorctl restart all

Het resultaat is hetzelfde.
(Het is toch de bedoeling dat de plug-in geïnstalleerd wordt op de CLIENT?)

Kun je op regel 25 eens deze toevoegen:

    print(response.status_code)

Let op dat de vier spaties vooraan de regel ook nodig zijn.

Daarna weer: sudo supervisorctl restart all

En dan kijken in de log of je iets ziet verschijnen: tail -f /var/log/supervisor/dsmr_datalogger.log

The current logging level only logs warnings and errors, to reduce I/O. More information can be found here: https://dsmr-reader.readthedocs.io/en/v2/troubleshooting.html#logging

Op regel 14 kun je dan hetzelfde doen:

    print('plugin test')

Let op dat de vier spaties vooraan de regel ook nodig zijn.

Daarna weer: sudo supervisorctl restart all

En dan kijken in de log of je iets ziet verschijnen: tail -f /var/log/supervisor/dsmr_datalogger.log

same output

  • Ik neem aan dat je gewoon de ingebouwde datalogger gebruikt om je meter uit te lezen he?

  • En je hebt de plugin ook ingeschakeld op hetzelfde systeem in de settings.py?

DSMRREADER_PLUGINS = [
    'dsmr_plugins.modules.forward_raw_telegram_to_api',
]
  • Krijg je op die installatie die aan de kabel hangt, wel informatie te zien in het Dashboard. Of in geen van beide DSMR-reader installaties?

ik heb de plug-in inmiddels op beide systemen geïnstalleerd en naar de "meterkast-versie" laten verwijzen.

(De Meterkast versie deed het heel even niet meer omdat ik een typefout had gemaakt in de APi-key. Dat wil zeggen de webpagina liet niets zien. Toen ik daar de plug-in juist had ingesteld, had ik weer gewoon een dashboard.)

Alleen lukt het me niet om de docker-versie te laten herstarten.

Je zult de plugin alleen in de meterkast-versie moeten installeren! Anders gaat dat elkaar bijten.

En die moet dan verwijzen naar de Docker versie. In de Docker-versie hoef je alleen de API ingeschakeld te hebben en de API-key van daar te gebruiken.

De API van de meterkast-versie kan gewoon uit. Mits je de gewone datalogger gebruikt,

Dat is juist contra aan wat ik had verwacht.....
(De CLIENT doet toch een API request bij de SERVER?
Dus de CLIENT heeft toch de API key nodig van de SERVER en niet andersom)

Status nu:
Meterkast (De SERVER): 502 Bad Gateway
Docker (De CLIENT): Geen gegevens gevonden.

Ik denk dat je het geen CLIENT en SERVER meer moet noemen, want nu kunnen aannames voor verkeerde informatie zorgen.

DSMR-reader is per definitie altijd een/de server. Echter, met de plugin kan een DSMR-server ook iets doorsturen naar een andere server/DSMR-reader. Dat maakt de plugin de client.

Vergeet dus al die termen, dit moet de setup zijn:

Meterkast DSMR-reader

  • Zit aan de slimme meter met kabel, werkt via datalogger.
  • API staat uit, is niet nodig.
  • Plugin is geinstalleerd, zodat alle uitgelezen telegrammen (als kopie) doorstuurd worden naar een andere DSMR-reader (Docker).
  • De plugin gebruikt de URL en API key zoals gedefinieerd in de Docker DSMR-reader.

Docker DSMR-reader

  • Zit niet aan de slimme meter en heeft dus geen datalogger nodig.
  • API staat hier aan. De API-key heb je nodig voor de plugin in de andere installatie.
  • Hier draaien geen plugins.

Helder beschreven Dennis, super! @Erik050572 Wellicht is het goed de beschrijving van Dennis uit te tekenen op papier. Maak het helder/inzichtelijk wat je setup (hoe verloopt de flow...), dan begrijp je het waarschijnlijk beter en krijg je het sneller aan de praat. Ik denk dat je er bijna bent, succes!

@xirixiz Ik begin het gevoel te krijgen dat ik het eindresultaat bijna kan aanraken.

@dennissiemensma
Jouw verhaal is echt verhelderend. Ik heb in de laatste paar weken heel veel bij geleerd. Nogmaals bedankt voor je tijd en je geduld.

Maar ik had inderdaad verkeerd begrepen:
Daarom heb ik de docker versie opnieuw geïnstalleerd en API aangezet
Vervolgens heb ik de plug-in in de Meterkast laten verwijzen naar de Docker versie. (en niet andersom zoals ik de hele tijd dacht.)

De Docker versie geeft echter nog steeds aan dat er geen data binnenkomt.
De plug-in ziet er nu zo uit:

 from django.dispatch import receiver

 from dsmr_datalogger.signals import raw_telegram


 @receiver(raw_telegram)
 def handle_forward_raw_telegram_to_api(**kwargs):
     API_HOST = 'http://192.168.1.41'  # Note: Check whether you use HTTP or SSL (HTTPS).
     API_KEY = 'UKZOFXOJ0E3MAI7IO0T6LEXNHDSIQHDSMHQZIF64R2HBJLMJR7E5JTGUJXZ6F3TX'
     TIMEOUT = 5  # A low timeout prevents the application from hanging, when the server is unavailable.

     try:
         # Register telegram by simply sending it to the application with a POST request.
         print('plugin test')
         response = requests.post(
             '{}/api/v1/datalogger/dsmrreading'.format(API_HOST),
             headers={'X-AUTHKEY': API_KEY},
             data={'telegram': kwargs['data']},
             timeout=TIMEOUT
         )
     except Exception as error:
         return logging.error(error)
     print(response.status_code)
     if response.status_code != 201:
         logging.error('Server Error forwarding telegram: {}'.format(response.text))

Ik vermoed dat ik de quotes om de API_HOST & API_KEY weg dien te halen halen. Echter als ik dat doe, krijg ik een 502 error op de meterkast & nog steeds geen data op de DOCKER.

N.B.:
Vanuit de meterkast krijg ik deze foutmelding "curl: (7) Failed to connect to 192.168.1.41 port 80: Verbinding is geweigerd" op onderstaand commando (vanuit de meterkast):
curl http://192.168.1.41/api/v1/datalogger/dsmrreading -d 'telegram=xxxxx' -H 'X-AUTHKEY: UKZOFXOJ0E3MAI7IO0T6LEXNHDSIQHDSMHQZIF64R2HBJLMJR7E5JTGUJXZ6F3TX'

Je kunt die quotes absoluut niet weghalen, die horen daar te staan.

Het lijkt erop dat je geen verbinding kunt maken met de Docker container. Dat moet je nu als eerste oplossen. Probeer die maar op de Pi in de meterkast uit te voeren:

telnet 192.168.1.41 80

Ik vermoed dat dat dan ook niet werkt.

Kan het zijn dat je Docker-container in een heel ander netwerk zit?

Heb je al een staatslot gekocht?
Jij mag niet meer raden.
:)

De Docker-container en de meterkast hangen aan dezelfde unmanaged switch, dus op hetzelfde netwerk.

Draait de webinterface van de Docker-DSMR-reader wel? Kun daar daar bij op hetzelfde IP (bijvoorbeeld vanaf je computer).

Het kan zijn dat het systeem wel bereikbaar is, maar er simpelweg geen proces op poort 80 draait.

Daar kan ik bij:

Docker:
Aantekening 2020-01-09 205155

Meterkast:
Aantekening 2020-01-09 205155

Als ik zoek naar open poorten op de dockerversie, krijg ik geen poort 80 te zien.

Je kunt in de adresbalk zien dat de URL voor Docker op een niet-standaard poort (niet 80) draait. Je zult die poort moeten meenemen in de plugin, maar probeer eerst maar of het werkt wanneer je het met de hand probeert:

telnet 192.168.1.41 8888

Als dat werkt kun je het in de plugin proberen:

API_HOST = 'http://192.168.1.41:8888'

Telnet werkt, de aanpassing in de plug-in nog niet

Wellicht goed om dan eerst wel even met cURL te proberen vanuit de meterkast-Pi naar de Docker, zoals hier: https://github.com/dennissiemensma/dsmr-reader/issues/797#issuecomment-569897253. Maar dan wel met de :8888 poort erbij gespecificeerd.

En vergeet niet om de applicatie te herstarten na elke wijziging in de plugin.

Wellicht goed om dan eerst wel even met cURL te proberen vanuit de meterkast-Pi naar de Docker, zoals hier: #797 (comment). Maar dan wel met de :8888 poort erbij gespecificeerd.

Dan krijg ik als reply: Failed to parse telegram

En vergeet niet om de applicatie te herstarten na elke wijziging in de plugin.

Dit commando heb ik elke keer uitgevoerd:
sudo supervisorctl restart all

Als je de plugin goed hebt ingesteld, moet je output kunnen vinden in de log van de datalogger. Bijvoorbeeld:

pi@rpi4:~ $ tail -f /var/log/supervisor/dsmr_datalogger.log 
The current logging level only logs warnings and errors, to reduce I/O. More information can be found here: https://dsmr-reader.readthedocs.io/en/v2/troubleshooting.html#logging
plugin test
201
plugin test
201
plugin test
201
plugin test

Als je geen plugin test kan vinden, heb je toch iets niet goed ingesteld. Dit is dus allemaal op de Pi die aan je meter hangt.

Dit is de response:

pi@DSMR-reader:~ $ tail -f /var/log/supervisor/dsmr_datalogger.log 
plugin test
plugin test
plugin test
....

Dat is mooi. En dat betekent dat je nu alleen nog op zoek hoeft naar de bijbehorende foutmelding. Je kunt de plugin nu uitbreiden met nog een print:

...
    except Exception as error:
        return logging.error(error)
...

Wordt:

...
    except Exception as error:
        print('Error', error)
        return logging.error(error)
...

Zorg ervoor dat er evenveel spaties zijn, zodat de nieuwe print uitgelijnd is met return logging.error(error).

Herstarten en opnieuw de log bekijken.

Ik heb de extra regel toegevoegd op regel 22.
Dit is dan de response:

plugin test
Error name 'requests' is not defined
....

Dat verklaart een hoop. Hoewel requests onderdeel is van de standaardinstallatie, kan het zijn dat er wat mis is gegaan eerder.

Je mag dit uitvoeren:

sudo su - dsmr
pip3 install requests==2.22.0
./reload.sh

En dan opnieuw kijken of het nu wel werkt.

Dat is helaas niet de oplossing.
De foutmelding blijft.

Dat is eigenlijk onmogelijk, maar ik zie nu in je eerdere code-dump dat je een deel van de imports mist: https://dsmr-reader.readthedocs.io/en/latest/plugins.html#example-3-forwarding-raw-telegram-data-to-another-instance-by-api

Je zult dit nog bovenaan moeten toevoegen:

import requests
import logging

Dat is wel erg dom!

Maar dit ziet er al beter uit:

...
plugin test
201
....

Ik heb de meterkast opnieuw opgestart & de data stroomt binnen :)

Mooi, dan kun je die zelf-toegevoegde print() statements verwijderen. Die zijn niet meer nodig.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

swerveshot picture swerveshot  ·  4Comments

tomkooij picture tomkooij  ·  3Comments

joep2000 picture joep2000  ·  11Comments

dennissiemensma picture dennissiemensma  ·  8Comments

KobeBergmans picture KobeBergmans  ·  4Comments