DSMR-reader v6 release

[dennissiemensma]

DSMR-reader v6 release discussions

Cross-ref: xirixiz/dsmr-reader-docker#391

[dennissiemensma]

Release candidate 6 nu: https://github.com/dsmrreader/dsmr-reader/releases/tag/v6.0rc6

[dennissiemensma]

Het lukt mij niet om die versie te draaien.

Bij de start geeft die dit aan:

    DSMR Reader version: development
    DSMR Reader Docker version: development
    Build-date: 20260108-1551

Als ik in de webinterface of dsmrreader/__init__.py kijk, dan is het nog rc8.

VERSION = (6, 0, 0, "rc", 8)

podman-compose pull + podman-compose up -d --force-recreate zou afdoende moeten zijn toch? Of zie ik iets over het hoofd? 🙈

[xirixiz]

Hmm, dit zou je moeten zien. Maar klopt dat het afdoende zou moeten zijn. Gerbuik je deze image of die van de Docker HUB?
Maar voor de zekerheid heb ik nog een build gestart zojuist....

 ghcr.io/xirixiz/dsmr-reader-docker:development

Het image ID zou dit moeten zijn dan: d18b0d78b010 (AMD64 iig)

[remco-77]

FYI, ik heb net een podman-compose pull + podman-compose up -d --force-recreate gedaan, en krijg dan inderdaad image id d18b0d78b010 en dsmrreader v6.0rc9 met Build-date: 20260108-1944.

[dennissiemensma]

@xirixiz dank! Met de nieuwe image is het wel gelukt:

    ───────────────────────────────────────────────────
    DSMR Reader version: development
    DSMR Reader Docker version: development
    Build-date: 20260118-2019
    ───────────────────────────────────────────────────

Geen idee waarom die eerder op rc8 bleef hangen

[xirixiz]

Ik vermoed omdat ik alleen de build voor AMD64 heb gestart, en niet voor alles, omdat er best al wat mensen aan het testen waren.

[dennissiemensma]

Ik ga nu thuis v6 als leidend draaien en v5 nog er naast om te zien of er iets niet werkt. Al gebruik ik niet alle features, zoals teruglevering of PVOutput.

[dennissiemensma]

Dev docs bijgewerkt: https://dsmr-reader.readthedocs.io/en/development/
Deze heeft nog wat werk nodig, maar de kern staat er in: https://dsmr-reader.readthedocs.io/en/development/how-to/upgrade/to-v6/

[ghost]

Ik heb de laatste v6 RC als test draaiend en naar wens.
Wat betreft de 'docs'.

Ik raad je aan om het diagram zeker en vast niet als eerste te plaatsen in het upgrade document.

Een reguliere gebuiker is mijns inziens niet bekend met de materie en zou n.a.v. het diagram zelfs 'koudwatervrees' kunnen ervaren bij het upgraden.

[dennissiemensma]

@bertusdebruin dank voor de vroege test! Ik zal de documentatie wat bijwerken dan.

Waren er nog andere zaken waar je niet direct uit kwam?

[ghost]

@dennissiemensma Nee ik kwam er direct uit. Het zijn vormzaken waar je op het moment van schrijven ff goed op moet letten. Bijv. zoals je weet schakelt jou compose script naar :6 van de dsmr-reader container, maar die is nog niet actief. Dat is nu :development. Van dat soort orde van grootte.

Wellicht een idee om meer ruimte tussen de diverse parameters in de compose.yml file te plaatsen. Zodat er duidelijk onderscheid zichtbaar is. Er staat behoorlijk veel in. Ik vond het nu gepriegel en vanuit een klein scherm niet altijd even snel leesbaar.

Tot slot is de container installatie toch wel een pakje goed en beter opletten dan de traditionele installatie. Je moet goed opletten, een , of spatie teveel in de compose configuratie en het kan al resulteren in een error. Tip voor de minder ervaren gebruiker, wanneer je vaker met containers werkt, weet je wat ik bedoel.

[dennissiemensma]

Dit zijn mijn oude comments, maar ik groepeer ze even hier, geen nieuwe reactie nodig hoor!

[dennissiemensma]

bedankt voor je feedback, dit is exact wat ik nodig had, omdat ik wil weten hoe het voor iemand is die zelf niet met containers (en dit soort configs) werkt.

Ik zal daarom denk ik de parameters uit de compose file halen en ze in een .env file zetten. Die is wat minder gevoelig voor fouten en daarnaast hoeven jullie dan ook zelden meer de compose-file aan te passen.

Zodra ik dit bijgewerkt heb kom ik er op terug, zodat je die setup kan gebruiken. Dat maakt het ook veel makkelijker voor je denk ik!

[dennissiemensma]

ik heb de docs nu bijgewerkt:

• https://dsmr-reader.readthedocs.io/en/development/how-to/installation/container-setup/

Je kunt je huidige setup blijven gebruiken, of wisselen naar een aparte env file. Als je dat laatste wil:

sudo su - dsmrreader

wget https://raw.githubusercontent.com/dsmrreader/dsmr-reader/refs/heads/v6/provisioning/container/compose.prod.env -O /home/dsmrreader/compose.env

In compose.env kun je nu eerst al je instellingen goedzetten/overnemen uit je bestaande compose.yml bestand.

Daarna kun je die even hernoemen (mocht het niet in 1x goed gaan):

mv compose.yml OLD.compose.yml

Nieuwe downloaden:

wget https://raw.githubusercontent.com/dsmrreader/dsmr-reader/refs/heads/v6/provisioning/container/compose.prod.yml -O /home/dsmrreader/compose.yml

In die compose.yml zul je (nog) even:

image: ghcr.io/xirixiz/dsmr-reader-docker:6

Weer op deze moeten zetten:

image: ghcr.io/xirixiz/dsmr-reader-docker:development

En eventueel dit deel aanpassen naar hoe je het lokaal heb (verwijderen of hernoemen):

    # TODO for you: Alter "ttyUSB0" if your system uses a different name. Or disable these two lines if you use a network-connected smart meter (or API).
    devices:
       - /dev/ttyUSB0:/dev/ttyUSB0  

Nu kun je wisselen met:

podman-compose up -d

Of, als dat fouten geeft qua "bestaande" containers:

podman-compose up -d --force-recreate

---

Mocht dat niet werken of je er niet uit komen, dan kun je terug met:

mv OLD.compose.yml compose.yml

podman-compose up -d --force-recreate

[dennissiemensma]

