Dear Patrick,
Have you able to solve the problem?
Yes, I also confirm that any other device (may be unknown) messing up the position of other device. We have tested by stopping the original device to send data but the device were still updating on regular basis by any other device’s data. We were not able able to test much more because the issue didn’t happen after server restart.
If we use “decoder.ignoreSessionCache” then device stop updating in case of GT06 because they don’t send IMEI information in every message.
And Hi @Anton, Sorry to bother you, but Is there any solution to this problem?
The config parameter is the solution. Currently it's applied globally for all protocols.
Yes Anton I know about the config parameter, but for gt06 protocols devices doesn't update because of no IMEI information. Have you changed anything in last version regarding this problem? As I didn't see any commit regarding this, excluding a commit where you handled multiple devices data on a single connection https://github.com/traccar/traccar/commit/65a39217ea14ef266a042c284189ac13a43b20c5. Am I missing something? or we can't ever find any solution if any device doesn't send IMEI info in every message?
Thanks, and Sorry for late reply as I was investigating commits more carefully.
Changed topic to shorter and more clear name.
I don't think there were any changes recently to the way unknown devices are handled, at least not intentional ones.
Unknown device tracking is being added to other devices and "decoder.ignoreSessionCache" configuration parameter stopping positions being saved in the database.
We recently upgraded from 4.1 to 4.6 to troubleshoot this issue with unknown devices messing up other devices location information.
This is similar to https://www.traccar.org/forums/topic/2-devices-swapping/#post-36802 but the fix seems to break the system so that positions no longer are parsed and stored in the database.
Any thoughts on how to troubleshoot this problem. I believe that the configuration parameter "decoder.ignoreSessionCache" should fix the problem but unfortunately it is causing more problems by stopping the HEX message from being decoded and thus showing up in the database.
P.S. We were able to simulate the symptom by renaming a device in the database and it then would have the path from that device show up in another device. Upgrading from 4.1 to 4.6 stopped that from happening. Unfortunately it didn't stop the problem of an unknown devices positions from going onto another random device.
Thanks!