VKW - Invalide Daten

[da-winci]

Bekomme leider nur invalide Daten.
Mir scheint die Länge ist zu kurz, kann das sein?
Was kann ich machen um dem Problem auf die Schliche zu kommen?
Kann ich diese Datenwurst irgendwie händisch oder mit einem Tool entschlüsseln?
Den Entschlüsselungskey habe ich heute bekommen.
Bin wirklich um jede Hilfe dankbar!
Habe einen VKW MA309MH4 Smartmeter.

Laut Code müsste es hier fehlschlagen:

if (plaintext[0] != 0x0F || plaintext[5] != 0x0C)
{
     Serial.println("Packet was decrypted but data is invalid!");
     receive_buffer_index = 0;
     return;
}

14:26:17.366 -> 68FAFA6853FF000167DB084B464D1020043BD78201552100004483B42D5539F7DC88C9573AFB79C56C3C7A9D86BC3E5845A99FAE35C4CC93EB3247939D73D7EF31DF33BC169026B14B0B0F83225B18E5FC455CDCBB165AB649532E33869A74159289480BFF892769D8BF6C1279CF35CA04839A4A6387374B7610F5AFD57065D0CCF9FEAF2D61AF52AD08F314E20559283E102CB78043275B83A3439B6274F85FD3733768125DADF33D45B27AE6C98E521FE65B5CAFB8BF1BDBF6A478DEB7AC7D5D944C8382E10164FB0BD8B6AB86D9E1A9D22A7EDC3C2FBB8F625E654F322A932FA8CDA73DD0E0B687203A8799A8EC827DF50B685439452B8BDDF019D8202316 Packet was decrypted but data is invalid!
14:26:25.287 -> 68FAFA6853FF000167DB084B464D1020043BD78201552100004484BBF8DFACEF4578719FE6319FEC5F7DED2211FF8136E109033C4E83109DD974A4BABF3F47F66647C46FAC4E721C05DAEA46E714B6E1581FD9994857DE98B694D422C5CADC99D459483D72CF752BAD155D5C6F1C489ADD1F57FDC61901FA70A161DC0C2E8055796631B6C64586B264041078BF856EA3ABE9FCE6F80F29B77DFB4A9FB29A76BF8EDB0CA334D78EF3FBB7FFEE5BC118D3CA04316733DF41CB4561F91B6FAA5BDFD8CBC007A54FFFB918278F8FA122334607D080D012CB898A66806C6DF8C7D47DEEAB9A0CE51C5FAE168042EAB628D90ECD4B0133C0F57384A2C37A2333832B16 Packet was decrypted but data is invalid!
14:26:31.320 -> 68FAFA6853FF000167DB084B464D1020043BD78201552100004486AAC97CCE1C3291DEB08ECAA2AE8E71E87387F96A31C5CB231070E0BBF20FACD1C6BDC727ACF2DF0BCF66CFFB6DD407C22C51706864705CD409C6157024D1639BCFA78257F7BA34AB1DC9C5970A1608D4DAB7953AE8DD1516E2B1993C5D16047071AC6B8DC66FEF4E5DE1AB09EB04263FCAC700BA70BBF206153AC677B8841918B8302F26EC4F559B2F31A133D3E763196E68204F0AB6025A76DA8F1EFFF8DB2AB97B59F0A2415F9CBD34C9F56A464334B249AA710FC9857DD0AC564CC1415CFC7327FB8BB65F88278AB54AF6DFD5C84FCDDB8D8AA393444B6F9D88026C6C05A2FABCB6A116 Packet was decrypted but data is invalid!

[Noschvie]

VKW ist anders als Netz-NOE, kenne aber leider nicht die Details...

[da-winci]

Die hier verwendete DLMS Entschlüsselung sollte die VKW Zähler genauso unterstützen oder was ist hier anders?
Siehe ->https://github.com/DomiStyle/esphome-dlms-meter#supported-providers

[FKW9]

Hab mein Python test script hochgeladen
https://github.com/FKW9/esp-smartmeter-netznoe/tree/0446ace9308a83485453d2600443c40becfa098b/python

