Open roarfred opened 6 years ago
There might be just a hint to something here: https://github.com/Gurux/Gurux.DLMS.Net/blob/master/Development/GXDLMSClient.cs#L1979
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 |
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)