When I use Director I can read from and write to clock.
However, using Gurux.DLMS.c, I can only read the clock, the write operation does not return any data and does not update the clock.
I am using HLS, and I have filled the object struct like this:
thanks for the reply. I used the example code, but I am not sure that the time_init is working properly, see image attached. After sending de message there is no change in meter's clock and there is no response to the write command. It is supposed to have an answer after a write, isn't it?
Thanks,
Jose Torres
You need to change the authentication level at least to low before you can update the clock. The meter should reply to an error if the write fails. Writing time isn't always an easy task. There are a lot of different properties for the date-time and if one of them is different that meter expects, write fails.
Try to read date-time from the meter and then write it back. Check what meter replies. The deviation is usually reason for the problems. You must use the same time zone than the meter is using.
Hi Mikko,
I am using dlms_Authentication_High_GMAC as HLS, with password, systemTitle and keys provided by the maker of the meter with no success.
About the example code, at what moment the struct time is transformed into gxobject that is passed to cl_write? It is passed clock.base that is gxobject type, and there there is no data about time...
What kind of error you are getting? Ask if you need to read the Invocation counter first from the manufacturer.
gxObject is base structure. When data is written to the meter we have base address that is converted to gxClock. This is used in ANSI C because there are no classes.
that is the problem, I get no answer when trying to write, it seems that the meter simply ignore the command. The manufacturer said that the invocation number is restarted as 1 for each new connection...
I thougth that could be an authentication problem, but then I tried to read some objects that can only be read if you have HLS and it worked, so the authentication was in place and working. I also tried to write to more simple objects than the clock and could not write too.
I have no idea of what to try now, do you have any more tips that I could check?
Thanks,
José Torres
Because data is ciphered I can't say anything for sure. I notest that the client doesn't increase the invocation counter after AARQ is generated. I created an issue from it and it's not fixed. I don't know if this might help you. Get the latest version and let me know if you have problems.
Hi Mikko,
I have found that the problem was that I was not initializing the clock object before sending the message.
I followed the example you refered me to:
gxClock clock;
unsigned char ln[] = { 0,0,1,0,0,255 };
INIT_OBJECT(clock, DLMS_OBJECT_TYPE_CLOCK, ln);
time_init(&clock.time, 2000, 1, 1, 0, 0, 0, 0, 0x8000);
ret = com_write(connection, &clock.base, 2);
and now it works.
But what about other types of objects, they have a _init like clock? How I initialize an object of type data, for example? Is there a data_init? Where can I find it?
Thanks,
José Torres
int var_setUInt32(dlmsVARIANT* data, uint32_t value)
{
var_clear(data);
data->vt = DLMS_DATA_TYPE_UINT32;
data->lVal = value;
return DLMS_ERROR_CODE_OK;
}
it is setting lVal, and should be ulVal, rigth?
Hi,
Hi,
There is com_updateClock method in client example that does this.
https://github.com/Gurux/GuruxDLMS.c/blob/85cd98d18013d60fc43fef2dc914c…
BR,
Mikko
Hi Mikko,
Hi Mikko,
thanks for the reply. I used the example code, but I am not sure that the time_init is working properly, see image attached. After sending de message there is no change in meter's clock and there is no response to the write command. It is supposed to have an answer after a write, isn't it?
Thanks,
Jose Torres
Hi,
Hi,
You need to change the authentication level at least to low before you can update the clock. The meter should reply to an error if the write fails. Writing time isn't always an easy task. There are a lot of different properties for the date-time and if one of them is different that meter expects, write fails.
Try to read date-time from the meter and then write it back. Check what meter replies. The deviation is usually reason for the problems. You must use the same time zone than the meter is using.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I am using dlms_Authentication_High_GMAC as HLS, with password, systemTitle and keys provided by the maker of the meter with no success.
About the example code, at what moment the struct time is transformed into gxobject that is passed to cl_write? It is passed clock.base that is gxobject type, and there there is no data about time...
BR,
Jose Torres
Hi,
Hi,
What kind of error you are getting? Ask if you need to read the Invocation counter first from the manufacturer.
gxObject is base structure. When data is written to the meter we have base address that is converted to gxClock. This is used in ANSI C because there are no classes.
BR,
Mikko
Hi Mikko,
Hi Mikko,
that is the problem, I get no answer when trying to write, it seems that the meter simply ignore the command. The manufacturer said that the invocation number is restarted as 1 for each new connection...
I thougth that could be an authentication problem, but then I tried to read some objects that can only be read if you have HLS and it worked, so the authentication was in place and working. I also tried to write to more simple objects than the clock and could not write too.
I have no idea of what to try now, do you have any more tips that I could check?
Thanks,
José Torres
Hi,
Hi,
Can you get me a trace from the sent and received bytes and I can check what is happening.
BR,
Mikko
Hi Mikko,
Hi Mikko,
that is the log of trying to write to 0.0.1.0.0.255, attribute 8, dayligth saving enable:
Trying to write 1 to 0.0.1.0.0.255:8 (Dayligth Saving Enable)
Start Connection
send: 7EA00703 03938C11 7E
receive: 7EA01E03 037340CC 81801205 01800601 80070400 00000108 04000000 01533B7E
parse UAResponse OK
send AARQ request
send: 7EA07003 03107BAA E6E60060 62A10906 07608574 05080103 A60A0408 4D4D4D00
00BC614E A9030201 018A0207 808B0760 85740508 0205AC12 80107038 9CCE67B3 59AC56AB 552A158A
4522BE23 0421211F 30000000 012BFC9A BC946111 23B51EB0 76C3E2D5 F14F68E1 F1F33C7A BB20F334
067E
receive: 7EA07C03 03304D1C
E6E70061 6EA10906 07608574 05080103
A2030201 00A305A1 0302010E A40A0408
534D5733 30303033 A7030201 01880207
80890760 85740508 0205AA12 80101B0D
86432110 88C4E271 B8DCEE77 3B9DBE23
0421281F 30000000 021156EC E3779DFA
FC2D23EC CF7A7037 1849F267 F7557A10
6D49D283 E77E
parse AAREResponse OK
send Application Association Request
send: 7EA03F03 0332250C
E6E600CB 31300000 0001E9FD 1BBC9D3E
0E0FB51E 516AC26B 55218B12 E810E884
F8898D58 41775383 21C0D8C6 C274253B
6B88A992 3C7C8718 7E
receive: 7EA03803 03520238
E6E700CF 2A300000 0002DE57 6BBC6999
F3ED233E EC4F7871 9B22834A A768BF13
51768FC7 D3C91C13 EB0AC408 FC30DC04
747E
parse Application Association Response OK
send write to 0.0.1.0.0.255:8 to enable dayligth saving:
send:
7EA02E03 03540FD5 E6E600C9 20300000
00025660 EEFA6139 C63F6362 933213A6
F21D90B3 33308CB0 E0CCE183 9975857E
No response...
Thanks,
José Torres
Hi José,
Hi José,
Because data is ciphered I can't say anything for sure. I notest that the client doesn't increase the invocation counter after AARQ is generated. I created an issue from it and it's not fixed. I don't know if this might help you. Get the latest version and let me know if you have problems.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I have found that the problem was that I was not initializing the clock object before sending the message.
I followed the example you refered me to:
gxClock clock;
unsigned char ln[] = { 0,0,1,0,0,255 };
INIT_OBJECT(clock, DLMS_OBJECT_TYPE_CLOCK, ln);
time_init(&clock.time, 2000, 1, 1, 0, 0, 0, 0, 0x8000);
ret = com_write(connection, &clock.base, 2);
and now it works.
But what about other types of objects, they have a _init like clock? How I initialize an object of type data, for example? Is there a data_init? Where can I find it?
Thanks,
José Torres
Hi Jose,
Hi Jose,
All works at the same way.
gxData d;
unsigned char ln[] = { ... };
INIT_OBJECT(d, DLMS_OBJECT_TYPE_DATA, ln);
GX_INT32(d.value) = 10;
ret = com_write(connection, BASE(d), 2);
BR,
Mikko
Hi Mikko,
Hi Mikko,
I found that just after I sent the message...
And I found a little bug also in variant.c:
int var_setUInt32(dlmsVARIANT* data, uint32_t value)
{
var_clear(data);
data->vt = DLMS_DATA_TYPE_UINT32;
data->lVal = value;
return DLMS_ERROR_CODE_OK;
}
it is setting lVal, and should be ulVal, rigth?
Thank you very much for your help.
BR,
José Torres
Hi,
Hi,
Because value is stored to the union it doesn't matter, but you are right. I'll add this to the worklist and it's released with the next release.
BR,
Mikko