Dit zou het allemaal veel makkelijker moeten maken, nogmaals bedankt voor de heads up.

[allureGOT]

Ik draai de software niet in docker, komt er ook een stappenplan om "bare-metal" te upgraden?

[dennissiemensma]

Dit zijn mijn oude comments, maar ik groepeer ze even hier, geen nieuwe reactie nodig hoor!

[dennissiemensma]

zeker! De info om te switchen naar containers is onderdeel van de upgrade guide.

De development preview staat hier:

• https://dsmr-reader.readthedocs.io/en/development/how-to/upgrade/to-v6/
• https://dsmr-reader.readthedocs.io/en/development/how-to/installation/container-setup/

De officiele v6 release is er momenteel nog niet, maar naar verwachting op korte termijn.

Updaten naar v5.12 is eventueel ook nog een optie voor je, om nog niet meteen te hoeven updaten, maar er komt een moment dat distro's in hun OS niet meer de oude Python-versies van DSMR-reader v5.x ondersteunen. Idem voor de databases. Of andere vendors, zoals Dropbox.

[allureGOT]

Op dit moment draai ik op 5.12.

Ik had de preview gelezen en gezien dat je daar naar docker "moet". Dat zou ik liever niet willen omdat ik de dsmr-software nu op een dedicated ubuntu-host draai. Docker zou daar weer een overhead op zijn.

Hier draai ik de meest actuele python versie op: 3.12.3

[dennissiemensma]

Dit zijn mijn oude comments, maar ik groepeer ze even hier, geen nieuwe reactie nodig hoor!

[dennissiemensma]

het staat je altijd vrij om zelf DSMR-reader direct op je host te installeren (of om nooit te updaten), alleen kan ik er geen support meer voor leveren. Het gat qua technische kennis onder gebruikers is hiervoor te divers.

DSMR-reader is, los van wat verplaatste mappen, verder niet veranderd. Je zult alleen wel zelf Python moeten bijwerken om te zorgen dat je in lijn blijft met de dependencies.
Deze zullen ongetwijfeld onaangekondigd veranderen, ook de Python-versie, omdat al deze constraints nu in de container zitten en nooit meer een issue voor de buitenwereld is.

Deze hele container setup had Xirixiz vele jaren geleden al werkend voor DSMR-reader. Maar zelf was ik destijds ook nog wat terughoudend qua impact. De overhead van containers is op Linux-systemen inmiddels minimaal, eigenlijk native. Ik heb dan ook bewust een paar jaar gewacht voordat deze stap gezet werd, zowel voor de gemiddelde hardware als performance.

[ghost]

@dennissiemensma

'Je kunt je huidige setup blijven gebruiken, of wisselen naar een aparte env file. Als je dat laatste wil:'

Mijn eerste insteek is niet om mijn installatie proces 'zo' makkelijk mogelijk te maken, maar meer of een container setup voor mij naar wens is.

Zoals ik reeds eerlijk eerder heb aangegeven een tijd geleden, ben ik simpelweg geen fan van een container-based installatie wanneer het enkel gaat om een enkele setup op bijvoorbeeld een Raspberry Pi.

P.s. ik heb met container gewerkt, maar ben er geen fan van. Zie eerdere reacties.

[dennissiemensma]

Dit zijn mijn oude comments, maar ik groepeer ze even hier, geen nieuwe reactie nodig hoor!

[dennissiemensma]

dan heb ik je verkeerd begrepen, ik dacht dat je al over was. Hoe dan ook is je input waardevol geweest voor anderen.

Voor jou geldt hetzelfde, voel je vrij om dan voorlopig niet te updaten. Ik raad je wel aan om later dit jaar het alsnog een poging te geven. Wat je persoonlijke reden (of voorkeur) ook is, containers zijn tegenwoordig niet meer weg te denken. Ook in mijn dagelijkse werk gebruiken we inmiddels al jaren containers en we willen nooit meer terug naar de vorige situatie.

Dat heeft ook bij mij zelf wel even geduurd voordat ik over was. Dus weet dat ik jouw (of jullie) gedachtengang zeker begrijp.

[allureGOT]

Ok, duidelijk, ik heb m'n DSMR-host opgenomen in Portainer als host, nu nog de docker-compose om zien te bouwen voor gebruik in Portainer.

[ghost]

@dennissiemensma Nee ik ben nog niet over. Ik heb simpelweg mijn Pi gecloned en een upgrade naar container based v6 uitgevoerd. En dezelfde Pi daarna vers geinstalleerd op OS versie 13 en daarop een verse DSMR-reader v6 geinstalleerd zonder back-up. De originele Pi daar is niets veranderd en die draait gewoon nog op mijn slimme meter. Deze actie was puur om te kijken of v6 iets voor mij is.

Zakelijk zie ik de meerwaarde van een container based omgeving. Vooral bij meerdere versies van dezelfde software en/of het snel willen en kunnen schakelen tussen meerdere dedicated systemen met dezelfde containers. Voor prive zie ik dat voordeel echter niet. Een Pi is ideaal voor een enkele of een paar kleine lite apps. Er hoeft niet geschakeld te worden, er is immers 1 enkele Pi. En er is geen haast bij eventueel downtime.

Gezien het relatief geringe werkgeheugen van een Pi, is Podman onnodig mijn geheugen aan het opeten, er draait slechts een enkele DSMR-reader app. Maar voor die ene enkele app sinds v6 nu wel meerdere containers, elk met hun eigen OS en dus overhead. Een dedicated server zal 0 problemen ondervinden maar een kleine Pi? @allureGOT haalde dat ook al eens aan. Ik ben benieuwd wat het doet op een Pi als de database echt groot wordt. Zonder overhead aan Podman had de v5 van DSMR-reader daar bij mij ook wel eens last van.

Ik bgrijp dat de database op te schonen is. Gegeven is alleen dat ik niet dagelijks naar DSMR-reader kijk. Mocht de database (te) vol zitten, een melding geeft dat er of geen gegevens meer worden opgeslagen, achterloopt met opslaan en/of de vraag naar een opschoon actie, dan ben ik waarschijnlijk te laat. Datzelfde geldt ook voor een crash. Zakelijk worden containers zeker en vast extern gemonitord. Op een enkele simpele Pi worden die containers niet gemonitord. Wat als er een container crashed? Is het Podman? Is het de app binnen de container? Is het een te volle database? Geheugen te kort? Joost mag het weten. Ook dat geeft overhead, omdat je nu kennis moet hebben van Podman, helemaal omdat er niets extern wordt gemonitord en je dus zelf op pad mag.

