Before commenting read Forum rules
Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
Forums
Hi!
I just wanted to check with your whether this is a meter bug or something that needs to be interpreted differently in the DLMS library.
This is the final challenge response I get from the meter:
c7 <- ActionResponse
01 <- ActionResponseNormal
81 <- InvokeAndPriority
00 <- ActionResult (OK)
01 <- ?
00 <- Data
09 <- OctetString
10 <- Length
64 a3 75 84 d2 d3 59 9d e4 6a 6f e2 2a 24 f7 7c <- Challenge Response
By looking at the DLMS standard, I do not think the "?" byte belongs here. I had to remove it and adjust the package size manually to make it work.
What do you think?
Non-superfluous byte in Action-Response
The format of the "pseudo ASN.1" used in DLMS can be a little confusing, but there is at least one example action-response message in the Green Book, which shows the contents unambiguously. In table C.1 you will see an action-response which goes
C7 01 40 00 01 00 01 01 ...
which is:
c7 Action-Response
01 Action-Response-Normal
40 Invoke-And-Priority
00 Success
01 Optional Get-Data-Result present
00 data CHOICE
0101 Array of 1 element (the start of the actual data)
etc.
Your mystery byte is the one which says the optional data field is actually present. Some meters and clients are currently making mistakes with these "optional data present" bytes.
Interesting..
Thanks for taking the time to point that out!
In that case, does this mean that the Gurux library should be able to handle this?
Actually, when looking closer at the code, it looks like it is supposed to be handled here:
https://github.com/Gurux/Gurux.DLMS.Net/blob/master/Development/GXDLMS…
I guess it would work fine for me in this case if it consumed another byte after those conditions.
Interesting
That piece of code seems to be checking for the data present byte, handling its possible absence as a benign omission. I don't think its handled correctly in every part of the code, though. There seems to be some problem with the authentication code at the moment.
Hmm..
kurumi: What do you think? Will this turn into a bug report or does that code work as it supposed to?
Action-Response
Hi,
Coppice is right about that one byte. It is needed, but there are several meters that are not add it.
We actually broke this when we was reading meters for one of our clients and meter did not sent this byte. We accidentally commit this version to public repo. :-( For this reason there was version that was not working correctly. That should be fixed now.
BR,
Mikko
Action-Response
In what version has that been fixed. The installer for the current version of DLMSDirector (8.0.0.20) still seems to expect those "optional data present" octects to be missing.
-
Thank you for addressing this issue. The new version works great.
Not sure if this is of interest to you, but the default conformance bytes did no longer work for me. I had to change them from 00 00 1C to 00 7E 1F to get the correct access rights. I guess those were the default values in 8.2.0.1?
Action-Response
Hi,
It should be fixed in that version. We will check it.
BR,
Mikko
conformance bytes
Hi,
We changed conformance bytes to set only minimum values.
SelectiveAccess, Set and Get
You have set
Action, EventNotification, SelectiveAccess, Set, Get, MultipleReferences, BlockTransferWithAction, BlockTransferWithSetOrWrite, BlockTransferWithGetOrRead, Attribute0SupportedWithGet and PriorityMgmtSupported.
We can try to set other bits than Action on. We are not supporting Action at the moment and now there are meters that support action and this is causing some problems.
Can you check is this ok for you and let me know?
BR,
Mikko
-
For me, this is totally OK. I don't think I will be using Action at this point.
I didn't really care about those bytes until they stopped working, but I will use those specific class properties from here on out instead of bluntly entering bytes. Thanks. :)