AmsToMqttBridge icon indicating copy to clipboard operation
AmsToMqttBridge copied to clipboard

Detection of DLMS header timestamp and header size

Open roarfred opened this issue 6 years ago • 3 comments

There's a challenge with data changed from the latest Kamstrup meter. From the documentation, there's a 0x09 byte that was intentionally removed and it is unclear why.

Problem is now that we need to find a good way to parse the header in a safe way. The Kaifa meter still has this 0x09 byte here. We are having a bit of trouble understanding how this can be detected without forcing a headerLength field into the meter OBIS code files.

I will try to better document this, but in the mean time, there's some information about the discovery (in norwegian) here: https://www.hjemmeautomasjon.no/forums/topic/1982-lesing-av-ams-data-amshan-iot/?do=findComment&comment=32850 (Read from here and about 10 posts ahead to get the picture)

roarfred avatar Mar 06 '18 13:03 roarfred

There might be just a hint to something here: https://github.com/Gurux/Gurux.DLMS.Net/blob/master/Development/GXDLMSClient.cs#L1979

roarfred avatar Mar 06 '18 19:03 roarfred

Kamstrup confirms this byte was intentionally removed, to conform to DLMS. Started some communication with NVE and NTE to see if Kaifa was just having the same bug, and this can be disregarded all together.

I also found some more information that can be used to explain bytes immediately following the header checksum like this:

E6 E7 00 0F 40 00 00 00 00 02 02 09 06 01 01 01 08 00 FF 12 11 22

Byte Meaning
E6 E7 00 fixed, it indicates LLC
0F fixed, 15 = Data Notification
40 00 00 00 fixed, Long Invoke-Id and Priority
00 The next zero bytes is a date (could typically be 0C indicating a 12 byte representation of a date)
02 Data following is a structure,
02 ... of two elements
Element 1
09 It's an octet-string
06 ... of 6 characters
0101010800FF the value
Element 2
12 it's an unsigned long (2 bytes)
1122 the value

roarfred avatar Mar 07 '18 16:03 roarfred

  • DLMS.com confirms on 15-Mar-2018, the data from the Kaifa meter is not valid.
  • NTE Nett AS confirms on 15-Mar-2018, they will take this issue to Kaifa, and get back with a response.
  • Until we have a confirmation there will be a fix, the property compensateFor09Debug will be a workaround. This should now also be on the master branch, as of #32

roarfred avatar Mar 20 '18 10:03 roarfred