Netz NOE about esphome-dlms-meter HOT 32 OPEN

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

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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.

from esphome-dlms-meter.

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.

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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)

from esphome-dlms-meter.

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.

from esphome-dlms-meter.

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...

from esphome-dlms-meter.

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.

from esphome-dlms-meter.

@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

from esphome-dlms-meter.

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?

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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..

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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 [email protected] 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

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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!

from esphome-dlms-meter.

@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.

from esphome-dlms-meter.

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!

from esphome-dlms-meter.

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 (#7 (comment)) 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!
``

from esphome-dlms-meter.

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.

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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.

from esphome-dlms-meter.

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...

from esphome-dlms-meter.

Für Interessierte: arbeite gerade an einer nativen esphome Integration: SimonFischer04/esphome#1

from esphome-dlms-meter.

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

from esphome-dlms-meter.

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?

from esphome-dlms-meter.

@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.

from esphome-dlms-meter.

@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?

from esphome-dlms-meter.

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

Warum muss es ein Pico sein?

from esphome-dlms-meter.