hulp by docker-containers

[ronniebee]

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.

[Erik050572]

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

[ualex73]

@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?

[Erik050572]

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.

[dennissiemensma]

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

[ronniebee]

@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

• ronniexxx@ronald en in ronniexxx@ronald:~/docker

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:

[ronniebee]

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

[Erik050572]

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?

[ualex73]

@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

[Erik050572]

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

[ualex73]

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 .

[ronniebee]

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.

[dennissiemensma]

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

[Erik050572]

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

[ualex73]

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 .

[ualex73]

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.

[Erik050572]

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

[ualex73]

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' ;-)).

[Erik050572]

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

[dennissiemensma]

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

[Erik050572]

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

[dennissiemensma]

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

[Erik050572]

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:

[dennissiemensma]

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:

[Erik050572]

Dat komt redelijk overeen....

[dennissiemensma]

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?

[Erik050572]

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.

[dennissiemensma]

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.

[Erik050572]

Ik zal het in de gaten houden Op dit moment ziet, het er zo uit:

[ronniebee]

@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?

[ualex73]

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

[dennissiemensma]

@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?

[ronniebee]

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

[dennissiemensma]

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

[ronniebee]

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

[dennissiemensma]

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

[ronniebee]

Dank je Dennis. Zeer gewaardeerd.

[ualex73]

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

[ronniebee]

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?

[ualex73]

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.

[ronniebee]

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

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

en zo ziet mijn docker dir eruit.

[Erik050572]

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?

[dennissiemensma]

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

[Erik050572]

Dankjewel Dennis voor de suggestie. https://gathering.tweakers.net/forum/list_message/60978238#60978238

[ualex73]

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

[Erik050572]

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?

[dennissiemensma]

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.

[Erik050572]

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

[dennissiemensma]

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

[Erik050572]

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?

[dennissiemensma]

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.