I've fixed automatic approval of new devices.
You can come a long way with just configuring the xml file. I'm just not sure yet how to configure plain hex storage instead of changing it to int.
There is no configuration parameter to store original HEX values, but it should be fairly easy to convert back from decimal to hex.
Thanks for your fast response!
Yeah I did try the reverse dec->hex, but some values seemed a bit random, but it could also be with the way the car encodes some values.
Anyhow. All traccar does is convert the hex (8 bytes) to dec? so if I do a reverse (dec->hex) encode, i should end up with the exact same data that was sent in the ID?
Some decimal values were 64 bits long, but some were shorter, that's what got me confused as well. It probably discarded the leading zeroes?
It treats it as a number, so yes, leading zeroes are not printed.
How would it treat
1111.1111 1111.1111 1111.1111 1111.1111 1111.1111 1111.1111 1111.1111 1111.1111 (When all bits are HIGH)?
I believe it would return negative number:
https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
Hi,
First of all, thanks for creating such an extensive piece of software. For a current project I'm logging canbus data from a vehicle. I'm using the Teltonika FMB640 which sends 10 CAN strings in hex format (8 bytes, so 0x00.00.00.00.00.00.00.00) in id (145-154)
I see these values in my traccar portal, in ID:145-154, but it looks like they are converted. (to int?)
Anyhow, when I decode these values, they don't seem to represent the original values.
Our end goal is to only store these values in our own database. The GPS positions are not neccessary.
Some tips on disabling position storing in database are (as it seems) for older versions of traccar?
Is there any way to change teltonikaframedecoder to leave these values as hex? or possibly via the config.xml file?
Also, in another topic you mentioned automatic approval of new devices. How do I configure this?