Op zaterdag 17 januari 2026 09:26:29 schreef rew:

[...]ZO "uiteraard" is dat niet. Mijn Landis & Gyr E350 stuurt dus 10x hetzelfde.

1768638426 (00.491*kW)
1768638436 (00.477*kW)
1768638446 (00.476*kW)
1768638456 (00.472*kW)
1768638466 (00.468*kW)
1768638476 (00.466*kW)
1768638486 (00.465*kW)
1768638496 (00.468*kW)
1768638506 (00.464*kW)
1768638516 (00.462*kW)
1768638526 (00.465*kW)
1768638536 (00.463*kW)
1768638546 (00.456*kW)
1768638556 (00.458*kW)
1768638566 (00.456*kW)
1768638576 (00.455*kW)
1768638587 (00.456*kW)

Hij zal om xxx7, xxx8 ook een datapakket sturen, maar nog nooit heb ik dan een andere waarde geregistreerd dan wat ik even eerder had.

Hmja, dat is niet helemaal de bedoeling van dat telegram per seconde natuurlijk, ik vraag me af of dat echt aan de standaard voldoet.

The information in the P1 telegram must be updated every second

Goed. Behalve dan dat ie niet meer naar Stedin maandelijks de stand doorgeeft, voldoet ie niet aan de standaard.

Ik verwacht dat als ik Stedin vraag hoe het met de DSMR 5.0 compatibiliteit zit, dat ze geen antwoord geven maar wel m'n meter komen vervangen.

Aangezien dat toch al gepland staat laat ik het er maar bij.

De vraag is trouwens wat er met "actueel vermogen" bedoeld wordt.

Wil je iedere seconde weten wat er gemiddeld de afgelopen seconde verbruikt is, of wil je de actuele waarde op de milliseconde dat het bericht aangemaakt wordt? Als je dat laatste doet, dan komt er een in bepaalde gevallen een "onverklaarbaar" verschil tussen het middelen/optellen van alle verbruiken van een zeg uur en de meterstanden.

Stel dat mijn computer iedere seconde een 0.9s in de "stress" schiet (100% CPU) van het verwerken van dat pakketje. Dan is het verbruik, synchroon met de pakketjes structureel hoger en registreert de meter op de kwh stand meer dan wat je zou denken als je de actuele verbruikwaardes optelt. Aangezien de meter ongeveer 2s per 24h "achterloopt" (met het sturen van de pakketjes, dus 86398 updates per dag ipv 86400), zou je als er een "iedere seconde" verbruik is een rare 6 uur lang meer, 6 uur lang minder oscilatie ontstaan als mijn computer niet syncroon met de pakketjes iedere seconde meer en minder zou verbruiken.

Kortom, ik ben van mening dat er goede argumenten zijn om niet echt het "acutele verbruik" maar het "vermogen gemiddeld over de afgelopen rapportageperiode" in "huidig vermogen" te rapporteren.

[Bericht gewijzigd door rew op (66%)]

Een "actueel vermogen" bestaat niet bij wisselspanning. Je zult *altijd* moeten uitmiddelen over minimaal 20ms

Misschien begrijp ik bovenstaande discussie niet goed, maar ik heb ook (nog) een L&G E350 maar daar komt toch echt 1 x per 10 sec een verse databurst uit de P1 poort, en niet 1 x per seconde en dan steeds 10 keer hetzelfde.

Op zaterdag 17 januari 2026 09:26:29 schreef rew:
[...]ZO "uiteraard" is dat niet. Mijn Landis & Gyr E350 stuurt dus 10x hetzelfde.

1768638426 (00.491*kW)
1768638436 (00.477*kW)
1768638446 (00.476*kW)
1768638456 (00.472*kW)
1768638466 (00.468*kW)
1768638476 (00.466*kW)
1768638486 (00.465*kW)
1768638496 (00.468*kW)
1768638506 (00.464*kW)
1768638516 (00.462*kW)
1768638526 (00.465*kW)
1768638536 (00.463*kW)
1768638546 (00.456*kW)
1768638556 (00.458*kW)
1768638566 (00.456*kW)
1768638576 (00.455*kW)
1768638587 (00.456*kW)

Hij zal om xxx7, xxx8 ook een datapakket sturen, maar nog nooit heb ik dan een andere waarde geregistreerd dan wat ik even eerder had.

....

Lees ik nou ergens helemaal overheen ofzo? Er zit toch 10 seconden tussen de datagrammen, en het varieert continu?

Ik moest ook 3x kijken, maar volgens mij zijn dit de telegrammen nadat ze gefilterd zijn, niet wat er direct uit de meter komt.

[Bericht gewijzigd door Sine op (18%)]

Nou mijn E350 geeft met 10sec interval data. Maar dat kan een kwestie van configuratie zijn of andere firmware of weetikveel.

Er is tenslotte 2-wegs communicatie tussen het beheerplatform en de meters.

Misschien heeft rew ooit aan de netbeheerder gevraagt om een 1 sec interval meter, en heeft hij dit als workaround gekregen? ?

