roarfred / AmsToMqttBridge

Minimalistic system to read AMS/HAN data from electrical meter
216 stars 44 forks source link

Detection of DLMS header timestamp and header size #29

Open roarfred opened 6 years ago

roarfred commented 6 years ago

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 commented 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

roarfred commented 6 years ago

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 commented 6 years ago