@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.
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?
Only until the first time.
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.
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.
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.
@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.
Thank you Anton, :)
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?
Does it show errors for messages with GPS data as well? If yes, can you please post a fragment of the log.
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?
A foreign key from device table should point to it.
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?
I think I found an explanation for the problem in MySQL documentation:
As soon as you start receiving correct GPS coordinate, it should fix itself.