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
Hello Mikko,
We are focusing now on giving each object its attribute and method access level depending on the type of association. For example, the public client has a very limited access to object to read. Based on the enumeration "DLMS_ACCESS_MODE", we used these 4 types of access level : DLMS_ACCESS_MODE_NONE, DLMS_ACCESS_MODE_READ, DLMS_ACCESS_MODE_WRITE and DLMS_ACCESS_MODE_READ_WRITE.
Logically the DLMS_ACCESS_MODE_NONE is used when we do not want to give any access for an object for a specific type of association. We tried this access level for different object and it worked. It was giving "NoAccess" in the GXDLMSDirector. However we faced two problems with two different type:
1- DLMS_OBJECT_TYPE_PROFILE_GENERIC: while using the getProfileGenericAttributeAccess() function we tried to return "DLMS_ACCESS_MODE_NONE" when the authentication is none. When trying to read the list of object, when it reaches the profile generic object it is giving the following warning "Access Error: device reports read-write denied". However the list of object was read successfully and the corresponding profile generic are showing "NoAccess" which is correct. Our problem is with this warning that shouldn't supposed to appear and it is causing trouble while reading. (check picture)
Image
2- DLMS_OBJECT_TYPE_IEC_HDLC
2- DLMS_OBJECT_TYPE_IEC_HDLC_SETUP: while using the getHdlcSetupAttributeAccess() function we tried to return "DLMS_ACCESS_MODE_NONE" when the authentication is none. When trying to read the list of object, when it reaches then end and try to read the iec hdlc setup object it is throwing the following error "Access Error: device reports read-write denied"(check picture). However after that error the list of object wasn't read successfully and no objects are shown. It is urgent to track that error and solve it because it is blocking completely the reading. If you also have any idea what it is happening please share.
N.B: to easily repeat these problems just return "DLMS_ACCESS_MODE_NONE" for the type DLMS_OBJECT_TYPE_IEC_HDLC_SETUP and DLMS_OBJECT_TYPE_PROFILE_GENERIC and you will obtain the error and the warning respectively.
Hi Mikko,
Hi Mikko,
We were trying to use the method "Reset" of the object PRIME NB OFDM PLC MAC network administration data (id = 85) but surprisingly the different attribute were not cleared like expected. Even though we checked the function invoke_PrimeNbOfdmPlcMacNetworkAdministrationData() that is responsible to clear the different attributes but the expected result wasn't reached.
If you please can check it.
Best Regards,
Lara Wakim
Hi,
Hi,
Capture objects are read and it doesn't care from access right because they are always set.
Check is added for capture objects read and capture objects are not read if read is not allowed.
BR,
Mikko
Hi,
Hi,
Don't add the non-accessible objects to the association view. If a user can't access the object, don't show it. Check NONE_OBJECTS from the main.c. It will show only a few objects when use connects without authentication.
This is the correct way to handle objects that the user can't access.
BR,
Mikko
Hi,
Hi,
This is checked and it worked as expected. Note that you have to read values again after you have press the reset button.
BR,
Mikko
Hello,
Hello,
We followed your tip and it worked. Thank you!
It is far more efficient then the implementation that we did.
Best Regards,
Lara Wakim
Hi,
Hi,
We downloaded the latest version and the reset button worked as expected.
Best Regards,
Lara Wakim
Hello Mikko,
Hello Mikko,
We were testing the release "gurux.dlms.c 20200104.1" and more especially the feature "The season profile is sorted according to start date (in increasing order).". We noticed that you were comparing the different starting date of each season profile then put them in the increasing order. But something weird happened. In fact, in some cases the order wasn't right. After some digging we discovered the following for each first day in each month we saved the value in epoch time:
Month /Value in epoch time
1 January 31536000
2 February 34214400
3 March 5097600
4 April 7776000
5 May 10368000
6 June 13046400
7 July 15638400
8 August 18316800
9 September 20995200
10 October 23587200
11 November 26265600
12 December 28857600
Like you can notice the month 1 and 2 have a value greater than the month 11 and 12.
Sure, we were expecting that the month 1 has the smaller value and the month 12 has the greater one.
But we obtain that the month 3 has the smaller value and the month 2 has the greater one and surely it was increasing successively.
We think that you should check it. This problem was causing a wrong ordering of the season profile start date.
Best Regards,
Lara Wakim
Hi Mikko,
Hi Mikko,
We are facing a weird problem with the profile generic and we were not able to track it. We will explain it to you maybe you can guide us to find what are we doing wrong or what are we missing.
When we try to capture some row successively of a profile generic we reach a stage where we were not able to read the rows of the buffer in the GXDLMSDirector because the access level of the buffer (attribute 2) has switched alone from "Read" to "NoAccess" (check the picture). We were not able to know what is the reason behind this random change.
If you have any idea or explanation please share it with us.
Best Regards,
Lara Wakim
Hi,
Hi,
Meter returns an error and because that access level is changed to no access. There are some meters that don't use association view correctly and some attributes are not implemented. For this reason, the returned error changes the access level. Change it back from "no access" to "Read" and you can continue as normal.
BR,
Mikko
Hi,
Hi,
This issue is reproducible and we are working with that at the moment.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Just a kind reminder this issue is still not solved in the latest release of today.
Best Regards,
Lara Wakim
Hi Lara,
Hi Lara,
I'm sorry for the slow reply. The year is different and that is causing that numeric value is bigger in January (1st January 1971) than December (1st December 1970) .
BR,
Mikko
Hi Mikko,
Hi Mikko,
No problem, but you can please clarify more what do you mean by different year and how are we supposed to solve it?
Best Regards,
Lara Wakim