It doesn't look like you're using an official version of Traccar.
Hi.
I already translated the HEX messages .
I use the official traccar docker:)
Not to worry
Since I have upgraded Traccar from v4.8 to v5.3 I have exactly the same experience. At first glance I thought my device was defective, but as I now see you raising the same issue this can't be a coincidence. It looks like the alarm events from the TK905 device are not being processed properly. Since upgrading to v5 the event logging does not show the alarm events anymore. The only events that appear are deviceOnline, deviceOffline, deviceStopped, deviceMoving. Sidenote; only when battery is low (<20%) the software logs an alarm event reported as "alarm":"lowBattery". The alarm event for shock alarm, shown as "alarm":"sos" is completely gone. Does anyone know what is causing this new behaviour?
Usually we never remove any protocol functionality. The only exception if there's a conflict. For example two different devices use same field for different things.
Would that be easy to find in the code ? As what commands sets deviceOnline and what does Traccar do with the initial:
2022-12-15 20:29:55 INFO: [8774924e: watch < XXX.XX.XXX.XXX]
[SG*XXXXXXXXXX*0067*AL,151222,202944,V,XXXX,N,XXXX,E,0.0,060,9,00,70,90,0,50,00000000,1,1,204,4,20304,25909761,19,,10]
2022-12-15 20:29:55 INFO: [8774924e: watch > XXX.XX.XXX.XXX]
[SG*XXXXXXXXXX*0002*AL]
You can always check the commit history for the decoder file to see what changed between versions.
I noticed in:
That alarm '3' was removed without mentioning a reason of why.
} else if (BitUtil.check(status, 3)) {
return Position.ALARM_OVERSPEED;
It is an official alarm according to the documentation of the protocol.
And
Merge Request Fix alarm response
if (type.equals("AL")) {
vs
if (type.startsWith("AL")) {
in Merge Request Fix alarm decoding
the removal of
if (position != null) {
position.set(Position.KEY_ALARM, Position.ALARM_SOS);
}
Maybe this helps to clarify what changed Anton and may cause the issue ??
As I said, the only reason for removal is a conflict. One device use it for one type of alarm and another for something completely different.
Hi.
I've been going through my archive and noticed:
Report
Type=Alarm
Attributes=alarm=sos
I'm looking at that last merge request. ;-) but I am not a developer.
Can we have the settings back or maybe in some sort of configurable way? For TK-905 series there seems no documented conflict. Neither can I find a documented one on the forum.
If it was removed, it was done for a reason. One option is to make it configurable. Feel free to send a pull request if you want to implement that.
I can do a PR to revert the changes if necessary as I have no clue where to PR the 'make it configurable' part.
Unfortunately I am not a developer I just tried extensively hard by going through the changes to figure out where something was changed for a possible undocumented reason. ;-) as in the beginning we started with the quote:
"Usually we never remove any protocol functionality. The only exception if there's a conflict. For example two different devices use same field for different things."
The conflict seems undocumented in the change, so I can not determine what the conflict was or maybe there even wasn't a conflict and the changes were done by accident in this protocol. I really did my best to point out a change that was made.
If you cannot implement it, I would recommend to at least create a ticket on GitHub so we don't forget about it.
Tnx for the tip. :) let me do that indeed.
Issue was fixed in 5.6 many thanks.
I've been using Traccar for quite some time now with a TK-905 2G Traccar.
It used to raise an alarm when a shock was detected. ( If I add add admin mobile number to the device it will send me a text message "Sensor Alarm!") I removed the admin mobile number as I forward these events with Traccar.
Some time ago this 'shock alarm' stopped working, GPS , device moving e.g. worked just fine with traccar.
I tried to live with it.
Black Friday I saw an offer I could not refuse the TK-905 4G, so I thought well let's revive the shock alarm for this price.
Unfortunately the same issue... Did not work.
I spoke to a friend who also is experiencing the same.
At the moment I use traccar 5:5 and started to look at the logs. I took the GPS inside and gave it a twist.
According to the watch protocol this is the correct sequence.
I notice however "00000000", which I guess means nothing while still interpreting the manual of the protocol.
In my head this is the thing that issues the SMS message when an admin number has been assigned to the GPS device, hence should be an alarm.
After the initial session of AL I notice the UD2 message. Should also be quite common.
Could it be something changed in traccar source code while interpreting the protocol, or that we can configure the AL with 00000000 to actually raise something?
Looking forward to your insights.