Ik zal v6 uiteraard blijven volgen en later mijn keuze maken. Maar voor nu ben ik (nog) niet overtuigd en er niet blij mee.

[dennissiemensma]

Laten we voor nu dan zeggen dat dit een geval "we agree to disagree" is. Ik denk dat we alledrie een andere blik/ervaring en perceptie hebben op bovenstaande.

Hoe dan ook staat het je vrij om zelf de installatie van DSMR-reader v6 en hoger handmatig te doen. Er zijn geen wijzigingen in die dit beperken.

Alleen de ondersteuning voor debugging bij handmatige installaties verdwijnt. Hoewel ik denk dat de meeste issues ofwel in historische issues van dit project terug te vinden zijn, ofwel dat een willekeurige AI-agent je ook kan helpen bij toekomstige issues. Vaak is het toch maar een typo of verkeerd pad of iets wat een fout veroorzaakt.

[xirixiz]

Dank voor je reactie. Dit project wordt in vrije tijd, gratis en voor de community ontwikkeld. Dat betekent dat er keuzes gemaakt zijn die het project onderhoudbaar en beheersbaar houden voor een klein team, niet per se optimaal voor elke individuele voorkeur.

De waarheid zal ergen in het midden liggen. Een compactere stack is altijd wenselijk, maar containerisatie is een pragmatische keuze om het project duurzaam te houden. Wie liever op OS niveau werkt, kan dat blijven doen. Voor de meeste gebruikers is de container aanpak eenvoudiger en betrouwbaarder. PiHole biedt dat niet voor niets ook aan.

Maar Docker/Poman is geen wondermiddel en voegt een extra laag toe, maar biedt ook isolatie, reproduceerbaarheid en veilige upgrades. Het verplaatst sommige complexiteit, maar voorkomt veel host specifieke problemen en supportlast.

Bij een native Python installatie is het overigens nadrukkelijk de bedoeling om een venv te gebruiken. Daarmee blijven dependencies volledig geïsoleerd en is "--break-system-packages" geen issue en ook niet nodig. Dat argument gaat dus alleen op als je Python libs/packages rechtstreeks in het systeem probeert te installeren, wat in geen enkele situatie is aan te raden.

[nero355]

Hoe dan ook staat het je vrij om zelf de installatie van DSMR-reader v6 en hoger handmatig te doen. Er zijn geen wijzigingen in die dit beperken.

Mag ik aannemen dat de documentatie voor het handmatig installeren ook nooit zal verdwijnen ?
Of in ieder geval de 5.x documentatie extra notities voor 6.x zal bevatten ?

Alleen de ondersteuning voor debugging bij handmatige installaties verdwijnt. Hoewel ik denk dat de meeste issues ofwel in historische issues van dit project terug te vinden zijn, ofwel dat een willekeurige AI-agent je ook kan helpen bij toekomstige issues. Vaak is het toch maar een typo of verkeerd pad of iets wat een fout veroorzaakt.

Ik heb liever te maken met mensen dan "Machine Learning Chatbots" dus als de nieuwe versie net zo goed blijft draaien als de huidige dan zullen de mogelijke vragen die ik zal hebben hopelijk niet over eventuele errors en dergelijken gaan, maar hooguit over "Hoe laat ik dit of dat anders eruit zien ?" of "Wat kan je het beste doen op moment X qua datagroei ?" en dergelijken... 😉

[nero355]

Voor de meeste gebruikers is de container aanpak eenvoudiger en betrouwbaarder. PiHole biedt dat niet voor niets ook aan.

NOFI, maar dat kan je niet zomaar beweren zonder keiharde cijfers...

Maar Docker/Podman is geen wondermiddel en voegt een extra laag toe

Dat is precies mijn punt en de heren bij Ubiquiti hebben het zelfs op een gegeven moment teruggedraaid op al hun produkten !!
Die dachten namelijk van hun problemen af te kunnen komen door Podman Containers te gebruiken voor hun "All-in-One" produkten en dat pakte helemaal verkeerd uit...

Bij een native Python installatie is het overigens nadrukkelijk de bedoeling om een venv te gebruiken. Daarmee blijven dependencies volledig geïsoleerd en is "--break-system-packages" geen issue en ook niet nodig. Dat argument gaat dus alleen op als je Python libs/packages rechtstreeks in het systeem probeert te installeren, wat in geen enkele situatie is aan te raden.

Tja, voor zoiets als jullie project is dat misschien wel te doen, maar software zoals Mopidy of de add-ons/plug-ins van Kodi bijvoorbeeld maken daar geen gebruik van voor zover ik dat tot nu toe heb gezien.
Toen de meldingen over "--break-system-packages" ineens verscheen raakten een hoop mensen in de war/paniek vanwege iets dat voorheen nooit de installatie van Mopidy in de weg zat...
En tijdens de "Python 2.7 vs. 3.x periode" zaten een hoop Kodi gebruikers zich te ergeren aan add-ons/plug-ins die niet meer werkten of crashten tijdens het gebruik...

Op zulke momenten wil je toch misschien wel liever iets dat in een andere programmeertaal was geschreven 😉

[dennissiemensma]

Mag ik aannemen dat de documentatie voor het handmatig installeren ook nooit zal verdwijnen ?
Of in ieder geval de 5.x documentatie extra notities voor 6.x zal bevatten ?

Het hele punt van geen ondersteuning bieden is om dat niet te doen. Het hele waarom staat hier.

De v5 documentatie zelf blijft nog zeker wel een jaar online staan, maar verdwijnt nooit uit de repo. Dit blijft eeuwing in de v5-branch staan. Op den duur zet ik hem wel online uit, om te voorkomen dat gebruikers van nieuwe installaties bij oude docs terechtkomen.

Dit is overigens ook het geval met de online-documentatie voor DSMR-reader v2, v3 en v4, die staan al jaren uit:

• https://dsmr-reader.readthedocs.io/en/v2/
• https://dsmr-reader.readthedocs.io/en/v3/
• https://dsmr-reader.readthedocs.io/en/v4/

---

Ik kan je sws aanraden om dit project (en elk open-source-project dat je graag gebruikt) te forken op je Github-account zodat je altijd een kopie hebt.

De online-documentatie van DSMR-reader komt uit hetzelfde project, die staat ook in je eigen kopie, zelfs in je eigen installatie van DSMR-reader v5:

• v5 docs: https://github.com/dsmrreader/dsmr-reader/tree/v5/docs

