Hello everyone,
I'm trying to get a SeeWorld P5 pet tracker (rechargeable model, JT808-based firmware) working properly in Traccar, and before I spend more time on it I'd like to check with people who know the huabao decoder better than I do.
What I have:
The vendor gave me two documents: the generic "GPS Tracker Communication Protocol" (JT/T 808 style: 0x0100 registration, 0x0102 auth, 0x0002 heartbeat, 0x0200 position, 0x8001/0x0001 general responses, 0x8300 text, 0x8900 pass-through, 0x8105 terminal control) and a P5-specific annex listing the additional information items the device actually sends. They are here:
https://drive.google.com/file/d/1nEhE2bigd_PGJr2gtJ3sL9udktYDocXR/view?usp=sharing
https://docs.google.com/spreadsheets/d/187jF95Uz7yORdpg3pLqBIwMhczqLt1qj/edit?usp=sharing&ouid=102030115120108594980&rtpof=true&sd=true
What I tried so far:
I first pointed the device at Traccar on port 5015 (huabao). Positions were decoded and the device did appear on the map, so the port looks right, but two things bothered me:
Timestamps were off. The 0x0200 BCD time is documented as GMT+8, and I couldn't get local time to come out right just by changing the timezone in the UI. Is decoder.timezone (as a device or server attribute) the correct way to handle this for huabao, or is the offset expected to be handled elsewhere?
Data consumption and battery life were clearly worse than with the vendor platform. From the logs it looked like the device was reconnecting very often instead of keeping/closing the session cleanly around each report (the P5 only holds the TCP session open for a short window around each report, roughly every 5 minutes). Is there a known case where the huabao decoder doesn't acknowledge a message the P5 sends (heartbeat with the 0x0FA0 parameter block, 0x0900 pass-through upstream, 0x0704 batch upload), so the device retries and re-registers? Anything I should check in the logs to confirm that?
Out of curiosity I then tested the same device on flespi, where it works fine, including sending custom text commands via the 0x8900 pass-through (type 0xFF), e.g. Ledswitch,1 → SET OK!. So the device itself is well behaved; my question is really about the right Traccar configuration.
The data I need:
This is the main point for me — I need the extra attributes, not just lat/lon. According to the P5 annex, the additional information items in 0x0200 are:
0x30 (1 byte) GSM signal strength
0x31 / 0x32 / 0x33 (1 byte each) satellites: total / GPS / BeiDou
0xCD (2 bytes) altitude in metres
0xE1 (1 byte) battery percentage (0x64 = 100%)
0xCC (20 bytes) ICCID
0x9F (N) up to 3 cell towers, ASCII "MCC,MNC,LAC,CELLID,RSSI,..."
0x54 (1 + n*7 + 1) up to 3 WiFi APs with MAC + a "home" flag (0 = away, 1/2/3 = saved home network)
Alarm bits used: bit 0 SOS, bit 15 low battery, bit 16 vibration.
The heartbeat also carries a 0x0FA0 parameter block with sound switch, light switch, battery %, charging status, motion state and daily activity minutes — which is exactly the kind of thing I'd like to see as attributes.
Questions:
Is huabao on port 5015 the right protocol for this device, or is there a better-matching protocol in Traccar for SeeWorld/SWD firmware?
Which of the additional IDs above does the current huabao decoder already handle (battery, satellites, RSSI, cell/WiFi), and which are simply ignored?
Is the 0x0FA0 heartbeat payload parsed at all, or is a heartbeat only used to keep the session alive?
Can I send the vendor text commands from Traccar — i.e. is there a way to issue a custom command that produces a 0x8900 pass-through with type 0xFF (and read the 0x0900 reply), and does the huabao command set expose 0x8105 command words 0x21/0x22 (light/sound on-off) and 0x23/0x24 (light/sound duration)?
If some of this isn't implemented, is a protocol document plus sample HEX enough for it to be considered, and is there anything specific I should provide?
Happy to post raw HEX frames and full server logs for any of the above.
Thanks a lot for any pointers.
Hello everyone,
I'm trying to get a SeeWorld P5 pet tracker (rechargeable model, JT808-based firmware) working properly in Traccar, and before I spend more time on it I'd like to check with people who know the huabao decoder better than I do.
What I have:
The vendor gave me two documents: the generic "GPS Tracker Communication Protocol" (JT/T 808 style: 0x0100 registration, 0x0102 auth, 0x0002 heartbeat, 0x0200 position, 0x8001/0x0001 general responses, 0x8300 text, 0x8900 pass-through, 0x8105 terminal control) and a P5-specific annex listing the additional information items the device actually sends. They are here:
https://drive.google.com/file/d/1nEhE2bigd_PGJr2gtJ3sL9udktYDocXR/view?usp=sharing
https://docs.google.com/spreadsheets/d/187jF95Uz7yORdpg3pLqBIwMhczqLt1qj/edit?usp=sharing&ouid=102030115120108594980&rtpof=true&sd=true
What I tried so far:
I first pointed the device at Traccar on port 5015 (huabao). Positions were decoded and the device did appear on the map, so the port looks right, but two things bothered me:
Timestamps were off. The 0x0200 BCD time is documented as GMT+8, and I couldn't get local time to come out right just by changing the timezone in the UI. Is decoder.timezone (as a device or server attribute) the correct way to handle this for huabao, or is the offset expected to be handled elsewhere?
Data consumption and battery life were clearly worse than with the vendor platform. From the logs it looked like the device was reconnecting very often instead of keeping/closing the session cleanly around each report (the P5 only holds the TCP session open for a short window around each report, roughly every 5 minutes). Is there a known case where the huabao decoder doesn't acknowledge a message the P5 sends (heartbeat with the 0x0FA0 parameter block, 0x0900 pass-through upstream, 0x0704 batch upload), so the device retries and re-registers? Anything I should check in the logs to confirm that?
Out of curiosity I then tested the same device on flespi, where it works fine, including sending custom text commands via the 0x8900 pass-through (type 0xFF), e.g. Ledswitch,1 → SET OK!. So the device itself is well behaved; my question is really about the right Traccar configuration.
The data I need:
This is the main point for me — I need the extra attributes, not just lat/lon. According to the P5 annex, the additional information items in 0x0200 are:
0x30 (1 byte) GSM signal strength
0x31 / 0x32 / 0x33 (1 byte each) satellites: total / GPS / BeiDou
0xCD (2 bytes) altitude in metres
0xE1 (1 byte) battery percentage (0x64 = 100%)
0xCC (20 bytes) ICCID
0x9F (N) up to 3 cell towers, ASCII "MCC,MNC,LAC,CELLID,RSSI,..."
0x54 (1 + n*7 + 1) up to 3 WiFi APs with MAC + a "home" flag (0 = away, 1/2/3 = saved home network)
Alarm bits used: bit 0 SOS, bit 15 low battery, bit 16 vibration.
The heartbeat also carries a 0x0FA0 parameter block with sound switch, light switch, battery %, charging status, motion state and daily activity minutes — which is exactly the kind of thing I'd like to see as attributes.
Questions:
Is huabao on port 5015 the right protocol for this device, or is there a better-matching protocol in Traccar for SeeWorld/SWD firmware?
Which of the additional IDs above does the current huabao decoder already handle (battery, satellites, RSSI, cell/WiFi), and which are simply ignored?
Is the 0x0FA0 heartbeat payload parsed at all, or is a heartbeat only used to keep the session alive?
Can I send the vendor text commands from Traccar — i.e. is there a way to issue a custom command that produces a 0x8900 pass-through with type 0xFF (and read the 0x0900 reply), and does the huabao command set expose 0x8105 command words 0x21/0x22 (light/sound on-off) and 0x23/0x24 (light/sound duration)?
If some of this isn't implemented, is a protocol document plus sample HEX enough for it to be considered, and is there anything specific I should provide?
Happy to post raw HEX frames and full server logs for any of the above.
Thanks a lot for any pointers.