Slimme meter uitlezen via P1-poort

[mcmd]

Raven schreef op vrijdag 11 oktober 2024 @ 06:21:
[...]

3 stopcontacten zoeken die elk op een andere fase zitten en daar dan slimme stekkers met spanningsmeting in doen?

Mijn slimme meter geeft deze informatie door iedere seconde.

[True]

mcmd schreef op dinsdag 10 december 2024 @ 16:36:
[...]

Mijn slimme meter geeft deze informatie door iedere seconde.

Ja, maar die hele discussie ging niet over DSMR 5 die dat heeft maar DSMR 4.2 die dat niet doet ..

[RichieB]

Ik lees mijn Landis + Gyr al jaren uit met DSMR-Reader. Nu heeft mijn dochter een nieuw appartement met Kaifa MA105A meter. Ik heb vandaag een paar uur gespendeerd om daar data uit de p1 poort te krijgen (met een QNAP NAS). Ik heb 2 verschillende kabels gebruikt. Met 1 kabel heb ik welgeteld 3 telegrammen eruit kunnen krijgen (daar zaten uren tussen) maar meestal krijg ik helemaal niets. Ik gebruik de DSMR-reader datalogger maar daarin zal het probleem niet zitten. Hetzelfde issue (compleet geen data) treedt op met:

code:

sudo python3 -m serial.tools.miniterm /dev/ttyUSB0 115200 --xonxoff

Een van de telegrammen die ik wel kreeg:

code:

/KFM5KAIFA-METER

1-3:0.2.8(42)
0-0:1.0.0(250103230146W)
0-0:96.1.1(4530303237303030303032313735323135)
1-0:1.8.1(009830.195*kWh)
1-0:1.8.2(008263.144*kWh)
1-0:2.8.1(000000.000*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.059*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00011)
0-0:96.7.9(00008)
1-0:99.97.0(2)(0-0:96.7.19)(170117074229W)(0000012192*s)(000101000001W)(2147483647*s)
1-0:32.32.0(00000)
1-0:32.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
1-0:31.7.0(000*A)
1-0:21.7.0(00.059*kW)
1-0:22.7.0(00.000*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303139333430323338333534303135)
0-1:24.2.1(250103220000W)(01162.444*m3)

Wat ik eigenlijk zoek is validatie van deze conclusies die ik heb getrokken:

1. Ik gebruik de juiste kabel, want ik krijg (sporadisch) een telegram te zien
2. De p1-poort van de Kaifa meter functioneert (af en toe)
3. Of de kabel is brak of de Kaifa meter is brak, want ik krijg geen telegrammen elke X seconden

Zie ik iets over het hoofd? Kan ik nog iets anders proberen?

[Raven]

@RichieB Is dat het hele telegram? Daar mist wat

Welke kabels heb je gebruikt? Bij deze meter moet de data volgens mij geïnverteerd worden, al verklaard dat het zo nu en dan wel krijgen van een (incompleet) telegram niet.

[ Voor 21% gewijzigd door Raven op 04-01-2025 09:38 ]

[habbekrats]

@RichieB Is een oudje dsmr 4.05 op mijn eerste meter had ik een gelijk schema als hier https://willem.aandewiel....v4-slimme-meter-uitlezer/



bij sommige merken moet de datalijn met een pull up hoog gehouden worden. pin 5 tx-sm


daarna zou het met putty elke 10 seconden moeten lukken 115200 8n1

[RichieB]

@habbekrats Bedankt voor je antwoord, maar ik gebruik geen WeMos maar een P1-USB kabel die door Linux wordt herkend als FT232RL. Kan ik in die kabel een modificatie doen om dit probleem op te lossen?

Is het niet vreemd dat zonder modificatie ik toch een paar telegrammen correct heb kunnen ontvangen?

code:

[  216.839704] usbcore: registered new interface driver usbserial
[  216.844314] usbserial: USB Serial Driver core
[  216.864830] usbcore: registered new interface driver ftdi_sio
[  216.871284] USB Serial support registered for FTDI USB Serial Device
[  216.876293] ftdi_sio 6-2:1.0: FTDI USB Serial Device converter detected
[  216.881643] usb 6-2: Detected FT232RL
[  216.886594] usb 6-2: Number of endpoints 2
[  216.891363] usb 6-2: Endpoint 1 MaxPacketSize 64
[  216.896082] usb 6-2: Endpoint 2 MaxPacketSize 64
[  216.900726] usb 6-2: Setting MaxPacketSize 64
[  216.908128] usb 6-2: FTDI USB Serial Device converter now attached to ttyUSB0
[  216.913039] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

[RichieB]

Raven schreef op zaterdag 4 januari 2025 @ 09:38:
@RichieB Is dat het hele telegram? Daar mist wat

Ja, dit is alles. Als ik even google dan zie ik dat ik wellicht "0-1:24.4.0" (VALVE_POSITION_GAS) mis, maar misschien produceert mijn meter die gewoon niet..

Welke kabels heb je gebruikt? Bij deze meter moet de data volgens mij geïnverteerd worden, al verklaard dat het zo nu en dan wel krijgen van een (incompleet) telegram niet.

Gewoon een P1-USB kabel van Marktplaats die zich identificeert als FT232RL / FTDI, zie hier boven.

[iMars]

habbekrats schreef op zaterdag 4 januari 2025 @ 10:51:
@RichieB Is een oudje dsmr 4.05 op mijn eerste meter had ik een gelijk schema als hier https://willem.aandewiel....v4-slimme-meter-uitlezer/

[Afbeelding]

bij sommige merken moet de datalijn met een pull up hoog gehouden worden. pin 5 tx-sm
[Afbeelding]

daarna zou het met putty elke 10 seconden moeten lukken 115200 8n1

De dataline moet eigenlijk altijd met een pull-up weerstand hoog gehouden worden. De P1 poort is een open collector aansluiting. Soms werkt het zonder de pull-up, maar netjes is het niet.

[Raven]

RichieB schreef op zaterdag 4 januari 2025 @ 17:03:
[...]

Ja, dit is alles. Als ik even google dan zie ik dat ik wellicht "0-1:24.4.0" (VALVE_POSITION_GAS) mis, maar misschien produceert mijn meter die gewoon niet..

De checksum hoort er ook nog bij, daarmee kun je controleren of het telegram niet corrupt is.

[iMars]

Raven schreef op zaterdag 4 januari 2025 @ 17:19:
[...]

De checksum hoort er ook nog bij, daarmee kun je controleren of het telegram niet corrupt is.

Inderdaad, als de data corrupt is, komt het niet door de CRC check en zal je dus geen telegrammen zien verschijnen.

Wat je kan proberen @RichieB is om met putty of andere terminal programma even de seriele poort te openen. Zie je daar data voorbij komen, weet je dat het kabeltje werkt, maar dat de data corrupt is (gebeurd vrij vaak, in zo'n geval kan je een andere meter aanvragen). Krijg je geen data binnen, kijk dan of je kabel een pullup weerstand heeft als deze (ff opgezocht met google, niet mijn foto):

[RichieB]

@iMars Ik krijg met Python miniterm ook geen data binnen. Ik had gelezen dat de checksum (de regel die begint met !) optioneel is en dat niet alle meters die meesturen.

Bedankt voor het plaatje met de pull-up weerstand. Ik zal zo mijn soldeerbout opwarmen.

[Raven]

@RichieB De enige keer dat ik die niet zag was toen er een niet-slimme digitale meter met
Wikipedia: IEC 62056 interface hier hing, die eindigde wel elk telegram met "!" maar geen checksum. Slimme doen dat volgens mij wel altijd met checksum.

[RichieB]

@iMars Ik heb mijn kabel opgemaakt, had mijn soldeerbout en 1K weerstand gereed.... zit er al eentje in.

Wat nu? Moet ik de weerstand juist verwijderen? Of is dat onzin?

[ZwarteIJsvogel]

Die weerstand hoort daar (de P1 Data uitgang is open collector).

Waarom gebruik je eigenlijk "--xonxoff" (behalve copy/paste)? Bij jouw kabel hangt de P1 Data_Request ingang via de rode draad hard aan +5V en is dus geen enkele vorm van flow control van toepassing.

Je wilt ook geen last hebben van karakter encondings en andere transformaties. Gebruik "--raw" om dat te verhinderen.

Kun je wel telegrammen ontvangen buiten python om? Dit is mijn scriptje om P1-data naar stdout te sturen:

code:

#!/bin/bash
PORT=/dev/ttyUSB0

stty -F $PORT raw speed 115200 >/dev/null
cat $PORT

[iMars]

ZwarteIJsvogel schreef op woensdag 8 januari 2025 @ 09:11:
Die weerstand hoort daar (de P1 Data uitgang is open collector).

Waarom gebruik je eigenlijk "--xonxoff" (behalve copy/paste)? Bij jouw kabel hangt de P1 Data_Request ingang via de rode draad hard aan +5V en is dus geen enkele vorm van flow control van toepassing.

Je wilt ook geen last hebben van karakter encondings en andere transformaties. Gebruik "--raw" om dat te verhinderen.

Kun je wel telegrammen ontvangen buiten python om? Dit is mijn scriptje om P1-data naar stdout te sturen:

code:

#!/bin/bash
PORT=/dev/ttyUSB0

stty -F $PORT raw speed 115200 >/dev/null
cat $PORT

@RichieB wat @ZwarteIJsvogel zegt,... de weerstand hoort daar omdat alle meters een open collector aansluiting hebben (optcocoupler voor galvanische scheiding). Wat ik ook al eerder zei, probeer via terminal/cli/putty/whatever even de usb-serialport uit te lezen. Kans is groot dat de kabel gewoon werkt, maar dat je meter corrupte data uitspuugd...

[Septillion]

@RichieB Helemaal eens met @iMars, gebruik gewoon eens een terminal programma om zaken uit te sluiten.

Maar ik zit nog even te kijken, is data_request (pin2) wel aangesloten? Want ik zie maar 3 verbonden draden en de 4e groene hangt los. Dus zit deze verbinding nog ergens anders / staat er werkelijk netjes 5V op die lijn?

[iMars]

Septillion schreef op woensdag 8 januari 2025 @ 11:08:
@RichieB Helemaal eens met @iMars, gebruik gewoon eens een terminal programma om zaken uit te sluiten.

Maar ik zit nog even te kijken, is data_request (pin2) wel aangesloten? Want ik zie maar 3 verbonden draden en de 4e groene hangt los. Dus zit deze verbinding nog ergens anders / staat er werkelijk netjes 5V op die lijn?

3 draden is voldoende, je maakt immers geen gebruik van de voeding uit de P1 poort, de USB poort geeft al 5v.

Als de 5v van de USB naar pin 2, Ground naar pin 3 (of 6) en data naar pin 5 van je RJ12 (p1 poort) gaat, is al voldoende

[Septillion]

@iMars Correct, maar mijn punt is dus dat ik na zou kijken of dat goed zit.

[iMars]

Septillion schreef op woensdag 8 januari 2025 @ 11:41:
@iMars Correct, maar mijn punt is dus dat ik na zou kijken of dat goed zit.

Uiteraard Ik neem de aanname (assumption is the MTF) dat dat wel goed zit, hij heeft er immers een paar goede telegrammen ermee kunnen lezen: RichieB in "Slimme meter uitlezen via P1-poort"

Alles bij elkaar gezien, is mijn huidige gok dat de data corrupt is en dat er daarom maar 3 goede telegrammen doorheen kwam en heul veul niet.

Dus @RichieB : check de output even

[Septillion]

@iMars Ja, dat zou ook goed kunnen. Maar als de DR niet goed verbinding maakt zou het dus ook onregelmatig kunnen zijn.

En had DSMR 4.0 al 5v?

[The Zep Man]

RichieB schreef op vrijdag 3 januari 2025 @ 23:51:
Ik lees mijn Landis + Gyr al jaren uit met DSMR-Reader. Nu heeft mijn dochter een nieuw appartement met Kaifa MA105A meter.

Ik heb geen ervaring met die meter, maar kwam dit tegen op AliExpress. Niet om jou die kabel te laten kopen, maar om de tekst in de omschrijving (die van elders geript is, waar kan ik zo even niet vinden in Google):

The P1 port is a RJ11/RJ12 port, using the following pin out:

I grabbed an old modem cable, with RJ11/RJ12 plug and then I connected the appropriate pins to a modern devices USB-BUB. This device provides all the pins required. The request pin, as described above must be kept “HIGH” to retrieve data (i.e. provide 5V all the time). So I connected the request pin to the USb-BUB 5V. The other pins are DATA for the output, which I connected to the RX pin of the USB-BUB and GND which I obviously connected to the USB-BUB’s ground. This is a temporary solution until I get a proper 5V FTDI cable.

Note: to connect to the serial port, you need special port settings: 7 data bits (instead of the more regular 8 ) with even parity at 9600 baud.

Software

The P1 port uses a reversed serial protocol (1=0 and 0=1), to get this to work with a FTDI chip (this chip is used on the USB-BUB) you need to reverse the RX pin. Luckily FTDI provides a tool known as FT_PROG to do this. on the domoticaforum for figuring this one out. Here is a screenshot which shows you how to make the inverse RX setting in FT_PROG:

Dit betreft ook een FTDI chip. Mogelijk heb je wat aan deze informatie. Zo niet, er worden (ook in Nederlandse webwinkels) kabels verkocht voor deze specifieke meter. Wellicht brengt dat nog een oplossing (en anders terugsturen en geld terugkrijgen).

[hterhofte]

Septillion schreef op woensdag 8 januari 2025 @ 11:50:
@iMars Ja, dat zou ook goed kunnen. Maar als de DR niet goed verbinding maakt zou het dus ook onregelmatig kunnen zijn.

En had DSMR 4.0 al 5v?

Ja, zie ook hterhofte in "Zelfbouw Laadpaal ervaringen" met daarin een link naar een overzicht van dit soort specs van de verschillende versies en ook een overzicht van de inmiddels meer dan 90 verschillende soorten slimme meters die in Nederland zijn uitgerold.

[iMars]

hterhofte schreef op woensdag 8 januari 2025 @ 14:37:
[...]

Ja, zie ook hterhofte in "Zelfbouw Laadpaal ervaringen" met daarin een link naar een overzicht van dit soort specs van de verschillende versies en ook een overzicht van de inmiddels meer dan 90 verschillende soorten slimme meters die in Nederland zijn uitgerold.

Ja, die specs kan ik bijna dromen
DSMR 2/3 : 9600 7E1 en geen 5v
DSMR 4 : 115200 8N1 en 5v/100mA
DSMR 5 : 115200 8N1 en 5v/250mA

En het vermogen wat ze kunnen leveren is ook een specificatie, en geen garantie Genoeg DSMR 5 meters die moeite hebben met simpele esp8266 te voeden (mijn ethernet reader werkt op een DSMR 4 meter, maar de bekende ZIV meters, DSMR 5, vertikt het...)

[RichieB]

ZwarteIJsvogel schreef op woensdag 8 januari 2025 @ 09:11:
Die weerstand hoort daar (de P1 Data uitgang is open collector).

Check, ik laat de weerstand zitten.

Waarom gebruik je eigenlijk "--xonxoff" (behalve copy/paste)? Bij jouw kabel hangt de P1 Data_Request ingang via de rode draad hard aan +5V en is dus geen enkele vorm van flow control van toepassing.

Ok, dan is de "--xonxoff" waarschijnlijk nutteloos. Dit zat in een voorbeeld dat ik ergens tegen kwam. Met of zonder maakt voor mij niets uit.

[...]
Kun je wel telegrammen ontvangen buiten python om? Dit is mijn scriptje om P1-data naar stdout te sturen:

code:

#!/bin/bash
PORT=/dev/ttyUSB0

stty -F $PORT raw speed 115200 >/dev/null
cat $PORT

Dank! "stty" staat wel op de NAS. Helaas geeft dit script bij mij helemaal geen output, hetzelfde resultaat als met python dus.

[RichieB]

iMars schreef op woensdag 8 januari 2025 @ 11:03:
[...]
Wat ik ook al eerder zei, probeer via terminal/cli/putty/whatever even de usb-serialport uit te lezen. Kans is groot dat de kabel gewoon werkt, maar dat je meter corrupte data uitspuugd...

Nee, helaas. Wat ik ook probeer, de P1 poort geeft helemaal geen output.. behalve die paar telegrammen vorige week dan..

[RichieB]

iMars schreef op woensdag 8 januari 2025 @ 11:48:
[...]

Alles bij elkaar gezien, is mijn huidige gok dat de data corrupt is en dat er daarom maar 3 goede telegrammen doorheen kwam en heul veul niet.

Alle tests die ik tot nu toe gedaan heb (met python en met stty) doen helemaal geen error controle, gewoon data lezen en printen. Er wordt dus nergens iets gefilterd.

Dus @RichieB : check de output even

Helaas, er is geen enkele output.

[RichieB]

The Zep Man schreef op woensdag 8 januari 2025 @ 14:03:
[...]
Ik heb geen ervaring met die meter, maar kwam dit tegen op AliExpress. Niet om jou die kabel te laten kopen, maar om de tekst in de omschrijving (die van elders geript is, waar kan ik zo even niet vinden in Google):
[...]

Hah, ik had dezelfde gedachte en heb deze vergelijkbare al besteld in de kleur "Kaifa MA105A". Als dit ook niet werkt ga ik klagen bij Liander want dan verdenk ik toch echt de meter.

[RichieB]

Ik denk nu echt dat de P1 poort van mijn meter kapot is. Na uren wachten krijg ik er troep uit met het script van @ZwarteIJsvogel :

code:

$ ./test-p1.sh
/TER

-3:0.2.8(42)0-0:1.0.0(250108165918W)0-0:90323730303033231351851.819*kWh)
-0:1.8.2(00)
-0:2.8.1(000000.000*kWh)
�J���������������������

Zoals @iMars dus hier al zegt: de data is corrupt. Is dit genoeg reden om een nieuwe meter te krijgen?

[ Voor 20% gewijzigd door RichieB op 08-01-2025 19:09 ]

[Martin7182]

RichieB schreef op woensdag 8 januari 2025 @ 19:07:
Ik denk nu echt dat de P1 poort van mijn meter kapot is. Na uren wachten krijg ik er troep uit met het script van @ZwarteIJsvogel :

code:

$ ./test-p1.sh
/TER

-3:0.2.8(42)0-0:1.0.0(250108165918W)0-0:90323730303033231351851.819*kWh)
-0:1.8.2(00)
-0:2.8.1(000000.000*kWh)
�J���������������������

Zoals @iMars dus hier al zegt: de data is corrupt. Is dit genoeg reden om een nieuwe meter te krijgen?

Ik zou eerst een goed werkende P1 meter van een ander even proberen (inclusief alle hardware). Ik heb wel eens corrupte data gekregen omdat ik per ongeluk een slechte voedingsadapter gebruikt had.

[RichieB]

Martin7182 schreef op woensdag 8 januari 2025 @ 19:29:
[...]

Ik zou eerst een goed werkende P1 meter van een ander even proberen (inclusief alle hardware). Ik heb wel eens corrupte data gekregen omdat ik per ongeluk een slechte voedingsadapter gebruikt had.

Euh, hij hangt aan de USB poort van een QNAP NAS met 4 draaiende schijven er in. Die voeding werkt prima. Ik zal de volgende keer voor de zekerheid de P1 poort ook proberen uit te lezen met m'n MacBook om echt alles uit te sluiten.

[iMars]

RichieB schreef op woensdag 8 januari 2025 @ 19:07:
Ik denk nu echt dat de P1 poort van mijn meter kapot is. Na uren wachten krijg ik er troep uit met het script van @ZwarteIJsvogel :

code:

$ ./test-p1.sh
/TER

-3:0.2.8(42)0-0:1.0.0(250108165918W)0-0:90323730303033231351851.819*kWh)
-0:1.8.2(00)
-0:2.8.1(000000.000*kWh)
�J���������������������

Zoals @iMars dus hier al zegt: de data is corrupt. Is dit genoeg reden om een nieuwe meter te krijgen?

Test de kabel op een andere meter (buren, vrienden, familie, etc). Als je meter geen goede data geeft (zo te zien bij jou en corrupt en inconsistent) is dat inderdaad een goede reden. Maar als het blijkt dat het de kabel is en ze komen voor niks omdat de meter wel goed is, kunnen ze voorrijkosten e.d. in rekening brengen.

Als de kabel van jij op een andere meter het wel doet, en bij jou niet, kan je er aardig zeker van zijn dat het inderdaad je meter is die raar doet.

[iMars]

RichieB schreef op woensdag 8 januari 2025 @ 20:46:
[...]

Euh, hij hangt aan de USB poort van een QNAP NAS met 4 draaiende schijven er in. Die voeding werkt prima. Ik zal de volgende keer voor de zekerheid de P1 poort ook proberen uit te lezen met m'n MacBook om echt alles uit te sluiten.

Sluit ook je eigen meter uit, door het op een andere meter aan te sluiten zoals ik in mijn eerder bericht zei

[RichieB]

Met de P1 kabel van Ali had ik dezelfde problemen, maar op mijn MacBook met CoolTerm deed alles het prima. Er moest dus iets aan de hand zijn op de NAS. Ik had al met fuser en lsof gekeken of er een ander proces /dev/ttyUSB0 gebruikte. Daarmee had ik niets gevonden. Nu heb wat verder gezocht en ik vond hier een hint dat USB id 0403:6001 (de FTDI FT232 USB-Serial kabel heeft dat USB id) op een QNAP NAS gebruikt wordt door de /sbin/ups_yec UPS tool. Uiteindelijk vond ik hier de manier om die uit te schakelen:

code:

/sbin/daemon_mgr ups_yec stop "/sbin/ups_yec" &
rm /sbin/ups_yec

Daarna werkte het test script en DSMR-Reader als een zonnetje!

[KingDurk]

Vraagje. Ik heb een esp-p1 meter waarmee ik de meter uitlees. Via de dsmr integratie heb ik de data in home assistant.

Ik zou zeggen dat er geen verdere internetconnectie nodig is want de data is lokaal. Toch als ik het internet blokkeer via de router voor de p1 meter krijg ik geen data meer binnen. Maak ik een denkfout? Of kan ik het ergens in de settings aanpassen? Ik kan de esp meter nog wel gewoon benaderen via ip.

[iMars]

KingDurk schreef op maandag 3 februari 2025 @ 15:54:
Vraagje. Ik heb een esp-p1 meter waarmee ik de meter uitlees. Via de dsmr integratie heb ik de data in home assistant.

Ik zou zeggen dat er geen verdere internetconnectie nodig is want de data is lokaal. Toch als ik het internet blokkeer via de router voor de p1 meter krijg ik geen data meer binnen. Maak ik een denkfout? Of kan ik het ergens in de settings aanpassen? Ik kan de esp meter nog wel gewoon benaderen via ip.

Het eerste waar ik aan denk (kan natuurlijk niet vanaf hier jouw situatie zien ) is dat je meer blokkeert dan internet. Heb je apparte vlans? En zit P1 in een andere vlan dan HA?

[duckmountain]

Na één en ander gelezen te hebben wil ik jullie mijn code voor ESP32 niet onthouden.
Hij is supersnel, ongeveer 120 milliseconde.
CRC controle zit erin verwerkt.

C++:

#include "crc16.h"  // uit de DSRM library 
#include <driver/uart.h>

// Configuratie constanten
#define P1_UART_NUM UART_NUM_2
#define P1_UART_RX_PIN 16
#define P1_UART_TX_PIN 17
#define P1_UART_BAUD 115200
#define P1_TELEGRAM_BUFFER_SIZE 2048 // Vergroot naar 2KB voor veiligheid
#define P1_START_CHAR '/'
#define P1_END_CHAR '!'
#define P1_CRC_LENGTH 4
#define P1_MAX_TIMEOUT 5000
#define P1_MAX_TELEGRAM_SIZE 1024 // Maximum grootte van één telegram

// Circulaire buffer implementatie
class CircularBuffer {
   private:
     uint8_t *buffer;
     size_t capacity;
     size_t readIndex;
     size_t writeIndex;
     size_t count;

   public:
     CircularBuffer(size_t size)
         : capacity(size), readIndex(0), writeIndex(0), count(0) {
          buffer = new uint8_t[size];
     }

     ~CircularBuffer() { delete[] buffer; }

     size_t available() const { return count; }

     size_t freeSpace() const { return capacity - count; }

     bool write(const uint8_t *data, size_t length) {
          if (length > freeSpace())
               return false;

          for (size_t i = 0; i < length; i++) {
               buffer[writeIndex] = data[i];
               writeIndex = (writeIndex + 1) % capacity;
          }
          count += length;
          return true;
     }

     size_t read(uint8_t *data, size_t length) {
          length = (length < count) ? length : count;
          for (size_t i = 0; i < length; i++) {
               data[i] = buffer[readIndex];
               readIndex = (readIndex + 1) % capacity;
          }
          count -= length;
          return length;
     }

     void clear() { readIndex = writeIndex = count = 0; }

     bool findPattern(const uint8_t *pattern, size_t patternLength,
                      size_t &position) {
          for (size_t i = 0; i < count; i++) {
               size_t pos = (readIndex + i) % capacity;
               bool found = true;
               for (size_t j = 0; j < patternLength && found; j++) {
                    if (buffer[(pos + j) % capacity] != pattern[j]) {
                         found = false;
                    }
               }
               if (found) {
                    position = i;
                    return true;
               }
          }
          return false;
     }
};

// Globale variabelen
CircularBuffer rxBuffer(P1_TELEGRAM_BUFFER_SIZE);
unsigned long lastValidTelegram = 0;

enum TelegramStatus {
     TELEGRAM_OK,
     TELEGRAM_NO_START,
     TELEGRAM_NO_END,
     TELEGRAM_INCOMPLETE,
     TELEGRAM_TIMEOUT,
     TELEGRAM_BUFFER_OVERFLOW,
     TELEGRAM_CRC_ERROR
};

// Helper template voor veilige min operatie
template <typename T, typename U> T safe_min(T a, U b) {
     return (a < static_cast<T>(b)) ? a : static_cast<T>(b);
}

// CRC functies
uint16_t hexStringToUint16(const char *hexStr) {
     uint16_t value = 0;
     sscanf(hexStr, "%4hx", &value);
     return value;
}