Daar staan ook de handmatige instructies in die je vermoedelijk ooit hebt gebruikt.

---

Voor v6 is er geen magie, de containers gebruiken onderwater ook zaken die (doorgaans) op een willekeurige distro beschikbaar zijn. Maar Xirixiz neemt dus al die zaken voor ons weg in de container.

Je kunt altijd kijken hoe de container voor v6 opgebouwd is onderwater:

• https://github.com/xirixiz/dsmr-reader-docker/blob/development/Dockerfile

Gooi dat in een willekeurige agent en vermeld je distro en dan kom je denk ik een heel eind.

[allureGOT]

Eens, Ik draaide de software nog bare-metal, inmiddels overgegaan naar docker.
Om de software en in gebruik zijnde DB in docker te krijgen heb je wel wat technische kennis nodig, meer dan enkel het stappenplan volgen.)

Ik gebruikte al op meerdere plaatsen docker-hosts, en gebruik Portainer om dit te beheren, dit om toch het een en ander middels een GUI te kunnen bedienen.

Qua overhead lijkt het wel mee te vallen:
RAM gebruik, de gele "vlek" rechts geeft het "gestoei" aan om de docker-container te configureren.

CPU gebruik loopt wel iets op, dat kun je uiterst rechts zien, deze gaat van 1,5% (bare-metal) naar 2,8% (docker).

Nu gebruik ik Zabbix om mijn apparatuur en hosts te monitoren, dus zal ook een melding krijgen zodra de container onderuit gaat. Dat is natuurijk niet een standaard oplossing als je de software enkel op een Raspberry Pi gebruikt en verder geen infra hebt.

[dennissiemensma]

Ik heb helaas niet de mooie grafieken zoals jij ze hebt, maar in htop zie ik grofweg hetzelfde hier. Op een RaspberryPi 4 en 5.

Enig kanttekening is dat ik een DSMRv4 meter heb, dus die stuurt wat minder data dan de meeste meters. Maar dan nog verwacht ik niet dat de load een factor 10 hoger zou zijn bij mij.

Puur ter info: Dit is op twee recente installaties van RaspberryPi OS Trixie 13. De enige conclusie die ik kan trekken is dat het RAM-gebruik minimaal 1 GB is (incl host OS), maar dat ik daar niet van schrik.

De rPi 4 heb ik gisteren opnieuw geinstalleerd en daar draaide nog Debian 10 op met native DSMR-reader v5, met ~600 MB usage. Die 400 MB extra zal vast niet alleen Podman zijn, maar ook het OS en meer. En hoe dan ook vind ik 1 GB nog wel acceptabel met de hardware van tegenwoordig en de prijzen.

De rPi 5 blaast echt alles weg en die is relatief "duur" tov de vorige versie, maar de rPi 4 trekt het ook prima. Daar is de SD-kaart waarschijnlijk ook nog eens de bottleneck ipv CPU.

Pi 4

Pi 5

[ghost]

@allureGOT Hoeveel werkgeheugen heb je en welke CPU? Overhead op een dedicated is vaak een lachertje. Een Pi heeft beperkte capaciteit. Een paar procent meer belasting kan het verschil maken. Tot slot hoeveel dagen heb je opgeslagen in je DB?

[dennissiemensma]

Ik weet niet of je van alle comments een mail krijgt, maar hier nog wat recente stats van mij van de Pi 4 en Pi 5, puur ter info.

[spiralshapeturtle]

• DSMR = nieuw versie 5.12 in podman docker wel met de 17 versie DB
• dsmr="baremetal" 5.12

Beide halen met een eigen script data op uit de HomeWizard P1 module, ik vond DSMR altijd vrij energie hongerig voor een energiemeter ;-) dat lijkt nu minder impact te hebben.

[dennissiemensma]

Dank voor het delen. DSMR-reader is nooit geoptimaliseerd hiervoor.

Ik denk dat de meeste winst zit in de grote bump van Python 3.10 (of ouder, ik weet niet wat je bare-metal draaide) naar nu Python 3.13 in v6. En binnenkort wil ik wel Python 3.14 proberen (recent gereleased). En daarvoor hoeven gebruikers zelf niets meer bij te werken op hun OS.

Alle versies na Python 3.10 zijn stukken beter geworden qua performance, ongeacht hoe het gebruikt wordt (benchmarks zijn niet altijd representatief).

[allureGOT]

Dit is een intel i3 met 6GB Ram.
Er zit nu +/- 5 jaar aan data in de DB, ik weet niet hoe ik exacte dagen uit de DB kan toveren.

[dennissiemensma]

Dagen stats

select count(id) from dsmr_stats_daystatistics;

Bij mij:

dsmrreader=# select count(id) from dsmr_stats_daystatistics;
 count 
-------
  3662

---

Metingen

select count(id) from dsmr_datalogger_dsmrreading;

Bij mij:

dsmrreader=# select count(id) from dsmr_datalogger_dsmrreading;
 count  
--------
 234800
(1 row)

---

Databasegrootte

SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
  FROM pg_class C
  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema')
    AND C.relkind <> 'i'
    AND nspname !~ '^pg_toast'
  ORDER BY pg_total_relation_size(C.oid) DESC
  LIMIT 20;

Bij mij:

                           relation                            | total_size 
---------------------------------------------------------------+------------
 public.dsmr_consumption_electricityconsumption                | 61 MB
 public.dsmr_datalogger_dsmrreading                            | 44 MB
 public.dsmr_consumption_quarterhourpeakelectricityconsumption | 16 MB
 public.dsmr_stats_hourstatistics                              | 9712 kB
...

[allureGOT]

@dennissiemensma, thanks!
Hieronder de data van de twee verschillende locaties waar elk hun eigen slimme meter draait.
Beide inmiddels over op het docker-image (5.12.0-2025.12.31)

@xirixiz, in de docker compose zit ook een healthcheck welke om de 10 seconden de volgende regel uitspuugt:
127.0.0.1 - - [07/Jan/2026:10:01:37 +0100] "GET /about HTTP/1.1" 200 13047 "-" "curl/8.14.1" "-"
Logt ie dit ook in een file? Of begrijp ik goed dat de uitkomst naar "/dev/null" gaat?

Dagen stats (locatie1)

dsmrreader=# select count(id) from dsmr_stats_daystatistics;
 count 
-------
  3194
(1 row)

Metingen (locatie1)

dsmrreader=# select count(id) from dsmr_datalogger_dsmrreading;
 count  
