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 "
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.
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:
-
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:

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..

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.

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
directoryAls 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.pngMijn 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:
\

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:

Dit is per meting:

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:

Dat komt redelijk overeen....

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:

@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 connectionsDit 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
cuhandmatig de slimme meter kan uitlezen: https://dsmr-reader.readthedocs.io/en/latest/installation/explained.html#your-first-reading-optionalAlleen 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:
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 "
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
...........................................................

en zo ziet mijn docker dir eruit.

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

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.
Dankjewel Dennis voor de suggestie.
https://gathering.tweakers.net/forum/list_message/60978238#60978238
@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.
@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:

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:

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:

dsmr:

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..
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-URLInvalid auth keyFailed 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

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',
]
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
Docker DSMR-reader
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:

Meterkast:

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.
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