If you want to read the last day, you should use readByRange method. You can give start and end date.
Now you are using ReadByEntry, where you give index and count.
I can successfully initialize connection with different authentication levels, get association and read objects by their logical name. I can read profile columns also. However, I cannot read profile entries - every time I try, I get this getUInt16 error.
This getUint16 error is a major issue in my case. I sometimes get it when reading the association. Sometimes, meaning irregularly.
In case of association, after several attempts I usually manage to get it without error, but in case of readRowsByRange I always obtain getUint16 and I am unable to read profile entries.
I have similar troubles using Gurux Director. It somehow manages to read profile entries, but frequently reports "Invalid structure format", "System.IndexOutOfRangeException" or getUint16.
Do you think that the issue might caused by the meter itself?
Usually, meter are supporting read rows byRange better where you give start and end time.
All the meters are not supporting read rows by entry where you give start and end index.
If I had said that range is better supported its mistake. I did try to find this but didn't found it.
I checked this from the email that you did send to me and from this log.
When you give index and count, the meter returns a clear exception.
Can you try to read using start and end time? I check from my notes that some meters are expecting that time zone is skipped and your meter is expecting that.
Try something like tis:
java.util.Calendar start = java.util.Calendar.getInstance(java.util.TimeZone.getTimeZone());
start.set(java.util.Calendar.HOUR_OF_DAY, 0); // set hour to midnight
start.set(java.util.Calendar.MINUTE, 0); // set minutes
start.set(java.util.Calendar.SECOND, 0); // set seconds
start.set(java.util.Calendar.MILLISECOND, 0);
start.add(java.util.Calendar.DATE, -1);
java.util.Calendar end = java.util.Calendar.getInstance();
end.set(java.util.Calendar.MINUTE, 0); // set minutes
end.set(java.util.Calendar.SECOND, 0); // set seconds
end.set(java.util.Calendar.MILLISECOND, 0);
GXDateTime s = new GXDateTime(start);
GXDateTime e = new GXDateTime(end);
//Skip devitation
s.getSkip().add(DateTimeSkips.DEVITATION);
e.getSkip().add(DateTimeSkips.DEVITATION);
cells = readRowsByRange((GXDLMSProfileGeneric) it, s, e);
Thank you for replying. I have tried what you suggested (reading rows by range with time skips), but without any success. I get the same error - getUint16.
This is what I tried:
Calendar end = Calendar.getInstance();
end.set(Calendar.MINUTE, 0);
end.set(Calendar.SECOND, 0);
GXDateTime entToReturn = new GXDateTime(end);
entToReturn.setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND)));
This is really strange. Your data is correct, but the meter doesn't reply at all.
Can you check the following:
1. Meter firmware is the latest?
2. Can you read all the rows from the meter in 1.0.99.1.0.255? Is there data between 2019-12-02 00:00 and 2019-12-03 08:00
1. Yes, the firmware version is the latest.
2. There is data in the specified period - please see attached screen below. I can read profile entries by Gurux Director, you can see non-null entry for 2019-12-02 10:00.
That's what makes me think that the problem might concern gurux java implementation, not the gurux or meter itself, as it works in director.
I have built a private package and conducted numerous tests, but the result is the same: getUInt16. I have sent you transmission logs on email.
I have tried different parametrization of skips, according to your advice:
- setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND, DateTimeSkips.DAY_OF_WEEK))),
- setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND))),
- no skips.
Please let me know in case you implement any further changes, I'll be happy to conduct tests on my meter.
So I should obtain the same format as I get in GXDLMSDirector, which according to you is:
07 E3 0C 03 02 00 00 00 FF FF C4 00
These are my datetimes when particular skips are set:
Nothing skipped: 07 E3 0C 02 01 00 00 00 00 FF C4 00
Miliseconds and day of week: 07 E3 0C 02 FF 00 00 00 FF FF C4 00
Day of week only: 07 E3 0C 02 FF 00 00 00 00 FF C4 00
Miliseconds only: 07 E3 0C 02 01 00 00 00 FF FF C4 00
So the closest to GXDLMSDirector is skipping only miliseconds:
07 E3 0C 02 01 00 00 00 FF FF C4 00 //milliseconds skipped
07 E3 0C 03 02 00 00 00 FF FF C4 00 // GXDLMSDirector
-----------^^ ^^-------------------
I marked the difference (02 01 vs 03 02). What more should I change?
Hi,
Hi,
If you want to read the last day, you should use readByRange method. You can give start and end date.
Now you are using ReadByEntry, where you give index and count.
BR,
Miko
Hi Kurumi,
Hi Kurumi,
I used readRowsByRange after reading first item:
cells = readRowsByRange((GXDLMSProfileGeneric) it, start.getTime(), end.getTime());
That's where I've got "Failed to read last day: getUInt16". Please find the transmission logs below:
TX: 16:25:40.152 00 01 00 01 00 01 00 40 C0 01 C1 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E3 0B 0E FF 01 00 00 FF FF C4 00 09 0C 07 E3 0B 0F FF 10 00 00 FF FF C4 00 01 00
TX: 16:25:41.153 00 01 00 01 00 01 00 40 C0 01 C1 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E3 0B 0E FF 01 00 00 FF FF C4 00 09 0C 07 E3 0B 0F FF 10 00 00 FF FF C4 00 01 00
TX: 16:25:41.802 00 01 00 01 00 01 00 17 62 15 80 01 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D 05 50
Hi,
Hi,
Can you read anything else from the meter? Is the connection established? Can you read this with GXDLMSDirector?
Data is correct, but the meter doesn't reply for some reason.
BR,
Mikko
I can successfully initialize
I can successfully initialize connection with different authentication levels, get association and read objects by their logical name. I can read profile columns also. However, I cannot read profile entries - every time I try, I get this getUInt16 error.
This getUint16 error is a major issue in my case. I sometimes get it when reading the association. Sometimes, meaning irregularly.
In case of association, after several attempts I usually manage to get it without error, but in case of readRowsByRange I always obtain getUint16 and I am unable to read profile entries.
I have similar troubles using Gurux Director. It somehow manages to read profile entries, but frequently reports "Invalid structure format", "System.IndexOutOfRangeException" or getUint16.
Do you think that the issue might caused by the meter itself?
Hi,
Hi,
This is the first time when I'm hearing from this. Can you send failed log to me by email. I can check what is causing this.
BR,
Mikko
Email sent. I'd really
Email sent. I'd really appreciate your support on this. Thanks!
Mikko,
Mikko,
Following your advice, I tried to read profile by entry, instead of reading it by range (which according to you is not supported by the meter).
But reading by entry also causes problems:
gurux.dlms.GXDLMSException: Access Error : Device reports scope of access violated.
Which is unexpected, as I connect to the meter using G level and I can read and write single objects without any access issues.
Could you help resolve this issue?
Please find the full transmission log below:
TX: 15:59:58.423 00 01 00 01 00 01 00 38 60 36 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 41 42 34 38 34 30 43 44 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D FF FF
RX: 15:59:58.620 00 01 00 01 00 01 00 2B 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 1E 1D 05 50 00 07
Connection initialized, AARE response: 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 1E 1D 05 50 00 07.
Reading object: 1.0.99.1.0.255 Ch. 0 Load profile with recording period 1 #1, attribute: 3
TX: 15:59:59.138 00 01 00 01 00 01 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 03 00
RX: 15:59:59.337 00 01 00 01 00 01 00 96 C4 01 C1 00 01 08 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 02 04 12 00 01 09 06 00 00 60 0A 01 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 01 08 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 02 08 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 05 08 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 08 08 00 FF 0F 02 12 00 00 02 04 12 00 05 09 06 01 00 01 04 00 FF 0F 03 12 00 00 02 04 12 00 05 09 06 01 00 01 18 00 FF 0F 03 12 00 00
Reading object: 1.0.99.1.0.255 Ch. 0 Load profile with recording period 1 #1, attribute: 7
TX: 15:59:59.353 00 01 00 01 00 01 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 07 00
RX: 15:59:59.528 00 01 00 01 00 01 00 09 C4 01 C1 00 06 00 00 04 B8
Reading object: 1.0.99.1.0.255 Ch. 0 Load profile with recording period 1 #1, attribute: 8
TX: 15:59:59.530 00 01 00 01 00 01 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 08 00
RX: 15:59:59.723 00 01 00 01 00 01 00 09 C4 01 C1 00 06 00 00 45 AF
TX: 15:59:59.727 00 01 00 01 00 01 00 20 C0 01 C1 00 07 01 00 63 01 00 FF 02 01 02 02 04 06 00 00 00 01 06 00 00 00 05 12 00 01 12 00 00
RX: 15:59:59.896 00 01 00 01 00 01 00 05 C4 01 C1 01 0D
TX: 15:59:59.903 00 01 00 01 00 01 00 17 62 15 80 01 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D 05 50
RX: 16:00:00.074 00 01 00 01 00 01 00 05 63 03 80 01 00
Connection released: 63 03 80 01 00
Hi,
Hi,
Usually, meter are supporting read rows byRange better where you give start and end time.
All the meters are not supporting read rows by entry where you give start and end index.
If I had said that range is better supported its mistake. I did try to find this but didn't found it.
I checked this from the email that you did send to me and from this log.
When you give index and count, the meter returns a clear exception.
Can you try to read using start and end time? I check from my notes that some meters are expecting that time zone is skipped and your meter is expecting that.
Try something like tis:
java.util.Calendar start = java.util.Calendar.getInstance(java.util.TimeZone.getTimeZone());
start.set(java.util.Calendar.HOUR_OF_DAY, 0); // set hour to midnight
start.set(java.util.Calendar.MINUTE, 0); // set minutes
start.set(java.util.Calendar.SECOND, 0); // set seconds
start.set(java.util.Calendar.MILLISECOND, 0);
start.add(java.util.Calendar.DATE, -1);
java.util.Calendar end = java.util.Calendar.getInstance();
end.set(java.util.Calendar.MINUTE, 0); // set minutes
end.set(java.util.Calendar.SECOND, 0); // set seconds
end.set(java.util.Calendar.MILLISECOND, 0);
GXDateTime s = new GXDateTime(start);
GXDateTime e = new GXDateTime(end);
//Skip devitation
s.getSkip().add(DateTimeSkips.DEVITATION);
e.getSkip().add(DateTimeSkips.DEVITATION);
cells = readRowsByRange((GXDLMSProfileGeneric) it, s, e);
BR,
Mikko
Hi Kurumi,
Hi Kurumi,
Thank you for replying. I have tried what you suggested (reading rows by range with time skips), but without any success. I get the same error - getUint16.
This is what I tried:
Calendar end = Calendar.getInstance();
end.set(Calendar.MINUTE, 0);
end.set(Calendar.SECOND, 0);
GXDateTime entToReturn = new GXDateTime(end);
entToReturn.setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND)));
Calendar start = Calendar.getInstance();
start.set(Calendar.HOUR_OF_DAY, 0);
start.set(Calendar.MINUTE, 0);
start.set(Calendar.SECOND, 0);
start.set(Calendar.MILLISECOND, 0);
start.add(Calendar.DATE, -1);
GXDateTime startToReturn = new GXDateTime(start);
startToReturn.setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND)));
Object[] cells = meterReader.readRowsByRange(profileGeneric, startToReturn, endToReturn);
Transmission log:
TX: 08:55:14.836 00 01 00 01 00 01 00 38 60 36 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 41 42 34 38 34 30 43 44 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D FF FF
RX: 08:55:15.048 00 01 00 01 00 01 00 2B 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 1E 1D 05 50 00 07
Connection initialized, AARE response: 61 29 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 10 04 0E 08 00 06 5F 1F 04 00 00 1E 1D 05 50 00 07.
Reading object: 1.0.99.1.0.255 Ch. 0 Load profile with recording period 1 #1, attribute: 3
TX: 08:55:15.405 00 01 00 01 00 01 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 03 00
RX: 08:55:15.688 00 01 00 01 00 01 00 96 C4 01 C1 00 01 08 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 02 04 12 00 01 09 06 00 00 60 0A 01 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 01 08 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 02 08 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 05 08 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 08 08 00 FF 0F 02 12 00 00 02 04 12 00 05 09 06 01 00 01 04 00 FF 0F 03 12 00 00 02 04 12 00 05 09 06 01 00 01 18 00 FF 0F 03 12 00 00
Reading object: 1.0.99.1.0.255 Ch. 0 Load profile with recording period 1 #1, attribute: 7
TX: 08:55:15.718 00 01 00 01 00 01 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 07 00
RX: 08:55:15.845 00 01 00 01 00 01 00 09 C4 01 C1 00 06 00 00 04 FC
Reading object: 1.0.99.1.0.255 Ch. 0 Load profile with recording period 1 #1, attribute: 8
TX: 08:55:15.847 00 01 00 01 00 01 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 08 00
RX: 08:55:16.067 00 01 00 01 00 01 00 09 C4 01 C1 00 06 00 00 45 AF
TX: 08:55:16.081 00 01 00 01 00 01 00 40 C0 01 C1 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E3 0C 02 FF 00 00 00 FF 80 00 00 09 0C 07 E3 0C 03 FF 08 00 00 FF 80 00 00 01 00
TX: 08:55:17.083 00 01 00 01 00 01 00 40 C0 01 C1 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E3 0C 02 FF 00 00 00 FF 80 00 00 09 0C 07 E3 0C 03 FF 08 00 00 FF 80 00 00 01 00
TX: 08:55:18.083 00 01 00 01 00 01 00 40 C0 01 C1 00 07 01 00 63 01 00 FF 02 01 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 E3 0C 02 FF 00 00 00 FF 80 00 00 09 0C 07 E3 0C 03 FF 08 00 00 FF 80 00 00 01 00
TX: 08:55:18.171 00 01 00 01 00 01 00 17 62 15 80 01 00 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 1E 1D 05 50
Hi,
Hi,
This is really strange. Your data is correct, but the meter doesn't reply at all.
Can you check the following:
1. Meter firmware is the latest?
2. Can you read all the rows from the meter in 1.0.99.1.0.255? Is there data between 2019-12-02 00:00 and 2019-12-03 08:00
BR,
Mikko
Hi,
Hi,
1. Yes, the firmware version is the latest.
2. There is data in the specified period - please see attached screen below. I can read profile entries by Gurux Director, you can see non-null entry for 2019-12-02 10:00.
That's what makes me think that the problem might concern gurux java implementation, not the gurux or meter itself, as it works in director.
Hi,
Hi,
Can you read profile generic with GXDLMSDirector and send trace to me.
I'll check this.
BR,
Mikko
Hi,
Hi,
I've read the profile generic with GXDLMSDirector successfully and sent you an email.
Thank you,
Pietari
Hi,
Hi,
Thank you from this info. There is one byte that is different between Java and C# versions.
Java don't use weekday and C# uses it.
I know the reason for this and we can remove lines from readByRange.
There is a legacy reason for this.
s.getSkip().add(DateTimeSkips.DAY_OF_WEEK);
e.getSkip().add(DateTimeSkips.DAY_OF_WEEK);
I'll send an email to you where is updated file.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thank you for quick response.
I have built a private package and conducted numerous tests, but the result is the same: getUInt16. I have sent you transmission logs on email.
I have tried different parametrization of skips, according to your advice:
- setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND, DateTimeSkips.DAY_OF_WEEK))),
- setSkip(new HashSet<>(Arrays.asList(DateTimeSkips.DEVITATION, DateTimeSkips.MILLISECOND))),
- no skips.
Please let me know in case you implement any further changes, I'll be happy to conduct tests on my meter.
Best wishes
Pietari
Hi,
Hi,
Don't skip DEVITATION. Only difference between GXDLMSDirector and java messages are that day of week and devitation are skipped on your java trace.
GXDLMSDirector date time.
07E3 0C 03 02 00 00 00 FF FFC4 00
Your latest java datetime:
07E3 0C 02 FF 00 00 00 FF 8000 00
BR,
Mikko
Thanks, so I removed skipping
Thanks, so I removed devitation skipping.
However, the problem still occurs, and my java datetime format is still different to GXDLMSDirector.
What should I skip then? Milliseconds, day of the week, or nothing?
So I should obtain the same
So I should obtain the same format as I get in GXDLMSDirector, which according to you is:
07 E3 0C 03 02 00 00 00 FF FF C4 00
These are my datetimes when particular skips are set:
Nothing skipped: 07 E3 0C 02 01 00 00 00 00 FF C4 00
Miliseconds and day of week: 07 E3 0C 02 FF 00 00 00 FF FF C4 00
Day of week only: 07 E3 0C 02 FF 00 00 00 00 FF C4 00
Miliseconds only: 07 E3 0C 02 01 00 00 00 FF FF C4 00
So the closest to GXDLMSDirector is skipping only miliseconds:
07 E3 0C 02 01 00 00 00 FF FF C4 00 //milliseconds skipped
07 E3 0C 03 02 00 00 00 FF FF C4 00 // GXDLMSDirector
-----------^^ ^^-------------------
I marked the difference (02 01 vs 03 02). What more should I change?
Hi,
Hi,
02 01 Is the day of month and weekday. I'll check this.
BR,
Mikko
Hi,
Hi,
Can you send a log to me by email from this?
BR,
Mikko
Hi Mikko,
Hi Mikko,
I've just sent an email with log.
Best wishes
Pietari