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.