Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detection of DLMS header timestamp and header size #29

Open
roarfred opened this issue Mar 6, 2018 · 3 comments · Fixed by #32
Open

Detection of DLMS header timestamp and header size #29

roarfred opened this issue Mar 6, 2018 · 3 comments · Fixed by #32

Comments

@roarfred
Copy link
Owner

roarfred commented Mar 6, 2018

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
Copy link
Owner Author

roarfred commented Mar 6, 2018

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

@roarfred
Copy link
Owner Author

roarfred commented Mar 7, 2018

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
Copy link
Owner Author

  • 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant