Netz NOE

[tyler123durden]

Ich habe leider bei einem Netz NÖ Kaifa Zähler ein Problem.

1) Scheint das Timing hier etwas langsamer zu sein, die Pause zwischen erstem und zweitem Datensatz sind ca. 160ms:

2) Scheint auch das Datenformat etwas anders zu sein. Meine zwei Nachrichten sehen so aus:

68FAFA68            4 M-Bus Start long frame, FA=länge=250
53FF00              3 C field, A field, CI Field
0167                2 ?
DB08                2 ?
4B464D65509C2EFD    8 System Title
81F820              3 ?
0003301D            4 Frame Counter
D5 99 FF 9E 43 BF F9 39 F1 9F 49 7D 59 69 CD 5C 60 70 98 6A 37 38 CF 6F DB 93 93 E7 E0 FD A9 25 8C 08 11 88 59 EF 32 64 93 BC DA C6 2A 2E E3 20 5C 15 D2 6A 6C 67 28 61 3E 71 DC DC 72 25 15 BF 4C 41 8E 58 58 FE 7C 08 A2 B6 2A 1E 01 FB 8D DB 6C 06 48 01 52 29 3E 32 9D 70 4C CF A4 7B 8B 24 F7 76 B8 32 16 7C CA 37 D1 19 D6 8A A6 A5 51 7E 2D E5 BB 1E 49 B0 34 5D 18 A2 B1 D0 41 FF 7F 1F 75 1F F6 3C 1D 4D 13 DB 0A B9 69 E3 89 3E 4D C9 4F 85 A3 6F 08 CD E8 E8 BC 9D C5 30 EF 58 58 F8 43 F3 49 A5 27 03 E3 D0 B5 C5 84 6A 56 B3 D5 26 2E D5 45 2E A6 68 17 0F 0A AE 87 AA E5 ED CF B9 89 D1 14 F7 6F BE AD 54 55 04 C3 E9 1D EB 1F 6D A6 4D 0F 4E F2 4C 08 82 F4 15 08 EC E2 11 E4 17 BD 6C B1 3E 
86                  Checksum
16                  M-Bus Stop

Packet2: 
68 14 14 68 53 FF 11 01 67 91 04 E9 DE 70 8A 11 07 36 93 57 93 36 80 F9 9B 16

68141468        4 M-Bus Start long frame, FA=länge=250
53FF11          3 C field, A field, CI Field
0167
91 04 E9 DE 70 8A 11 07 36 93 57 93 36 80 F9 
9B              Checksum
16              M-Bus Stop

Damit ist zB die ersten Payload 228 Byte lange und nicht 227 wie bei dir. Und der zweite Teil vom IV liegt bei Index 22

Mich würde vorallem interessieren, ob das schon wer erfolgreich mit diesem Code laufen hatte?

Gibt es eigentlich irgendwo eine frei verfügbare Spec von MBus und DLMS oder hat da sowieso wieder jeder sein eigenes Protokoll?

[FKW9]

Mit genau diesem Programm: Nein. Habe ihn an einigen Stellen modifizieren müssen, aber im Prinzip funktioniert er für den Kaifa MA309 von NetzNÖ. Die Payload ist 228 und Index vom IV ist 22, das stimmt. Meine gesamte Payload ist 243.

Die Pause zwischen den Paketen liegt bei mir auch so in dem Bereich, sollte aber kein Problem sein, da ja eh gewartet wird, bis das 2. Paket ankommt (bis timeout).

Die Doku von EVN wirst du vielleicht schon kennen: 218_9_SmartMeter_Kundenschnittstelle_lektoriert Wenn du willst, kann ich die modifizierte Version von mir publishen, inklusive Excel Auswertung wie die entschlüsselte ADPU zu interpretieren ist.

MfG

[tyler123durden]

Danke für die Info. Die EVN Doku kenne ich schon und so kann ich die Daten auch Parsen. Scheinbar funktioniert der Code auch nicht für die entschlüsselte APDU zumindest bei mir gibt es Fehler. Das soll jetzt überhaupt keine Kritik an dem Projekt sein, ich bin echt froh, dass es das gibt, es wurde ja nicht mit diesem Smart Meter entwickelt. Es ist halt ziemlich traurig, dass wir in AT keine einheitliche Schnittstelle über Infrarot haben können.

