Test new completely rewritten Traccar Client app
I suspect that the interval is not a guaranteed thing. Maybe there's no GPS signal?
GPS signal is not a problem, even indoors works just fine.
Traccar is being used professionally here, with a mix of Android and iOS devices.
With the older version, everything worked flawless: iOS devices with 300 seconds interval was on the dot, Android devices were a little off by a few seconds. Nothing to worry about and was fantastic. Battery life was ok on high accuracy.
With the new major update, interval setting is gone on iOS. Not even after setting Distance to 0.
Also, Distance triggering does not work. No new updates are received, even when multiple times exceeding the distance setting.
I also get reports from colleagues that battery is drained quickly.
And there is a constant blue bar in the notification bar at the top.
With the new major update on Android, interval setting is used, but does not work.
As I said earlier, no matter if the app is in background, foreground, screen on or off.
Wouldn't it be possible to revert back to the old style app (maybe as a new version number so the app stores are not complaining) and develop and debug the new app further?
I would be willing to test this with you as I have a few models Android and iOS laying around.
Would it be possible to publish the previous stable version as a legacy app to Android and iOS stores?
Without a plan to support old apps, there's no plan to publish them as a separate instance.
If something is not working correctly on the new version, I'm happy to work through it. But the old interval setting is not coming back. What is your use case where distance-based tracking does not work?
In my example, I set a distance of 30 meters. However, if I last transmitted 10 meters in front of the house and then put the phone away, I never actually arrive at home. Afterwards, the status changes to offline. Both the client and server versions are up to date.
Exactly what Tim says, but also I want to be able to know if trackers are still alive by having some sort of heartbeat.
For all I know, someone could have turned off the tracker at a valid point, do some grocery shopping, visit their mom and return back to the place where it went offline and turn the tracker back on.
The hearbeat should include the tracker's location.
If we see a tracker is offline for no given reason, the owner of the tracker will be called to turn it back on.
Planning to add an update with a heartbeat. Note that it will include the last known location, but should indicate that the app is still active.
Ok nice.
Please don't take this as criticism, but why not include new location in heartbeat?
Is it a restraint in iOS/Android or is it to preserve energy/CPU load?
It is just how the SDK does it. Supporting new location will add more complexity and also should be unnecessary because if location changes, it will start reporting by distance.
Big update version 9.1.0 includes:
- New configuration parameters
- Heartbeat time interval - regular status updates when stationary
- Disable elasticity option - currently distance automatically adjusts higher depending on speed; this option disables that
- Disable stop detection - disables stationary state completely
- Prevent suspend option for iOS - allows more consistent heartbeats on iOS, but uses more battery
- Option to share full logs
Антон, так же тестирую новую версию, в целом логика понятна. Есть пожелания к улучшению, можете включить в передаваемые метрики Heartbeat значение батареи? Либо предусмотреть опцию включения/выключения передачи необязательных параметров, в которые войдут высота, батарея и т.п. Раньше по интервалу все прилетало, теперь же только в динамике/движении. Heartbeat помогает, но поддерживать статус онлайн не более, а отслеживание остальных показателей устройств отлетает.
What server port should we use with new client? I have client 9.0.3 (newer is not available for me in Play store) and server 6.7.2.
Using 5055 server sends 200 and shows device online (green) but not updating location or anything else. Payload in server log shows json object.
POST / HTTP/1.1\r\nContent-Type: application/json; charset=utf-8\r\nContent-Length: 395\r\nHost: traccar.foobar.fi:5055\r\nConnection: Keep-Alive\r\nAccept-Encoding: gzip\r\nUser-Agent: okhttp/3.14.9\r\n\r\n{"location":{"timestamp":"2025-06-12T15:34:20.001Z","coords":{"latitude":60.4563811,"longitude":22.1837844,"accuracy":3.85,"speed":0.18,"heading":348.98,"altitude":20.3},"is_moving":false,"odometer":0,"battery":{"level":0.57,"is_charging":false},"activity":{"type":"still"},"extras":{},"_":"&id=65115824&lat=60.4563811&lon=22.1837844×tamp=2025-06-12T15:34:20.001Z&"},"device_id":"65115824"}
If trying to use 5175, I got error on client and checking on server, it is not listening on 5175 (netstat -tl | grep "5175").
If you're using the latest Traccar, port 5055 is the correct one.
Ok, any idea of howto debug this further. It seems that devices that still have old client software are working fine and updated ones (9.0.3) are showing 200 on client end but location is not updated in the server.
Does the location match with what you see in json?
If you want to discuss it further, let's move to the separate thread because the issue is clearly on the server side.