uint16_t calculateCRC16(const uint8_t *data, size_t length) {
     uint16_t crc = 0;
     for (size_t i = 0; i < length; i++) {
          crc = _crc16_update(crc, data[i]);
     }
     return crc;
}

bool validateCRC(const uint8_t *telegram, size_t length) {
     if (length < P1_CRC_LENGTH + 1)
          return false;

     char crcStr[5];
     memcpy(crcStr, telegram + length - P1_CRC_LENGTH, P1_CRC_LENGTH);
     crcStr[4] = '\0';

     uint16_t receivedCRC = hexStringToUint16(crcStr);
     uint16_t calculatedCRC = calculateCRC16(telegram, length - P1_CRC_LENGTH);

     return receivedCRC == calculatedCRC;
}

void setupP1UartDMA() {
     uart_config_t uart_config = {.baud_rate = P1_UART_BAUD,
                                  .data_bits = UART_DATA_8_BITS,
                                  .parity = UART_PARITY_DISABLE,
                                  .stop_bits = UART_STOP_BITS_1,
                                  .flow_ctrl = UART_HW_FLOWCTRL_DISABLE};

     // Reset UART voor een schone start
     uart_driver_delete(P1_UART_NUM);

     if (uart_driver_install(P1_UART_NUM, P1_TELEGRAM_BUFFER_SIZE * 2, 0, 0,
                             NULL, 0) != ESP_OK) {
          Serial.println("UART driver installatie mislukt!");
          return;
     }

     if (uart_param_config(P1_UART_NUM, &uart_config) != ESP_OK) {
          Serial.println("UART configuratie mislukt!");
          return;
     }

     if (uart_set_pin(P1_UART_NUM, P1_UART_TX_PIN, P1_UART_RX_PIN,
                      UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE) != ESP_OK) {
          Serial.println("UART pin configuratie mislukt!");
          return;
     }
     // Voeg deze regel toe voor invertering:
     uart_set_line_inverse(P1_UART_NUM, UART_SIGNAL_RXD_INV);
     uart_flush(P1_UART_NUM);
}

TelegramStatus processP1Telegram() {
     static uint8_t tempBuffer[P1_MAX_TELEGRAM_SIZE];
     size_t startPos = 0;
     TelegramStatus result = TELEGRAM_NO_START;

     // Zoek start character
     uint8_t startPattern[] = {P1_START_CHAR};
     if (!rxBuffer.findPattern(startPattern, 1, startPos)) {
          return TELEGRAM_NO_START;
     }

     // Lees data tot aan start character
     if (startPos > 0) {
          rxBuffer.read(tempBuffer, startPos);
     }

     // Zoek end character en CRC
     size_t available = rxBuffer.available();
     size_t endPos = 0;
     bool foundEnd = false;

     for (size_t i = 0; i < available && endPos < P1_MAX_TELEGRAM_SIZE; i++) {
          uint8_t byte;
          rxBuffer.read(&byte, 1);
          tempBuffer[endPos++] = byte;

          if (byte == P1_END_CHAR) {
               if (i + P1_CRC_LENGTH < available) {
                    // Lees CRC
                    rxBuffer.read(&tempBuffer[endPos], P1_CRC_LENGTH);
                    endPos += P1_CRC_LENGTH;
                    foundEnd = true;
                    break;
               }
          }
     }

     if (!foundEnd) {
          return TELEGRAM_INCOMPLETE;
     }

     // Valideer CRC
     if (!validateCRC(tempBuffer, endPos)) {
          Serial.println("CRC validatie mislukt");
          return TELEGRAM_CRC_ERROR;
     }

     // Verwerk geldig telegram
     Serial.println("Geldig telegram ontvangen:");
     Serial.write(tempBuffer, endPos);
     Serial.println();
     Serial.println();

     lastValidTelegram = millis();
     return TELEGRAM_OK;
}

void setup() {
     Serial.begin(115200);
     setupP1UartDMA();
     Serial.println("P1 DMA Receiver gestart met verbeterde buffer handling");
     lastValidTelegram = millis();
}

void loop() {
     size_t length = 0;

     if (uart_get_buffered_data_len(P1_UART_NUM, &length) != ESP_OK) {
          Serial.println("Fout bij opvragen buffer lengte");
          delay(100);
          return;
     }

     if (length > 0) {
          uint8_t tempBuffer[128]; // Kleine buffer voor incrementele lezen
          size_t readSize = safe_min<size_t>(length, sizeof(tempBuffer));

          int readLength =
              uart_read_bytes(P1_UART_NUM, tempBuffer, readSize, 0);

          // Nieuwe diagnostische logging
          Serial.printf("Beschikbare bytes: %d, Gelezen bytes: %d\n", length,
                        readLength);
          Serial.println("Bytes (HEX):");
          for (int i = 0; i < readLength; i++) {
               Serial.printf("%02X ", tempBuffer[i]);
          }
          Serial.println();

          if (readLength > 0) {
               if (!rxBuffer.write(tempBuffer, readLength)) {
                    Serial.println("Buffer vol, oudste data wordt verwijderd");
                    // Maak ruimte vrij in de buffer
                    size_t toRemove = safe_min<size_t>(
                        static_cast<size_t>(readLength), rxBuffer.available());
                    uint8_t dummy[128];
                    rxBuffer.read(dummy, toRemove);
                    rxBuffer.write(tempBuffer, readLength);
               }

               // Verwerk alle complete telegrammen in de buffer
               while (rxBuffer.available() > 0) {
                    TelegramStatus status = processP1Telegram();

                    if (status == TELEGRAM_INCOMPLETE) {
                         break; // Wacht op meer data
                    }

                    if (status == TELEGRAM_CRC_ERROR) {
                         // Zoek naar volgend start karakter
                         size_t nextStart;
                         uint8_t startPattern[] = {P1_START_CHAR};
                         if (rxBuffer.findPattern(startPattern, 1, nextStart)) {
                              uint8_t dummy[128];
                              rxBuffer.read(dummy, nextStart);
                         }
                    }
               }
          }
     }

     // Check timeout
     if (millis() - lastValidTelegram > P1_MAX_TIMEOUT) {
          Serial.println("Timeout - geen geldig telegram ontvangen");
          rxBuffer.clear();
          uart_flush(P1_UART_NUM);
          lastValidTelegram = millis();
     }

     taskYIELD(); // Laat andere taken ook draaien
}

Wel even in code-tags

[ Voor 0% gewijzigd door Septillion op 07-02-2025 06:58 ]

[True]

duckmountain schreef op donderdag 6 februari 2025 @ 21:35:
Na één en ander gelezen te hebben wil ik jullie mijn code voor ESP32 niet onthouden.
Hij is supersnel, ongeveer 120 milliseconde.
CRC controle zit erin verwerkt.

[..]

Zie: Overzicht van UBB-codes en dan vooral: Overzicht van UBB-codes #tag_code

[Raven]

Als aanvulling op hierboven: "=c" erbij @duckmountain [code=c] [/]

[KingDurk]

iMars schreef op woensdag 5 februari 2025 @ 09:14:
[...]

Het eerste waar ik aan denk (kan natuurlijk niet vanaf hier jouw situatie zien ) is dat je meer blokkeert dan internet. Heb je apparte vlans? En zit P1 in een andere vlan dan HA?

Goede vragen. Goed om te weten dat het zou moeten kunnen. Dat zijn allemaal goede vragen en heb daar zo geen antwoord op. Bij andere eps32 werkt het wel door via de router het internet te blokkeren en ook enkele andere devices.


Wat betreft andere vlans weet ik niet. Heb wel iets ingesteld met vlan om de odido router er tussenuit te kunnen halen.

Ik ga verder op zoek

[iMars]

KingDurk schreef op vrijdag 7 februari 2025 @ 22:48:
[...]


Goede vragen. Goed om te weten dat het zou moeten kunnen. Dat zijn allemaal goede vragen en heb daar zo geen antwoord op. Bij andere eps32 werkt het wel door via de router het internet te blokkeren en ook enkele andere devices.


Wat betreft andere vlans weet ik niet. Heb wel iets ingesteld met vlan om de odido router er tussenuit te kunnen halen.

Ik ga verder op zoek

Ik ken de Odido router niet, maar als dit een standaard "simpele" router is, zal deze mogelijk geen vlans ondersteunen. Ook omdat vlans je niks zegt, of niet weet, ga ik ervan uit dat je dat niet hebt, anders had je het wel geweten

In dat geval is het wel raar, de enige verwijzing wat ik bijvoorbeeld in de yaml config zet, is een verwijzing naar de volledige config op GitHub zodat je deze binnen kan halen op het moment dat je 'm in ESPHome adopteert.

[Kip]

Voor wie op een leuke manier de data uit DSMR-reader wil weergeven: voor minder dan 10 euro is via AliExpress een ESP32 met een 2,8-inch touchscreen te koop, ook wel bekend als de Cheap Yellow Board (CYB).

Met de Arduino IDE, SquareLine Studio en de API van DSMR-reader is het eenvoudig om een display te maken voor je energieverbruik.

Als er interesse is, kan ik de code opschonen en beschikbaar stellen.

Met een druk op het scherm verander je de weergave naar de volgende "screen".

[cville]

Volgens de DSMR spec mag de afwijking van de P1 timestamps maximaal 0.5s per 24h zijn. Bij mij is dat op dit moment +39s. Aangezien ik bij negatieve prijzen mijn PV inverter wil curtailen, moet ik het real-time zelfverbruik weten. Dat lukt niet met een P1 timestamp dat 39s voorloopt.

Weet iemand hoe Enexis hier mee omgaat? Ik dacht dat de P1 klok regelmatig gesynchroniseerd wordt maar kan daar niets over vinden. Weet iemand hoe dit zit?

[mcmd]

cville schreef op woensdag 26 maart 2025 @ 15:05:
Volgens de DSMR spec mag de afwijking van de P1 timestamps maximaal 0.5s per 24h zijn. Bij mij is dat op dit moment +39s. Aangezien ik bij negatieve prijzen mijn PV inverter wil curtailen, moet ik het real-time zelfverbruik weten. Dat lukt niet met een P1 timestamp dat 39s voorloopt.

Weet iemand hoe Enexis hier mee omgaat? Ik dacht dat de P1 klok regelmatig gesynchroniseerd wordt maar kan daar niets over vinden. Weet iemand hoe dit zit?

Ik heb wel eens de drift gemeten en zag toen dat periodiek er een correctie plaats vond. Waarom neem je niet de tijd van NTP bij de meting?

[cville]

mcmd schreef op woensdag 26 maart 2025 @ 15:39:
[...]

Ik heb wel eens de drift gemeten en zag toen dat periodiek er een correctie plaats vond. Waarom neem je niet de tijd van NTP bij de meting?

Dat doe ik ook maar ik liep tegen het probleem aan dat mijn Tibber factuur niet klopte. Voor details zie hier.

Wat was bij jou de drift en hoe vaak wordt dit aangepast?

[rwanrooy]

cville schreef op woensdag 26 maart 2025 @ 15:05:
Volgens de DSMR spec mag de afwijking van de P1 timestamps maximaal 0.5s per 24h zijn. Bij mij is dat op dit moment +39s. Aangezien ik bij negatieve prijzen mijn PV inverter wil curtailen, moet ik het real-time zelfverbruik weten. Dat lukt niet met een P1 timestamp dat 39s voorloopt.

Weet iemand hoe Enexis hier mee omgaat? Ik dacht dat de P1 klok regelmatig gesynchroniseerd wordt maar kan daar niets over vinden. Weet iemand hoe dit zit?

Ik verwacht dat ze via de mobiele verbinding de tijd automatisch syncen met hun ntp servers. Kan zijn dat de mobiele dataverbinding het al een tijd niet meer doet. Je zou ze eens met de netbeheerder kunnen bellen daarover. Al weet ik niet hoeveel 39seconden drift uiteindelijk uitmaakt voor de Facturatie. Ik verwacht te verwaarlozen. Maar 39 seconden is wat ntp betreft lichtjaren verschil.

[mcmd]

cville schreef op woensdag 26 maart 2025 @ 15:54:
[...]


Dat doe ik ook maar ik liep tegen het probleem aan dat mijn Tibber factuur niet klopte. Voor details zie hier.

Wat was bij jou de drift en hoe vaak wordt dit aangepast?

Mijn metingen in 2025 (meting over 24uur), de som hiervan is .055264):

code:

20250101  Clock time difference drift:   0.496035s
20250102  Clock time difference drift:  -0.138769s
20250103  Clock time difference drift:   0.040407s
20250104  Clock time difference drift:   0.084711s
20250105  Clock time difference drift:  -0.072016s
20250106  Clock time difference drift:   0.024279s
20250107  Clock time difference drift:  -0.166070s
20250108  Clock time difference drift:   0.178835s
20250109  Clock time difference drift:  -0.879259s
20250110  Clock time difference drift:   0.397105s
20250111  Clock time difference drift:   0.243324s
20250112  Clock time difference drift:   0.882509s
20250113  Clock time difference drift:  -0.512395s
20250114  Clock time difference drift:   0.265710s
20250115  Clock time difference drift:  -0.785212s
20250116  Clock time difference drift:   0.369368s
20250117  Clock time difference drift:  -0.028547s
20250118  Clock time difference drift:  -0.623622s
20250119  Clock time difference drift:  -0.001768s
20250120  Clock time difference drift:   0.397134s
20250121  Clock time difference drift:   0.377085s
20250122  Clock time difference drift:   0.158007s
20250123  Clock time difference drift:  -0.534691s
20250124  Clock time difference drift:   0.335988s
20250125  Clock time difference drift:   0.086170s
20250126  Clock time difference drift:  -0.938938s
20250127  Clock time difference drift:   0.258718s
20250128  Clock time difference drift:   0.224167s
20250129  Clock time difference drift:   0.580399s
20250130  Clock time difference drift:  -0.506783s
20250131  Clock time difference drift:  -0.436553s
20250201  Clock time difference drift:   0.487582s
20250202  Clock time difference drift:   0.010845s
20250203  Clock time difference drift:   0.140824s
20250204  Clock time difference drift:   0.404301s
20250205  Clock time difference drift:  -0.231293s
20250206  Clock time difference drift:   0.109094s
20250207  Clock time difference drift:  -0.558256s
20250208  Clock time difference drift:  -0.043988s
20250209  Clock time difference drift:   0.986650s
20250210  Clock time difference drift:  -0.917101s
20250211  Clock time difference drift:   0.905397s
20250212  Clock time difference drift:  -0.083067s
20250213  Clock time difference drift:   0.085762s
20250214  Clock time difference drift:  -0.672501s
20250215  Clock time difference drift:   0.402929s
20250216  Clock time difference drift:   0.181605s
20250217  Clock time difference drift:  -0.168950s
20250218  Clock time difference drift:  -0.179161s
20250219  Clock time difference drift:   0.194140s
20250220  Clock time difference drift:  -0.791999s
20250221  Clock time difference drift:   0.410815s
20250222  Clock time difference drift:   0.197946s
20250223  Clock time difference drift:   0.148834s
20250224  Clock time difference drift:   0.110889s
20250225  Clock time difference drift:  -0.083144s
20250226  Clock time difference drift:  -0.675190s
20250227  Clock time difference drift:   0.757859s
20250228  Clock time difference drift:  -0.477308s
20250301  Clock time difference drift:   0.566526s
20250302  Clock time difference drift:  -0.765681s
20250303  Clock time difference drift:   0.474502s
20250304  Clock time difference drift:   0.259023s
20250305  Clock time difference drift:  -0.812854s
20250306  Clock time difference drift:   0.255759s
20250307  Clock time difference drift:   0.368005s
20250308  Clock time difference drift:   0.117826s
20250309  Clock time difference drift:  -0.630294s
20250310  Clock time difference drift:   0.409045s
20250311  Clock time difference drift:   0.142980s
20250312  Clock time difference drift:  -0.635721s
20250313  Clock time difference drift:   0.192248s
20250314  Clock time difference drift:  -0.051174s
20250315  Clock time difference drift:   0.126112s
20250316  Clock time difference drift:  -0.023231s
20250317  Clock time difference drift:   0.191674s
20250318  Clock time difference drift:   0.038584s
20250319  Clock time difference drift:   0.275428s
20250320  Clock time difference drift:   0.028464s
20250321  Clock time difference drift:  -0.699992s
20250322  Clock time difference drift:  -0.560641s
20250323  Clock time difference drift:   0.044077s
20250324  Clock time difference drift:   0.950925s
20250325  Clock time difference drift:  -0.040937s
20250326  Clock time difference drift:  -0.594231s

[cville]

mcmd schreef op woensdag 26 maart 2025 @ 17:15:
[...]

Mijn metingen in 2025 (meting over 24uur), de som hiervan is .055264):

code:

20250101  Clock time difference drift:   0.496035s
20250102  Clock time difference drift:  -0.138769s
20250103  Clock time difference drift:   0.040407s
20250104  Clock time difference drift:   0.084711s
20250105  Clock time difference drift:  -0.072016s
20250106  Clock time difference drift:   0.024279s
20250107  Clock time difference drift:  -0.166070s
20250108  Clock time difference drift:   0.178835s
20250109  Clock time difference drift:  -0.879259s
20250110  Clock time difference drift:   0.397105s
20250111  Clock time difference drift:   0.243324s
20250112  Clock time difference drift:   0.882509s
20250113  Clock time difference drift:  -0.512395s
20250114  Clock time difference drift:   0.265710s
20250115  Clock time difference drift:  -0.785212s
20250116  Clock time difference drift:   0.369368s
20250117  Clock time difference drift:  -0.028547s
20250118  Clock time difference drift:  -0.623622s
20250119  Clock time difference drift:  -0.001768s
20250120  Clock time difference drift:   0.397134s
20250121  Clock time difference drift:   0.377085s
20250122  Clock time difference drift:   0.158007s
20250123  Clock time difference drift:  -0.534691s
20250124  Clock time difference drift:   0.335988s
20250125  Clock time difference drift:   0.086170s
20250126  Clock time difference drift:  -0.938938s
20250127  Clock time difference drift:   0.258718s
20250128  Clock time difference drift:   0.224167s
20250129  Clock time difference drift:   0.580399s
20250130  Clock time difference drift:  -0.506783s
20250131  Clock time difference drift:  -0.436553s
20250201  Clock time difference drift:   0.487582s
20250202  Clock time difference drift:   0.010845s
20250203  Clock time difference drift:   0.140824s
20250204  Clock time difference drift:   0.404301s
20250205  Clock time difference drift:  -0.231293s
20250206  Clock time difference drift:   0.109094s
20250207  Clock time difference drift:  -0.558256s
20250208  Clock time difference drift:  -0.043988s
20250209  Clock time difference drift:   0.986650s
20250210  Clock time difference drift:  -0.917101s
20250211  Clock time difference drift:   0.905397s
20250212  Clock time difference drift:  -0.083067s
20250213  Clock time difference drift:   0.085762s
20250214  Clock time difference drift:  -0.672501s
20250215  Clock time difference drift:   0.402929s
20250216  Clock time difference drift:   0.181605s
20250217  Clock time difference drift:  -0.168950s
20250218  Clock time difference drift:  -0.179161s
20250219  Clock time difference drift:   0.194140s
20250220  Clock time difference drift:  -0.791999s
20250221  Clock time difference drift:   0.410815s
20250222  Clock time difference drift:   0.197946s
20250223  Clock time difference drift:   0.148834s
20250224  Clock time difference drift:   0.110889s
20250225  Clock time difference drift:  -0.083144s
20250226  Clock time difference drift:  -0.675190s
20250227  Clock time difference drift:   0.757859s
20250228  Clock time difference drift:  -0.477308s
20250301  Clock time difference drift:   0.566526s
20250302  Clock time difference drift:  -0.765681s
20250303  Clock time difference drift:   0.474502s
20250304  Clock time difference drift:   0.259023s
20250305  Clock time difference drift:  -0.812854s
20250306  Clock time difference drift:   0.255759s
20250307  Clock time difference drift:   0.368005s
20250308  Clock time difference drift:   0.117826s
20250309  Clock time difference drift:  -0.630294s
20250310  Clock time difference drift:   0.409045s
20250311  Clock time difference drift:   0.142980s
20250312  Clock time difference drift:  -0.635721s
20250313  Clock time difference drift:   0.192248s
20250314  Clock time difference drift:  -0.051174s
20250315  Clock time difference drift:   0.126112s
20250316  Clock time difference drift:  -0.023231s
20250317  Clock time difference drift:   0.191674s
20250318  Clock time difference drift:   0.038584s
20250319  Clock time difference drift:   0.275428s
20250320  Clock time difference drift:   0.028464s
20250321  Clock time difference drift:  -0.699992s
20250322  Clock time difference drift:  -0.560641s
20250323  Clock time difference drift:   0.044077s
20250324  Clock time difference drift:   0.950925s
20250325  Clock time difference drift:  -0.040937s
20250326  Clock time difference drift:  -0.594231s

Dat lijkt me zeer acceptabel en een wereld van verschil met mijn 39s. Bedankt!

[timovd]

Sinds vandaag krijg ik geen data meer in Home Assistant van de lezer (ESP).
Mijn P1 lezer is bereikbaar via het netwerk.
De laadpaal (load balancer) is nog wel in staat om de digitale meter uit te lezen via de P1-poort.
De P1 telegrammen worden gesplitst d.m.v. een splitter (die het al jaren doet). Ook direct aangesloten (zonder splitter) op de poort heeft het zelfde resultaat.
Ik gebruik deze firmware: https://github.com/letsco...eleases/tag/mega-20241222
De logging van de P1 lezer (in de webinterface van ESPMegaP1) is leeg. ("Fetching log entries...")
De digitale meter is een Iskra AM550 (van Stedin)

HA logging zegt:

code:

raise ParseError(File "/usr/local/lib/python3.13/site-packages/dsmr_parser/parsers.py", line 131, in validate_checksum
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
self.validate_checksum(telegram_data)
File "/usr/local/lib/python3.13/site-packages/dsmr_parser/parsers.py", line 83, in parse
parsed_telegram = self.telegram_parser.parse(telegram)
File "/usr/local/lib/python3.13/site-packages/dsmr_parser/clients/protocol.py", line 159, in handle_telegram
Traceback (most recent call last):
2025-03-28 18:12:51.885 ERROR (MainThread) [dsmr_parser.clients.protocol] failed to parse telegram
dsmr_parser.exceptions.ParseError: Failed to perform CRC validation because the telegram is incomplete. The checksum and/or content values are missing.)

En dit iedere minuut.

Iemand een idee waar dit aan kan liggen?

[Aiolos]

Exception heeft het over een crc fout door incompleet telegram, kun je eens telnetten naar de esp (waarschijnlijk op poort 8088) en kijken hoe het telegram er uit komt.

[timovd]

Aiolos schreef op vrijdag 28 maart 2025 @ 19:12:
Exception heeft het over een crc fout door incompleet telegram, kun je eens telnetten naar de esp (waarschijnlijk op poort 8088) en kijken hoe het telegram er uit komt.

Daar zie ik wel berichten binnenkomen.

3f en een PV-installatie die nu teruglevert

code:

...
1-3:0.2.8(50)
0-0:1.0.0(25033015473
3)
1-0:72.36.0(00003)
0-0:96.13.0()
1-0:32.7.0(237.1*V)
1-0:52.7.0(237.1*V)
1-0:72.7.0(236.6*V)
1-0:31.7.0(004*A)
1-0:51.7.0(006*A)
1-0:71.7.0(005*A)
1-0:21.7.0(00.000*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(01.086*kW)
1-0:42.7.0(01.467*kW)
1-0:62.7.0(01.296*kW)
!47AC
...

Sommige berichten zijn wat langer waarbij het s/n wordt meegestuurd. Het verbruik (kw/h zie ik nergens).

Log level Error --> Info:

code:

1088539: WD : Uptime 18 ConnectFailures 0 FreeMem 18784 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
...

Horen hier ook de P1 telegrammen te staan?

[ Voor 81% gewijzigd door timovd op 30-03-2025 16:16 ]

[True]

timovd schreef op zondag 30 maart 2025 @ 15:32:
[...]

Daar zie ik wel berichten binnenkomen.

3f en een PV-installatie die nu teruglevert

code:

...
1-3:0.2.8(50)
0-0:1.0.0(25033015473
3)
1-0:72.36.0(00003)
0-0:96.13.0()
1-0:32.7.0(237.1*V)
1-0:52.7.0(237.1*V)
1-0:72.7.0(236.6*V)
1-0:31.7.0(004*A)
1-0:51.7.0(006*A)
1-0:71.7.0(005*A)
1-0:21.7.0(00.000*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(01.086*kW)
1-0:42.7.0(01.467*kW)
1-0:62.7.0(01.296*kW)
!47AC
...

Sommige berichten zijn wat langer waarbij het s/n wordt meegestuurd. Het verbruik (kw/h zie ik nergens).

Log level Error --> Info:

code:

1088539: WD : Uptime 18 ConnectFailures 0 FreeMem 18784 WiFiStatus: WL_CONNECTED 3 ESPeasy internal wifi status: Conn. IP Init
...

Horen hier ook de P1 telegrammen te staan?

Dan lijkt het dus op een defecte slimme meter, een defecte poort op de slimme meter een defecte kabel of een defecte poort op je uitleesapparaat. Kwestie van uitsluiten.

[timovd]

@True de slimme meter of de poort lijkt mij niet, want de LB op de laadpaal werkt nog goed. Die kan ik ook nog uitlezen in HA.
De kabel heb ik ook al uitgesloten, want ik heb een splitter en die er tussenuit gehaald en meerdere kabeltjes geprobeerd.
Dan het uitleesapparaat; blijkbaar komen er dus wel telegrammen binnen, maar ik kan niet goed beoordelen of deze compleet of corrupt zijn.

Edit: Blijkbaar is er gisteren (om 21:00:05) nog wel een signaal in mijn HA gekomen en het dashboard geeft nu vele uren de zelfde waarden terug. Het doet dus toch nog iets.

[ Voor 18% gewijzigd door timovd op 31-03-2025 08:33 ]

[timovd]

Nieuw berichten er uit laten spugen met Telnet. Het serienummer heb ik onleesbaar gemaakt.
"1-0:1.8.1" zal telwerk I (levering dal) zijn. Dat is wel gek gezien de timestamp (overdag op een werkdag), aangezien ik nu teruglever (zie 1-0:x2.7.0) en het normaaltarief actief is. Andere telwerken zijn niet uit te lezen in recente berichten. Mijn energieleverancier kan op afstand wel de standen uitlezen.

code:

1-3:0.2.8(50)
0-0:1.0.0(250401154203S)
0
1-0:31.7.0(00)
1-0:51.7.0(005*A)
1-0:71.7.0(004*A)
1-0:21.7.0(00.000*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.967*kW)
1-0:42.7.0(01.370*kW)

1-0:62.7.0(01.175*kW)
!3C5E
/ISK5\2M550T-1014

1
000*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.962*kW)
1-0:42.7.0(01.330*kW)
1-0:62.7.0(01.169*kW)
!6EA3
/ISK5\2M550T-1014

1-3:0.2.8(50)
0-0:1.0.0(250401154211S)
0-0:96.1.1(***)
1-0:1.8.1(002433.403*kWh)
1-0:1.8
.0(00.000*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.967*kW)
1-0:42.7.0(01.368*kW)
1-0:62.7.0(01.176*kW)
!D87F
/ISK5\2M550T-1014

1-3:0.2.8(50)
0-0:1.0.0(250401154216S)
0-0:96.1.1(***)
1-0:1.8.1(002433.403*kWh)
1-0:1.8.2(001872.2
V)
1-0:31.7.0(004*A)
1-0:51.7.0(005*A)
1-0:71.7.0(004*A)
1-0:21.7.0(00.000*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.969*kW)
1-0:42.7.0(0
1.365*kW)
1-0:62.7.0(01.172*kW)
!5F55
/ISK5\2M550T-1014

De berichten zien er niet erg georganiseerd uit, of hoort dat zo? Toch corrupte berichten waar mijn laadpaal/load balancer wel mee overweg kan?

[Martin7182]

Ik zie duidelijk de header, data en CRC. Dit ziet er niet heel corrupt uit, al lijkt er af en toe iets te ontbreken. Ik zou in ieder geval de CRC controleren om uitsluitsel te hebben.

[ Voor 44% gewijzigd door Martin7182 op 01-04-2025 16:09 ]

[timovd]

@Martin7182 en regel 17/18 en 31/32 bijvoorbeeld?

[Martin7182]

@timovd ik zou de contacten even schoonmaken met wat spiritus en evt. een kortere kabel proberen. Ik kreeg hier problemen met de nieuwe meter die met een hogere baudrate werkt. De kabel was te lang/slecht en dat gaf ook fouten.

[Septillion]

@timovd Dat je overdag 1-0:1.8.1 krijgt is op zich niet gek. Dat is gewoon een van de meterstanden en die zouden gewoon elke keer binnen moeten komen. Hij zou dan alleen niet op moeten lopen.

Maar verder mis je inderdaad grote brokken. Want je zou dus ook telkens 1-0:1.8.2, 1-0:2.8.1 en 1-0:2.8.2 binnen moeten krijgen (de andere 3 telwerken). En regel 17, 18, 31, 32, 45 en 46 zijn allemaal niet compleet.

[floriszz]

Sinds een week is mijn Slimme meter vervangen van een goed werkende DSMR2.2 meter die via een simpele serieel naar usb kabel gekoppeld is aan Raspberry PI HomeAssistant DSMR slimme Meter integratie, naar een Kaifa MA304 E0079 meter. Waarna ik geen standen meer binnen kreeg.
Ik heb de integratie verwijderd en opnieuw toegevoegd en gekozen voor '4'(in plaats van 2.2)
In eerste instantie blij, want standen kwamen gelijk binnen, maar hij lijkt maar 1x per etmaal een update te sturen, terwijl ik de polling op '0'(event based) heb.

Moet ik kiezen voor '5' in plaats van '4' of moet ik de polling aanpassen?
Heeft iemand hier ervaring mee?

[shoof]

Ik ben gestart met HA en ESPhome, nu wil ik graag mijn kaifa slimme meter integreren. Ik heb een ESP32 S3 dev bordje. Nu ben ik benieuwd hoe ik dit het simpelste kan aansluiten. Een schema dat ik een paar keer tegen kwam is het volgende:

ESP32 - P1
3v3 - 2 RTS
GPIOx - 5 RXD
GND - 3 GND

En dan een 10k weerstand over RXD en 3v3

Werkt dit bij jullie in de praktijk en welke GPIO gebruiken jullie dan? Verder ben ik benieuwd of de 3v3 voldoende is voor de RTS, ik lees ook weer dat er 5v nodig zou zijn? De GPIO's kunnen toch niet tegen 5v?

[Septillion]

@shoof ESPHome ondersteund tegenwoordig het inverten van de data en de S3 heeft 3 UARTS. Dus zolang je een GPIO pakt die vrij is en als input kan dienen zou dat moeten werken.

Alleen Data Request moet volgens de spec aan 5V, dus die koppel je aan pin 1. Data request hoeft niet naar de ESP dus dat is geen probleem. De 5V van P1 kan je ook gebruiken om de ESP module te voeden daar de meeste wel een voltage regulator bevatten.

[shoof]

Septillion schreef op zondag 23 november 2025 @ 22:18:
@shoof ESPHome ondersteund tegenwoordig het inverten van de data en de S3 heeft 3 UARTS. Dus zolang je een GPIO pakt die vrij is en als input kan dienen zou dat moeten werken.

Alleen Data Request moet volgens de spec aan 5V, dus die koppel je aan pin 1. Data request hoeft niet naar de ESP dus dat is geen probleem. De 5V van P1 kan je ook gebruiken om de ESP module te voeden daar de meeste wel een voltage regulator bevatten.

Super, dat klinkt goed, ik ga knutselen. Is de weerstand over 3v3 en RxD dan nog wel nodig?

Pin 1 verbind ik dan door met 2. Ik denk dat het bordje teveel vraagt aangezien de meter max 100mA kan leveren, dus ik voed hem via usb. Moet ik dan nog iets met de GND op pin 6 van de p1?

[Septillion]

@shoof Zeker, want de uitgang van de P1 is open collector.

Je hebt geen DSMR5 meter? Die Leveren 250mA en zou genoeg moeten zijn. Mijn D1 Mini draait er ook al 6 jaar (en 3 meters) prima op.

GND moet inderdaad verbonden met ESP GND, wat het ook voedt. Anders heb je geen return pad.

[ Voor 19% gewijzigd door Septillion op 23-11-2025 22:57 ]

[shoof]

Septillion schreef op zondag 23 november 2025 @ 22:56:
@shoof Zeker, want de uitgang van de P1 is open collector.

Je hebt geen DSMR5 meter? Die Leveren 250mA en zou genoeg moeten zijn. Mijn D1 Mini draait er ook al 6 jaar (en 3 meters) prima op.

GND moet inderdaad verbonden met ESP GND, wat het ook voedt. Anders heb je geen return pad.

Wederom dank. Ik vermoed dat het een dsmr 4 is, vandaar. Maar ik kan dus ook de 5v van de esp32 pakken en aansluiten op RTS en dan poort 1 en 6 niet gebruiken. Er vanuitgaande dat ik hem voed via een losse voeding?

[Septillion]

@shoof Waar je de 5V voor Data Request vandaan haalt maakt niet uit, zolang de GND's maar verbonden zijn.

[iMars]

@shoof wat @Septillion zegt:


Als je 1 en 6 niet gebruikt, prima. Zolang er maar 5v (volgens mij werkt 3v3 ook) op pin 2 (data_request) komt om de poort te activeren. En een pull-up weerstand tussen 5v en pin 5 (data pin) komt.

Dus alleen pinnen 2, 3 en 5 (is minimale wat je nodig hebt) gebruiken is prima!

[shoof]

iMars schreef op dinsdag 25 november 2025 @ 10:08:
@shoof wat @Septillion zegt:
[Afbeelding]

Als je 1 en 6 niet gebruikt, prima. Zolang er maar 5v (volgens mij werkt 3v3 ook) op pin 2 (data_request) komt om de poort te activeren. En een pull-up weerstand tussen 5v en pin 5 (data pin) komt.

Dus alleen pinnen 2, 3 en 5 (is minimale wat je nodig hebt) gebruiken is prima!

Super, dank allemaal, ik krijg de data binnen:) uiteindelijk werkt het inderdaad ook met 3v3 ipv 5. Eerst lukte het niet, maar dat lag aan de instellingen in ESPhome, ik moest de rx als inverted instellen, toen kwam alles binnen.

[Flappie]

Zojuist is mijn oude DSMR4 meter vervangen door een nieuwe ZIV ESMR 5 meter.
Ik lees uit met DSMR meter (https://github.com/dsmrreader/dsmr-reader)

Ik zie echter wel data binnenkomen maar blijkbaar met een verkeerde datum en tijd?
Iemand een idee?

/CTA5ZIV-METER

1-3:0.2.8(50)
0-0:1.0.0(241014145620S)
0-0:96.1.1(4530303930303030373433383837313234)
1-0:1.8.1(000000.068*kWh)
1-0:1.8.2(000000.000*kWh)
1-0:2.8.1(000000.020*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.444*kW)
1-0:2.7.0(00.318*kW)
0-0:96.7.21(00006)
0-0:96.7.9(00002)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00002)
1-0:52.36.0(00002)
1-0:72.36.0(00003)
0-0:96.13.0()
1-0:32.7.0(233.0*V)
1-0:52.7.0(232.0*V)
1-0:72.7.0(233.0*V)
1-0:31.7.0(002*A)
1-0:51.7.0(001*A)
1-0:71.7.0(003*A)
1-0:21.7.0(00.444*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.021*kW)
1-0:62.7.0(00.296*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730313032303032343132383939313234)
0-1:24.2.1(251212120000W)(00000.038*m3)
!A7E3

Volgens DSMR Reader is de timestamp: 14 oktober 2024 ?
Moet de meter gewoon nog even bijwerken? Hoe lang zou dit kunnen duren?

[True]

