Implementing new "TKQ2" response for "watch" protocol message.

Hi,

I have a device D79 using "watch" protocol. I catched the tcp data sent from the device, and immediately(300 milliseconds) after the "TKQ" message comes, there is another message from the device now of the new type "TKQ2". I simulated the communication with the original chinese server and the server replies analogically as in case of "TKQ" type: [3G*deviceId*0004*TKQ2].

Is it possible to implement another if clause in WatchProtocolDecoder.java right after "TKQ" clause?

else if (type.equals("TKQ2")) {
            sendResponse(channel, id, index, "TKQ2");
}

I am not aware of another code in source, which might be touched by this new message type.

I don't even know what "TKQ" message means, nor the TKQ2, but maybe the proper response message will make the device also communicate better (not that something is wrong now).

Thanks
Martin

Do you have documentation?

Actually I found out there is a copy of this document also on your server:

3G electric protocol

There is no "TKQ" or "TKQ2" message type in documentation, but in code you have implemented at least "TKQ".

There are many watch protocols out there. You have to find the right one for your device.

I think this is the one. It is 3G message. Why "TKQ" is missing in documetation, I don't know, chinese just don't care and don't update the documentation.

But there is "TKQ" implemented in traccar source code but I did not find any protocol documentation on internet mentioning it. What was the protocol used to implement this message type?

Check second document here:

https://www.traccar.org/protocols/

I checked the first three documents from the link you provided but I do not see watch protocol and no "TKQ" string anywhere in the documents. It is completely different.

Obviously by second document I meant you need to scroll down to the "watch" protocol and open the second link there.

There is "TKQ2" in documentation.

I translated and it has something to do with voice but god knows what exactly...

But still I can not see the reason to implement an answer to tkq and not to tkq2.

Terminal detects offline voice
The terminal requests the recording to be issued:

[CS*YYYYYYYYYY*LEN*TKQ]

The server replies:

[CS*YYYYYYYYYY*LEN*TKQ]

The terminal requests a friend to record and issue:

[CS*YYYYYYYYYY*LEN*TKQ2]

The server replies:

[CS*YYYYYYYYYY*LEN*TKQ2]

Great.

Perfect, so you are going to implement TKQ2.

Feel free to send a pull request.

I did in the morning