@mitsubishievo99 dein Code würde mich natürlich trotzdem interessieren.

Ich werde aber wahrscheinlich mal das AmsToMqttBridge Projekt versuchen, das dürfte alles können was ich brauche.

[FKW9]

Meine modifizierte Version ist jetzt gepublished.

Einheitlichkeit und Österreich? HAHA Am meisten stört mich ja, dass da ein chinesisches Produkt bundesweit ausgerollt wird, aber naja, kostet ja sonst zu viel. Ich schweife ab..

Vielleicht bringt dir mein Code was und nochmal Danke an @DomiStyle.

[tyler123durden]

Besten dank. Bei mir konnte ich mittlerweile auch die Energiedaten parsen, aber jetzt weiß ich auch wie man den Zeitstempel bekommt.

[deviant-aut]

Hab den Sagemcom T210-D von Netz-NOE

[21:14:11][D][uart_debug:114]: <<< 68:01:01:68:53:FF:00:01:67:DB:08:53:41:47:59:05:EA:DB:83:81:F8:20:00:00:67:C9:1C:7A:90:CD:08:DC:DF:38:AE:05:27:78:D7:CC:44:FD:C9:4D:08:3E:8F:51:77:FF:EA:4D:12:5A:74:1B:D8:6F:7C:2D:77:E8:E9:DB:14:B5:1E:EF:CE:3B:33:F5:7C:65:6B:4C:3A:D7:D1:61:60:DA:D8:0E:37:19:B5:21:80:21:14:B6:E2:59:22:F9:14:A8:70:44:66:50:AD:BC:D7:E6:C8:8C:F7:BA:CE:27:AD:60:09:BE:99:93:FC:21:FC:F5:52:3B:02:4C:4D:27:1E:45:9D:D0:D5:15:81:37:1A:3D:90:29:48:A9:A9:4A:DD:0C:28:4A:9D:BD

[21:14:11][D][uart_debug:114]: <<< 69:74:BE:20:DD:A0:04:35:0F:71:EB:5F:2A:D7:CB:C2:07:3B:7B:23:0B:64:59:C5:A3:78:96:99:C6:FB:0B:2B:E7:E4:C6:4E:B6:9D:D6:81:C7:1E:A9:F6:AC:38:29:A1:B1:9B:E1:2F:AC:9A:97:95:09:09:8B:EE:D4:B1:7C:4E:44:99:36:1D:5F:03:0F:CD:20:48:F0:3B:A7:2B:ED:97:A0:50:F6:43:DF:9E:29:88:C7:EB:CD:43:8C:8C:DB:52:9A:A7:D0:4C:60:B9:B6:BD:16:25:50:68:25:48:26:A7:16:68:0D:0D:68:53:FF:11:01:67:EB:68:7B:59:C5:97:C4:35:47:16

Ich verstehe nicht ganz warum mein MBUS-Start mit 68:01:01:68 daher kommt

68:01:01:68:                4   
53:FF:00:                   3
01:67:                      2
DB:08:                      2
53:41:47:59:05:EA:DB:83:    8
81:F8:20:                   3
00:00:66:BB:                4
E9:29:BB:8B:C5:A0:54:91:81:14:80:19:65:3C:B9:03:EF:4F:52:E4:01:68:C0:2F:2E:9D:BF:EF:96:4B:9B:60:28:F6:DB:7C:61:7E:8F:CF:A6:49:0F:BC:75:EC:34:45:64:18:D8:8C:99:02:A9:41:49:2E:2C:2C:F9:3F:86:D3:93:88:AD:A7:6C:53:F0:DC:BA:14:7E:DA:B0:0A:3D:E8:4F:11:49:E9:44:C7:BC:78:C4:E3:B8:36:DF:7D:02:BC:96:EF:70:F5:F3:33:D5:DE:93:AF:57:3B:0C:81:B9:7E:F3:A6:27:B9:10:CF:48:85:A8:7F:5C:D1:3A:3F:A9:74:86:04:DB:9B:25:40:A9:42:D0:FC:E3:86:A1:C4:0C:48:FC:6C:56:D4:CF:69:68:F7:C4:47:B4:66:07:57:0D:0E:F8:46:91:6B:C5:CF:CD:6A:0E:F9:F1:D9:6E:E5:E0:82:91:A9:8C:6C:4D:88:1F:03:04:90:28:A3:FD:2D:C4:C2:B9:2B:BD:32:8F:E8:D9:17:5F:E6:F4:9C:4D:3E:95:B3:08:22:41:03:D3:73:D7:A3:26:A6:92:0E:91:19:34:36:BA:B8:82:C0:C3:DA:EA:34:2A:D2:F3:   235
D0:16:

68:0D:0D:68:                4
53:FF:11:                   3
01:67:                      2
EA:6A:DA:9D:E6:38:70:D5:    8
F9:16                       2

payload kommt wie zu erwarten wie beim KAIFA mit 243 (235+8)

[firegore]

Ich hab an einem ruhigem Wochenende eine angepasste Version auf einem EVN Kaifa zum laufen gebracht. Ziel wärs dass auf Dauer zu mergen, leider fehlt mir aktuell dazu die Zeit.

Ich hab die Version allerdings mal hochgeladen, falls wer eine funktionierende Version braucht (hoffe das ist ok so wenn ich das hier so verlinke, soll ja auch dann gemerged werden). Getestet nur mit dem Kaifa MA309 EVN, ich nehm aber mal an dass die Sagecom die gleichen Daten zurückgeben.

https://github.com/firegore/esphome-dlms-meter

[deviant-aut]

Decrypting habe ich noch geschafft. Das Decoding habe ich dann direkt von @firegore übernommen. Ein paar OBIS-Typen werden noch nicht erkannt. Einziger Unterschied sind aktuell eigentlich nur die Payload/DLMS Offsets/Längen.

[Noschvie]

Hab den Sagemcom T210-D von Netz-NOE

Ich verstehe nicht ganz warum mein MBUS-Start mit 68:01:01:68 daher kommt

68:01:01:68:                4   
53:FF:00:                   3
01:67:                      2
DB:08:                      2
53:41:47:59:05:EA:DB:83:    8
81:F8:20:                   3
00:00:66:BB:                4
E9:29:BB:8B:C5:A0:54:91:81:14:80:19:65:3C:B9:03:EF:4F:52:E4:01:68:C0:2F:2E:9D:BF:EF:96:4B:9B:60:28:F6:DB:7C:61:7E:8F:CF:A6:49:0F:BC:75:EC:34:45:64:18:D8:8C:99:02:A9:41:49:2E:2C:2C:F9:3F:86:D3:93:88:AD:A7:6C:53:F0:DC:BA:14:7E:DA:B0:0A:3D:E8:4F:11:49:E9:44:C7:BC:78:C4:E3:B8:36:DF:7D:02:BC:96:EF:70:F5:F3:33:D5:DE:93:AF:57:3B:0C:81:B9:7E:F3:A6:27:B9:10:CF:48:85:A8:7F:5C:D1:3A:3F:A9:74:86:04:DB:9B:25:40:A9:42:D0:FC:E3:86:A1:C4:0C:48:FC:6C:56:D4:CF:69:68:F7:C4:47:B4:66:07:57:0D:0E:F8:46:91:6B:C5:CF:CD:6A:0E:F9:F1:D9:6E:E5:E0:82:91:A9:8C:6C:4D:88:1F:03:04:90:28:A3:FD:2D:C4:C2:B9:2B:BD:32:8F:E8:D9:17:5F:E6:F4:9C:4D:3E:95:B3:08:22:41:03:D3:73:D7:A3:26:A6:92:0E:91:19:34:36:BA:B8:82:C0:C3:DA:EA:34:2A:D2:F3:   235
D0:16:

68:0D:0D:68:                4
53:FF:11:                   3
01:67:                      2
EA:6A:DA:9D:E6:38:70:D5:    8
F9:16                       2

payload kommt wie zu erwarten wie beim KAIFA mit 243 (235+8)

Das ist ein bei EVN / Netz-NOE bekanntes Problem: beim Sagemcom T210 wird das Längen-Feld nicht korrekt versorgt. Netz-NOE ist dabei, die entsprechenden Kunden zu informieren. Also, du wirst demnächst von Netz-NOE eine Email bekommen...

[hvg1]