--------
 419489
(1 row)

Databasegrootte (locatie1)

                           relation                            | total_size 
---------------------------------------------------------------+------------
 public.dsmr_datalogger_dsmrreading                            | 72 MB
 public.dsmr_consumption_electricityconsumption                | 65 MB
 public.dsmr_consumption_quarterhourpeakelectricityconsumption | 16 MB
 public.dsmr_stats_hourstatistics                              | 8576 kB
 public.dsmr_consumption_gasconsumption                        | 7336 kB
 public.dsmr_weather_temperaturereading                        | 7312 kB
 public.dsmr_stats_daystatistics                               | 824 kB
 public.dsmr_frontend_notification                             | 120 kB
 public.dsmr_backend_scheduledprocess                          | 120 kB
 public.django_session                                         | 96 kB
 public.django_migrations                                      | 72 kB
 public.auth_user                                              | 64 kB
 public.django_admin_log                                       | 64 kB
 public.dsmr_consumption_energysupplierprice                   | 56 kB
 public.auth_permission                                        | 56 kB
 public.django_content_type                                    | 40 kB
 public.dsmr_frontend_sortedgraph                              | 40 kB
 public.dsmr_datalogger_meterstatistics                        | 32 kB
 public.dsmr_backup_dropboxsettings                            | 32 kB
 public.auth_user_groups                                       | 32 kB
(20 rows)

Dagen stats (locatie2)

dsmrreader=# select count(id) from dsmr_stats_daystatistics;
 count 
-------
  1884
(1 row)

Metingen (locatie2)

dsmrreader=# select count(id) from dsmr_datalogger_dsmrreading;
 count  
--------
 356438
(1 row)

Databasegrootte (locatie2)

                           relation                            | total_size 
---------------------------------------------------------------+------------
 public.dsmr_datalogger_dsmrreading                            | 78 MB
 public.dsmr_consumption_electricityconsumption                | 49 MB
 public.dsmr_consumption_quarterhourpeakelectricityconsumption | 16 MB
 public.dsmr_stats_hourstatistics                              | 5184 kB
 public.dsmr_consumption_gasconsumption                        | 4712 kB
 public.dsmr_weather_temperaturereading                        | 4480 kB
 public.dsmr_stats_daystatistics                               | 528 kB
 public.dsmr_datalogger_meterstatistics                        | 424 kB
 public.dsmr_backend_scheduledprocess                          | 120 kB
 public.django_session                                         | 96 kB
 public.django_migrations                                      | 72 kB
 public.auth_user                                              | 64 kB
 public.django_admin_log                                       | 64 kB
 public.dsmr_consumption_energysupplierprice                   | 56 kB
 public.auth_permission                                        | 56 kB
 public.django_content_type                                    | 40 kB
 public.dsmr_frontend_sortedgraph                              | 40 kB
 public.dsmr_backup_dropboxsettings                            | 32 kB
 public.dsmr_frontend_notification                             | 32 kB
 public.auth_user_groups                                       | 32 kB
(20 rows)

[xirixiz]

Dat is inderdaad een stdout melding. Als feature kan ik ook wel opnemen dat je kan kiezen om logs te mounten, zodat ze persistent zijn, maar dat is wel een feature voor later (improvement).

Hier zie je bijvoorbeeld healthy staan:

Dit helpt docker/podman bij het bepalen bij een herstart. Dus bij unhealthy, opnieuw starten, dat soort dingen kan je dan gebruiken.

[allureGOT]

Ik was even "bang" dat er een logfile vol zou lopen, maar dat is dus niet het geval.
Restart policy nu op "On failure" retry count op 5 gezet.

Portainer:

[xirixiz]

Ik heb nog wat tweaks toegevoegd die het cpu gebruik iets zouden kunnen reduceren, maar wat je zag op jouw gragfieken is verwaarloosbaar. Ik heb gzip compression op 2 gezet ipv 5. De UI zou dan nog steeds snappy aan moeten voelen, maar met iets minder cpu gebruik. open_file_cache heb ik op off gezet, dat is niet echt nodig in een container. Tenslotte de healthcheck interval op 120s gezet, dat is eigenlijk voldoende voor een container als DSMR. Scheelt ook weer cpu piekjes.

[niekniek89]

Het is bekend dat het CPU gebruik iets of wat is toegenomen in de afgelopen docker images.
Ik heb dit toevallig vorige week nog onder de aandacht gebracht (ik ging mijn dsmrdb en dsmr upgraden, omdat ik nog een héél oud image gebruikte).

Daarbij merkte ik op dat ik van +- 1,5% naar +-3% gegaan ben.
Dit zou als het goed is opgelost worden in v6, zit hem in de logging van het huidige docker image.

[xirixiz]

Het is al iets afgenomen en ik vermoed dat het nog een klein beetje zal afnemen. Voorheen werden alle services gestart, ongeacht gebruikt of niet. Ik heb daar gisteren een slimmigheidje voor ingebouwd waardoor services die niet gebruikt worden, ook niet meer gestart worden. Met name voor Pi devices en soortgelijken kan dat een verschil maken. De development tag blijft nu nog even staan zoals die is, maar op de achtergrond ben ik dus nog eea aan het optimaliseren en vereenvoudigen.

[allureGOT]

Ik had zojuist een issue met de software/docker, ik weet niet precies waar het m in zat.

De foutmelding was:

s6-rc: warning: unable to start service init-docker-entrypoint: command exited 1
Herstarten van de docker verhielp het niet, opnieuw deployen met Docker-compose wel.

[allureGOT]

Check, ik vermoede al zoiets, ik heb de tips uit de genoemde issue verwerkt en de docker naar de tag :development (v6.0rc9) geüpgraded. Even zien wat het nu doet.

[allureGOT]

Tot nu toe, bijna 24 uur verder, lijkt het prima te draaien.

[dennissiemensma]

Fijn, bedankt voor het herproberen!

[allureGOT]

Update van :Latest naar :Development (6.0rc11 op dit moment) gedaan, nu struikelt de software over het niet kunnen aanmaken van een/de superuser:

[ FAIL ] init-dsmr-and-db | Superuser creation failed

Hoe kan ik dit oplossen?
edit:
Ik had 6.0rc12 verwacht maar krijg 6.0rc11....

[dennissiemensma]

Nog even voor wie deze thread later terugleest: Inmiddels is de gewone v6 uit.

[dennissiemensma]

Release candidate 10: https://github.com/dsmrreader/dsmr-reader/releases/tag/v6.0rc10

