Teltonika wrong KEY_DRIVER_UNIQUE_ID and FMCXXX support
Please provide some examples as a proof. Specifically I'm expecting a HEX sample and a corresponding key photo.
This is an example of a HEX message
00000000000000588e010000018f3505ddc001d2f45b6b03bd9e2105d10009130000004e000a000300ef0000f000000200000400b60005004262970018000000430fa5000200c7000000000010083ecb5f0001004e01dabbd81800007b00000100003922The desired value for driverUniqueId is 01DABBD81800007B
the actual obtained value fo driverUniqueId is 7B000018D8BBDA01
Can you please provide a photo of the tag id.
I think maybe the problem is different and maybe is related to Atrack parser
I am using 2 diferents gps model for same fleet. Atrack and teltonika this is the HEX message for atrack
40503472004f5c660003144df9a872e9663506196635061966350619fb7ecea7005fc123010002000c6bad00060100000100003536383638323031303030300007d007d000254349254d5625415400007c000005dcthis is the driver id that it decodes
568682010000
this is the HEX for teltonika
00000000000000588e010000018f3ef86fa000d2f4155d03bd90ea05da00461000000000000a000300ef0100f001000200000400b6000600426dda0018000000430fcb000200c70009ed83001013eb37f20001004e015686820100008300000100004b5dthis is the decoded id
8300000182865601
Fisical device that reads the tag
As you see the tag number marked in the ibutton is the same decoded by teltonika, but the one decoded by atrack is the one that i obtain with getLong in teltonika, and the one that i obtain in the fisical device that we use to obtain the ids.
Other think that you should note is that in teltonika the number must be positive in the code but in this case the getLongLE function gives a negative number -9007199248256182783, if you remove the condition you will get the value that is shown in the ibutton.
In this case one of the protocols is giving the wrong value, maybe atrack or teltonika, the test i made was using the same dallas key, and if the teltonika protocol is the correct you should remove the condition for positives values
From what I can see, the Teltonika is correct. Why did you claim it was wrong originally?
Ok, but you must remove the if condition to check if the calculates long is positive, because if you check the hex I sent you the value is negative.
And in this case we should check the atrackframedecoder. Is this ticket enough?
Hi guys, I saw that after your discussion the lineregister(90, null, (p, b) -> p.set(Position.KEY_DOOR, b.readUnsignedShort()));
has been replaced withregister(662, fmbXXX, (p, b) -> p.set(Position.KEY_DOOR, b.readUnsignedByte() > 0));
I have enabled the "SSF Car Is Closed" parameter from the Teltonika configurator since it is correctly installed on the vehicle but this is not present in the tracking position.
Can you tell me if I did something wrong in the Teltonika configurator?
Do you see the IO in the position?
See if the io 90 is present in the attributes of the position, if it is present you should create an computed attribute.
I had to select this codec to have the parameters returned by the can adapter! (codec 8 extended)
In the file TeltonikaProtocolDecoder.java in line 231 the driver unique id is read with
long driverUniqueId = b.readLongLE();the value must be readed in the correct order because the value of the dallas i button is not correct. this line of code should become.
long driverUniqueId = b.readLong();The other improvement you should do is that only FMB devices are registering the variables, you should include all FMCXXX devices because those devices are the same FMBXXX but with 4g module and teltonika renamed to FMCXXX