Bei deinen Daten fehlt das zweite Frame(beginnend mit 68141468). Probier mal das READ_TIMEOUT zu erhöhen.
Hast du einen TTL-USB Adapter? Das wäre optimal um die Daten abzufangen

[da-winci]

Das READ_TIMEOUT zu erhöhen hatte keine Auswirkung.
Hab nun ein zwei Datenframes mit einem TTL-USB Adapter aufgenommen.
Ich hoffe du kannst daraus mehr rauslesen als ich :)

Datenstream.txt

[Noschvie]

Habe in Erinnerung, dass es jemand mit Tasmota geschafft hat, einen "vorarlbergnetz smartmeter" auszulesen.

[FKW9]

Nein das ist kein zweites Datenframe, das ist schon die zweite Datenübertragung, die alle 5 Sekunden stattfindet.
Alle 5 Sekunden sollten zwei Daten-Frames in relativ kurzer Zeit hintereinander kommen, das erste beginnt mit 68FAFA68, das zweite mit 68141468.
[Frame1] -> 100ms -> [Frame2] -> 5 Sekunden warten -> Wiederholung

Vielleicht gibt es nur ein Frame bei VKW? Hast du dazu Infos?

NetzNÖ hat eine Anleitung, wie man händisch die Daten mit zwei Programmen entschlüsselt, probier das mal aus: 218_9_SmartMeter_Kundenschnittstelle_lektoriert_14.aspx

[micronano0]

@da-winci : ich habe mir deine Datenstream.txt Datei angeschaut und kann im 1. Moment keinen Fehler darin finden. Die Datensätze sind von der Byteanzahl her gleich lang wie mein Vergleichsdatensatz der funktioniert.
Auch im Header (die 1. 27 Bytes) scheinen korrekt zu sein. Auch das 2. Telegramm (ab Byte 256 ...) im Datensatz schaut gut aus.

Vielleicht möchtest du deine Daten mit dem Online Tool CyberChef checken.

AES ENCRYPT:
Key: dein key
IV (12 Bytes): 4B bis D7 und 00 00 8F A5
Mode: GCM
Input: Hex
Output: Hex

Input: hier kommt Telegramm1 + Telegramm2 rein

Telegramm1 Beginn: 83 (also BytePos 28 - wenn ich mit 1 zu zählen beginne)
Telegramm1 Ende: 89 (also BytePos 254 - wenn ich mit 1 zu zählen beginne)
Telegramm2 Beginn: A9 (also BytePos 266 - wenn ich mit 1 zu zählen beginne)
Telegramm2 Ende: F3 (also BytePos 374 - wenn ich mit 1 zu zählen beginne)

cyberChef

Spalte E = dein Datensatz // Spalte F = mein Datensatz
IV = Zeile 12 bis Zeile 19 und Zeile 24 bis Zeile 27

Telegramm1 Ende ... Telegramm2 Start

Telegramm2 Ende

Im cyberChef siehst du in Output, wenn alles korrekt dekodiert werden konnte, in Hex den OBIS Block.
Wenn du bei AES Encrypt den Output auf "RAW" stellst, dann kannst du zB. die Kaifa Serial Nummer lesen und siehst die Obis Blöcke.

Ich hoffe das hilft für's erste ;-)

[FKW9]

Also bei VKW beginnt das zweite Frame mit 68 72 72 68, und die Frames sind kürzer.
Aufjedenfall danke für deinen fundierten post! @micronano0

[da-winci]

@micronano0 Mega lieben Dank für deinen wirklich hilfreichen Post!
Mit deinen Vorgaben konnte ich nun folgenden HEX Output generieren.
0f00008eb20c07e7070d04110b1e00ff8880021009060000010000ff090c07e7070d04110b1e00ff8880020209060000600100ff090e314b464d303230303237373436330202090600002a0000ff09104b464d31323030323030323737343633020309060100200700ff12097102020fff1623020309060100340700ff12095702020fff1623020309060100480700ff12095f02020fff16230203090601001f0700ff12013902020ffe1621020309060100330700ff12015702020ffe1621020309060100470700ff12015a02020ffe1621020309060100010700ff060000000002020f00161b020309060100020700ff060000094c02020f00161b020309060100010800ff06000028b602020f00161e020309060100020800ff0600029bf002020f00161e020309060100030800ff06000002e902020f001620020309060100040800ff0600001f0202020f001620