Flappie schreef op vrijdag 12 december 2025 @ 12:02:
Zojuist is mijn oude DSMR4 meter vervangen door een nieuwe ZIV ESMR 5 meter.
Ik lees uit met DSMR meter (https://github.com/dsmrreader/dsmr-reader)

Ik zie echter wel data binnenkomen maar blijkbaar met een verkeerde datum en tijd?
Iemand een idee?

/CTA5ZIV-METER

1-3:0.2.8(50)
0-0:1.0.0(241014145620S)
0-0:96.1.1(4530303930303030373433383837313234)
1-0:1.8.1(000000.068*kWh)
1-0:1.8.2(000000.000*kWh)
1-0:2.8.1(000000.020*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(00.444*kW)
1-0:2.7.0(00.318*kW)
0-0:96.7.21(00006)
0-0:96.7.9(00002)
1-0:99.97.0(0)(0-0:96.7.19)
1-0:32.32.0(00000)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00002)
1-0:52.36.0(00002)
1-0:72.36.0(00003)
0-0:96.13.0()
1-0:32.7.0(233.0*V)
1-0:52.7.0(232.0*V)
1-0:72.7.0(233.0*V)
1-0:31.7.0(002*A)
1-0:51.7.0(001*A)
1-0:71.7.0(003*A)
1-0:21.7.0(00.444*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.000*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.021*kW)
1-0:62.7.0(00.296*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730313032303032343132383939313234)
0-1:24.2.1(251212120000W)(00000.038*m3)
!A7E3

Volgens DSMR Reader is de timestamp: 14 oktober 2024 ?
Moet de meter gewoon nog even bijwerken? Hoe lang zou dit kunnen duren?

Geef het sowieso één nacht.
Ik meen dat ze 's nachts een ET-phone-home doen, dan is er minder straling en is de dekking beter.

[Flappie]

True schreef op vrijdag 12 december 2025 @ 13:15:
[...]


Geef het sowieso één nacht.
Ik meen dat ze 's nachts een ET-phone-home doen, dan is er minder straling en is de dekking beter.

Hij is inmiddels bijgewerkt

[databeestje]

In het kader van, hoeveel P1 meter projectjes kan iemand nodig hebben. Ik heb met een combinatie van Gemini en CoPilot het volgende Vibe code ding gemaakt.

P1 DSMR5 input via serieel of netwerk (tcp)
Output naar TCP Server (datagram), Modbus TCP (Eastron SDM72 of Fronius SunPower), MQTT

https://github.com/smos/esp32-p1-modbus/tree/main

Aanleiding: Onderzoekend naar hybride PV-Batterij omvormers willen deze een Modbus energie meter. Aangezien de P1 meter dit in feite al doet leek mij dit overbodig. De voorkeur leunt naar een Fronius Gen24 Plus, hier is ook een CAN Proxy voor van Dala waarmee alles van EV accu's tot 3e partij accu systemen mogelijk is.

Voor de meterkast integratie vereist deze een Fronius energie meter, maar er is niet genoeg ruimte in mijn meterkast voor nog een energie meter
Niet dat een Solis S6 veel anders is, die heeft een Eastron nodig.

Mijn thuis situatie heb ik een Elfin EE10 die als Serieel server dient van de P1 poort, daar verbind HomeAssistant mee. Zonder naar een P1 splitter te gaan hier een alles-in-een van gerold. Deze zou alles tegelijk moeten doen. Dit project kan verbinden met TCP, wel zo handig voor testen, serieel nog niet getest.

Blijft vooralsnog langer dan een paar werken, dus dat is winst. Eastron registers kunnen verifieren met echte Eastron SDM72 waarvan er al 3 in de meterkast zitten (dus ruimte op)

[databeestje]

Antwoord op mijzelf, kan niet meer editten.

Verder gegaan met het projectje, en deze kan nu ook SMA/Speedwire broadcasten op het LAN. Probleem is dat ik geen SMA omvormer met ondersteuning heb. De packet capture ziet er goed uit en wordt geparsed, maar zoek eigenlijk een tester.

Input P1 via Serieel of via TCP
Output MQTT, TCP, Modbus (Eastron SDM72), Speedwire

Deze thuis in gebruik genomen in plaats van de Elfin EE10

[GPX]

Vandaag online, van GPX Open Source: GPXconnector hardware (P1poort reader) via https://github.com/GPXene...ctor/tree/master/hardware

[ Voor 6% gewijzigd door GPX op 01-04-2026 12:25 ]

[Hippe Lip]

Is er iemand die ooit een P1-simulator heeft gemaakt? En dan bedoel ik een device dat een telegram uitspuugt net zoals de slimme meter dat doet, maar dan met een geheel of gedeeltelijk zelf samengesteld telegram?

Ik zit met een lastige situatie: mijn 3-fase huisaansluiting is linksdraaiend, maar Zappi vereist een rechtsdraaiende aansluiting. Aanvankelijk had ik in de Zappi twee fases omgedraaid, maar dan wordt het al snel verwarrend, omdat ik ook twee harvi’s heb die dan ook aangepast moeten worden.

Daarom heb ik al een tijd geleden twee fases verwisseld onder de hoofdschakelaar: L2 en L3. Dan zit ik alleen nog met het punt dat de info van de fases uit de metingen van de Zappi en 2 harvi’s dan niet overeenkomen met wat mijn slimme meter uitspuugt.

Als ik nou een ‘corrector’ zou hebben die het telegram van de slimme meter aanpast en daar dezelfde L2- en L3-informatie verwisselt, dan klopt het weer (op de hoofdzekeringen –automaten– na dan…

[Wilin]

Hippe Lip schreef op woensdag 1 april 2026 @ 15:00:
Is er iemand die ooit een P1-simulator heeft gemaakt? En dan bedoel ik een device dat een telegram uitspuugt net zoals de slimme meter dat doet, maar dan met een geheel of gedeeltelijk zelf samengesteld telegram?

Ik gebruik deze om een batterij aan te sturen

[iMars]

Hippe Lip schreef op woensdag 1 april 2026 @ 15:00:
Is er iemand die ooit een P1-simulator heeft gemaakt? En dan bedoel ik een device dat een telegram uitspuugt net zoals de slimme meter dat doet, maar dan met een geheel of gedeeltelijk zelf samengesteld telegram?

Ik zit met een lastige situatie: mijn 3-fase huisaansluiting is linksdraaiend, maar Zappi vereist een rechtsdraaiende aansluiting. Aanvankelijk had ik in de Zappi twee fases omgedraaid, maar dan wordt het al snel verwarrend, omdat ik ook twee harvi’s heb die dan ook aangepast moeten worden.

Daarom heb ik al een tijd geleden twee fases verwisseld onder de hoofdschakelaar: L2 en L3. Dan zit ik alleen nog met het punt dat de info van de fases uit de metingen van de Zappi en 2 harvi’s dan niet overeenkomen met wat mijn slimme meter uitspuugt.

Als ik nou een ‘corrector’ zou hebben die het telegram van de slimme meter aanpast en daar dezelfde L2- en L3-informatie verwisselt, dan klopt het weer (op de hoofdzekeringen –automaten– na dan…

Ik heb mogelijk wel de hardware, maar hou me heel eerlijk niet zo bezig met de software kant

Ik heb nu een esp32c3 gebaseerde slimmelezer met ethernet, wifi, p1-in en p1-out. Met de juiste software kan je de p1-out manipuleren:

[Lord Anubis]

GPX schreef op woensdag 1 april 2026 @ 12:21:
Vandaag online, van GPX Open Source: GPXconnector hardware (P1poort reader) via https://github.com/GPXene...ctor/tree/master/hardware

Bedankt voor het delen. Helaas krijg het niet geopend met KiCad 9 en 10. Ook de PDF geeft een beschadigd bestand melding.

[hterhofte]

GPX schreef op woensdag 1 april 2026 @ 12:21:
Vandaag online, van GPX Open Source: GPXconnector hardware (P1poort reader) via https://github.com/GPXene...ctor/tree/master/hardware

Mooi dat jullie het hardware-ontwerp open source hebben gemaakt! Dat is dan al het tweede open hardware P1-ontwerp op GitHub
Wij (lectoraat Energietransitie, Hogeschool Windesheim) hebben in 2021-2022 ook een open hardware P1-gateway ontworpen: https://github.com/energietransitie/twomes-p1-gateway-hardware (KiCad, CERN-OHL-P-2.0 licentie). De bijbehorende firmware (ESP-IDF/C, Apache 2.0) staat hier: https://github.com/energietransitie/twomes-p1-gateway-firmware.
Qua hoofdlijnen een paar verschillen die me opvallen:

Jullie GPXconnector is een standalone ESP32-apparaat dat data naar de GPX cloud-API stuurt. Ons ontwerp fungeert daarnaast ook als gateway: het ontvangt via ESP-NOW meetdata van andere sensoren in huis (bv. binnentemperatuur) en stuurt alles door naar een onderzoeksserver.
Jullie ondersteunen (naar ik aanneem) DSMR5. Onze firmware ondersteunt DSMR v2 t/m v5 (zowel 115200/8N1 als 9600/7E1).
Ons ontwerp heeft ook een 3D-printbare behuizing erbij.

Het geheel is onderdeel van het NeedForHeat open source meetsysteem waarmee we de warmtetransitie in woningen onderzoeken; voor wie het interessant vindt staat er een uitgebreide beschrijving in een pre-print: https://arxiv.org/abs/2509.06927.
We zijn inmiddels ook bezig met een opvolger-ontwerp op basis van een M5Stack CoreInk: https://github.com/energietransitie/needforheat-p1-base-hardware (nog in ontwikkeling).
@Lord Anubis : de KiCad-compatibiliteitsissues die je noemt ken ik; bij ons werkt KiCad 8 prima met onze ontwerpen, misschien dat de GPX-bestanden met een oudere versie zijn gemaakt?

[Z900]

@Hippe Lip https://www.benefactus.nl...r/slimme-meter-simulator/

[Lord Anubis]

@hterhofte
Vraag; jullie gebruiken de stroom van de meter. Is dat voor elke DSMR meter gelijk kwa opbrengst? Is dit uitgebreid getest en bemonsterd op verbruik/zend momenten? Is de maximale stroom uit de P1-poort voor alle DSMR v5.0 meters exact 250mA ( las dat ergens en DSMT4 zou maar 100mA zijn? ), of zijn er uitschieters? Zijn hier metingen van?

Zelf net begonnen met een eigen versie voor de buurman met een esp8266 incl klein 1,5" display. Wil de stroom beperking overnemen als backup plan ( zonder de voltage regulator zoals bij jullie want die zit al op de ESP32/display bordje ), zodat als er de usb voeding wegvalt het iig data kan opslaan d.m.v de stroom van de DSMR meter. Dus met USB voeding, display en zenden; zonder USB voeding, alleen opslaan en per x minuut zenden. ( Nog net geen oneliner als volzin )

Maar nu mijn eignelijke vraag. Jullie schema volgend bij tijdelijk geen usb voeding, dus alleen DSMR5 voeding. Er wordt op de knoppen gedrukt ( denk ook aan contact denderen ) terwijl de ESP wilt gaan zenden of zet de wifi aan, zakt de stroom uit de 470uF niet te snel naar 0? Zodat er uiteindelijk niet verzonden kan worden en misschien er wel de esp reset ontstaat.
Is het beter om een weerstand tussen de schakelaars en de gpio pin te paatsen om de sink stroom en het denderen te beperken?

[hterhofte]

Lord Anubis schreef op woensdag 8 april 2026 @ 13:43:
@hterhofte
Vraag; jullie gebruiken de stroom van de meter. Is dat voor elke DSMR meter gelijk kwa opbrengst? Is dit uitgebreid getest en bemonsterd op verbruik/zend momenten? Is de maximale stroom uit de P1-poort voor alle DSMR v5.0 meters exact 250mA ( las dat ergens en DSMT4 zou maar 100mA zijn? ), of zijn er uitschieters? Zijn hier metingen van?

Zelf net begonnen met een eigen versie voor de buurman met een esp8266 incl klein 1,5" display. Wil de stroom beperking overnemen als backup plan ( zonder de voltage regulator zoals bij jullie want die zit al op de ESP32/display bordje ), zodat als er de usb voeding wegvalt het iig data kan opslaan d.m.v de stroom van de DSMR meter. Dus met USB voeding, display en zenden; zonder USB voeding, alleen opslaan en per x minuut zenden. ( Nog net geen oneliner als volzin )

Maar nu mijn eignelijke vraag. Jullie schema volgend bij tijdelijk geen usb voeding, dus alleen DSMR5 voeding. Er wordt op de knoppen gedrukt ( denk ook aan contact denderen ) terwijl de ESP wilt gaan zenden of zet de wifi aan, zakt de stroom uit de 470uF niet te snel naar 0? Zodat er uiteindelijk niet verzonden kan worden en misschien er wel de esp reset ontstaat.
Is het beter om een weerstand tussen de schakelaars en de gpio pin te paatsen om de sink stroom en het denderen te beperken?

Even vooraf: ik ken de ontwerpen en heb ze gebruikt, maar ik ben niet de hardware-ontwerper. Ook werk ik inmiddels niet meer bij Windesheim. Als het nodig is kan ik nog wel iets navragen.

Over de voeding uit de P1-poort:

- DSMR <= 3.0
Geen voeding uit P1 → daarom externe USB-voeding nodig

- DSMR 4.x (~100 mA)
Dit was de beperkende variant
Daarom zit er een buffercondensator in het ontwerp: C6 = 470 µF
Die is bedoeld om korte pieken (zoals wifi) op te vangen

- DSMR 5.x (~250 mA volgens spec)
Ruimer, maar wij hebben het ontwerp niet specifiek daarop geoptimaliseerd
Of je zonder buffer kunt durf ik niet zeker te zeggen

- DSMR6 / NextGen (X1: RJ45 + 500 mA via USB-voedingspoort van slimme meter)
Niet voor ontworpen

Handig overzicht van specs:
https://github.com/energietransitie/dsmr-info
en in het bijzonder:
https://github.com/energi...ob/main/dsmr-p1-specs.csv

Over je vraag of die 250 mA altijd gehaald wordt: dat is een specificatie, geen garantie. Ik heb zelf geen uitgebreide metingen per meter gezien; we hebben het vooral robuust proberen te maken met buffering.

Over je scenario: als je geen USB voeding gebruikt dan moet idd alle voeding uit de P1 poort komen. Maar wifi-pieken van een ESP zijn vrij hoog, dus alleen op P1 (zeker DSMR4) blijft krap; voor ons werkte het (wij stuurden maar 1x per 5 min of 1x per 10 min data door)

Je vraag over knoppen + stroom:
Ik denk dat de echte zorg zit in piekverbruik (wifi), niet in de knoppen zelf. Een GPIO met knop trekt normaal nauwelijks extra stroom, zo begrijp ik. Contactdenderen is meer een software-issue.

Ik kan me niet herinneren dat we resets door knopgebruik zijn tegengekomen. Brownouts door wifi-pieken zijn waarschijnlijker.

Tot slot: we zijn later begonnen met een nieuwe generatie hardware:
https://github.com/energi...dforheat-p1-base-hardware

Daar gebruiken we o.a. een M5CoreInk. Het oude ontwerp had relatief veel knoppen (verwarrend en niet zo robuust bij verzending). Met M5Stack hardware lossen we dat grotendeels op.

[ Voor 0% gewijzigd door hterhofte op 10-04-2026 22:29 . Reden: 500 mA voor DSMR6 X1 toegevoegd ]

[Lord Anubis]

hterhofte schreef op vrijdag 10 april 2026 @ 21:43:
[...]


Je vraag over knoppen + stroom:
Ik denk dat de echte zorg zit in piekverbruik (wifi), niet in de knoppen zelf. Een GPIO met knop trekt normaal nauwelijks extra stroom, zo begrijp ik. Contactdenderen is meer een software-issue.

Ik kan me niet herinneren dat we resets door knopgebruik zijn tegengekomen. Brownouts door wifi-pieken zijn waarschijnlijker.

Tot slot: we zijn later begonnen met een nieuwe generatie hardware:
https://github.com/energi...dforheat-p1-base-hardware

Daar gebruiken we o.a. een M5CoreInk. Het oude ontwerp had relatief veel knoppen (verwarrend en niet zo robuust bij verzending). Met M5Stack hardware lossen we dat grotendeels op.

Bedankt voor je antwoord.
Echter de extra stroombelasting door het denderen verdwijnt niet door softwarematige ontdendering, en jullie oplossing is grotendeels kleinendeels waar.

Ter wille van de gedachten gang. Hier is het verschil en uitgebreidere uitleg over verschil SW of HW ontdenderen.

· Wat software (anti-dender) doet: Het negeert de extra snelle pulsjes na de eerste stabiele meting. Het is uiteindelijk maar een timer. De GPIO software ziet/verwerkt het dus maar één echte “indrukking”, maar de hardware heeft nog steeds al die snelle aan/uit-cycles laten plaatsvinden en geeft voor iedere dender kleine piekstroompjes.

· Wat er elektrisch gebeurt tijdens denderen is dat Bij elke overgang van hoog naar laag (of omgekeerd) vloeit er kortstondig een piekstroom, vooral als de knop de GPIO direct naar massa trekt zonder weerstand (pull-up alleen intern, of nog erger helemaal geen pull-up). Die piekstroom kan kort oplopen tot tientallen mA per transitie. Het ging bij mij erom hoe snel gaat de 470uF leeg, het kan zomaar een drempel te ver zijn.


· Praktijkimpact brainfart: Bij een paar denderpulsen (bijv. 5-20 ms lang) klopt het dat de totale extra energie verwaarloosbaar is ten opzichte van de WIFI-opbouw ( activeren) of de WiFi-transmissie (tientallen tot honderden mA). Het wordt pas problematisch alsde buffer al bijna leeg is en de gebruiker op de knoppen blijft drukken waarbij dan elke mA telt. Die piekstroom kan je ESP voeding doen resetten.

Zelf ga ik ( altijd ) hardwarematig ontdenderen: een RC-filter (weerstand + condensator) of een Schmitt-trigger. Dan ontstaat er per indrukking exact één schone flank met minimale piekstroom.

Software oplossing is voor functionaliteit (één keer reageren), geen oplossing voor stroompieken en daardoor liever een kleine serieweerstand van 1k-10k in het knopsignaal. Die dingen zijn vaak al van beroerde kwaliteit.,

Ik ga het andere ontwerp bekijken. Merci beaucoup.

[Hippe Lip]

hterhofte schreef op vrijdag 10 april 2026 @ 21:43:
[...]
- DSMR6 / NextGen (X1: RJ45 + 500 mA via USB-voedingspoort van slimme meter)
Niet voor ontworpen

Heeft de nieuwe DSMR6-meter behalve die X1-poort ook een ‘gewone’ P1-poort zoals de DSMR5-meters (en lager), zodat een bestaande P1-dongle daarop aangesloten kan worden?

[ Voor 8% gewijzigd door Hippe Lip op 11-04-2026 09:21 ]

[ZwarteIJsvogel]

Nee. De X1 interface kan wel P1-telegrammen leveren via een websocket. Om de P1-telegrammen door te sturen naar bv. een P1-dongle heb je een X1-P1 converter nodig. Je kunt het allemaal nalezen in de X1 Companion Standard.

[hterhofte]

ZwarteIJsvogel schreef op zaterdag 11 april 2026 @ 09:51:
Nee. De X1 interface kan wel P1-telegrammen leveren via een websocket. Om de P1-telegrammen door te sturen naar bv. een P1-dongle heb je een X1-P1 converter nodig. Je kunt het allemaal nalezen in de X1 Companion Standard.

Kleine aanvulling hierop (en misschien inmiddels een tikje off-topic voor een P1-thread 😉):

DSMR6 / X1 (NextGen) is nog volop in ontwikkeling. De huidige X1 Companion Standard (v6.0.0) is een werkversie; details (o.a. API/security) zijn nog niet definitief.

Wat wel al redelijk duidelijk is:

- X1 is de opvolger van P1
→ RJ45 (ethernet), geen wifi
→ data via lokaal portaal, REST (historie) en WebSockets (realtime)

- Architectuur wordt modulair
→ “slimme” deel zit in losse gateway op de meter
→ draait op embedded Linux met gescheiden applicatielaag

- Security is steviger opgezet
→ TLS (minimaal 1.3) op lokale verbinding
→ interne PKI + ondertekende meetdata
→ autorisatie fysiek op de meter geregeld

- Voeding extern
→ geen PoE op X1
→ wel USB-C voor voeding: 5V / ~500 mA
→ alleen power (geen data), en loopt via je eigen verbruik

Qua tijdlijn (voor zover publiek af te leiden):

- 2025–2026: specificatie + aanbestedingen + start ontwikkeling
- vanaf ~2027: eerste uitrol verwacht
- vóór 2029: nodig i.v.m. uitfasering GPRS

Kort gezegd: richting is duidelijk (ethernet + lokaal + secure), maar het ecosysteem is nog niet “af”. Dus interessant om rekening mee te houden, maar nog wat vroeg om volledig op te bouwen i.p.v. P1.

--- nabrander

En nog een reality check qua timing: die hele NextGen-ontwikkeling loopt een beetje parallel aan een veel urgenter probleem: het uitzetten van 2G/GPRS per 2029.

Daarom moeten er de komende jaren ~2-2,5 miljoen slimme meters vervangen worden (plus nog een flinke bak oude meters). Dat tempo ligt zo hoog dat netbeheerders nu gewoon pragmatisch 4G/LTE(-M) meters plaatsen als vervanging.

Mijn lezing: die 2029-deadline gaan ze halen met “gewoon” DSMR5-achtige opvolgers, en DSMR6/X1 komt daar stap voor stap overheen gerold zodra het echt af is.

Oftewel: tegen de tijd dat X1 helemaal strak en stabiel is, heb je waarschijnlijk al drie P1-dongles versleten 😉

[ Voor 16% gewijzigd door hterhofte op 11-04-2026 11:00 ]

[hterhofte]

Lord Anubis schreef op zaterdag 11 april 2026 @ 07:35:
[...]
· Praktijkimpact brainfart: Bij een paar denderpulsen (bijv. 5-20 ms lang) klopt het dat de totale extra energie verwaarloosbaar is ten opzichte van de WIFI-opbouw ( activeren) of de WiFi-transmissie (tientallen tot honderden mA). Het wordt pas problematisch alsde buffer al bijna leeg is en de gebruiker op de knoppen blijft drukken waarbij dan elke mA telt. Die piekstroom kan je ESP voeding doen resetten.

Denk dat we hier grotendeels op één lijn zitten: de energie-impact van knopdender is verwaarloosbaar t.o.v. WiFi-pieken (dat is ook precies waar die 470 µF in het ontwerp voor zit).

Voor de volledigheid: de GPIO’s zijn in de firmware gewoon correct als input met pull-up geconfigureerd, dus er lopen geen significante stromen via de knoppen (dender verandert daar niets aan).

Ons ontwerp was ook echt gericht op een specifieke use case: in een meetcampagne van enkele weken wordt het device in het begin een paar keer bediend, en daarna vrijwel niet meer, terwijl periodiek (elke 5 á 10 min) automatisch meterstanden worden verzameld en verzonden.

Dat is denk ik net een andere context dan “veelvuldig interactief knopgebruik”, maar energetisch zit de bottleneck sowieso bij radio/WiFi, niet bij de knoppen.

[Raven]

@hterhofte
"RJ45 (ethernet), geen wifi "
"wel USB-C voor voeding: 5V / ~500 mA "

Hmm, ik dacht even aan iets a la TL-WR802N voor als het draadloos moet, maar die heeft meer dan 500mA nodig. Denk niet dat een ESP32 tegelijkertijd ethernet en wifi kan doen. Vraag mij dan nu af hoe je zo'n meter draadloos zou kunnen benaderen

[hterhofte]

Raven schreef op zaterdag 11 april 2026 @ 11:29:
@hterhofte
"RJ45 (ethernet), geen wifi "
"wel USB-C voor voeding: 5V / ~500 mA "

Hmm, ik dacht even aan iets a la TL-WR802N voor als het draadloos moet, maar die heeft meer dan 500mA nodig. Denk niet dat een ESP32 tegelijkertijd ethernet en wifi kan doen. Vraag mij dan nu af hoe je zo'n meter draadloos zou kunnen benaderen

Als ICT-er van huis uit zonder formele hardware-opleiding zit ik aan de rand van mijn kennis hier, maar toch: denk dat hier twee use cases door elkaar lopen.

1) P1 / X1 uitlezen (monitoring):
Voor zover ik het zie zijn er maar weinig use cases waarbij je echt per seconde P1/X1-data hoeft te verwerken of te pushen. Het typische patroon is juist event/periodiek: device blijft grotendeels idle, wordt kort actief om data uit X1 (RJ45 / 1000BASE-T) te lezen en stuurt daarna een korte update via WiFi. Dat past ook goed binnen een 5V / 500 mA budget, mits je ontwerp rekening houdt met piekstromen (WiFi + Ethernet PHY + CPU bursts) en voldoende buffering (zoals die 470 µF).

2) Realtime control (bijv. EVSE / HEMS / Modbus/RS485-achtige integratie):
Daar zit je in een andere klasse: lage latency, lokale regelkring en vaak een bedrade of industriële interface (Ethernet, RS485/Modbus e.d.). WiFi kan technisch ook in een 1 Hz push scenario, maar dan zit je continu in een relatief hoge duty cycle met bijbehorende piekstromen (orde 100-300 mA WiFi + 50-150 mA Ethernet PHY afhankelijk van implementatie). Dat kan binnen 500 mA, maar met beperkte marge.

Kort gezegd: X1 + ESP32 + WiFi kan prima binnen 500 mA, maar het is geen “free lunch continuous system”. Het werkt goed als burst/edge device, minder als altijd-actieve dual-radio realtime node.

Persoonlijk vind ik een richting als X1 + Matter over Thread dongle (gebaseerd op ESP32-C6?) voor dit soort edge-energie-data overigens interessanter worden qua ecosysteem en power-efficiency, maar dat is meer een architectuurkeuze.

[Lord Anubis]

Raven schreef op zaterdag 11 april 2026 @ 11:29:
@hterhofte
"RJ45 (ethernet), geen wifi "
"wel USB-C voor voeding: 5V / ~500 mA "

Hmm, ik dacht even aan iets a la TL-WR802N voor als het draadloos moet, maar die heeft meer dan 500mA nodig. Denk niet dat een ESP32 tegelijkertijd ethernet en wifi kan doen. Vraag mij dan nu af hoe je zo'n meter draadloos zou kunnen benaderen

Beetje afhankelijk van je data. Maar je kan de ESP-IDF lib gebruiken in C++ en het bevat een voorbeeld genaamd eth2ap. Werkt wel als je genoeg ram hebt en geen display e.t.c.
(Ooit getest ( esp32S3 ) om een ethernet signaal te sturen via ESP-NOW naar een MQTT server te sturen en dat werkte ook. Geen WIFI stack nodig.)

Denk alleen dat je zoals hterhofte hierboven schreef je een 1x sec continue transmit kan creeeren maar dat het verbinden naar je wifi langer duurt en je dus toch al achter loopt en continue al die stroom verbruiken met alle risico van dien. Een 1 Hz transmit is geen echte burst. Het is een bijna-continu belastingsprofiel, waarbij de radio elke seconde actief is. Dat resulteert in een constante warmteontwikkeling en het alleen maar heet wordt terwijl je met de 1 sec data niets mee kan. Zelf denk ik ook niet voor 100% nul op de meter situatie's als je daar aan denkt.

[ Voor 27% gewijzigd door Lord Anubis op 11-04-2026 12:24 ]

[Hippe Lip]

ZwarteIJsvogel schreef op zaterdag 11 april 2026 @ 09:51:
Nee. De X1 interface kan wel P1-telegrammen leveren via een websocket. Om de P1-telegrammen door te sturen naar bv. een P1-dongle heb je een X1-P1 converter nodig. Je kunt het allemaal nalezen in de X1 Companion Standard.

Dank je. Dat document had ik intussen ook gevonden, maar nog geen informatie –laat staan een leverancier– over een X1-P1-converter.

[ZwarteIJsvogel]

Hippe Lip schreef op zaterdag 11 april 2026 @ 12:02:
[...]

Dank je. Dat document had ik intussen ook gevonden, maar nog geen informatie –laat staan een leverancier– over een X1-P1-converter.

X1-P1 converters gaan denk ik pas komen als de nieuwe generatie meters in het veld verschijnt. In NetNL 42 van april 2024 werd 2027 genoemd als startjaar van de uitrol, maar dat gaat vast (veel) later worden.

[iMars]

hterhofte schreef op vrijdag 10 april 2026 @ 21:43:
[...]

- DSMR 5.x (~250 mA volgens spec)
Ruimer, maar wij hebben het ontwerp niet specifiek daarop geoptimaliseerd
Of je zonder buffer kunt durf ik niet zeker te zeggen

[...]

Het is inderdaad specificatie, geen garantie. Zo zijn de ZIV meters echt een ramp om daar een beetje voeding eruit te halen.

Raven schreef op zaterdag 11 april 2026 @ 11:29:
@hterhofte
"RJ45 (ethernet), geen wifi "
"wel USB-C voor voeding: 5V / ~500 mA "

Hmm, ik dacht even aan iets a la TL-WR802N voor als het draadloos moet, maar die heeft meer dan 500mA nodig. Denk niet dat een ESP32 tegelijkertijd ethernet en wifi kan doen. Vraag mij dan nu af hoe je zo'n meter draadloos zou kunnen benaderen

Volgens mij zijn ze daarmee bezig bij ESPHome, voor wifi en ethernet. Hoorde van Jesse (ontwikkelaar bij esphome) dat het op de lijst staat waarmee ze bezig zijn. Zou wel mooi zijn als dat kan ja

[Martin7182]

Raven schreef op zaterdag 11 april 2026 @ 11:29:
@hterhofte
"RJ45 (ethernet), geen wifi "
"wel USB-C voor voeding: 5V / ~500 mA "

Hmm, ik dacht even aan iets a la TL-WR802N voor als het draadloos moet, maar die heeft meer dan 500mA nodig. Denk niet dat een ESP32 tegelijkertijd ethernet en wifi kan doen. Vraag mij dan nu af hoe je zo'n meter draadloos zou kunnen benaderen

500 mA gemiddeld zou voor mij sowieso afvallen (dat is ~22 kWh per jaar). Ik gebruik nu een Raspberry PI Zero-W en die trekt een heel stuk minder. Moet het nog exact nameten, maar de geringe warmte die eraf komt doet vermoeden dat het in de orde van 100 mA of minder is.

[hterhofte]

Martin7182 schreef op zaterdag 11 april 2026 @ 14:59:
[...]

500 mA gemiddeld zou voor mij sowieso afvallen (dat is ~22 kWh per jaar). Ik gebruik nu een Raspberry PI Zero-W en die trekt een heel stuk minder. Moet het nog exact nameten, maar de geringe warmte die eraf komt doet vermoeden dat het in de orde van 100 mA of minder is.

Hardware kan best wel wat schelen, maar goed nagaan wat je echt nodig hebt en slim schedulen goed ook.

Wij zijn voor de tweede generatie van NeedForHeat (open hardware en software zie https://arxiv.org/pdf/2509.06927) overgestapt op de M5Stack CoreInk als basismodule. Die kan behalve deep sleep ook 'helemaal uit'; alleen een externe BM8563 RTC staat dan aan die slechts 2.3 μA, trekt. Met een beetje slimme scheduling (zie https://www.energietransi...are/measuring/scheduling/ ) kom je dan een stuk verder als je bijvoorbeeld slechts elke 10 minuten een sensorwaarde nodig hebt; tussendoor 'helemaal uit' loont namelijk al bij meetintervallen van 1 á 2 minuten of groter.

Voor onze Living Room module inclusief Sensirion SCD41 CO₂ monitoring konden we zo uit de 390 mAh LiPo van de CoreInk tot 3 dagen autonomie krijgen. Helaas onvoldoende voor ons type onderzoek en tijd om een 3x AAA BatteryBASE te maken hadden we ook niet meer, dus toen toch maar aan de stekker laten leggen tijdens de metingen.

[Raven]

hterhofte schreef op zaterdag 11 april 2026 @ 11:52:
[...]


Als ICT-er van huis uit zonder formele hardware-opleiding zit ik aan de rand van mijn kennis hier, maar toch: denk dat hier twee use cases door elkaar lopen.

1) P1 / X1 uitlezen (monitoring):
Voor zover ik het zie zijn er maar weinig use cases waarbij je echt per seconde P1/X1-data hoeft te verwerken of te pushen. Het typische patroon is juist event/periodiek: device blijft grotendeels idle, wordt kort actief om data uit X1 (RJ45 / 1000BASE-T) te lezen en stuurt daarna een korte update via WiFi. Dat past ook goed binnen een 5V / 500 mA budget, mits je ontwerp rekening houdt met piekstromen (WiFi + Ethernet PHY + CPU bursts) en voldoende buffering (zoals die 470 µF).

2) Realtime control (bijv. EVSE / HEMS / Modbus/RS485-achtige integratie):
Daar zit je in een andere klasse: lage latency, lokale regelkring en vaak een bedrade of industriële interface (Ethernet, RS485/Modbus e.d.). WiFi kan technisch ook in een 1 Hz push scenario, maar dan zit je continu in een relatief hoge duty cycle met bijbehorende piekstromen (orde 100-300 mA WiFi + 50-150 mA Ethernet PHY afhankelijk van implementatie). Dat kan binnen 500 mA, maar met beperkte marge.