• Met een fix voor de gebroken "View API Docs" pagina in het "Support" scherm

[allureGOT]

dsmr_logs.txt
Watchtower heeft vannacht de laatste versie binnengehengeld en heeft mijn dsmr om zeep geholpen, de fix zoals hierboven verhelpt het niet.

[allureGOT]

Ik heb een terugrol naar :latest gedaan. Dsmr draait weer stabiel.

[dennissiemensma]

@allureGOT Xirixiz heeft vandaag een nieuwe :development build gemaakt van de laatste rc, 12, waar ik mijn rc11-bug in gefixt heb.

Excuses voor het ongemak, het was een onfortuinlijke combinatie van omstandigheden dat ik blind rc11 foutief had gemaakt en er niet een nieuwe build beschikbaar was.

Deze start zonder problemen:

[allureGOT]

Als ik nu naar :development ga, krijg ik 6.0rc11 terug en niet rc12.. :?

DSMR Reader version: 6.0rc11 DSMR Reader Docker version: development Build-date: 20260129-0609

Edit:
Excuus, voor de zekerheid een volledige refresh gedaan en nu krijg ik wel netjes 6.0rc12.
DSMR Reader version: 6.0rc12 DSMR Reader Docker version: development Build-date: 20260202-1344

[dennissiemensma]

@xirixiz ik heb geen nieuwe issues meer gezien of gehoord sinds rc12. Denk je dat we binnenkort v6 kunnen releasen?

[allureGOT]

Ter info:

Ik had onderstaande issue in de dsmr-container(v6.0rc9):
2026-01-21 18:16:00,795 ERROR schedule execute_scheduled_processes 39 | (PermissionError) dsmr_backup.services.backup.run errored: [Errno 13] Permission denied: '/app/backups/dsmrreader-postgresql-backup-Wednesday.sql'

Dit kwam omdat de User en Group nog op 803 stonden terwijl de container als ID1000 draait, ik heb de map nu backups nu 777 gegevens als rechten.

[xirixiz]

Ik had hetzelfde issue kwam ik zojuist achter. Het is gebruikelijker om dat ID te gebruiken, maar mss is dat niet zo handig om te doen tijdens de release naar v6. Ik zet het even terug naar 803, wat het was, om issues te voorkomen.

[dennissiemensma]

Helpt het instellen van deze dan ook niet in dit geval?

DUID=1000
DGID=1000

Mits dat de IDs van de host spiegelt...

[xirixiz]

Ja correct, dit heeft lang niet goed gewerkt.

Je kan of

DUID=1000
DGID=1000

Die variabelen (environment) zetten. Of deze

PUID=1000
PGID=1000

Dit werkt nu goed. Ik had deze vars nog in mijn .env file staan voor docker-compose, maar omdat deze functionaliteit to onlangs niet naar behoren werkte, liep ik daar nu ook tegenaan. De container draait nu dus inderdaad netjes met de DUID en PGID die ik heb ingesteld. Voor mensen die host UID en GID mapping willen is dat juist goed.

Het beste kan je de owner en group id die je hebt staan op de gemounte backup folder mappen naar de container @allureGOT.
Bijvoorbeeld, user x heeft UID 101 en GID 102, dan zou je het beste dit kunnen meenemen in je docker-compose vars:

DUID=101
DGID=102

[allureGOT]

Ja, duidelijk maar omdat ik niet weet waar de container de waarde 803 "vandaan" gehaald had, wilde ik niet zomaar de owner en group aanpassen, zit 803 hard in de container?

[htca]

minor waarschijnlijk, maar ik draai de latest version; in het about scherm staat nog v5.12

[FutureCow]

latest is v5.12 dus dat klopt
development is v6.0rc12

[htca]

Living on the edge.... naar dev omgezet ;-)

[xirixiz]

Hahaham daar hou ik van. Goed bezig!

[allureGOT]

Goed bezig! Haha 🤣

[dennissiemensma]

[allureGOT]

Heb een vers pull-request gedaan, dit lost het inderdaad op. Excuus :X

[allureGOT]

Ik zie een foutmelding in de logs terugkomen, met betrekking op het deel buienradar, wisselen van weerstation/locatie heeft geen effect.

    DSMR Reader version: 6.0rc12
    DSMR Reader Docker version: development
    Build-date: 20260202-1344

2026-02-09 16:00:06,115 ERROR services run 21 | Buienradar: Selected station info not found: 6260 2026-02-09 17:00:06,733 ERROR services run 21 | Buienradar: Selected station info not found: 6275

[dennissiemensma]

Als ik de API bekijk die DSMR-reader gebruikt, dan zie ik 6275 er wel bij staan.

• https://data.buienradar.nl/2.0/feed/json

Ze staan hard gemapt in DSMR-reader:

• https://github.com/dsmrreader/dsmr-reader/blob/v6/src/dsmr_weather/models/settings.py

En als ik er een paar check, zie ik dezelfde terug. Dus ik zie helaas niet zo 1-2-3 een oorzaak. Deze integratie is ook niet veranderd in DSMR-reader v6.

[allureGOT]

Het lijkt wel een fout aan de kant van buienradar te zijn geweest, sinds vanmorgen 11:00 is de melding weg.

[dennissiemensma]

[TommiieeSV]

In de upgrade guide staat

ghcr.io/xirixiz/dsmr-reader-docker:6

maar ik krijg een manifest unknown melding. Ik zie bij de packages ook geen 6-tag: https://github.com/xirixiz/dsmr-reader-docker/pkgs/container/dsmr-reader-docker

[dennissiemensma]

@TommiieeSV voor nu kun je :development gebruiken. Dat is de laatste release candidate die inhoudelijk hetzelfde is. De :6 container volgt wanneer Xirixiz daar privé tijd voor heeft, dat zal ongetwijfeld ergens komende dagen zijn.

[xirixiz]

Yes! Vandaag staat er op de planning. De huidige/laatste versie 5 taggen zoals versie 6 getagged zal worden:

ghcr.io/xirixiz/dsmr-reader-docker:5
ghcr.io/xirixiz/dsmr-reader-docker:5.12
ghcr.io/xirixiz/dsmr-reader-docker:5.12.0

Ik pas daarvoor de pipeline eerste aan op de "oude" setup, en bouw dan een nieuwe 5.12.0 release, zodat voor ieder architectuur de juiste tag beschikbaar komt. Vervolgs gaat de development branch naar de main branch en kan v6.0.1 gebouwd worden:

ghcr.io/xirixiz/dsmr-reader-docker:development
ghcr.io/xirixiz/dsmr-reader-docker:latest
ghcr.io/xirixiz/dsmr-reader-docker:6
ghcr.io/xirixiz/dsmr-reader-docker:6.0
ghcr.io/xirixiz/dsmr-reader-docker:6.0.1

Bovenstaande gaat over ghcr.io, maar uiteraard geldt hetzelfde voor docker.io images en tags.

Daarnaast zal ik de komende dagen de docs nog wat optimaliseren, op dit moment zijn die erg summier.
Ik wil dat graag ook zo houden omdat het meeste eigenlijk beschreven staat in de docs die dennis heeft gemaakt.

[xirixiz]

Stap 1: Gereed. Alle oude tags verwijderd van zowel ghrc.io als docker.io. Laatste versie v5 volgens tags zoals besproken.
Stap 2: Gereed. "development" branch merge naar "main" branch
Stap 3: Gereed. Development nog 1x bouwen
Stap 4: Gereed. Final check development tag v6.0.1
Stap 5: Gereed. DSMR Reader v6 bouwen met tags zoals besproken.

Kortom: we zijn live met de v6 release 🎉

[niekniek89]

Bij mij lijkt de webserver niet tot stand te komen.... pagina werkt helaas niet meer.

[dsmr] 2026-02-14T09:55:35.497120000Z
[ INFO ] init-devices | Mapped /dev/ttyUSB0 (gid=20) -> add app to group dialout
[dsmr] 2026-02-14T09:55:35.497782000Z
[ INFO ] init-devices | Set permissions on /dev/ttyUSB0 to 666
[dsmr] 2026-02-14T09:55:35.498200000Z s6-rc: info: service init-devices successfully started
[dsmr] 2026-02-14T09:55:35.512585000Z
[dsmr] 2026-02-14T09:55:35.512646000Z ───────────────────────────────────────────────────
[dsmr] 2026-02-14T09:55:35.512685000Z
[dsmr] 2026-02-14T09:55:35.512719000Z ___ ___ __ __ ___ ___ _
[dsmr] 2026-02-14T09:55:35.512756000Z | / | / | _ \ | _ _ __ _ | |_ _ _
[dsmr] 2026-02-14T09:55:35.513722000Z | |) __ \ |/| | / | / -) / _ / -) '|
[dsmr] 2026-02-14T09:55:35.513779000Z |/|/| |||\ ||__,_,_||
[dsmr] 2026-02-14T09:55:35.513819000Z __ _
[dsmr] 2026-02-14T09:55:35.513847000Z | \ ___ | |___ _ _
[dsmr] 2026-02-14T09:55:35.513888000Z | |) / _ / | / / -) '|
[dsmr] 2026-02-14T09:55:35.513925000Z |/_/_|____||
[dsmr] 2026-02-14T09:55:35.513958000Z
[dsmr] 2026-02-14T09:55:35.513988000Z DSMR-protocol reader, telegram data storage and
[dsmr] 2026-02-14T09:55:35.514020000Z energy consumption visualizer.
[dsmr] 2026-02-14T09:55:35.514048000Z
[dsmr] 2026-02-14T09:55:35.514077000Z
[dsmr] 2026-02-14T09:55:35.514109000Z ───────────────────────────────────────────────────
[dsmr] 2026-02-14T09:55:35.514310000Z User UID: 1000
[dsmr] 2026-02-14T09:55:35.515239000Z User GID: 1000
[dsmr] 2026-02-14T09:55:35.515375000Z ───────────────────────────────────────────────────
[dsmr] 2026-02-14T09:55:35.515888000Z DSMR Reader version: 6.0.1
[dsmr] 2026-02-14T09:55:35.515937000Z DSMR Reader Docker version: 20260214.380
[dsmr] 2026-02-14T09:55:35.515985000Z Build-date: 20260214-0838
[dsmr] 2026-02-14T09:55:35.516026000Z ───────────────────────────────────────────────────
[dsmr] 2026-02-14T09:55:35.516066000Z
[dsmr] 2026-02-14T09:55:35.516184000Z
[ INFO ] init-useradd | Setting up directories and permissions
[dsmr] 2026-02-14T09:55:35.538908000Z s6-rc: info: service init-useradd successfully started
[dsmr] 2026-02-14T09:55:35.539181000Z s6-rc: info: service init-datalogger-mode: starting
[dsmr] 2026-02-14T09:55:35.543625000Z
[ INFO ] init-datalogger-mode | Starting
[dsmr] 2026-02-14T09:55:35.543935000Z
[ OKAY ] init-datalogger-mode | Running as STANDALONE (local server + datalogger)
[dsmr] 2026-02-14T09:55:35.544189000Z s6-rc: info: service init-datalogger-mode successfully started

[dennissiemensma]

Ik heb het nu toegevoegd: https://dsmr-reader.readthedocs.io/en/v6/how-to/upgrade/to-v6/#upgrade-step-a2-apply-mandatory-environment-variable-changes

Het blijft even roeien met de riemen die we hebben. In beide projecten is zoveel gewijzigd dat dit helaas onvermijdelijk is, al dacht ik dat we er al waren 😁

[dennissiemensma]

@TommiieeSV ik zou je datalogger lekker laten voor wat het is. Totdat de hardware interface van de meter wijzigt (waarschijnlijk nooit) zou dat moeten blijven werken. In principe kan dat ook gewoon een scriptje blijven zoals die nu is.

En anders kun je hem ooit nog vervangen door ser2net, mocht je datalogger zelf ooit fysiek stuk gaan.

[xirixiz]

Achja, de wereld vergaat er niet mee 😄. Zoals @dennissiemensma al aangeeft is er onderwater heel veel gewijzigd, maar uiteindelijk zorgt dat juist weer voor meer duidelijkheid en stabiliteit. Het is helaas niet anders dan dat er issues uitkomen. Maar het zal voornamelijk configuratie gerelateerd zijn.

[TommiieeSV]

Ik heb het nu toegevoegd: https://dsmr-reader.readthedocs.io/en/v6/how-to/upgrade/to-v6/#upgrade-step-a2-apply-mandatory-environment-variable-changes

Het blijft even roeien met de riemen die we hebben. In beide projecten is zoveel gewijzigd dat dit helaas onvermijdelijk is, al dacht ik dat we er al waren 😁

Hier missen wel nog de django db env vars die ook nodig zijn.