Kannst du damit die richtigen OBIS Blöcke erzeugen und mal schauen ob die generell eigentlich passen?
Wenn ich den Output auf "Raw" einstelle, wird tatsächlich die richtige Smartmeter-Seriennummer angezeigt :)

Das zweite Frame der VKW Zähler scheint wohl tatsächlich mit 68 72 72 68 zu beginnen.
Wirklich mega wir kommen der Sache hier gemeinsam näher 👍

[FKW9]

Datum Zeit: 13.07.2023 17:11:15
0.0.96.1.0.255 Zaehlernummer: 1KFM0200277463
0.0.42.0.0.255 COSEM logical device name: KFM1200200277463
1.0.32.7.0.255 Spannung L1 (V): 241.1
1.0.52.7.0.255 Spannung L2 (V): 240.5
1.0.72.7.0.255 Spannung L3 (V): 239.9
1.0.31.7.0.255 Strom L1 (A): 3.13
1.0.51.7.0.255 Strom L2 (A): 3.42
1.0.71.7.0.255 Strom L3 (A): 3.44
1.0.1.7.0.255 Wirkleistung Bezug [kW]: 0.0
1.0.2.7.0.255 Wirkleistung Lieferung [kW]: 2.376
1.0.1.8.0.255 Wirkenergie Bezug [kWh]: 10.422
1.0.2.8.0.255 Wirkenergie Lieferung [kWh]: 170.982
1.0.3.8.0.255 Blindleistung Bezug [kW]: 0.745
1.0.4.8.0.255 Blindleistung Lieferung [kW]: 7.938

[FKW9]

Mit drei kleinen Änderungen im Code sollte es funktionieren, wenn ich nichts übersehen habe (Ob der Timestamp funktioniert, bin ich mir nicht sicher):

Hier den Wert auf 27 ändern:

esp-smartmeter-netznoe/src/dlms.h

Line 7 in 0446ace

#define DLMS_HEADER1_LENGTH 26

Und hier die payload_length auf 336 und payload_length_msg1 auf 227 setzen:

esp-smartmeter-netznoe/src/main.cpp

Lines 153 to 154 in 0446ace

	uint16_t payload_length = 243;
	uint16_t payload_length_msg1 = 228;

Und hier das Python test script für VKW Daten:
https://github.com/FKW9/esp-smartmeter-netznoe/blob/master/python/kaifa_dlms_decoder_vkw.py

[da-winci]

@FKW9 Danke für den schnellen Code Änderungsvorschlag.
Es schlägt noch bei untenstehendem if() fehl. Muss ich hier auch was ändern bezüglich 0x0F und 0x0C?
Hab dir noch die beiden plaintext felder gedebuggt.

Serial.println();
Serial.println("plaintext[0]: " +String(plaintext[0]));
Serial.println("plaintext[5]: " +String(plaintext[5]));
if (plaintext[0] != 0x0F || plaintext[5] != 0x0C)
{
Serial.println("Packet was decrypted but data is invalid!");
receive_buffer_index = 0;
return;
}

