Trips incorrectly defined/calculated (6.11.1)
Why would you create a new topic for a follow-up?
Because I found out that after some time old issues enter some sort of ignored state and no more info. or answers are given.
Also, because this is not the same exact issue and not the same version described in old title.
Something changed between versions and now the server is calculating trips better, altough some errors persist.
Walter, I can only say this is not a Traccar issue. My business has done a lot of work for our customers on accurate trip calculation, and it's always been data from the GPS tracker that has required tweaking.
Step 1: What GPS trackers are you using?
Hello Kaldek, let me explain.
I've been using the same trackers since version 4, no changes in config, no changes in the server (other than traccar updates)
I also have a 2nd server for testing and all the same behavioral changes can be replicated under test server. (main x86-64 / test arm64)
I use A LOT o diferent brands and models, most of them using h02, gt06 and huabao protocols, there's also some watches and some cellphones with the proper app. Even some devices are made by me.
The thing is:
It was ALL working fine under Traccar version 4.xx.
Under version 5 notifications went to the drain, and I lost certain notifications, not all, which is quite odd. No matter what I config, those notifications never appeared again. (alarms)
Once upgraded to v6 trips got messed and in the last update I can see them again, just some are wrong.
And still, no changes have been made on devices, server or configs. other than traccar updates.
Trackers send data each "xx" seconds or when direction changes angle "xx" degrees.
There's trackers that have ACC no/off report and some that don't have it, so trips get defined by movement on some and by ACC on others.
I have received some complaints from some customers about trip definitions. They are not trustable since this last version, it was heavily used in past versions to control their travels. (work trucks)
My motorcyles have both the same tracker and are the same they always had.
I have made some long road travels in the past and my refuels defined a trip. Not since v6, and still didn't travelled since last version so I can't tell now.
One friend traveled through ALL of Brazil and another through ALL of Argentina, both using same the trackers as my bikes have. Only one of my friends have ACC (on/off) report enabled, so the other's trips got defined only by motion.
And both their travels were perfectly drawn in the travel history and both with the correct trip definitions at the time (had them captured to post on socials) but all "lost" when the issue started. (Have to search now what happens)
So, since there was no change in devices or configs, or in the server (twice as much memory and cpu as ever needed at top work) I can't understand why could the trackers be the cause of it, specially since that behavior changed again on last version and altough not perfect, still way way better than it was a couple months ago.
Is not double the cpu and ram, I got confused by the on screen graphs disposition. More like 3 to 4 times what has been ever needed.
Walter I recommend starting with this Computed Attribute, which we call the "Motion Nullifier" for devices where we only want Motion to be calculated by Traccar. We add this boolean Computed Attribute to devices where we need to ensure that the device's own decision about motion is ignored.
motion ? null : null
Fundamentally, a trip will not stop if Motion stays True. If you can't tune this on the tracker itself, then it needs to be done in Traccar so that it gets to decide rather than the tracker.
Because we only use Teltonika trackers, it has been easier for us to find the settings that work well. On the devices themselves, we make sure that we avoid GPS drift by using the Teltonika Static Navigation settings.
Depending on the issues encountered, we also consider using the following settings, either globally or per-device where supported as an attribute:
- event.motion.speedThreshold
- report.trip.minimalTripDistance
- report.trip.minimalTripDuration
- report.trip.minimalParkingDuration
- report.trip.minimalNoDataDuration
- report.trip.useIgnition (we use this one the most)
For reverse engineering an issue with trip reporting, we will use the raw Position data, for example by using the Replay function, to look at the positions which Traccar is seeing, and determine why - based on the Motion, Trips and Stops documentation - Traccar determined there was no trip end or start. Every time we have done this, it's become clear why something was not tracked as a trip.
Will check on all your data, thank you.
Well hello again.
This is a follow up from: https://www.traccar.org/forums/topic/trip-reports-not-working-properly-610/
Trips were not calculated at all, no matter the config on traccar.xml or absence of it, only gps drift was shown as trips.
Positions were correct and logic from positions report showed that it should calculate trips correctly, but didn't.
Finally trips are being calculated, mostly fine, but... There's still inconsistencies. (See 1st image below)
Did'nt even tried 6.11.0 so I don't know which version had this fixes done.
At the time of trip start, the bike was under a tarp inside the garage and it stood there until next day 1/2 hour before trip stop time.
That displayed time is the time of a shake report sent by the device to the server, and was used as trip start altough there were several hours between that report and the next one, so one of the conditions for trip defining was not respected by traccar itself when calculating the trip. (see 2nd attached image)
Adding report.trip.useIgnition changes nothing. (bike reports ignition and it's state is correctly shown on screen/device details)
So... ¿what now?
For not defining them at all or for defining them too much, still is wrong, this seems very odd and I don't know what else to try.
https://imgur.com/WBA3k81
https://imgur.com/YxfyAvx
https://i.imgur.com/WBA3k81.jpeg
https://i.imgur.com/YxfyAvx.png