Made verifying the checksum of a message optional

[fremouw]

In the DSMR 3.0 spec there's no checksum value to verify a (P1) message, so a simple message could look like this,
`/ISk5\2ME382-1000

1-0:1.8.1(000671.578kWh)
1-0:1.7.0(00.318kW)
!`

I've mainly added an optional parameter to the parse function to not verify the checksum and added some if statements to not actually verify it. As it's optional it should not conflict with current code.

[matthijskooijman]

Apologies for my superlate response. Overall, you change looks good (left one remark inline). However, I'm not quite sure if adding a (runtime) bool parameter to parse is the best way to configure this. In #22 I just wrote:

This is probably best fixed with an option somewhere, probably in the parser, which means either a runtime argument to the P1Parser::parse function, or a template argument to the P1Parser class (where the latter might make more sense). The argument could either be a DSMR version number (deriving whether a checksum is needed from that, a simple boolean enable_crc or something, or an object/struct containing an enable_crc which allows more options later). Any thoughts on that?

[matthijskooijman]

Is this needed? Is there a CRLF after the !? If I read the v4 spec correctly, there should be no CRLF after the last line (which I think is the checksum line in v4, and the ! line in v3)? Are you seeing a CRLF in your messages?

[fremouw]

Hmm, you could be right, I've checked the v3 spec and there's no CRLF. Need to check if that's somehow added to my recording.

[fremouw]

Apologies for my superlate response. Overall, you change looks good (left one remark inline). However, I'm not quite sure if adding a (runtime) bool parameter to parse is the best way to configure this. In #22 I just wrote:

This is probably best fixed with an option somewhere, probably in the parser, which means either a runtime argument to the P1Parser::parse function, or a template argument to the P1Parser class (where the latter might make more sense). The argument could either be a DSMR version number (deriving whether a checksum is needed from that, a simple boolean enable_crc or something, or an object/struct containing an enable_crc which allows more options later). Any thoughts on that?

I've added it runtime so I can use one firmware for multiple smart meters and make it configurable over a web interface.

[mrWheel]

Matthijs,
For a builder of my DSMR-logger I also need a way to escape the CRC.
Is there any plan (any time soon) you will merge this into the master branche?