"There are only 10 attributes in Activity Calendar, so if you try to read attribute #11, I believe that meter is returning an error."
I've raised two different queries. one for Limiter and second for Activity Calendar. but it seems you misunderstood. attribute #11 with Limiter I've asked.
I believe that I know the reason. This fails if the script table is not found from the association view. We'll fix this and release the new version tomorrow.
I create issues:
Limiter action over and under thresholds read failed if script table object is not found from the association view. https://www.gurux.fi/node/17796
so, "FF FF FF FF FF FF FF FF FF 80 00 FF" these fields not converting into date format.
when I dig into, I found something in convert() API
in "02/02/2021 05:59:03 UTC+05:30", library considering it as DLMS_DATA_TYPE_DATETIME
where as "FF FF FF FF FF FF FF FF FF 80 00 FF", library considering it as DLMS_DATA_TYPE_OCTET_STRING
might be due to this, "FF FF FF FF FF FF FF FF FF 80 00 FF" was not converting into date format.
Can you plz check once and provide some helpful details to me?
Meter is returning the date-time as DLMS_DATA_TYPE_OCTET_STRING. There is no easy way to check out that this value is date-time. Other programming languages handle this automatically, but we try to use as little memory as possible with ANSI C so you must do this by yourself.
Loop objects and change "FF FF FF FF FF FF FF FF FF 80 00 FF" to date time with dlms_changeType method. You can use the logical name to check when data must be converted.
so here, Library is modifying obis_inOperation buffer somehow, when I'm trying to read index 3. which is creating issue to me. Please note that, I've read multiple other meter objects, but not faced this type of issue with any of that.
Can you please check and let me know what could be the fix?
Hi,
Hi,
There are only 10 attributes in Activity Calendar, so if you try to read attribute #11, I believe that meter is returning an error.
You are right. Attribute #10 is missing from obj_activityCalendarToString. It's added and the new version is released shortly.
BR,
Mikko
Hi Mikko,
Hi Mikko,
with respect to mention text in your last reply.
"There are only 10 attributes in Activity Calendar, so if you try to read attribute #11, I believe that meter is returning an error."
I've raised two different queries. one for Limiter and second for Activity Calendar. but it seems you misunderstood. attribute #11 with Limiter I've asked.
Regards,
Vishal
Hi,
Hi,
For some reason, I forget the limiter part. Are you reading the association view or are you adding those objects manually?
BR,
Mikko
Hi,
Hi,
I believe that I know the reason. This fails if the script table is not found from the association view. We'll fix this and release the new version tomorrow.
BR,
Mikko
Hi,
Hi,
I create issues:
Limiter action over and under thresholds read failed if script table object is not found from the association view.
https://www.gurux.fi/node/17796
obj_activityCalendarToString doesn't add attribute #10 to the string.
https://www.gurux.fi/node/17797
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thanks for your quick support with above queries and also thanks for your quick resolution.
Now, I have one more query.
I'm trying to read Profile Generic IP object: 1.0.94.91.0.255
first reading Index 3 and than Index 2
Issue I'm facing is in converted string from library.
-> Currently Library provide me below response string.
Index: 2 Value: "["02/02/2021 05:59:03 UTC+05:30", "230.639999", "0.000000", "0.000000", "0.000000", "49.980000", "0.000000", "0.000000", "0.000000", "127.000000", "0.000000", "FF FF FF FF FF FF FF FF FF 80 00 FF", "0.000000", "FF FF FF FF FF FF FF FF FF 80 00 FF", "224966.000000", "249", "14", "97", "0.000000", "0.000000", "False", "17280"]"
-> But expected response would be
Index: 2 Value: "["02/02/2021 05:59:03 UTC+05:30", "230.639999", "0.000000", "0.000000", "0.000000", "49.980000", "0.000000", "0.000000", "0.000000", "127.000000", "0.000000", "", "0.000000", "", "224966.000000", "249", "14", "97", "0.000000", "0.000000", "False", "17280"]"
so, "FF FF FF FF FF FF FF FF FF 80 00 FF" these fields not converting into date format.
when I dig into, I found something in convert() API
in "02/02/2021 05:59:03 UTC+05:30", library considering it as DLMS_DATA_TYPE_DATETIME
where as "FF FF FF FF FF FF FF FF FF 80 00 FF", library considering it as DLMS_DATA_TYPE_OCTET_STRING
might be due to this, "FF FF FF FF FF FF FF FF FF 80 00 FF" was not converting into date format.
Can you plz check once and provide some helpful details to me?
Regards,
Vishal
Hi,
Hi,
Meter is returning the date-time as DLMS_DATA_TYPE_OCTET_STRING. There is no easy way to check out that this value is date-time. Other programming languages handle this automatically, but we try to use as little memory as possible with ANSI C so you must do this by yourself.
Loop objects and change "FF FF FF FF FF FF FF FF FF 80 00 FF" to date time with dlms_changeType method. You can use the logical name to check when data must be converted.
BR,
Mikko
BR,
Mikko
Hi,
Hi,
There is a new version released where
https://www.gurux.fi/node/17796
and
https://www.gurux.fi/node/17797
are fixed.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I took released changes and its working expected.
But I'm facing issue when added some own snippet outside of library. Somehow Library is modifying outside buffers. Please find further details below.
Current snippet is something like below in communication.c file outside of DLMS-C Library;
static char obis_inOperation[25] = {0x00};
static void print_obis_inOperation(void)
{
printf("obis_inOperation -> ");
for(int ccc=0; ccc<25; ++ccc)
{
printf("%02x:", obis_inOperation[ccc]);
} printf("\n");
}
com_readValue()
{
...
print_obis_inOperation();
ret = com_read(connection, ptrObj, 7);
print_obis_inOperation();
...
}
Debug Prints are something like;
-------- Reading Object ActivityCalendar 0.0.13.0.0.255
obis_inOperation -> 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
Request -> 00:01:00:20:00:01:00:20:c8:1e:30:00:00:00:01:3d:7f:3d:0c:b5:21:65:1c:2e:b6:52:1d:8b:b0:53:95:62:bb:77:31:42:f1:91:22:b0:
Response -> 00:01:00:01:00:20:00:59:cc:57:30:00:02:54:08:07:1d:78:e9:ac:c9:29:f4:43:00:ef:ae:79:fb:95:3a:0a:5c:89:16:62:0d:9e:aa:7d:82:fb:14:23:91:39:43:7f:07:83:7c:a5:1f:26:f4:bd:b7:8c:5e:17:88:66:49:5a:af:12:63:4a:2b:bc:6e:ae:be:13:55:18:21:4f:9c:e4:bf:15:87:07:5e:ae:c0:4b:af:d9:35:7f:6d:e3:fc:22:68:
obis_inOperation -> 0a:00:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
so here, Library is modifying obis_inOperation buffer somehow, when I'm trying to read index 3. which is creating issue to me. Please note that, I've read multiple other meter objects, but not faced this type of issue with any of that.
Can you please check and let me know what could be the fix?
Regards,
Vishal
Hi Mikko,
Hi Mikko,
I made a mistake due to which above issue arises. Please ignore above message.
Both the fixes working as expected. Thanks for your support.
Regards,
Vishal
Hi Vishal,
Hi Vishal,
Thanks for letting me know this.
BR,
Mikko