Huabao protocol device unique ID limited to 12 digits?

Hi everyone,

I’m using a Huabao protocol GPS device with a 15-digit IMEI configured on the tracker.

However, when the data reaches Traccar server, the decoded device unique ID only contains 12 digits, and the first 3 digits are missing.

Example:
Configured IMEI: 123456789012345
Received in Traccar: 456789012345

I would like to ask:

• Does the Huabao protocol officially support only 12-digit device IDs?
• Is this limitation from the device firmware or from Traccar decoder handling?
• Has anyone successfully used full 15-digit IMEI with Huabao protocol devices?

Thank you.

Hello! I had exactly the same problem today with an AT603 and here's what I learned:

The problem is the JT808/2013 protocol.
The protocol only supports 12 digits in the identifier field — it's a limitation of the standard, not of Traccar or the firmware.

Solution 1 — 2013 Protocol (12 digits)
The device does not send the IMEI — it sends the internal Device Number with leading zeros until it reaches 12 digits.

In my experience with the AT603:
Full IMEI: 866846066059234 (15 digits)
Device Number: 46066059234 (11 digits)
Traccar ID: 046066059234 (leading zero = 12 digits)
Rule: Go to 192.168.1.1/set → check the Device Number → add leading zeros until you have 12 digits → use this value in Traccar.

Solution 2 — Protocol 2019 (15 digits)
Change the device to JT808/2019 — supports full 15-digit IMEI without truncation. In Traccar, use the full IMEI as the identifier.

After that, the device came online.

I hope this helped.

Thank you very much for the detailed explanation. This helped me understand the issue much better.

I would like to ask one more thing regarding Solution 2.

You mentioned that JT808/2013 only supports 12-digit identifiers, but JT808/2019 supports the full 15-digit IMEI.

Does this mean the 12-digit limitation is only for the 2013 version of the protocol, while the 2019 version changed the identifier field format to support full IMEI length?

Or is the device using a completely different identifier mechanism in JT808/2019?

Thanks again for sharing your experience.

Yes, your understanding is correct: The 12-digit limitation is specific to the 2013 version, and the 2019 version changed the identifier field format.
JT808/2013 - 6-byte BCD field

The 2013 standard defines the terminal identifier field as 6 bytes in BCD (Binary Coded Decimal) format. Since each BCD byte represents 2 decimal digits, 6 bytes allow a maximum of 12 digits. Therefore, devices with 2013 use the last 12 digits of the IMEI or a 12-digit internal serial number.
JT808/2019 - Expanded field

The 2019 revision expanded the identifier field to support the full 15-digit IMEI. It's not a completely different mechanism, it's the same concept but with a larger field size in the packet header, which allows sending the full IMEI without truncation.

In practice with the AT603, In my experience with the AT603, even using the 2013 protocol, the device does not send the last 12 digits of the IMEI as the manual suggests, it sends the internal Device Number configured on the platform, padded with leading zeros until it reaches 12 digits. This means that the identifier in Traccar must correspond to the Device Number and not the IMEI, regardless of the protocol version.

Summary

Version: 2013
Field: BCD 6 bytes
Digits: 12
Identifier: Device Number (leading zeros)

Version: 2019
Field: Expanded field
Digits:15
Identifier:Full IMEI

Thank you for the detailed explanation.

So, just to confirm — the cause of the 12-digit identifier is not the Huabao/JT808 protocol itself, but how the device firmware implements the JT808/2013 standard, correct?

In the case of the BSJ KG12, even though I configured the full IMEI:

863012234566179

the device still only sends a 12-digit identifier:

012234566179

So it seems the device is either:

• truncating the IMEI to fit the JT808/2013 12-digit field, or
• sending an internal Device Number instead of the actual IMEI.

Is my understanding correct?

Yes, your understanding is correct.
The 12-digit limitation comes from both factors together, the JT808/2013 protocol defines the identifier field as 6 bytes BCD (maximum 12 digits), and the device firmware decides how to fill those 12 bytes.
Looking at your BSJ KG12 example, the device is simply truncating the first 3 digits of the IMEI to fit the 12-digit field. This is different from the AT603 I worked with, which uses an internal Device Number instead of the IMEI.
The key takeaway is that each manufacturer implements this differently, some truncate the IMEI, others use an internal serial number. So the safest approach is always to check the actual identifier in the Traccar logs rather than assuming what the device sends.
For your BSJ KG12, the Traccar identifier should be the last 12 digits of the IMEI: 012234566179

To identify the exact identifier your device is sending to Traccar, run this command on your server:

tail -f /opt/traccar/logs/tracker-server.log | grep -E "Unknown device|your_device_ip"

Restart your device and look for a line like this:

WARN: Unknown device - XXXXXXXXXXXX (your_device_ip)

The XXXXXXXXXXXX is the exact identifier you need to register in Traccar.

If you don't know your device IP, use this instead to capture all JT808 traffic:

tail -f /opt/traccar/logs/tracker-server.log | grep "jt808"

Look for lines like:

INFO: [Txxxxxxxx: jt808 < device_ip] 7e0100...
WARN: Unknown device - XXXXXXXXXXXX (device_ip)

The identifier shown in the Unknown device warning is the correct one to use in Traccar — no guessing needed.

Thank you for the answer again

Yes, I did check in Traccar server log it decode correctly with the last 12 digit that I config to devices

Great to hear it's working!
That confirms the BSJ KG12 truncates the first 3 digits of the IMEI to fit the JT808/2013 12-digit field, exactly as expected.
For future devices, always check the Traccar logs first to confirm the actual identifier being sent. It saves a lot of troubleshooting time.
Good luck with your project!

Thank you very much for your help.

You're welcome.