Is there a reason this is in the server forum and not devices?
Hi Anton,
No reason - I certianly meant to click the devices forum.... my apologies., I have a few tabs open.
Feel free to move it if you can? or I can copy/paste/delete a new entry.
Thank you.
I'm currently running the following patch - with a fixup for the above firmware bug.
I don't have another TK913 or another watch-protocol device that I can test alongside it however.
But the code is here in case it's useful for others, Cheers
--- a/src/main/java/org/traccar/protocol/WatchProtocolDecoder.java
+++ b/src/main/java/org/traccar/protocol/WatchProtocolDecoder.java
@@ -256,8 +256,23 @@ public class WatchProtocolDecoder extends BaseProtocolDecoder {
getLastLocation(position, null);
- position.set(Position.KEY_BATTERY_LEVEL, Integer.parseInt(values[2]));
- position.set(Position.KEY_STEPS, Integer.parseInt(values[0]));
+ int steps = Integer.parseInt(values[0]);
+ int rolling = Integer.parseInt(values[1]);
+ int battery = Integer.parseInt(values[2]);
+
+ position.set(Position.KEY_STEPS, steps);
+ /*
+ according to the docs the data order should be [steps, rolling, battery]
+ but some versions have a bug which mises this up. This aims to catch the error
+ */
+ if (steps == 0 && battery == 0 && rolling > 0) {
+ // fixup use rolling value as battery
+ position.set(Position.KEY_BATTERY_LEVEL, rolling);
+ } else {
+ // per protocol
+ position.set(Position.KEY_BATTERY_LEVEL, battery);
+
+ }
return position;
}
diff --git a/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java b/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java
index 5fd0ede44..42ee71b04 100644
--- a/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java
+++ b/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java
@@ -17,6 +17,13 @@ public class WatchProtocolDecoderTest extends ProtocolTest {
var decoder = inject(new WatchProtocolDecoder(null));
+ // test NON-standard battery index in LK message
+ verifyAttribute(decoder, buffer("[SG*9139008196*0009*LK,0,93,0]"), "batteryLevel", 93);
+
+ // test standard battery index in LK message
+ verifyAttribute(decoder, buffer("[SG*9139008196*0009*LK,0,50,25]"), "batteryLevel", 25);
+
Hi @Rob,
I also own a TK913 device and I have the same problem.
As I know nothing in Java, would you mind send me your tracker-server.jar ?
mine is (in docker): 3746306 Apr 11 20:32 /opt/traccar/tracker-server.jar
It would really be kind of you
Many thanks from France.
My device:
TK913(70SALASCD)_V_2.0 2024/03/11
ID:0123456
IP:my.own.traccar:5093
BAT:95%
APN:<myapn>,,
GPS:15
LTE:27
,,,
Hi,
Yes - email me
[redacted]
We don't allow personal contact details on the forum.
Sorry Anton.
how do I get in touch with Berbigou?, I'm happy to help them.
You can post anything you need on the forum.
@Berbigou, I'll post a docker image here. what arch do you need? amd64 or arm64?
Hi Rob, you're great ! I would need arm64 (for a Bananapi-M5 with armbian 6.6.16-current-meson64 aarch64 GNU/Linux) !
Hi Rob,
how are you ?
Can you help me with my tracker-server.jar, please ?
Many thanks
Hello
I understand the code more or less. But I can not find the path to change the the code. And if I would find the directory, I don't know how to build an own Docker image to fix the battery status for me actually.
Is there a plan to add these changes to the major release?
Best regards
Okay, now I am at the point to build my own docker file with my own zip. I changed the lines like Rob's example. But now I think there is a step to compile the code or somethong like that to build my own .zip file. Could anyone help me with that step?
Sorry for those noob questions. But I am trying to learn. and I think it could help others to read those hint here :)
Have you checked the official documentation?
Hi,
I have a new device TK913 (these were always 2G, but I have a 4G variant) - I don't know if it's a clone.
The badge is TKMARS and the encoded Manufacturer ID is "SG"
It's using the Watch protocol as expected.
But I have found a protocol oddity - probably a bug on the vendor side.
Here's a "UD" Message
Battery is at data index [12] according to the protocol document and has a value I agree with at 92%
Steps = 0 and rolling (whatever that is, maybe IMU) is 50.
But when the movement stop, after a few minutes I get an "LK" message every 5 minutes as expected
But here the battery (92%) is at data index [1] and not as the protocol document states (below) at data index [2]:
As such, when the device is not moving, the event report is with battery level = 0
I'm sure this kind kind of thing is common for these cheap devices.
Have you seen this before? any work arounds you can think of?
Here's my firmware details below from a "check..." SMS.
Cheers, Rob