Timezone issues with gt06

Peter3 years ago

Hello,

I am running a server in Europe with daylight saving zones (CEST = GMT+2).
The server has the time set with this date-output:
Thu Apr 1 22:55:10 CEST 2021
Thu, 01 Apr 2021 22:55:10 +0200

A gt06 device sends this data (according to the logs):

2021-04-01 22:55:41  INFO: [ee33208b: gt06 < 89.14.19.20] HEX: 78782222150401143726cf0531348f01ba644000148e00e80100bf004d760000000467a0490d0a
2021-04-01 22:55:41  INFO: [ee33208b: gt06 > 89.14.19.20] HEX: 78780522046754d30d0a
2021-04-01 22:55:41  INFO: [ee33208b] id: 352672102036886, time: 2021-04-01 20:55:38, lat: 48.39489, lon: 16.10699, course: 142.0

The problem is the data which is saved in the database.
This data package is saved as a position with the following entries:
servertime: 2021-04-01 20:55:41
devicetime: 2021-04-01 18:55:38
fixtime: 2021-04-01 18:55:38

According to my understanding the time in the logs with "2021-04-01 20:55:38" is UTC but it is stored yet with 2 hours prior in the database which is obviously wrong.
Until now i wasn't able to set up a unit test for simulating and debugging the input of this data into traccar. Same for using a dummy client to manually send this data for debugging.

It gets even more interesting with data from this device. Every 10 pakets a new position is additionally inserted into the database where the devicetime is right. In every of those added entries the network is "null".
Example:
servertime: 2021-04-01 20:56:36
devicetime: 2021-04-01 20:56:36
fixtime: 2021-04-01 18:56:08
network: "null" (as literal, no real null value)
But in the logs there is no data for this entry:

2021-04-01 22:56:36  INFO: [ee33208b: gt06 < 89.14.19.20] HEX: 78780a1344060400010469da9e0d0a
2021-04-01 22:56:36  INFO: [ee33208b: gt06 > 89.14.19.20] HEX: 78780513046961df0d0a
2021-04-01 22:56:36  INFO: [ee33208b] id: 352672102036886, time: 2021-04-01 20:56:08, lat: 48.39489, lon: 16.10699, course: 142.0
2021-04-01 22:56:41  INFO: [ee33208b: gt06 < 89.14.19.20] HEX: 78782222150401143826cf0531349501ba644000148e00e80100bf004d76000000046afd7d0d0a
2021-04-01 22:56:41  INFO: [ee33208b: gt06 > 89.14.19.20] HEX: 78780522046a8f360d0a
2021-04-01 22:56:41  INFO: [ee33208b] id: 352672102036886, time: 2021-04-01 20:56:38, lat: 48.39489, lon: 16.10699, course: 142.0

The attributes for those entries are always like this (beside the totalDistance):

{"status":68,"ignition":false,"charge":true,"blocked":false,"batteryLevel":100,"rssi":4,"distance":0.0,"totalDistance":1.004037229E7,"motion":false,"hours":506355000}

There is no entry for "gt06.timezone" in the configuration.
There is no entry regarding timezone in the configuration of this server.
There is no entry regarding timezone in the configuration of this device.

Conclusion: Traccar seems to substract 2 more hourse from the sent time of UTC from the device without any reason I can find.

Can you give me a hint how to fix/analyze/debug this?

Regards
Peter

Anton Tananaev3 years ago

If your device doesn't report UTC time, you have to configure gt06.timezone to the timezone that your device is reporting in.

Peter3 years ago

As you can see in the log entries, the sent data from the devices are in UTC.
I also used the unit tests to debug the decoding of the messages and all the time, the data of the devices is proper UTC time.

Anton Tananaev3 years ago

Please highlight where you see it. Make sure you highlight original HEX.

Peter3 years ago

Uhm, I just used a unit test to decode the data and debugged to the point where the datetime is decoded.
I used a unit test like this:

    @Test
    public void testDecode3() throws Exception {
        Gt06ProtocolDecoder decoder = new Gt06ProtocolDecoder(null);
        Object object = binary("78782222150401143726cf0531348f01ba644000148e00e80100bf004d760000000467a0490d0a");
        decoder.decode(null, null, object);
    }

This provided me the information in Gt06ProtocolDecoder -> decodeGps (line 224) with the Datebuilder the proper information.
If you want me to show you which bytes are the datetime in this hex, then i'd first have to analyze how the gt06 protocol is set up and/or the decoder is working for finding this exact position.

Anton Tananaev3 years ago

I would recommend doing that. Find bytes. It's not hard.

Peter3 years ago

78782222150401143726cf0531348f01ba644000148e00e80100bf004d760000000467a0490d0a
The date + time is in the emphasized 6 bytes.
This is "2021-04-01 20:55:38" UTC which i received at 2021-04-01 22:55:41 server time (GMT+2)
So according to this observation the device should properly send UTC but Traccar is storing it as "2021-04-01 18:55:38" in device and fixtime.

Anton Tananaev3 years ago

Interesting. The only possible explanation I see is that device reports wrong timezone here:

https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/protocol/Gt06ProtocolDecoder.java#L455-L471

You can try overriding it.

Peter3 years ago

Could be, but this message has the type 34 (hex 22), thus it isn't of the type "MSG_LOGIN".
Thus the timezone is set here:
https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/protocol/Gt06ProtocolDecoder.java#L435-L443
and the rest of the message is decoded here:
https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/protocol/Gt06ProtocolDecoder.java#L540-L544

Anton Tananaev3 years ago

Login is always the first message, so you should have it too.

Peter3 years ago

I have found now the login message:
78780d0103526721021661620329de320d0a
7878 = basic
0d = 13 byte length (13 - 5 = 8 byte data length)
01 = message id (MSG_LOGIN)
Because data length is < 10 no further data is being processed

So the login message doesn't provide any information for the timezone. So the device is still using the data default timezone with UTC.

I also sent the data of this tracker for a short time to the demo3 tracker and there the data was displayed properly.
I'm really confused where to look further regarding this error.

Anton Tananaev3 years ago

I would recommend debugging. Maybe the timezone is set somewhere. Possibly on a group or something.

Peter3 years ago

Thanks a lot for the feedback and hint with the group.
In the end there was a timezone set in a group which caused the wrong timezone for decoding the datetime. (Found it by debugging)

By the way: is there some official GT06 specification available somewhere? Until now my understanding of the GT06 protocol comes from reverse engineering the Traccar GT06 code.

Anton Tananaev3 years ago
Peter3 years ago

Godlike, thanks again :)