After update to 5.9 devices offline

M Farida year ago

I upgraded to 5.9 fro 4.16.
I have alot of devices offline after upgrade
The devices works on protocol GT06 port5023
It sends a message but the server not able to decode i think.
Please help

Anton Tananaeva year ago

Have you checked the logs?

M Farida year ago

Yes, enabled the ALL log level, this is what i found:

2023-10-07 14:35:41 DEBUG: Flushed=true written=75 remaining=0 WriteFlusher@2c4947d1{WRITING}->null
2023-10-07 14:35:41 DEBUG: update WriteFlusher@2c4947d1{IDLE}->null:WRITING-->IDLE
2023-10-07 14:35:41  INFO: [Ta09b59a7: gt06 < 196.150.203.130] 78780d0103561535900356290011c68e0d0a
2023-10-07 14:35:41 DEBUG: Flushing Flusher@486a64d0[PROCESSING][queueSize=0,aggregate=null]
2023-10-07 14:35:41 DEBUG: Event received
2023-10-07 14:35:41 DEBUG: Flusher@486a64d0[PROCESSING][queueSize=0,aggregate=null] processed 0 entries flush=false batch=null: []
2023-10-07 14:35:41 TRACE:   simple execute, handler={0}, maxRows={1}, fetchSize={2}, flags={3}
2023-10-07 14:35:41 TRACE:  FE=> Bind(stmt=S_9,portal=null,$1=<'356153590035629'>,type=VARCHAR)
2023-10-07 14:35:41 DEBUG: notifyCallbackSuccess Flusher@46dbbbba[PROCESSING]
2023-10-07 14:35:41 TRACE:  FE=> Execute(portal={0},limit={1})
2023-10-07 14:35:41 TRACE:  FE=> Sync
2023-10-07 14:35:41 DEBUG: notifyCallbackSuccess org.eclipse.jetty.util.Callback$1@4396592e
2023-10-07 14:35:41 DEBUG: sendFrame(TEXT@70acbe4a[len=467,fin=true,rsv=000,m=null]HeapByteBuffer@136768cd[p=0,l=467,c=467,r=467]={<<<{"
positions":[{"id":50406...l,"geofenceIds":null}]}>>>}, org.eclipse.jetty.util.Callback$1@4396592e, false)
2023-10-07 14:35:41 DEBUG: Queuing TEXT@70acbe4a[len=467,fin=true,rsv=000,m=null]HeapByteBuffer@136768cd[p=0,l=467,c=467,r=467]={<<<{"po
sitions":[{"id":50406...l,"geofenceIds":null}]}>>>}
2023-10-07 14:35:41 DEBUG: onFrame TEXT@70acbe4a[len=467,fin=true,rsv=000,m=null]HeapByteBuffer@136768cd[p=0,l=467,c=467,r=467]={<<<{"po
sitions":[{"id":50406...l,"geofenceIds":null}]}>>>}
2023-10-07 14:35:41 TRACE:  <=BE BindComplete [{0}]
2023-10-07 14:35:41 TRACE:  <=BE DataRow(len={0})
2023-10-07 14:35:41 DEBUG: Extending out TEXT@70acbe4a[len=467,fin=true,rsv=000,m=null]HeapByteBuffer@136768cd[p=0,l=467,c=467,r=467]={<
<<{"positions":[{"id":50406...l,"geofenceIds":null}]}>>>} Flusher@6da26a57[PROCESSING] false
2023-10-07 14:35:41 TRACE:  <=BE CommandStatus({0})
2023-10-07 14:35:41 TRACE:  <=BE ReadyForQuery({0})
2023-10-07 14:35:41 DEBUG: Queuing TEXT@70acbe4a[len=467,fin=true,rsv=000,m=null]HeapByteBuffer@136768cd[p=0,l=467,c=467,r=467]={<<<{"positions":[{"id":50406...l,"geofenceIds":null}]}>>>}
2023-10-07 14:35:41 TRACE:   getString columnIndex: {0}
2023-10-07 14:35:41 TRACE:   getString columnIndex: {0}
2023-10-07 14:35:41 TRACE:   getLong columnIndex: {0}

IMEI tracked: 356153590035629
Aparently the device sends the login messages, but no responce from the server, cant figure out why? was working before upgrade.

M Farida year ago

Now I made a trial, I created a new database and defined the gps device in it, and it worked.
In th eoriginal database, removed the device and created a new one with same id, also not worked.
Any suggestions

M Farida year ago

Now I made a trials,
Trial 1: I created a new database and defined the gps device in it, and it worked.
Trial 2: In the original database, removed the device and created a new one with same id, also not worked.
Trial 3: I created a new user and created the device in the new user, and it worked ???
Any suggestions

Anton Tananaeva year ago

Not sure why you would enable debug logs, but it makes the output completely useless because it's almost impossible to find anything.

Alejandroa year ago

Hi M Farid!
did you solve this issue? I am facing same problem when upgrading from 4.15 to 5.10 with devices with GT06 protocol. The server is skipping positions without any reason

Your answer would be very helpful, i will appreciate your help

Anton Tananaeva year ago

Do you want to provide logs?

M Farida year ago

I solved it by deleting the devices and the user and create a new user and created the devices again, and it worked.
Didn't know the cause.

Alejandroa year ago

Hi Anton, here the logs of a connection:

2024-01-08 22:45:10  INFO: [T56d70d10] connected
2024-01-08 22:46:45  INFO: [T56d70d10: gt06 < 185.57.216.32] 78780d0108620920600064040006f9670d0a78780d0108620920600064040007e8ee0d0a78780d010862092060006404000810190d0a
2024-01-08 22:46:45  INFO: [T56d70d10: gt06 > 185.57.216.32] 787805010006ad630d0a
2024-01-08 22:46:45  INFO: [T56d70d10: gt06 > 185.57.216.32] 787805010007bcea0d0a
2024-01-08 22:46:45  INFO: [T56d70d10: gt06 > 185.57.216.32] 787805010008441d0d0a
2024-01-08 22:47:38  INFO: [T56d70d10] disconnected
  • Status timeout is set to 3600s , but got disconnected after 2-3 minutes
  • If peer sends a position, it is skipped
  • I tested M Farid workaround in one device: delete a device from migrated database, and saved again, and this device now works OK
  • My database has 3500 devices, positions tracked every 10 seconds (movement) or 1800 secs (stopped). I mentioned now I am testing for final migration to 5.10.
  • When low traffic/devices on testing server, all works OK. This "skipping positions" behaviour only happens when full charge.
  • MySQL and traccar optimization (https://www.traccar.org/optimization/) already done
Anton Tananaeva year ago

If re-creating device solves the problem, it likely means that your device had some timestamp in the future.

Alejandroa year ago

I have checked tc_positions and there is not any future timestamp for this device. What it is surprising for me is behavior changes depending on server load, any idea?