Detection of DLMS header timestamp and header size

[roarfred]

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]

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

[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]

• 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 Removing09 from header #32