Problems with SinoTrack ST-901M
Looks like there's some issue in the database.
Ok, thank you for your reply. The first database tables to look for data inconsistencies regarding incoming data from the devices would be tc_devices and tc_positions, right?
When thinking about the issue I come to the following conclusion regarding the error progression: Traccar would probably take the uniqueid (gps device identifier) given by the h02 encoded message to the server (9176966567 in the error example) and query for the unique id in tc_devices. This id would be referenced in the data set for a new row in tc_positions as deviceid (foreign key, right?). I don't understand where the database inconsistency occurs in this scenario with a valid h02 message. Could the root of the issue be a change in the database structure between Taccar v6.5 and v4.11 or because of the switch from H2 to MariaDB? What do you think?
Since the error is related to JSON parsing could it be that Traccar tries to read old data but because there was a protocol change following the device change for the migration Traccar tries to query data for the wrong protocol?
Since it is the only field with JSON data the tc_positions.attributes data would be my guess for source of the Nullpointer exception. Here some data rows the faulty the example device probably try to access or tries to produce during the error:
- tc_devices entry:
select * from tc_devices where uniqueid=9176966567 limit 1;
+----+-------+------------+---------------------+------------+---------+------------+-------+-------------+---------+----------+----------+---------+----------------+-------------+------------+----------------+----------------+---------------+---------------------+--------------+------------+
| id | name | uniqueid | lastupdate | positionid | groupid | attributes | phone | model | contact | category | disabled | status | expirationtime | motionstate | motiontime | motiondistance | overspeedstate | overspeedtime | overspeedgeofenceid | motionstreak | calendarid |
+----+-------+------------+---------------------+------------+---------+------------+-------+-------------+---------+----------+----------+---------+----------------+-------------+------------+----------------+----------------+---------------+---------------------+--------------+------------+
| 48 | TK 52 | 9176966567 | 2024-06-19 09:28:18 | 19761082 | 11 | {} | | Ford Ranger | Technik | default | | offline | NULL | | NULL | 0 | | NULL | 0 | | NULL |
+----+-------+------------+---------------------+------------+---------+------------+-------+-------------+---------+----------+----------+---------+----------------+-------------+------------+----------------+----------------+---------------+---------------------+--------------+------------+
- tc_positions (last valid entry migrated from H2 database to new MariaDB database):
select * from tc_positions where deviceid=48 limit 1;
+--------+----------+----------+---------------------+---------------------+---------------------+-------+------------+-----------+----------+-------+--------+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+-------------+
| id | protocol | deviceid | servertime | devicetime | fixtime | valid | latitude | longitude | altitude | speed | course | address | attributes | accuracy | network | geofenceids |
+--------+----------+----------+---------------------+---------------------+---------------------+-------+------------+-----------+----------+-------+--------+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+-------------+
| 110562 | ruptela | 48 | 2021-01-19 15:10:55 | 2021-01-19 15:10:48 | 2021-01-19 15:10:48 | | 49.5861066 | 8.3266633 | 401.9 | 0 | 18 | null | {"sat":16,"hdop":0.6,"event":7,"ignition":false,"io173":0,"io27":29,"io28":1,"io29":12050,"io30":4047,"io65":11725836,"io150":26203,"distance":0.0,"totalDistance":0.0,"motion":false} | 0 | null | NULL |
+--------+----------+----------+---------------------+---------------------+---------------------+-------+------------+-----------+----------+-------+--------+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+-------------+- An example of an valid h02 entry for comparionson to the old ruptela data:
select * from tc_positions where protocol='h02' limit 1;
+-------+----------+----------+---------------------+---------------------+---------------------+-------+----------+-----------+----------+-------+--------+---------+--------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+-------------+
| id | protocol | deviceid | servertime | devicetime | fixtime | valid | latitude | longitude | altitude | speed | course | address | attributes | accuracy | network | geofenceids |
+-------+----------+----------+---------------------+---------------------+---------------------+-------+----------+-----------+----------+-------+--------+---------+--------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+-------------+
| 10859 | h02 | 88 | 2024-07-23 11:43:43 | 2024-07-23 11:43:37 | 2024-07-23 11:43:37 | | 22.99963 | 112.9996 | 0 | 0 | 227 | NULL | {"ignition":true,"status":4294967295,"io1":"262","io2":"01","io3":"21068","io4":"55631","distance":0.0,"totalDistance":0.0,"motion":false} | 0 | null | null |
+-------+----------+----------+---------------------+---------------------+---------------------+-------+----------+-----------+----------+-------+--------+---------+--------------------------------------------------------------------------------------------------------------------------------------------+----------+---------+-------------+
It could be any table. It fails on loading device cache. So anything that's linked to the device could have a problem.
Ok, thank you.
We tried to migrate an old Traccar instance (Traccar v4.11 on Windows with H2 database) to a new Traccar instance with the current version (Traccar 6.5 on Linux with MariaDB database [ENGINE=InnoDB]). We used DBeaver Community Editon to migrate the DB Tables. This seemed to work for all the user, device and geofence data.
Then when switching the server-IP for the devices we ran into some problems. We migrated 69 devices (all GPS-devices are SinoTrack model ST-901M or ST-901W) most went fine but 10 of them didn't come online in the new Web interface.
The most common error regarding these devices in the traccar_server_log was like the following example (slightly obfuscated):
For most of the faulty devices the model was switched from another manufacturer to a new ST-901M and the previously migrated device entries were changed to a new unique_id to target the correct device. But since we have more devices which work after the same procedure, we can't seem to find the reason for this. Can the error lie in the db migration?
We would be really happy about some pointers regarding this error messages. Can someone help us with this?