Hi there. I was using the Python library and I got a problem when trying to write the Clock time attribute.
I wanted to test a very far away date, like in the year 2040, but I got "Access Error : Device reports Read-Write denied."
After some testing on my part I arrived to the conclusion that it won't allow me to set a date after March 28th 2038. It works fine for a date prior to that.
However, the GuruX Director works just fine, letting me set whatever year I want, so the problem comes from the Python side of things.
Please let me know if someone can help me. Thank you in advance.
Hi, This is the year 2038…
Hi,
This is the year 2038 problem. The problem is that several meters are using UInt32 for Epoch time and this causes the problem. If you can write this with GXDLMSDirector can you add a hex trace from the write so I can check what might cause this? I did try to write this to the one meter and it worked without problems. Can you run python --version and let me also know the Python version number that you are using?
https://en.wikipedia.org/wiki/Year_2038_problem
BR,
Mikko
Hi Kurumi, thank for you…
Hi Kurumi, thank for you quick response.
These are the hex messages from Clock time writing via the GuruX Director the date "01/01/2063 01:18:09":
12:49:16 Writing object 0.0.1.0.0.255, interface Clock
TX: 7E A0 27 03 25 54 8F 5B E6 E6 00 C1 01 C1 00 08 00 00 01 00 00 FF 02 00 09 0C 08 0F 01 01 FF 01 12 09 FF 80 00 00 7F 03 7E
12:49:16
RX: 7E A0 10 25 03 74 5F C3 E6 E7 00 C5 01 C1 00 50 89 7E
12:49:16 Reading object 0.0.1.0.0.255, interface Clock
TX: 7E A0 19 03 25 76 2F BB E6 E6 00 C0 01 C1 00 08 00 00 01 00 00 FF 02 00 60 1A 7E
12:49:16
RX: 7E A0 1E 25 03 96 01 A9 E6 E7 00 C4 01 C1 00 09 0C 08 0F 01 01 01 01 12 09 FF FF C4 00 7E 5C 7E
The Python version I am using is the 3.10 one. The GuruX Library is in its most recent update too.
Hi, Can you get the hex…
Hi,
Can you get the hex trace from Python as well so I can compare them?
BR,
Mikko
Hi. Sure I'll send you the…
Hi. Sure I'll send you the log from both.
This is trying to write the following timestamp on the Clock time attribute: "31/03/2038 00:00:00"
This works on the Director but not on Python.
GURUX DIRECTOR LOGS:
14:59:49 Writing object 0.0.1.0.0.255, interface Clock
TX: 7E A0 27 03 25 98 EF 57 E6 E6 00 C1 01 C1 00 08 00 00 01 00 00 FF 02 00 09 0C 07 F6 03 1F FF 00 00 00 FF 80 00 80 B1 D2 7E
14:59:49
RX: 7E A0 10 25 03 B8 3F CF E6 E7 00 C5 01 C1 00 50 89 7E
14:59:49 Reading object 0.0.1.0.0.255, interface Clock
TX: 7E A0 19 03 25 BA 4F B7 E6 E6 00 C0 01 C1 00 08 00 00 01 00 00 FF 02 00 60 1A 7E
14:59:49
RX: 7E A0 1E 25 03 DA 69 21 E6 E7 00 C4 01 C1 00 09 0C 07 F6 03 1F 03 00 00 00 FF FF C4 00 D7 02 7E
PYTHON LOGS:
TX: 14:57:49 7E A0 25 03 25 BA 89 6C E6 E6 00 C1 01 C1 00 08 00 00 01 00 00 FF 02 00 09 0A 07 F6 03 1F FF 00 00 00 FF 00 7D 88 7E
RX: 14:57:49 7E A0 10 25 03 DA 2B 8F E6 E7 00 C5 01 C1 03 CB BB 7E
On Python it returns the following error: "Access Error : Device reports Read-Write denied."
Hi, There is something wrong…
Hi,
There is something wrong with your date-time. It's 07F6031FFF000000FF00 when it should be 07F6031FFF000000FF800080. So two bytes are missing.
Try with this:
c.time = datetime.datetime(2040,3, 31, 0, 00, 00)
BR,
Mikko
Hi Kurumi. Using datetime as…
Hi Kurumi.
Using datetime as you suggested let us set those dates without encountering the previous errors, however I still have a couple of questions.
How can we set ourselves the values for the timezone and the daylight saving using this method? Before, we constructed the hex strings ourselves with those values too, but here how can we pass them to the value?
Then, the resulting hex string, using the datetime method you suggested, seems different than what we were expecting before.
This is trying to write the following timestamp (format "dd/mm/yyyy HH:MM:SS") on the Clock time attribute: "31/03/2038 00:00:00"
PYTHON LOGS:
TX: 16:35:22 7E A0 27 03 03 54 6C 2C E6 E6 00 C1 01 C1 00 08 00 00 01 00 00 FF 02 00 09 0C 07 F6 03 1F 03 00 00 00 FF FF C4 00 95 49 7E
RX: 16:35:22 7E A0 10 03 03 74 BD 16 E6 E7 00 C5 01 C1 00 50 89 7E
As you can see we get "07 F6 03 1F 03 00 00 00 FF FF C4 00".
In general, we are quite confused on how to properly pass timestamps to the library in order to account these things too. If you can help us in understanding this better it would help us greatly. Thank you in advance.
Hi, You can add time zone…
Hi,
You can add time zone like this:
d = GXDateTime(datetime.datetime(2040,3, 31, 0, 00, 00))
#Timezone
d.deviation = 0x800
c.time = d
Daylight saving is updated using the clock object and they are not part of date time.
07 F6 03 1F 03 00 00 00 FF FF C4 00 look correct date-time. It's "31/03/2038 00:00:00"
What do you think is wrong in this?
BR,
Mikko
Hi Kurumi. We are having a…
Hi Kurumi.
We are having a hard time understanding the last four/three bytes. The other bytes, the ones linked to the datetime, are clear to us, but the last four/three ones, that should be linked to the deviation and daylight saving are not clear, we were expecting different results from "FF C4 00" for the datetime "31/03/2038 00:00:00".
Hi, From the read message,…
Hi,
From the read message, it looks like your meter is not using the deviation. You need to skip it like this.
d.skip = DateTimeSkips.DEVITATION
#or as I told before.
d.deviation = 0x800
BR,
Mikko