13:07:35.698 -> plaintext[0]: 111
13:07:35.698 -> plaintext[5]: 143
13:07:35.698 -> Packet was decrypted but data is invalid!
13:07:36.756 -> 68FAFA6853FF000167DB084B464D1020043BD7820155210000C7D3D5EB408ABCC29846906E0144490B7A2F858379C62BBF6E7595A736405E496A3632D77139D053AD8E93601C588FEC0B33DDB22FEC6F85ACD4BB05C993AADFCB21B1E6206EAB06C6FC9BEE30DD7E822DD71AFA776F5C1E2D9735281AD518D32322F73F786F8F20A4FACB19892A3675AF8E76DF2F30B47C08EB54DE4B474AAC852E9359794B3E6DBAD1383FDF019FEB582C3D1CC24305CF5F86D8BF62F176A800A0B7F6EAACE5A5F13BAE46487602A3F817F6DCD95D6BA8AE46EC6AE431B035420FDDD827B5805F3FEC96152C8B147CAFF84D0C79D676993C49FFB280DB0619CE1D2CB4D6CF16
13:07:41.767 -> plaintext[0]: 6
13:07:41.767 -> plaintext[5]: 72
13:07:41.767 -> Packet was decrypted but data is invalid!
13:07:42.800 -> 68FAFA6853FF000167DB084B464D1020043BD7820155210000C7D447E4CA155777082EA48F21D380DBBBE2FFDA513B0720DC40D72F280D5361BE4EE3D8191B14A25E7B940DB845DE0357878B9DE2E8C4F21B608DC02CC21C119F49935B13DD8633FAD9C6B7763806DF084F6457B3AFC40B90A8F2C128CF6ED2987DF796D454C1E32F5CF1EFE25A50EB7C74F23C15877C60529DC4A8E49E8E08C38A8C30EF964A509714772480C6F7744F67C0A44AA2B89E353A671CFD12D7633F3DAC3D5EF56136B6D6D64D36EFF555247E8CD53597D786D3CF243405359BA0B97BC47207C723F656347FACECFEF59C25D279B2442D569A6C48E25D3A772388361B5393817416
13:07:47.800 -> plaintext[0]: 148
13:07:47.800 -> plaintext[5]: 253
13:07:47.800 -> Packet was decrypted but data is invalid!
13:07:50.210 -> 68FAFA6853FF000167DB084B464D1020043BD7820155210000C7D504FC06AAFD1EBB85F7601BA24AADEC4940291C04B00BD72A81C7EC5E65299B73E342181B48AB61BAA5245471567B60ED4B33925E97C58FF57347C4D8FA3D1833AE0D847BE702BDB7C226CB500435D277C1CFEB515400DFB107DCC0C15CE830848BE4FE11308132A066FF2CE1253CB0C11897783057C4CF1EBA47E09CAA007B5017F7DE430105E3346BC054CD88FFAEA296541C9EE6C4C72D79A9E8001C698AA8DDFF2257DF1806D7E418B17671A7C63940777E3EAB1B58F566778E733BF17FE5A88472558D92EF887820DCA96B626723BCF4EBE78234483C1D16DDE84C92AAB8CB137D9F16
13:07:55.240 -> plaintext[0]: 215
13:07:55.240 -> plaintext[5]: 148
13:07:55.240 -> Packet was decrypted but data is invalid!
13:07:56.268 -> 68FAFA6853FF000167DB084B464D1020043BD7820155210000C7D7150A703CB2D609BE1F9A32982213AD77204A325CD297FA422043C58634E5DC75F6E2FF2975DEDD570B761D8222B28D53A45280C37951BFED8856785975E69CE602D0BA3F9D424F3FD356D7982AB4027E347289AB49359BFF8BA7197C0B52238E5BBA5DAA416E10C9A4BD1814630848CA613BCEF5D9C4B516437A627C1E45DAB0B9F959D58476E066ACA085E0323E666A328C3CFA3C34C6487409925C4BE427314411E662F7BCA046D3FA9CC46798D71510DEB9418DE8B37507E9C123049E2F5FE708FE3D34C54F32CDA3EDF2E1553E141DFF1BB89D0096FA1A2FCAED5193D2C5C9611A2D16

[FKW9]

Nein an diesen Byte-Positionen im Plaintext muss genau das stehen.
Bei den Daten fehlt das 2. Frame ... da gibts irgendwo noch ein Problem.
Es ist ein bisschen suspekt, dass genau nach dem 1. Frame keine Daten mehr da sind.

[da-winci]