Het is ook allemaal geen drama natuurlijk, hoort er een beetje bij als je early adopter wil zijn. Door deze ervaringen kunnen jullie de docs ook weer netjes bijwerken :)

[dennissiemensma]

Het staat er nu wat algemener: https://dsmr-reader.readthedocs.io/en/v6/how-to/upgrade/to-v6/#upgrade-step-a2-apply-mandatory-environment-variable-changes

Ik moet er helaas vandoor, maar kom er later wel weer op terug. Dank!

[niekniek89]

@xirixiz hier mijn huidige config.
uiteindelijk kunnen upgraden naar v6.0.1.
ik heb hem nu werkend gekregen met onderstaande yaml settings:

alles werkt, krijg geen foutmeldingen meer… heb ik nu het juiste erin staan?

[xirixiz]

Ziet er goed uit! 👍 🥳 . Veel meet en tweak plezier.

[dennissiemensma]

@niekniek89 fijn om te horen, dank voor het delen!

[TommiieeSV]

Ik ben er ook in geslaagd om succesvol te upgraden. Het werkt en geen errors in de logs. Dank voor alle hulp!

Nog even ter feedback, ik heb met mijn setup uiteindelijk voor 2 punten terug moeten keren naar deze discussie tov de upgrade guide. Ik kan me zo voorstellen dat anderen deze misschien niet of moeilijk weten te vinden, dus nog deze 2 tips voor de upgrade guide:

• Benoem expliciet alle nieuwe DJANGO_DATABASE_* env vars die nodig zijn. Ze staan wel in de compose.env, dus op zich staat het wel benoemd, maar het zou zomaar eens wat onnodige github issues kunnen opleveren.
• De rewrite van DSMRREADER_OPERATION_MODE naar CONTAINER_RUN_MODE en de wijzigingen voor de values:
  standalone = standalone
  api_server = server_remote_datalogger
  api_client = remote_datalogger

Het is een aanname, maar kan me voorstellen dat mensen die al containerized draaien best vaak een remote datalogger gebruiken.

Maargoed, all is well en nogmaals dank voor de hulp!

[xirixiz]

Super, en bedankt voor de comments en het delen ervan.

[dennissiemensma]

@TommiieeSV fijn om te horen!

En dank voor de feedback, ik heb nu nog wat meer voorbeelden erbij gezet: https://dsmr-reader.readthedocs.io/en/v6/how-to/upgrade/to-v6/#upgrade-step-a2-apply-mandatory-environment-variable-changes

[TommiieeSV]

Ik heb toch weer problemen. Het heeft ongeveer 50 minuten goed gedraaid, maar daarna is DSMR reader gestopt met telegrammen verwerken. Ze komen wel nog binnen, maar ze worden niet verwerkt.

2026/02/15 12:58:41 | stderr | DETAIL:  Failing row contains (1003659, 2026-02-15 08:58:00+00, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).
2026/02/15 12:58:41 | stderr | 2026-02-15 12:58:41,783 ERROR    schedule     execute_scheduled_processes      39 \| (IntegrityError) dsmr_consumption.services.run errored: null value in column "delivered_1" of relation "dsmr_consumption_electricityconsumption" violates not-null constraint
2026/02/15 12:58:11 | stderr |  
2026/02/15 12:58:11 | stderr | DETAIL:  Failing row contains (1003658, 2026-02-15 08:58:00+00, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).
2026/02/15 12:58:11 | stderr | 2026-02-15 12:58:11,440 ERROR    schedule     execute_scheduled_processes      39 \| (IntegrityError) dsmr_consumption.services.run errored: null value in column "delivered_1" of relation "dsmr_consumption_electricityconsumption" violates not-null constraint
2026/02/15 12:58:08 | stderr | 2026-02-15 12:58:08,531 WARNING  datalogger   telegram_to_reading              82 \| Rejected telegram: Invalid telegram CRC. The calculated checksum '23949' (5D8D) does not match the telegram checksum '41316' (A164)
2026/02/15 12:57:40 | stderr |  

Hele rits aan dit soort berichten, 50 minuten na succesvolle start.
Op de About pagina staat Too many unprocessed readings: 4055 (2 hours ago)
@xirixiz @dennissiemensma

Edit: de live waarden Consuming en Returning kloppen, maar de grafiek loopt niet verder dan 9u57, de eerste start na de upgrade.

[allureGOT]

Heb je onderstaande regel in je Docker-compose staan? Probeer eens deze regel te commenten (#) en daarna te herstarten?

• /etc/localtime:/etc/localtime:ro

#2097

[TommiieeSV]

Heb je onderstaande regel in je Docker-compose staan? Probeer eens deze regel te commenten (#) en daarna te herstarten?

* /etc/localtime:/etc/localtime:ro

Dit lijkt te werken, de grafiek laat nu weer de actuele tijd zien en het aantal unprocessed readings neemt af!
Dankjewel voor de snelle hulp.

[niekniek89]

ik krijg alleen sinds de upgrade naar V6.0.1 de volgende error;

er worden dus geen backups meer gemaakt…
aan Backup pad oid is niets gewijzigd.
wellicht door dit?

UID: 803
GID: 1000

die had ik er voorheen niet in zitten

[allureGOT]

Je moeten even in de container kijken welke rechten er op je backup-folder liggen.

[xirixiz]

Eigenlijk meer op de host, de folder waarmee je de backup folder mount. Maar het heeft inderdaad wel met uid / gid te maken. Even rechttrekken op de folder en de container herstarten en dan werkt het weer.

[niekniek89]

Rechten op folder aangepast, container herstart…. En gelukt! Thanks

[htca]

Bij mij draait 6.0.1 ook inmiddels. Ik zag deze update pagina; moet je niet eerst de boel down brengen en na pullen weer up?

podman-compose down

podman-compose pull

podman-compose up -d

[dennissiemensma]

Je kunt op elk moment pullen, dat doet alleen wat met de basis images lokaal. Ik dacht dat podman-compose up -d zelf kijkt of er wijzigingen zijn.

Als dat niet zo is, kan ik het altijd nog bijwerken naar podman-compose up -d --force-recreate, dat werkt sowieso.

[dennissiemensma]

Dank allen voor jullie input, feedback, tijd en testbevindingen. Voor nu sluit ik deze en kan alle follow-up via nieuwe issues of discussions.

Deze is ook inmiddels dusdanig groot, dat het sowieso te onoverzichtelijk is geworden voor nieuwe issues hierbinnen. 😁