Do you think that, since the current activity can be reliably fetched when continuous tracking is enabled, the same mechanism could also be used as a fallback when the device appears to remain stationary for a certain period?
For example, Traccar could keep track of the last location that actually triggered a location update, along with the coordinates and timestamp of that update. If subsequent location readings remain within a certain distance of those saved coordinates — say 20 meters — for a certain period, such as 5 minutes, Traccar could then fetch the device's current activity using the same mechanism it uses when continuous tracking is enabled.
If the recognized activity is still, Traccar could then switch to stationary mode and stop continuous GPS tracking. If the activity indicates movement, it could continue tracking normally.
So, roughly:
Save the coordinates and timestamp of the last location that triggered a location update.
Continue obtaining location readings normally.
If the current coordinates remain within, for example, 20 meters of the saved coordinates for 5 minutes, check the current Android activity.
If the activity is recognized as still, switch to stationary mode.
If the activity indicates movement, continue continuous tracking as normal.
This could potentially serve as a fallback for cases where the normal stop-detection logic fails to transition to stationary mode, while still avoiding unnecessary activity checks on every location update.
Since the affected devices are already showing still with high confidence when continuous tracking is manually toggled off and back on, it seems like periodically querying the activity under these circumstances might be a possible workaround while the underlying issue is being investigated.
What do you mean with location history ??
What is not clear about location history? It is locations during the time in question.
you mean logs without masking the coordinates??? if so, As much as I wish I can provide them *and I do have access to them) , but that will reveal precise location info which I think adds little value compared to masked coordinates and adding distance instead (the currently shared logs)
If you feel that will help you in one way or another I can create a script that adds a random constant value to the coordinates, which will still mask them but give you access to the updated value, but I don't think I will be able to getting around doing that today
What I want to know if it was a one-off location jump. That could explain why geofence was triggered, but not motion.
Can you please share the timestamp of the moment you are interested in and I can look ? You mean the location right before line
2026-09-23 18:53:47 Geofence exit
and the next location update after this line ?
Yes locations around that timestamp.
Do you think that, since the current activity can be reliably fetched when continuous tracking is enabled, the same mechanism could also be used as a fallback when the device appears to remain stationary for a certain period?
For example, Traccar could keep track of the last location that actually triggered a location update, along with the coordinates and timestamp of that update. If subsequent location readings remain within a certain distance of those saved coordinates — say 20 meters — for a certain period, such as 5 minutes, Traccar could then fetch the device's current activity using the same mechanism it uses when continuous tracking is enabled.
If the recognized activity is still, Traccar could then switch to stationary mode and stop continuous GPS tracking. If the activity indicates movement, it could continue tracking normally.
So, roughly:
Save the coordinates and timestamp of the last location that triggered a location update.
Continue obtaining location readings normally.
If the current coordinates remain within, for example, 20 meters of the saved coordinates for 5 minutes, check the current Android activity.
If the activity is recognized as still, switch to stationary mode.
If the activity indicates movement, continue continuous tracking as normal.
This could potentially serve as a fallback for cases where the normal stop-detection logic fails to transition to stationary mode, while still avoiding unnecessary activity checks on every location update.
Since the affected devices are already showing still with high confidence when continuous tracking is manually toggled off and back on, it seems like periodically querying the activity under these circumstances might be a possible workaround while the underlying issue is being investigated.