Hmm dann verhält sich das mit dem ESP32 über die Serielle schnittstelle noch etwas anders als über den USB-TTL Wandler.
Das READ_TIMEOUT auf 2000 stellen hat erstmal auch nichts gebracht.
Grad nochmal zurückgewechselt auf den USB-TTL Wandler. Hier sind definitiv die "68727268" sichtbar.

[FKW9]

Meine Vermutung ist, dass dein 2. Frame mit einer etwas zu großen Verzögerung kommt. Kannst du checken, wie die Daten überm TTL-USB Wandler kommen? Kommt da alles auf einmal oder ist da ein delay dazwischen?

[da-winci]

Die Daten kommen alle aufeinmal.
Also der 1. und 2.te Frame kommen ohne Verzögerung daher.
Alle 5s ein volles Paket.
Evtl. könnte der Pullupwiderstand Probleme machen, welcher an den RX des ESPs geht?
Soll ich mal andere Pullupwiderstände probieren?

[FKW9]

Ja mein Fehler, deswegen gibt es ja das READ_TIMEOUT.......

[FKW9]

Versuch mal dort wo er die Daten ausliest, die einzelnen Bytes direkt zu printen

esp-smartmeter-netznoe/src/main.cpp

Line 113 in 8245f22

receive_buffer[receive_buffer_index++] = Serial2.read();

[da-winci]

Hab nun folgendes in der while(Serial2.available()) schleife eingebaut:
Serial.println(receive_buffer[receive_buffer_index],HEX);

--> Datenlogging.txt

Die Daten vom Oszi bezüglich Anfang des Datenpakets scheint mit dem was die ESP Serial sagt zumindest übereinzustimmen.

[da-winci]

Kein Problem. Falls du Hilfe beim Debuggen brauchst gib mir bitte Bescheid!
Ich helfe gerne mit den Möglichkeiten die ich hier hab.
Denke gemeinsam bekommen wir das schon hin 👍
Übrigens im oberen Bild sieht man eine kleine Wartezeit. Hoffe das ist kein Problem für die Auswertung.

[FKW9]

Ich komm grad drauf, dass ich im Debug-Print nur das erste Frame printe (bis 255)!

esp-smartmeter-netznoe/src/main.cpp

Lines 139 to 144 in 8245f22

	#ifdef DEBUG_OUTPUT
	for (int i = 0; i < 256; i++)
	{
	Serial.printf("%02X", receive_buffer[i]);
	}
	#endif

Also das 2. Frame ist eh da! Dann wird's noch an der Dekodierung liegen und den richtigen Byte-Positionen...
Das mit der kleinen Wartezeit ist kein Problem.

[FKW9]

Im branch vkw-test habe ich eine erste Testversion. Das entschlüsselte Paket unterscheidet sich doch ein bisschen mehr als gedacht, aber dies sollte so mal funktionieren.

Was noch fehlt ist die Auswertung der folgenden OBIS Kennziffern:

• 0.0.1.0.0.255 (Timestamp)
• 0.0.96.1.0.255 (Zählernummer)
• 0.0.42.0.0.255 (COSEM logical device

[da-winci]

Mega vielen lieben Dank für deine schnellen Anpassungen!
Hab nun deinen Code in ArduinoStudio kompilieren wollen.
Das ganze Logging und drumherum was ich nicht benötige fehlt deshalb.
Es ist also wirklich nur dein Code um die Smartmeter Daten abzugreifen.
Beim kompilieren kommt noch folgender Fehler. -> variable 'meter_data' set but not used
Kann mir grad nicht erklären wieso, weil die Variable eigentlich verwendet werden sollte?
Mit dem aktuellen Code vor deinen Änderungen tritt dieser Kompilierfehler nicht auf.

Hab dir meine drei files mal angehängt. Kannst du diese bei dir ohne Fehler kompilieren?
HeatingControl.zip

[FKW9]

dein compiler behandelt die Warnings als Error, deswegen schlägt es fehl. Du musst dem Compiler sagen das er das nicht soll mit dem Flag -Werror. Wie das in ArduinoIDE geht weiß ich nicht.

Oder du verwendest den teil des codes (im prinzip wird das struct meter_data nur initialisiert) am ende mit println(meter_data.power_plus) und println(OBIS_TIMESTAMP[0])

[da-winci]

Die Dekodierung für die VKW Smartmeter funktioniert nun endlich!
Die Auswertung des Timestamps wär noch super da ich im Zählerkasten im Keller keinen WLAN Empfang habe um die Zeit zu bekommen.
Mir ist auch aufgefallen das Zeit holen über den NTP Server bremst das Hauptprogramm extrem.
Das mag in deinem Fall kein Problem sein, aber in meinem Fall für schnelle Regelung bräuchte ich den Zeitstempel des Smartmeters.
Falls du mal Zeit findest den Zeitstempel zu implementieren, das wär wirklich cool. 👍

Lieben Dank für all eure Hilfe!

Encoded raw data stream:
68FAFA6853FF000167DB084B464D1020043BD7820155210001217A29BE821203EF1B19A8DE2F39EBE508B84A4B076457D1C0851F4883408A702D48785E0184BEC2B4B8133268185AAE32221D08CBF68914D39E5C5EB4678A88F183D2E32EC265E155E6ED1AFBEC7DB696153F06A05AF95C9D2D8EDE9FE1249C9674CBB2FFD43CB98283C75521E5A3945F874CD3C8C32ABA5BA66CB08136C3A0FA0FF63182F0CC42BC20609CAB62D6A8970EA4E6CE0EC758357E25E1944D655BD66FB474991A8A56D1A17DD6576C37341E56FB762CC8822925489257B1B783B83494423F29ABA1566FE0EF35E770C0512EC6A0AD251E61470BB6790C185AAABDAE314852C808166872726853FF110167F4B687FEC9C89FC031F7367F698E02686BBF9ECCBD0218227E584D13A7D3EA8CE330AD1BD4B816D2705D464679426737E20FC54C4919ED282C7155D1313E61C5FB198B658E384C0E8364C5DBB43B85958FBC70EEEFF49199FF8E1D7CEECFC2405E40EEA6E3953F8E0B5D1A1F64781668FAFA6853FF000167DB084B464D1020043BD7820155210001217BEBBDD61A5B0B519D317000529B043168CA873E102E00ADAB093FBEE7290E0339295A89FBFAD4FBCB7F60B97E521ADC78B9598833B15AC3F1FC49434E61F18D00CC1E94DB6D648BF0EEDC85C4F8DC8D1A3047E6A7BB68214B4F79CD5A8467786245B918B7A682982949CE104375DCB54C206887C3E19B4A7DE9E83D9201413C110B55A1CE8499244CDFDE9F727CD60D8FF241DA1096156B62CF5A0FE07372E5B46BE26B601ADE561CFD879732CFDB210819E4203A371E55E4DDA86C6968D647468DBCDBF1E0F81954CD36FD76BDA6F2793CF184B69AFE4D04A26BC7907268EDE47AA0BC97166872726853FF1101677DD9BF2120D35265C8FD366D7EA3B5D2C55D66F84D130AB686AD418CD5E26D94DEE9D07B1ECAC948F355DDE1848D2BEED5946DC8B889E8C26083EA27F38A4666E67A54E45EDD03FBA073B7A09EDD172FDFAFE7D80FC83967711DE97B2838FCB560EE04D3224AD268536F5BC7CF351600
Found OBIS code:
0000010000FF
Found OBIS code:
0000600100FF
Found OBIS code:
00002A0000FF
Found OBIS code:
0100200700FF
VoltageL1 237.80
Found OBIS code:
0100340700FF
VoltageL2 237.70
Found OBIS code:
0100480700FF
VoltageL3 239.30
Found OBIS code:
01001F0700FF
CurrentL1 0.33
Found OBIS code:
0100330700FF
CurrentL2 1.26
Found OBIS code:
0100470700FF
CurrentL3 0.28
Found OBIS code:
0100010700FF
ActivePowerPlus 336.00
Found OBIS code:
0100020700FF
ActivePowerMinus 0.00
Found OBIS code:
0100010800FF
ActiveEnergyPlus 14724.00
Found OBIS code:
0100020800FF
ActiveEnergyMinus 323080.00
Found OBIS code:
0100030800FF
ReactivePowerPlus 897.00
Found OBIS code:
0100040800FF
ReactivePowerMinus 16228.00
Received valid data!

Damit kann ich nun endlich meine Heizstabsteuerung realisieren. :)
5044W kommen momentan von der Photovoltaikanlage (Sonne)
0W Bezug aus dem Netz (Stecker)
4000W werden in den Boilerheizstab eingespeist