Kort gezegd: X1 + ESP32 + WiFi kan prima binnen 500 mA, maar het is geen “free lunch continuous system”. Het werkt goed als burst/edge device, minder als altijd-actieve dual-radio realtime node.

Persoonlijk vind ik een richting als X1 + Matter over Thread dongle (gebaseerd op ESP32-C6?) voor dit soort edge-energie-data overigens interessanter worden qua ecosysteem en power-efficiency, maar dat is meer een architectuurkeuze.

Nou, ik geef zelf de voorkeur aan 1x per seconde, al is dat dan specifiek voor vermogen en niet voor energie of gas, die 2 mogen wel wat minder vaak. Bij moeders hangt er een DSMR5 meter en de data daarvan ging rechtstreeks naar een daar geplaatste RPi, die de telegrammen parsde en daarna alleen dat wat ik wil bewaren (2x kWh-telwerk, vermogen, gas en netspanning) doorstuurde naar Home Assistant en in een SQL-database gooide. Maar dat is bedraad.

In mijn huidige woning hangt een meter die over een paar jaar niet meer kan communiceren met Enexis (2G / GPRS), deze geeft maar 1x per 10s data. Heb inmiddels wel een CT-klem liggen (SCT-013-000) zodat ik voor vermogen toch vaker metingen kan krijgen.

