3.1 to 3.2 Upgrade

Anton Tananaev9 years ago

I think I found an explanation for the problem in MySQL documentation:

A TIMESTAMP cannot represent the value '1970-01-01 00:00:00' because that is equivalent to 0 seconds from the epoch and the value 0 is reserved for representing '0000-00-00 00:00:00', the “zero” TIMESTAMP value.

As soon as you start receiving correct GPS coordinate, it should fix itself.

Anton Tananaev9 years ago

@Andrei

Unfortunately there is no upgrade script for default H2 database. There is only one for MySQL:

https://www.traccar.org/update-from-3-1-to-3-2/

I guess you can adopt it to H2 if you have some SQL knowledge and if you really need to save data. If data is not that important, I would recommend to just remove the old database and start again from scratch.

Note that if data is important for you, you probably shouldn't use default embedded database and go with MySQL or PostgreSQL for example.

jaimzj9 years ago

Okay, I just noticed one more thing.

When traccar service was stopped for upgrade, the data stored on devices were later sent when the traccar services were started hence the data coming in was old data. during that time I could see these in the log.

However now, I dont see those messages in the log.

And regarding what you quoted above from MYSQL documentation, would that by anyway mean that everytime device sends non gps data, it would repeat the same thing? or is it only until the first set of GPS cordinates are received.

Additionally, I feel position duplicate filter might need to be disabled for this to work right?

Anton Tananaev9 years ago

Only until the first time.

jaimzj9 years ago

Another set of info, I removed the filter (position duplicate) and now, the error continuously shows up for all devices including, devices with correct gps updates in the position table.

  • These position updates can be some as recent as 1 hour back and some few seconds back, and some months back.
jaimzj9 years ago

And another feedback from my side is.

(Now I can see for a particular vehicle, that is Parked/Stationary), It is I believe accepting those non GPS status messages.

However for each such message - it makes a entry in position table with attributes. as below.

{"alarm":true,"ignition":false,"power":6,"gsm":4,"index":118,"ip":"106.194.9.76"}

Two points I noticed.

  1. Alarm shows : true
  2. This would also mean a lot more entries in the position table (Increasing the table size)
Anton Tananaev9 years ago

Yes, it would mean more entries in position table, but as you noticed it's possible to filter those if you don't want this feature.

Andrei9 years ago

@tananaev

Thanks for the quick answer. I will move to MySQL, will also try to migrate the H2 database but if it's too much pain I will start from scratch.

jaimzj9 years ago

Thank you Anton, :)

jaimzj9 years ago

Dear Anton,

I might have to re-start this topic again, Trying to figure out how this works.

I have a device id = 39 in device table.

In position Table last position received for this device is as below time stamps, and above that in log it does show entries, with that epoch 1970 error which means the device is sending status messages.

serverTime : 2015-11-01 18:28:19
deviceTime : 2015-11-01 18:28:19
fixTime : 2015-11-01 18:28:19
valid : 1
latitude : xx.574047088623047
longitude : xx.36486053466797
attributes : {"sat":5,"mcc":404,"mnc":7,"lac":3,"cell":5242880,"index":102,"ip":"106.67.180.162"}

But in this case, there is a GPS Data available in position Table, why would then this error be thrown then? and not stored as status message, as you mentioned earlier.

Some devices It does work as well for. so sharing the position last with you so you can see if there is any other condition set in the code?

Anton Tananaev9 years ago

Does it show errors for messages with GPS data as well? If yes, can you please post a fragment of the log.

jaimzj9 years ago

Dear Anton,

Data with GPS it does not show that error message.
Data without GPS it shows that error message only some devices but majority. (All my devices are same make/version).

I was able to resolve this issue, here is what the problem was as per my understanding.

When ever I added a device, I made the initial position entry with a pre-fixed location, during which the deviceTime, ServerTime Values were set, however fixTime was set as '0000-00-00 00:00:00'

What I did was replaced all the fixTime='0000-00-00 00:00:00' to an actual date. and now I don't see the error.

However I do have one concern, all such position entries where the 1st entry for the device, not the last. So am just wondering is it necessary to read row1 or the latest row?

Anton Tananaev9 years ago

A foreign key from device table should point to it.

jaimzj9 years ago

Dear Anton,

Another development, Please advice if this is how it is supposed to be.

Now I dont see those epoch deviceTime errors at all.

Status Message's are being updated into Position table, However

The positionId in device Table is not being updated with the latest status messages position. is that the correct working?