[FKW9]

Timestamp wird jetzt im neusten Commit b2c20f4 ausgewertet, zusätzlich mit epoch time die die Zeitzone berücksichtigt (kein NTP mehr nötig!).

In deinem Code verwendest du noch ACTIVE_ENERGY_PLUS_OFFSET; das kannst du löschen wenn du es nicht brauchst

[laimermic]

Seltsamerweise bekomme ich nur invalide Daten. Ich habe es dann mal mit dem TEST_SETUP-flag ausprobiert aber selbst dort bekomme ich nur die Meldung:

Packet was decrypted but data is invalid!

und folgenden Encoded raw data stream:

68FAFA6853FF000167DB084B464D1020043BD78201552100008FA2DF4E42850F1A76EB5A935E4236EA7D26107644C7C163229F2538BEF9E354016C5DFC2DAC071DD083FDD2AB1EB4F335F33FBCE54A88B5C97A529E979B614290FDB2B5DF760A4E88D6984EF23D79C48336D16F299FC3BF16C8072FCCA23EE667C8031757DBFC1FF24EE6738465C90E675D90611BA740CE9125A0300853C0F0D95828E043B50184AAA43FF8335BCE02D6E8A7B5F7818923FBFE30AAC3F619F8B4AF778DAC38BFB3CCFFC59C2231E90E067C5911DC935320E655C2CF1C04CA3805EBED05163904138F2BE3C7FDE84F7FCEAC9519F99D3343BD64FCB110BAD698BF67AE112EB4166872726853FF110167355183CB78C9E3C40670CC906A45E6133862A3847E453A5BC811D3803D98C1C47E161FB0F1C7478E65AB29A51F790AC0AF685B136E37B4A9E7FA10C27DB29E4E29B84A8603120FEB4DFC4EF587F6B3E8148E4570FA99BA97B3C941A097A79D3558102C249ACBEF12561AA58EF2E416

Mache ich irgendetwas falsch?

Ich verwende den bereits in der key.h-Datei vorhandenen Schlüssel:

// Your Encryption Key
static const unsigned char KEY[] = {0x35, 0x32, 0x36, 0x32, 0x34, 0x34, 0x34, 0x35, 0x37, 0x36, 0x34, 0x36, 0x34, 0x32, 0x34, 0x34, 0x35, 0x37, 0x37, 0x31, 0x33, 0x36, 0x36, 0x36, 0x33, 0x39, 0x36, 0x43, 0x35, 0x32, 0x35, 0x37};

[FKW9]

Der key ist falsch, da würde der key von @da-winci hingehören, aber den habe ich natürlich nicht veröffentlicht. Ich habe kein VKW, deswegen musst du die Daten und den Key von dir eintragen.

Wie sehen deine Daten aus? Ist das zweite Paket da, beginnend mit 68727268 (VKW)? Enden deine Pakete mit 16?

[micronano0]

@laimermic
Hallo Michael, möchtest du mal im Arduino Simulator ausprobieren, ob du Daten bekommst?
Du mußt "nur" in Zeile 25 deine Raw Daten vom Zähler hineingeben (rxBuffer ....).
Der key wird beim Programmstart abgefragt. Er ist ohne die 0x einzugeben. Einfach deinen 32stelligen key reinkopieren und Enter

[laimermic]

Wies aussieht hab ich es einfach nur nicht hinbekommen meinen Key in key.h richtig einzusetzen. Trotzdem danke 👍 . Ich kann die Daten jetzt auslesen