Overigens heb ik wel bedrade netwerktoegang bij de meter, had de telefoonlijn vervangen door een netwerkkabel en er ligt een PoE-powered ESP32 klaar die ook via die kabel communiceert die daar gaat komen. Maar die houdt de kabel dan in gebruik daar die ook voor andere dingen gebruikt gaat worden (er hangen ook modbus-meters).

Mocht die DMSR6 variant eerder beschikbaar komen dan de planning om de DMSR2 meter te vervangen, dan zou ik de X1-P1 converter kunnen gebruiken en net als op de gebruikelijke manier de meter aan de UART Rx van een ESP32 / RPi kunnen hangen? (Uiteraard wel lettend op de logic level )

Lord Anubis schreef op zaterdag 11 april 2026 @ 11:53:
[...]

Beetje afhankelijk van je data. Maar je kan de ESP-IDF lib gebruiken in C++ en het bevat een voorbeeld genaamd eth2ap. Werkt wel als je genoeg ram hebt en geen display e.t.c.
(Ooit getest ( esp32S3 ) om een ethernet signaal te sturen via ESP-NOW naar een MQTT server te sturen en dat werkte ook. Geen WIFI stack nodig.)

Denk alleen dat je zoals hterhofte hierboven schreef je een 1x sec continue transmit kan creeeren maar dat het verbinden naar je wifi langer duurt en je dus toch al achter loopt en continue al die stroom verbruiken met alle risico van dien. Een 1 Hz transmit is geen echte burst. Het is een bijna-continu belastingsprofiel, waarbij de radio elke seconde actief is. Dat resulteert in een constante warmteontwikkeling en het alleen maar heet wordt terwijl je met de 1 sec data niets mee kan. Zelf denk ik ook niet voor 100% nul op de meter situatie's als je daar aan denkt.

Hier ligt een ESP32-PoE-ISO klaar van Olimex , maar die houdt dan wel de enige kabel in gebruik.

Hmm, misschien komt iemand op het idee om dit via Matter de doen zoals @hterhofte beschreef.

iMars schreef op zaterdag 11 april 2026 @ 14:33:
[...]

Volgens mij zijn ze daarmee bezig bij ESPHome, voor wifi en ethernet. Hoorde van Jesse (ontwikkelaar bij esphome) dat het op de lijst staat waarmee ze bezig zijn. Zou wel mooi zijn als dat kan ja

Ok , hier heb ik een ESP32-PoE-ISO liggen die in de meterkast gaat komen, zodra LAN begon te werken werd wifi uitgeschakeld. Maar LAN wordt dan ook voor voeding gebruikt, die kan ik dan niet aan de meter hangen.

Martin7182 schreef op zaterdag 11 april 2026 @ 14:59:
[...]

500 mA gemiddeld zou voor mij sowieso afvallen (dat is ~22 kWh per jaar). Ik gebruik nu een Raspberry PI Zero-W en die trekt een heel stuk minder. Moet het nog exact nameten, maar de geringe warmte die eraf komt doet vermoeden dat het in de orde van 100 mA of minder is.

Daar kan ik wel mee leven

[iMars]

Raven schreef op zaterdag 11 april 2026 @ 18:05:

[...]
Ok , hier heb ik een ESP32-PoE-ISO liggen die in de meterkast gaat komen, zodra LAN begon te werken werd wifi uitgeschakeld. Maar LAN wordt dan ook voor voeding gebruikt, die kan ik dan niet aan de meter hangen.
[...]

Nu is het zo bij esphome dat je alleen ethernet, of alleen wifi in de config kan zetten. Doe je beiden, dan geeft ie een foutmelding bij het maken van de firmware.

Ik weet niet hoe dat in andere talen/manieren gaat, zoals Arduino, Python, etc.

Die ESP32-PoE-ISO heb ik hier ook een aantal varianten van liggen. Zover ik weet kan je sowieso de PoE stroom trekken/gebruiken, zonder dat je ip configuratie via ethernet gaat. Je zou dus de wifi moeten kunnen gebruiken en stroom van ethernet/PoE (maar waarom zou je dat willen denk ik dan gelijk. Ethernet is stabieler dan wifi en hoe minder devices op wifi, des te lager de channel utilization/vervuiling )

[Raven]

@iMars Hier gebruik ik de 16MB build van ESPEasy, oftewel de max build met alles erin Zodra de netwerkcontroller werkt zet ie wifi uit. Maar stel dat die DSMR6 meter komt en ik wil de ESP32 via netwerkkabel zijn ding laten doen (zowel voeding als verbinding) dan zou ik in het geval van de DSMR6 variant de X1->P1 adapter nodig hebben omdat er geen bedrade netwerkkaart beschikbaar is om de X1 poort op aan te sluiten?

[iMars]

Ik heb me nog niet zo verdiept in de nieuwe X1 poort. Maar ik doe een aanname dat de X1 poort een "simpele" ethernet aansluiting is... en geen poe levert (of heb ik het daar nu mis)?

Even specificatie opgezocht: https://www.netbeheernede...x1_companion_standard.pdf

4.1.2. Fysieke poort: RJ45 >> Deze poort biedt geen Power over Ethernet (PoE)
4.1.3. Fysieke poort: USB-C poort >> Voeding is beperkt tot maximaal
500mA/5V, is kortsluitvast en is onderdeel van het bemeten voedingscircuit van de
elektriciteitsmeter (klant betaalt de stroomkosten voor voeding).

De meter zelf heeft geen vast ip-adres, het is of een dhcp-adres, of een apipa adres.

Als je een ESP32-PoE-ISO gebruikt, maak je dus geen gebruik van je PoE en zal je het via de usb-c poort moeten voeden (een goedkopere WT32-ETH01 is dan misschien een betere keuze qua prijs).

Voor iedereen die de router, of een switch in de meterkast hebben zou mijn advies om een directe ethernet verbinding te nemen (there goes my business )

Voor diegene die dat niet hebben, zou er dus een eth2wifi functie gemaakt moeten worden. Dan op de ethernetpoort een dhcp servertje draaien, of met apipa werken. En de output via wifi.

[Lord Anubis]

Nog veels te ver weg om je hierop voor te bereiden.

Enige wat ik me afvroeg is is er dan een dubbele implementatie van een data afnemer (maar wel 1 teller); 1 voor de net beheerder en 1 die aangezet wordt voor de klant als er dus voeding op komt te staan.

[hterhofte]

Ja, het gaat nog even duren voordat we X1 in het wild zien, maar het onwtwerp- en implementatieproceds is volop gaande. Nog even wat info over de timing van het NextGen proces waar de lokale X1 interface deel van uitmaakt (uit de aanbestedingspresentatie van de app layer van 15 mei 2024, dus de timing kan best gewijzigd zijn; als iemand meer weet lees ik het graag):


In de aanbestedingsdocumenten staat ook:

The DSO will provide a converter to consumers that own a P1 device. This converter converts the default X1 output to the previous DSMR5.0.2 P1 Companion Standard output. This converter is not part of the DSMR6 tender.

De aanbestedingsdocumenten zijn te vinden via https://ted.europa.eu/en/...ge=1&simpleSearchRef=true

• DSMR6 Gateway and OS: https://s2c.mercell.com/today/79193
• DSMR6 App-layer: https://s2c.mercell.com/today/87307
• DSMR6 Public Key Infrastructure (PKI): https://s2c.mercell.com/today/122647

[Lord Anubis]

Nog snel in een paar dgn een offerte indienen gaat mij niet meer lukken.
Dus uiteindelijk ligt het protocol in principe vast.