Hi!
When reading association view with GuruX.DLMS version 9.0.2411.2201, the list of attributes and methods where empty like this (for the clock object, but it applies to other objects as well):
<GXDLMSObject xsi:type="GXDLMSClock">
<Version>0</Version>
<ShortName>20224</ShortName>
<LogicalName>0.0.1.0.0.255</LogicalName>
<Description>Ch. 0 Clock object #1</Description>
<Attributes />
<Methods />
</GXDLMSObject>
But after upgrading the nuget packages (in this case the GuruX.DLMS to version 9.0.2506.1801), both "Attributes" and "Methods" has entries, and in all these entries, both "Access" and "Access3" is set to 0.
(this is for an old EMH LZQJ meter)
In our code, we have code like this when reading the Clock (and other) object:
var clock = Client!.Objects.FindByLN(ObjectType.Clock, clockObis) as GXDLMSClock;
if (clock!.CanRead(2)) --> This now return FALSE, and we cannot read this object.
This code now fails, as the "CanRead" now returns false.
I found some changes in commit "1dab66fd9637f4a7a1238258b8190ebef21ca756" (Version 9.0.2503.0301) that I suspected had something to do with this, so I compiled a version without these changes, but "CanRead" still returns false.
When Connecting to the meter in Gurux director, I initially got the same problem, but after reading association view again, it works there, but I cannot see how to get "CanRead" to work again in our code.
Please ignore what I wrote…
Please ignore what I wrote about Gurux director. It must have been an observation error, as I can now see that the one I am using, is using an older version of GuruX.DLMS.dll (version 9.0.2409.2002).
After some more testing, I…
After some more testing, I can now confirm that it is the changes in commit "1dab66fd9637f4a7a1238258b8190ebef21ca756" (Version 9.0.2503.0301), that is causing these problems.
When the code from this commit is included, and we read the association view, the Clock object (applies to all object, but using Clock as example) for this EMH meter, looks like this. I have not copied the whole object, but all items in the Attributes list has Access = 0 and Access3 = 0:
<GXDLMSObject xsi:type="GXDLMSClock">
<Version>0</Version>
<ShortName>20224</ShortName>
<LogicalName>0.0.1.0.0.255</LogicalName>
<Description>Ch. 0 Clock object #1</Description>
<Attributes>
<Item>
<Index>1</Index>
<Type>OctetString</Type>
<Access>0</Access>
<Access3>0</Access3>
<Values />
<UIValueType>0</UIValueType>
<AccessSelector>0</AccessSelector>
</Item>
<Item>
<Index>2</Index>
<Access>0</Access>
<Access3>0</Access3>
<Values />
<UIValueType>0</UIValueType>
<AccessSelector>0</AccessSelector>
</Item>
There is a comment in the code:
"Some meters return only supported access rights"
So I guess that the EMH meter I am reading, is one of those.
I think that if the meter does not report the access level, it should not be set to "NoAccess" (as the meter has not reported this), but to "NotSet", and "CanRead" should return true, if the meter has not reported it's access levels.
In this case, the code would still work for these old EMH meters.
Hi, CanRead returns true if…
Hi,
CanRead returns true if the attribute Access is set to read.
The old code sets the access right to ReadWrite if the access right was not returned.
It was changed because the DLMS standard defines:
++++
the attribute_access_descriptor and the method_access_descriptor elements always
contain all implemented attributes or methods;
++++
For this reason, access right is NoAccess if the meter doesn't return it, and CanRead returns false. There is no NotSet in the DLMS standards.
I need to think about how this can be resolved. There is no simple and easy solution to this.
BR,
Mikko
Thanks for your reply! I…
Thanks for your reply!
I understand you want to follow the standard, and I am all for that, but as I understand you, these EMH meters is not reporting the access mode, and is so not following the standard.
That is why I suggested the "NotSet" option, as if the meter does not report this, we do not know what access mode are actually used in the meter.
If, like now, it is set to NoAccess, code that checks "CanRead" will fail, even if it would work if tried.
It would be nice if you find a solution, but if not, we will have to find a workaround.
Maybe this will work, if we do it for EMH meters:
When reading Association view, change all Access and Access3 that is AccessMode.NoAccess to AccessMode.ReadWrite, and store this in our database?
I can see one problem with this, and that is if newer EMH meters is actually reporting access mode correctly, we will override where the meter says NoAccess (but that might happen with the old EMH meters also, so I guess we will have to handle that anyway).
I will try my own suggestion, and see how this will work, and hope you find a solution to this :)