Ich hab an einem ruhigem Wochenende eine angepasste Version auf einem EVN Kaifa zum laufen gebracht. Ziel wärs dass auf Dauer zu mergen, leider fehlt mir aktuell dazu die Zeit.

Ich hab die Version allerdings mal hochgeladen, falls wer eine funktionierende Version braucht (hoffe das ist ok so wenn ich das hier so verlinke, soll ja auch dann gemerged werden). Getestet nur mit dem Kaifa MA309 EVN, ich nehm aber mal an dass die Sagecom die gleichen Daten zurückgeben.

https://github.com/firegore/esphome-dlms-meter

@firegore ist da ein update geplant? seit dem esphome update 12.2022 gibts auch da fehler.

[firegore]

@firegore ist da ein update geplant? seit dem esphome update 12.2022 gibts auch da fehler.

danke für die Info, ich hab denselben Fix angewandt, sollte so funktionieren

[hvg1]

danke schon mal für den fix, bei mir scheitert das updaten auf die neueste esphome version leider immer noch - die fehler sind error: 'byte' has not been declared bzw. error: 'byte' does not name a type, hängen also nicht mit der payload length zusammen 😞

eine verständnisfrage hätte ich noch: gibt es allgemein gesprochen tiefergreifende änderungen und/oder abhängigkeiten bei der nö variante als die unterschiede im decrypting & decoding was payloadlength, offset etc. angeht? sprich wenn ich die unterschiede bei den punkten kenne, kann ich das in jede version der generellen esphome-dlms-meter komponente von DomiStyle anwenden in dem ich die entsprechenden werte austausche?

[firegore]

error: 'byte' has not been declared bzw. error: 'byte' does not name a type,

okay, grade gesehen, der Fehler tritt nur bei esp-idf auf, stell derweil mal auf arduino Framework um, esp-idf geht derweil bei meiner Version noch nicht. Bis ich den Commit von Domi eingearbeitet hab, damits auch mit esp-idf geht wirds noch dauern.

eine verständnisfrage hätte ich noch: gibt es allgemein gesprochen tiefergreifende änderungen und/oder abhängigkeiten bei der nö variante als die unterschiede im decrypting & decoding was payloadlength, offset etc. angeht?

Jaein, die Offsets sind anders, die EVN Meter geben aber auch (einen) zusätzlichen OBIS Code mit aus die in DomisCode fehlen (ich hab aber ehrlich gesagt vergessen welcher das war). Das Hauptproblem ist aber dass die EVN am Ende die Zählernummer mitschickt, das ist allerdings verbugt weil laut Spezifikation der Zähler auch ein "Ende vom OBIS Code"mitschicken sollte, das tut er nach der Zählernummer aber nicht. Ebenso schickt der Zähler 2mal den Timestamp mit, anstatt wie üblich nur einmal.

Manchmal frage ich mich warum wir uns hier in Österreich um Standards bei den Zählern bemühen, bzw. diese als "Standardisiert" bezeichnet werden, wenn sowieso jedes Bundesland sein eigenes Süppchen kocht, obwohl die Hardware ja sogar gleich ist..

Die unterstützten OBIS Codes bzw. die offizielle EVN Doku mit mehr Infos gibts hier: https://www.netz-noe.at/Download-(1)/Smart-Meter/218_9_SmartMeter_Kundenschnittstelle_lektoriert_14.aspx

[hvg1]

okay, grade gesehen, der Fehler tritt nur bei esp-idf auf, stell derweil mal auf arduino Framework um, esp-idf geht derweil bei meiner Version noch nicht.

wo und wie genau mach ich das? bin bis jetzt mit der noch laufenden version gut durchkommen, aber jetzt "erinnert" mich ja auch home assistent direkt an des update..

[Noschvie]

Habe es geschafft, die beiden SmartMeter Varianten der EVN mit der aktuellen Tasmota Version auszulesen. Der Langzeit-Test läuft nun...

[tkoe2022]

Ein großes DANKE an euch vorallem an Feuergore.

Mit der Angepassten Firmware an den EVN Kaifa Smartmeter läufts perfekt.

Hab den Code etwas geändert und es läuft. Meine Hardware ist ein KC 868 A8 Board https://www.kincony.com/arduino-esp32-8-channel-relay-module-kc868-a8.html wo ich am Steckplatz RF433 den M-Bus Slave Click angebunden habe.

Für mein Energiemanagement verwende ich den vorhandenen Loxone Miniserver. Um die Sensoren bzw. auch die Eingänge und Ausgänge des Bords zu nutzen und keine Umwege über HA, FHEM, QB,... gehen zu müssen nutze ich UDP.

Hab mal meine yaml angehängt.

clean kc868 24.02.2024.yaml.txt

[sthayduk]

Hat vielleicht irgend jemand eine Idee was zu tun ist wenn man die Meldung bekommt:

[E][espdm:107]: Packet was decrypted but data is invalid

Ich hab das Repo von @firegore genommen und ich hab auch einen Kaifa MA309M von der EVN. Die Keys hab ich mehrfach überprüft und auch im korrekten 0x.., 0x.. Format eingetragen.

Leider bekomm ich trotzdem die oben genannte Meldung! logs_meter01_run.txt

[firegore]

Hmmn,

ich hab die aktuelle 2024.03 Esphome Version bei mir getestet, der Code dürfte noch funktionieren. Ich würde an deiner Stelle anfangen das Loglevel auf Verbose zu ändern und dann erneut ein Logfile anzuhängen (Achtung: dort sind dann die kompletten Pakete roh enthalten, falls dich das stört kannst du mir sonst den Log auch sonst an github@firegore.com senden)

Dann sieht man zumindest mal ob das Datenformat passt, die EVN vllt. was an der Zählerfirmware geändert hat so dass die Daten jetzt anders sind oder ob sowieso nur Müll vom Zähler daherkommt.

Beispiel vom Loglevel Verbose (du musst ebenfalls die tx_buffer_size auskommentieren/erhöhen)

# Enable logging
logger:
  level: VERBOSE
  tx_buffer_size: 2048 # Only needed when logging large packets

[firegore]

Was mich hier auch/eher stutzig macht ist der Buffer Overflow der zufällig bei dir Auftritt, das sollte eigentlich nicht passieren, die Pakete sollten 282~ Byte haben, der Buffer ist 1024 Byte groß. Deine Pakete haben aber manchmal über 1024 Byte, was den Buffer zurücksetzt.

Das sieht aktuell danach aus als dass die Daten die beim ESP32 ankommen schon "Müll" sind und nichtmehr entschlüsselt werden können.

Dazu wär ganz intressant:

• Welchen M-Bus Adapter verwendest du?
• Wie lang ist das Kabel zwischen Smartmeter und M-Bus Adapter?
• Wie/wo ist er am ESP32 und am Smartmeter angeschlossen?
• Wo am Kaifa hast du das Kabel angeschlossen? (der M-Bus Kundenanschluss ist unter der weißen Gummikappe; auf keinen Fall den verplombten M-Bus anschluss verwenden)

