Checksum issue on Itron OpenWay 3Hz

[SaimenSays]

Hello and first of all thanks for your work!

We have Itron OpenWay 3.HZ in our house. I needed some hours to figure out why I can't get it working. It seems as this manufacturer is using a different CRC. After inspecting the code and disabling CRC checking, I see normal SML messages parsed. There are already to different checksum algorithms in sml_crc16.c. Does anybody know which other CRC Itron is using? Or can somebody give me a hint, how to find out the CRC algorithm needed? If I'm able to find the correct algorithm I will make a pull request.

[andig]

Looks like https://github.com/volkszaehler/libsml/pull/76. Any idea what algorithm the Itron used?

[devZer0]

what about asking the vendor ?

they should have an interest in interopability for their product and nobody knows who will use libsml with their add-on-product, so they should care...

furthermore, what about submitting a sml message from your ehz to https://github.com/devZer0/libsml-testing , so others may have a look ?

you may also try https://github.com/Apollon77/smartmeter-obis for decoding, to see how it behaves. i think it's a good sml parser and developed very actively.

have a look at https://github.com/Apollon77/smartmeter-obis/issues/5 , there is a simple usage example for binary dumps too.

[SaimenSays]

Update: Tried some SML data with online CRC calculaters. Kermit works, but I neither the default CRC is matching to online results, nor this Itron speciality. Which type of CRC16 is the implementation in sml_crc16_calculate()?

@devZer0: I will write the Itron a mail, but I don't think they will tell me. Previous experiences with other vendors told me so, because they want to sell there stuff.

Obis is the next step I think. It is only asining texts to the leading numbers, or did I got this wrong? I get following output with CRC disabled, so SML parsing is correct:

1-0:96.50.11#ITR# 1-0:96.1.0127#0a 01 49 54 52 00 03 xx xx xx # 1-0:1.8.0*127#7937000#Wh

[SaimenSays]

Update to my post above: According to Online CRC Calculator actual implementation of `sml_crc16_calculate()' uses MCRF4XX type, with additional XOR and toggled low high byte in the end.

[andig]

Now that would need an additional implementation. PR welcome 👍🏻

[devZer0]

mhh, does that mean we need to add another crc check and then stupidly do

if (*msg->crc != sml_crc16_calculate....)
  if (*msg->crc != sml_crc16kermit_calculate....)
   if (*msg->crc != sml_crc16anotherone_calculate....)
       goto error;

?

[SaimenSays]

First of all, type of CRC is still unknown. But I wrote a mail to Itron and hopefully get some kind of answer.

• It would be nice to have an option to suppress CRC check.
• Of course easiest way would be @devZer0 suggestion. Maybe the CRC check can be depent on manufacturer identification string, but this would need some more changes. This would mean the default CRC, Kermit for Holley, and anotherone for Itron.

[devZer0]

applying crc quirks based on manufacturer identification string also was something i was thinking about....

[SaimenSays]

I need to say sorry! This issue was my own fault. After recording the values for some days, what worked good even without CRC check, I recognized some strange jumps in the values. I thought WTF... After digging more into the protocol, I figured out that a bit is missing. So I checked the serial config and unfortunately it was set to 7bit and dropped the MSB. This works for SML messages with text and looks correct. But numbers are correct only when no hex >0x7f is involved.

tldr: SML seems work with work with 7bit on serial interface, but in fact it doesn't!