Die E350 is een DSMR4.2 meter, dat is een oudere standaard met een 10s periode voor de telegrammen.

Het nieuwe spul is allemaal minimaal DSMR5, en dan krijg je iedere seconden een telegram, alleen lijkt dat ding van REW stiekem niet helemaal aan de standaard te voldoen. Je verwacht iedere seconde een uniek telegram, niet 10x eentje met dezelfde inhoud.

FYI: bij mij zijn de meters vandaag vervangen.
Ik maak gebruik van een kant en klare P1 module (had geen zin in gerommel in de meterkast): https://smartgateways.nl/product/slimme-meter-wifi-gateway/
Ik kreeg in eerste instantie geen informatie meer door; ook bijvoorbeeld niet de ID's van de meter.
Na updaten van de firmware naar NL DSMR4+5 deed ie het weer.
En ander voordeeltje: geen aparte voedingsadapter meer nodig.

Op dinsdag 20 januari 2026 08:39:14 schreef joopv:
Misschien heeft rew ooit aan de netbeheerder gevraagt om een 1 sec interval meter, en heeft hij dit als workaround gekregen? ?

Nee, deze meter zat in het gebouw toen ik het ongeveer een jaar geleden kocht. Het gebouw is uit 2018, dus ik vermoed dat na de bouw deze meter de eerste was.

Op dinsdag 20 januari 2026 00:02:33 schreef joopv:
Een "actueel vermogen" bestaat niet bij wisselspanning. Je zult *altijd* moeten uitmiddelen over minimaal 20ms

Mee eens! Maar de netbeheerders lijken de standaard voor de DSMR meters geschreven te hebben alsof 'actueel vermogen" een eenduidig begrip is. Dus nergens een specificatie over hoelang er gemiddeld moet worden.

Lees ik nou ergens helemaal overheen ofzo? Er zit toch 10 seconden tussen de datagrammen, en het varieert continu?

Mijn verwerkingsprogramma slaat de data alleen op als er een verschil is met het vorige datagram. Er zijn een hoop dingen die niet of nauwelijks veranderen. Zoals "actueel tarief" is iets wat haast 2x per dag verandert, maar niet meer. (5x per week van 2->1 en vv).

Als ik zou zeggen: "Actueel vermogen is alles wat ik interessant vind de rest gooi ik weg!" dan zul je zien dat ik een tijd later ineens ook de hoogst gemeten stroom wil weten. Om dan "oeps. tot nu toe niet opgeslagen" te voorkomen log ik dus alles, maar slechts alleen als het verandert. Zo heb ik dus maar een paar copieen van: "meter serie nummer" (iedere keer dat het programma start en die waarde voor het eerst ziet).

Van bijvoorbeeld de gas-meter zie je 3600 kopieen met precies dezelfde meterstand. Ook onzinnig om die 3600 keer op te slaan.

Ik heb een pico-W bij de meter die de boel van de meter ontvangt. Vervolgens stuurt ie een pakketje over TCPIP (UDP) naar de server waar een programmatje dat uit mekaar haalt, kijkt of het veranderd is en logt. Ik heb hierboven al doorgegeven dat er inderdaad iedere sec een pakketje van de pico-W komt.

Bouwjaar staat op de meter.

Nieuwe meters hebben een vervangbare communicatiemodule in/op de kWh-meter.
Bij het veranderen van het communicatieprotocol, hoeft de netbeheerder alleen deze module te vervangen en blijft het telwerk en de aansluitingen ongemoeid. Is een stuk goedkoper, en sneller uit te voeren.

Bij het oude type kWh-meter zal de gehele meter vervangen moeten worden.

Op vrijdag 23 januari 2026 16:13:35 schreef keebrev:
Bouwjaar staat op de meter.

Nieuwe meters hebben een vervangbare communicatiemodule in/op de kWh-meter.
Bij het veranderen van het communicatieprotocol, hoeft de netbeheerder alleen deze module te vervangen en blijft het telwerk en de aansluitingen ongemoeid. Is een stuk goedkoper, en sneller uit te voeren.

Bij het oude type kWh-meter zal de gehele meter vervangen moeten worden.

dat scheelt een hoop draden niet vastgezet of langs de klem gezet ellende.

De nieuwe heeft wel iedere seconde een nieuwe meting.

1770051691 (01.263*kW)
1770051692 (01.260*kW)
1770051693 (01.258*kW)
1770051694 (01.257*kW)
1770051695 (01.265*kW)
1770051697 (01.257*kW)
1770051700 (01.255*kW)
1770051702 (01.249*kW)

maar zoals je ziet, ook wel eens 2x achter mekaar precies dezelfde waarde zodat mijn logger niet dezelfde waarde nogmaals wegschrijft. (96, 98, 99 en 01 ontbreken).

Die van mij telt (nu nog) elke 10 sec de waarde op tot vijf minuten in 30 loops , vijf minuten en stuurt dat gemiddelde naar Pvoutput. Als het raportformaat niet afwijkt hoef ik alleen een vertraging van 10 sec op te nemen in het python script.