Nieuwe KWh meter Liander in Hilversum-Noord

Mijn gasmeter geeft wel elke 10 minuten een update. Ik krijg elke seconde een nieuw P1 bericht met daarin telkens de gas-stand van de laatste 10 minuten, compleet met timestamp:

260117101500W, 2975.829
260117102500W, 2975.829
260117103500W, 2975.948
260117104500W, 2976.117
260117105500W, 2976.195
260117110500W, 2976.278

Op vrijdag 16 januari 2026 22:37:00 schreef RP6conrad:
Ik heb een recente slimme meter, elke 1 sek komt er een P1 telegram. Gas en watermeter zijn gekoppeld, hier worden de data elke 5 min geupdatet. Telegram in bijlage (opgelet, situatie Belgie).

Hmm, in Belgie bevat het telegram kennelijk andere velden. Parser zegt invalid telegram.

Die parser leest het aantal regels. Afhankelijk wat er aan de smartmeter is gekoppeld aan gas, water, warmte meters is die dus korter of langer, lijkt mij.

Als het telegram dan dus te kort of te lang is, keurt de parser het af.

Op zaterdag 17 januari 2026 12:25:04 schreef deKees:
Mijn gasmeter geeft wel elke 10 minuten een update. Ik krijg elke seconde een nieuw P1 bericht met daarin telkens de gas-stand van de laatste 10 minuten, compleet met timestamp:

Goh, waar ik sine corrigeer dat sommige meters toch echt iedere seconde data sturen, maar de metingen slechts 1x per 10 sec updaten... had ik het fout dat gasmeters slechts ieder uur een update sturen. Ook dat kan kennelijk varieren! Nooit te oud om te leren.

@eerder bericht van deKees, Ik had ooit een DSMR 4.2 (?) meter die niet volgens de standaard op 115k2 P1 data uitstuurde maar op een lagere baudrate. De netbeheerder gevraagd hoe dat kwam en of dat normaal was. Nooit antwoord op gehad. Twee weken later had ik een nieuwe meter.

[Bericht gewijzigd door rew op (21%)]

Op zaterdag 17 januari 2026 14:11:48 schreef harry64:
Die parser leest het aantal regels. Afhankelijk wat er aan de smartmeter is gekoppeld aan gas, water, warmte meters is die dus korter of langer, lijkt mij.

Als het telegram dan dus te kort of te lang is, keurt de parser het af.

Nee, er ontbrak een laatste "\n\r" achter het crc veld. Dit is de output met @RP6conrad zijn Belgische P1 telegram, de onbekende velden geven de "Error while parsing" meldingen (en hier wel stroom met decimalen):


Possible telegram found at offset 0
Possible telegram end at offset 1204
New-style telegram with length 1210
Header: LGF5E360
Error while parsing
Error while parsing
Equipment ID: 1LGZ0584051959
Error while parsing
Time: 125 9 25 10 49 34 1
Timestamp: 1761382174
Energy in, tariff 1: 34.162000 kWh
Energy in, tariff 2: 7.920000 kWh
Energy out, tariff 1: 11.254000 kWh
Energy out, tariff 2: 0.036000 kWh
Tariff: 2
Error while parsing
Error while parsing
Error while parsing
Power in: 2.110000 kW
Power out: 0.000000 kW
Power in L1: 0.000000 kW
Power in L2: 0.000000 kW
Power in L3: 0.000000 kW
Power out L1: 0.000000 kW
Power out L2: 0.000000 kW
Power out L3: 0.000000 kW
Voltage L1: 231.800000 V
Voltage L2: 0.000000 V
Voltage L3: 230.100000 V
Current L1: 9.310000 A
Current L2: 0.000000 A
Current L3: 9.320000 A
Switch position: 1
Power threshold: 99.999000 kW
Error while parsing
Error while parsing
Error while parsing
Error while parsing
Error while parsing
Device 1 type: 7
Error while parsing
Error while parsing
Time: 125 9 25 10 47 0 1
Device 1 counter at 1761382020: 21.437000 m3
Device 2 type: 3
Error while parsing
Error while parsing
Device 2 valve position: 1
Error while parsing
CRC: 0xf2d0
Parsing successful, data CRC 0xf2d0, telegram CRC 0xf2d0
ERROR: Parse errors: 16

Typisch voor Belgie zijn de kwart uur pieken, de actuele piek en de hoogst gemeten maandpiek + timestamp. DEze worden in elk telegram gezet. Bij de water en gas standen wordt ook telkens een timestamp meegegeven. In bijlage mijn python code om te parsen. Bovenaan kan je de OBIS lijst aanvullen met andere codes. Hier loopt dat op een raspberry, via MQTT worden deze dan verder verwerkt.

Op zaterdag 17 januari 2026 17:46:51 schreef PE9SMS:
[...]Nee, er ontbrak een laatste "\n\r" achter het crc veld. Dit is de output met @RP6conrad zijn Belgische P1 telegram, de onbekende velden geven de "Error while parsing" meldingen (en hier wel stroom met decimalen):


...
Equipment ID: 1LGZ0584051959
Error while parsing
Time: 125 9 25 10 49 34 1

Geinig! Je hebt een belgische driefase met 230V tussen de fasen. Je hebt een driefase meter waarbij ze de nul van de meter aan L2 hebben gehangen. En op het moment van de meting trek je 9.32A van L1 naar L3 en niets anders! Het kan zijn dat je installatie "1 fase" is.

Tip voor de programmeur:
1) Die "parse error" is een vervelende: Zorg dat je in dat geval ook de input die de fout veroorzaakt print.
2) Mijn programma om dit te parsen, die ziet gewoon x.y:z.a.b en kijkt dan naar de waarde die doorgegeven wordt. En hij heeft een tabel met x.y.... waardes als "alias". 1-0:1.7.0 huidig_verbruik . En als ie iets tegen komt wat ie niet kent dan archiveert hij gewoon de gelezen text onder 1-0:1.7.0 .

Ik heb nog een huisaansluiting van 2*115 VAC, dus geen nulleider. Dit is in Belgie nog steeds gangbaar in sommige plaatsen. De meter is een 3 fasen meter, waar dus 2 fasen van worden gebruikt.

Op zaterdag 17 januari 2026 16:42:55 schreef rew:
[...]
@eerder bericht van deKees, Ik had ooit een DSMR 4.2 (?) meter die niet volgens de standaard op 115k2 P1 data uitstuurde maar op een lagere baudrate. De netbeheerder gevraagd hoe dat kwam en of dat normaal was. Nooit antwoord op gehad. Twee weken later had ik een nieuwe meter.

Als dat zo snel gedaan werd, was ie misschien hackable. :)

Mwah. Mijn theorie is dat ze tegenwoordig gewoon voor iedere scheet de meter komen vervangen. Vervolgens nemen ze de oude in, meten hem na en zetten hem dan mogelijk ergens anders weer in.

Dan was het eenvoudiger geweest om de 2G voor een 4G module te vervangen.

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.

Going down now. Laterzzz. :P

Wast ik weer. Plaatsen ging niet door want gasmeter past niet. :P