Edit: Ansonsten auch gern mal deine verwendete .yaml als Gist/Pastebin posten (nicht vergessen vorher WLAN PW und DLMS Key zu ändern

[ColdFire1985]

Hi Clemens @firegore. Exakt das gleiche Verhalten mit buffer overflow und daten die invalid sind habe ich auch.

Hab mal bei der EVN nachgefragt ob die an der Schnittstelle was geändert haben jedoch ohne Erfolg. Für morgen wurde mir ein Rückruf versprochen. Mittlerweile wurden schon 2 ESP esp32 mini und esp8266 versucht sowie und 2 verschiedene modbus platinen. Aktuell habe ich das modul von mikroe im einsatz. Mein setup ist also: ESP 32 D1 MINI TSS721ADR (modbus von Mikroe) Kabel länge bus < 20 cm und stromversorgung des ESP läuft über netzteil mit 2A ausgangsleistung

Hoffentlich kommt da bald jemand dahinter was hier nicht stimmt. Danke für deinen Support schon vorab!

[deviant-aut]

@ColdFire1985 Versuch mal einen 100uF kondensator an den 3V oder besorg dir einen ordentlichen esp. Die esp32 mini sind müll, mit dem kondi läuft der bei mir aber seit monaten stabil.

[sthayduk]

Ich hab’s mittlerweile zum laufen gebracht in dem ich auf meinem ESP den GPIO16 (RX2) verwendet hab. Seit dem läuft das bei mir eigentlich problemlos. Ich verwende aber einen normalen großen ESP!

[ColdFire1985]

Hallo zusammen. Also mittlerweile habe ich auf ein ESP32 board (kein mini) getauscht mit gleichem Ergebnis. Ich hab sogar ein neues Projekt im ESP home angelegt und alles neu eingerichtet. Mit dem modbus board TSS721ADR gab es einen Hinweis der bei mir auch nicht funktioniert hat (https://github.com/DomiStyle/esphome-dlms-meter/issues/7#issuecomment-1062191356) ausgelötet kein Erfolg. Ich brauche bitte noch einen Denkanstoß was ich noch tauschen/versuchen kann. @deviant-aut auch deinen Hinweis habe ich mit dem mini noch versucht sowie mit dem aktuellen esp32 board jedoch auch hier erfolglos. Danke aber für die sehr gute idee! ``

16:37:52	[W]	[component:232]	Component took a long time for an operation (210 ms).
16:37:52	[W]	[component:233]	Components should block for at most 30 ms.
16:37:54	[W]	[component:232]	Component took a long time for an operation (1261 ms).
16:37:54	[W]	[component:233]	Components should block for at most 30 ms.
16:37:54	[VV	][scheduler:226]	Running interval 'update' with interval=60000 last_execution=409214 (now=469314)
16:37:54	[V]	[espdm:038]	receiveBufferIndex: 147
16:37:54	[E]	[espdm:041]	Received packet with invalid size

``

[firegore]

Wie hast du denn die Modbus Adapter mit dem ESP32 verbunden? (Welche Pins und vorallem was genau) Hast du neben RX/TX/GND auch VCC (bzw. 3.3V) verbunden?

Wenn ich mich recht erinner muss nur RX/TX/GND (theoretisch sogar nur TX und GND) verbunden werden. Der M-Bus Adapter wird vom Smartmeter versorgt, ansonsten kann ich morgen auch mal in den Keller gehen und nochmal nachschauen wie ichs genau verkabelt hab.

[ColdFire1985]

Hi, Also den modbus adapter habe ich vom esp mit den 3v versorgt sowie ground. Pins für rx bzw tx habe ich lt board beschreibung (1/3 bzw 16/17) verkabelt. Umverkabelt auf deinen hinweis dass die 3v nicht vom esp kommen. Board ist aktiv und liefert aber noch immer zu wenige daten. mittlerweile schon auch verlötet da ich den steckern nicht traue. Brauch ich noch wo einen ferrit kern oder irgend so einen müll? @firegore kannst du mir evtl noch all deine anpassungen zukommen lassen bzw auf git republishen(coldfire ÄT coldfire PUNKT AT. ) ganzliebschau ? Hab jetzt noch mit timeouts buffersizes rumgespielt jedoch erfolglos.

Anbei noch einen DUMP:

[13:05:07][V][espdm:038]: receiveBufferIndex: 144 [13:05:07][E][espdm:041]: Received packet with invalid size [13:05:07][E][espdm:042]: receiveBufferIndex 144 [13:05:07][E][espdm:043]: currentTime 23320 [13:05:07][E][espdm:044]: lastRead 21846 [13:05:07][E][espdm:045]: readTimeout 1000 [13:05:07][V][espdm:547]: 68 68 01 67 08 46 9D F8 20 01 51 94 B0 4A D3 15 45 AB 9B C7 D3 4A A1 07 B9 80 46 4C DC 3B 7C 5D AB 38 CD FE 80 62 CE 08 C1 0D C4 64 46 85 E6 70 9D CB 7F F4 C8 8A CE DC D0 80 3D B6 D6 A1 CD 10 B0 40 4C F8 1F F2 B0 54 FD 37 2C 4C 5E 4C 61 D3 51 BF 15 38 37 8F DF 31 A8 B9 A1 43 B9 FE 8A 7A 54 EF 23 98 C1 EC DA BC 73 4F 04 57 D3 8C 64 2F 3E F4 DF 08 29 D9 94 E9 A7 45 75 51 1F 5B A7 92 07 6B C4 C7 16 68 68 01 67 07 0B B5 92 EC F1 16 [13:05:12][W][component:232]: Component <unknown> took a long time for an operation (1511 ms). [13:05:12][W][component:233]: Components should block for at most 30 ms. [13:05:12][V][espdm:038]: receiveBufferIndex: 151 [13:05:12][E][espdm:041]: Received packet with invalid size [13:05:12][E][espdm:042]: receiveBufferIndex 151 [13:05:12][E][espdm:043]: currentTime 28313 [13:05:12][E][espdm:044]: lastRead 26770 [13:05:12][E][espdm:045]: readTimeout 1000 [13:05:12][V][espdm:547]: 68 68 01 67 08 46 9D F8 20 01 0D 26 B9 4A CB EF 4F B3 BF 2C 32 BA 62 6E 04 2F 6E 70 86 BA BF D5 89 9E 2C 8C 46 2F 85 C7 C8 E6 2C 31 B0 BA AE 1C 20 A7 5D F1 0D 58 45 CB 46 97 7A 76 BC 98 3D 02 F4 6B 37 52 43 01 5E A1 6D 7A 80 73 49 4C E6 4C 3E 4C 3B 23 29 CB 70 70 07 29 86 5E D3 7C 62 51 64 B6 EA 5B 7C 10 0B 61 51 A7 5D E9 E5 45 C4 01 6E 79 BA 08 52 F2 4A 7A 29 9B 94 4A 4A DA D6 FE 6E 6E FB CE 7C 10 A2 FE D3 16 68 68 01 67 01 92 F1 54 7C E5 40 19 16 [13:05:17][W][component:232]: Component <unknown> took a long time for an operation (1161 ms). [13:05:17][W][component:233]: Components should block for at most 30 ms. [13:05:17][V][espdm:038]: receiveBufferIndex: 116 [13:05:17][E][espdm:041]: Received packet with invalid size [13:05:17][E][espdm:042]: receiveBufferIndex 116 [13:05:17][E][espdm:043]: currentTime 33147 [13:05:17][E][espdm:044]: lastRead 31947 [13:05:17][E][espdm:045]: readTimeout 1000 [13:05:17][V][espdm:547]: 68 68 01 67 08 46 9D F8 20 01 0E 08 70 E6 DC 2F FE 10 52 E9 D0 16 7C FB E6 F1 64 5D 4A 3E 40 20 BA 1A D6 CD 73 A7 E0 F7 04 6B D3 BC 1F AE F4 49 3D 64 EF 2F 94 92 A1 46 A7 CD C1 80 94 0E 51 79 CD F7 37 B0 52 CE 64 49 76 94 31 02 7A E9 67 A8 2A 2F 54 85 BC 31 70 13 98 07 B9 7C 19 D6 9B 3B 91 A1 91 80 78 D7 97 ED 16 68 68 01 67 4F 3D 98 DC BC B0 16

[firegore]

Ich hab dir meine derzeit verwendete Config hochgeladen in die Repo. mein ESP32 ist ein Olimex ESP32-POE-ISO und ist per Ethernet angeschlossen, wird aber per USB per Strom versorgt.

Ich hab auch definitiv nochmal nachgesehen und mein Mikroe Board hat nur RX/TX/GND verbunden, kein 3.3V.

Deine Daten sind zwar konsistent haben aber den falschen Header am Anfang. Das müsste z.b. so aussehen:

[16:23:11][D][espdm:045]: Handling packet
[16:23:11][V][espdm:543]: 68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 65 50 99 B6 1C 81 F8 20 00 C1 55 60 CB 39 30 80 43 92 97 9C 7F 50 0B 17 7E B5 71 4A D5 89 9C 4C F3 69 52 0C CF 74 14 ED 7A 03 33 4B 29 E9 A4 82 A3 E9 2C 1A 3E 71 61 AB EC 14 55 58 9D BD F1 61 C2 A0 F7 AA 81 63 04 6D 91 C4 79 7D A7 65 20 10 C3 D3 BA 18 04 77 B3 67 56 C3 16 24 BB 34 78 8A 69 F7 6B 11 8D B3 43 C0 E7 D2 36 83 B4 DB 5B B4 1E 3C 98 C8 50 A2 7E 2B A3 72 FC 0E 1E 15 89 B1 9D 4B 79 36 F2 D7 74 09 79 67 15 7B B3 3E 27 C9 96 E7 59 F3 BB E5 F7 F2 45 88 5A 82 91 4E 08 B2 3E 12 E0 5A F0 97 50 75 20 3F 4B 81 BB AB C2 E8 F5 01 DB 92 59 D1 C6 35 69 7A 25 8D 93 1C BF 23 45 C2 CC F4 0B 51 11 0E 33 0B A5 6C C3 1F E1 63 7F A3 8B 22 74 AC 19 CB 63 F8 25 E8 63 E2 6B 5B C4 F6 12 D4 D8 16 05 E1 F5 35 CC FE D9 B3 B1 72 8C 16 68 14 14 68 53 FF 11 01 67 FA A7 2E 1F 7F A6 50 56 5A F3 BB B0 3E 11 11 9C 16

M-Bus Pakete müssen immer mit 68 FA FA 68 anfangen. Wo am Smartmeter hast du denn das Kabel angeschlossen, am P1 (HAN) oder am P2 (M-Bus; verplombt)? Funktionieren tut nämlich nur der P1/HAN Port (der unter der weißen Gummilippe), der verplombte Anschluss ist nur für die EVN, nicht aber für die Kundenauslesung.

[ColdFire1985]

Danke für die Config. Ich werde mein Glück weiter versuchen. Hab natürlich am am P1 angeschlossen also unter dem gummi ding. Nochmals danke für deine Bemühungen. Wenn ich es diese Woche nicht hin bekomme dann lass ich es bleiben.

Update: 240416. Ich bekomme korrekte daten! Woran hats gelegen.... tja ich würde mal trauen mich zu behaupten beim Netzbetreiber. Ich habe erneut den smartmeter eintragen lassen im system (netz nö portal raus und einen tag später wieder rein) und die 15 min aktivieren lassen. Danach auch das ganze prozedere mit Key anforderung etc. Hat zwar erstmal an den rohdaten nichts geändert aber dann... siehe da ich erhalte korrrekte Daten mit einem korrekten header. Danke für eure wirklich guten Ideen und Anleitungen! What a nigthmare...

[SimonFischer04]

Für Interessierte: arbeite gerade an einer nativen esphome Integration: https://github.com/SimonFischer04/esphome/issues/1

[Noschvie]

Nur als Anmerkung: Modbus und M-Bus sind "zwei paar Schuhe". Hier wird ein M-Bus Adapter benötigt und keine Modbus Schnittstelle.

[gitHelmut]

Hallo! Zwei Fragen an die Protokollprofis hier: Frage 1: Die EVN Demodaten aus dem Kundenschnittstelle-PDF beginnen mit 68 FA FA 68 53 FF 00 01 67 DB 08 ... Von mir zuhause aufgezeichnete Daten (Kaifa MA309M) beginnen mit 68 FA FA 68 53 FF FF 01 67 DB 08 ... Woran könnte das liegen? (Das hat übrigens zur Folge, dass das Gurux-Tool meine aufgezeichneten Daten nicht parsen kann) Frage 2: Ich kann meine aufgezeichneten Daten zwar mit einem Python-Programm entschlüsseln, da steht aber nur Schrott drin. Die EVN Demodaten hingegen kann das Programm richtig entschlüsseln. Ist es möglich, dass die EVN falsche Schlüssel versendet?

[Noschvie]

@gitHelmut Bist du dir sicher, dass das doppelte FF (68 FA FA 68 53 FF FF 01 67...) vom Kaifa gesendet wird? Der Schlüssel ist davon unabhängig.

[gitHelmut]

@Noschvie Danke für die Anregung. Habs nun mit dem Oszi geprüft, sah nicht nach doppeltem FF FF aus. Habe dann meinen UART-Code von ein auf zwei Stop-Bits geändert, und siehe da, jetzt kommt FF 01 und die entschlüsselten Daten enthalten sinnvolle Werte. Freude Nächste Hürde: Jetzt würde ich die Daten gerne mit einem Raspi Pi Pico entschlüsseln. Du kennst nicht zufälligerweise eine AES-GCM Library für Micropython?

[Noschvie]

Kennst du dies: https://github.com/Gurux

Warum muss es ein Pico sein?