Possible problem in the GXDateTime class of the Python library

By MetersGuru , 23 January, 2024
Forums
Gurux.DLMS

Hi there. I was using the Python library and I got a problem when trying to read the Clock time attribute.

I wanted to get the time timestamp value in a string form, using the format "%d/%m/%Y %H:%M:%S", so I used the GXDateTime method "toFormatString" with that pattern.
However, it often did not create a string with that pattern I specified in the input.

After a little digging, I think I got to the root of the problem, inside the "__toFormatString" of the same GXDateTime class.
Using the debugger I noticed that I only got those problems when it did not enter the "self.skip != DateTimeSkips.NONE" IF block.
It looks like that, inside that IF block, the result of the method actually takes into account the pattern that got passed via the input, however if you look at the result that gets returned outside of that IF block, the input pattern is not used, which is where I think the problem lies.

Of course I may be mistaken, so please, let me know if this is a bug that will be patched or if I am missing something.
Thank you in advance.

Kurumi

2 years 4 months ago

Hi,

Can you add a meter reply here as a hex string so this can be verified?

BR,
Mikko

MetersGuru

2 years 4 months ago

Hi Kurumi, thanks for you quick response.

These are the hex messages both in TX and RX:
TX: 12:42:24 7E A0 19 03 25 54 3F B9 E6 E6 00 C0 01 C1 00 08 00 00 01 00 00 FF 02 00 60 1A 7E
RX: 12:42:24 7E A0 1E 25 03 74 1D 6D E6 E7 00 C4 01 C1 00 09 0C 08 05 01 01 03 01 0B 20 00 FF C4 00 7D D3 7E

I don't think the problem is in the communication, as with the debugger I can see the correct value is retrieved by the Clock time read.
The problem only arises when I try to use the GXDateTime method "toFormatString", as it seems it will eventually ignore the pattern I pass to it (if it doesn't enter inside the IF block I described in my original post).

Kurumi

2 years 4 months ago

Hi,

Meters are sending data so many different was that I asked the bytes for that reason.

This was tested with meter reply: 7E A0 1E 25 03 74 1D 6D E6 E7 00 C4 01 C1 00 09 0C 08 05 01 01 03 01 0B 20 00 FF C4 00 7D D3 7E

and the output is: 01/01/53 02:11:32 when the method is
dt.toFormatString("%d/%m/%Y %H:%M:%S")

No fields are marked skipped by the meter.

So it seems to work with Python 3.11.7. Can you run python --version and let me know the Python version you are using?

BR,
Mikko

MetersGuru

2 years 4 months ago

My Python version is 3.10.

The date you get is correct, but you seem to have the same problem that I have.
The format we both tested is using capital Y for the year, meaning it should return the year with four digits instead of two.
If you look inside the "__toFormatString" of the GXDateTime class (which is the function that ends up getting called in the end by the normal "toFormatString" function) you will see that if it happens to have the "skip" value equal to "DateTimeSkips.NONE" then it will not use the pattern given via input, which causes the string to not having the four digits for the year in this example.

MetersGuru

2 years 4 months ago

Thank you for your work. I tested it on the new version and it now works properly.