<CR><LF> missing in the encrypt-message.js (and thus also in decrypt-message.js and p1-message.txt)

[Jeroen88]

Here in encrypt-message.js a <CR><LF> is missing in the example. Page 16 paragraph 6.2 of DSMR 5.02 P1 companion standard clearly states that the <CR><LF> after the CRC is part of the telegram. Not a big deal, but if somebody (like me :)) tries to decrypt and parse the result it fails because of the missing <CR><LF> at the end.

[svrooij]

Hi @Jeroen88, care to send a PR? I though these details came straight from an actual meter. Just made the examples for others to start experimenting with the decrypting (which is now also build into esphome)

[Jeroen88]

Hi Stephan, I am experimenting with decrypting too, that is why your example was a good test case. I am not a TypeScript programmer, cpp is my language. The solution is just adding an extra <CR><LF> at the very end of the telegram. Also, taking a closer look at the output, all lines should end in a <CR><LF> and yours are just a <LF>.

Here are the first hex bytes of the decrypt-message.js, taken from your const encryptedMessage and decrypted in CPP:

0x2f, 0x4b, 0x46, 0x4d, 0x35, 0x4b, 0x41, 0x49, 0x46, 0x41, 0x2d, 0x4d, 0x45, 0x54, 0x45, 0x52, 0x0a, 0x0a, 0x31, 0x2d, 0x33, 0x3a, 0x30, 0x2e, 0x32, 0x2e, 0x38, 0x28, 0x34, 0x32, 0x29, 0x0a, 0x30

As you can see the <LF> is present (0x0a) but the <CR> (0x0d) is missing.

I am looking for some real data, from a real encrypted meter. I can find encrypted data online but without the associated key. Do you happen to have a real example? I would love to test my decryption with it!

[svrooij]

@Jeroen88 you should see the decrypting and the parsing as two separate processes.

I developed this on a mac, hence the error with the line endings.

This message should decrypt correctly (since you got a DSMR message out of it).

You can also use the sample code provided to encrypt a DSMR with the line endings you want. Or why not make the parsing code just ignore the incorrect line endings? Possibilities are endless.

In my code found here all DSMR messages are parsed line by line (appending \r\n). That way is doesn't matter how they are send.

I can also help you creating a correctly encrypted message, so you can test your decryption?
If you want my opinion, if the message is encrypted don't bother checking the crc. The encryption/decryption already validates the message (as in, since you could decrypt it with the correct key the output is the same as the message that was inputted).