Positions missings in certain traccar version
Most likely some protocol specific issue. Have you checked the logs? You might want to backport the changes from the latest version to improve the protocol support.
Thank you for your response. Yes, I have checked the logs, but there are neither errors nor exceptions. There is simply no information appearing in the log. I searched with the specific IMEI of the devices with problems, but it seems like we don't receive data during those periods of time. Sometimes, some warnings appear of a filter ignoring positions, the duplicate filter, but I thought that shouldn't be the reason because a duplicated position has the same latitude and longitude, right? Additionally, the same filter is also enabled in the 4.5 version.
I think you need to dig deeper into a specific interval where you expected device to report, but it doesn't. Is there any HEX or nothing at all? If nothing at all, does service restart improve things?
I check on a specific interval where a noticed this situation
Until this point the device report normally, this is the imei: 868003032012465
2023-03-26 08:13:52 DEBUG: [DF9EA6C5: 5023 < 200.68.138.5] HEX: 7878211217031a0e0d33c701eddecd0af7a738089c81014e000f8c0054ca80000182d5a60d0a
2023-03-26 08:13:52 DEBUG: [DF9EA6C5: 5023 > 200.68.138.5] HEX: 7878051201821c660d0a
2023-03-26 08:13:52 INFO: [DF9EA6C5] id: 868003032012465, time: 2023-03-26 08:13:51, lat: 17.98127, lon: -102.22353, speed: 4.3, course: 129.0
after this, neither the imei nor the ip of the device appears,
and then, after 2 minutes, the ip appears
2023-03-26 08:15:53 INFO: [506AD629] connected
2023-03-26 08:15:53 DEBUG: [506AD629: 5023 < 200.68.138.5] HEX: 78780d0108680030320124650195b1020d0a
2023-03-26 08:15:53 DEBUG: [506AD629: 5023 > 200.68.138.5] HEX: 78780501019512a90d0a
and then continues to report normally
2023-03-26 08:16:02 DEBUG: [506AD629: 5023 < 200.68.138.5] HEX: 7878211217031a0e1001c701edc5300af7a216109ccc014e000f8c0054ca80000196644e0d0a
2023-03-26 08:16:02 DEBUG: [506AD629: 5023 > 200.68.138.5] HEX: 7878051201964ac30d0a
2023-03-26 08:16:02 INFO: [506AD629] id: 868003032012465, time: 2023-03-26 08:16:01, lat: 17.97763, lon: -102.22280, speed: 8.6, course: 204.0
This device is suposed to have an internal memory to store positions in case it lost the connection. Is there some filter that could be discarding those positions because the date doesnt match with the server?
I will backport the newest version of the protocol to see if it helps. Should I update both the encoder and decoder, or is updating just the decoder sufficient?
Sounds like your device just doesn't send any data.
Due to our needs, we have been using two different older versions of Traccar that were modified to meet a specific requirement: versions 3.16 and 4.5. Each version is on its own host. These versions work well for our needs, but in the last month, the server that uses the 3.16 Traccar version has started to present some problems with a specific protocol (GT06), resulting in some missing positions. On the map, it appears as if the device suddenly teleported. We also realized that these skips follow a 3-minute pattern. To check if the problem was with the tracking device, we changed it to other hosts that use the 4.5 version, and it worked perfectly on those.
The base code for the server was not touched, and some tables were added, but these are used with an external service. This service also consumes the Traccar API.
Obviously, since the version we use is an old one that has also been modified, I am not looking for a specific solution but some ideas to check. What could be causing those missing positions? Could it be a database problem? Perhaps the extra tables are causing some slowness when writing information in the positions table. Could it be the external service that makes use of the API? Or maybe a protocol-specific problem that was solved only in later versions of Traccar, and coincidentally, it started to give problems now.