BysMax

JC371, JC182 and JC451 on Traccar: the other JT808 models from Jimi IoT

14 min

IMPORTANT

Configuring video for Traccar. The server tells the camera where to connect by reading web.url and the jt1078 / jimiphoto ports from your traccar.xml. If that's missing there's no live video and no alarm photos — and no error in the log either. set the XML up here.

Reading order for this series: 1. how camera support works2. configure the server3. which camera to buy

We already covered the JC181 in production and the JC450 for heavy fleets. That leaves three models from the same family still unnamed: JC371, JC182, and JC451. This post is not a field test of any of the three — it's what we can state with certainty by looking at Traccar's source code, plus a clear warning about what we can't. For the full picture of what's compatible across the lineup, see our guide to Traccar-compatible cameras.

If you don't know how camera support works in Traccar in general, start with the camera support guide. Here I'll go straight to the point.

The only thing verified: the protocol, not the hardware

Traccar's Jt808ProtocolDecoder.java decoder has an explicit set of Jimi models with dedicated logic, JC_MODELS, with exactly five names: JC371, JC181, JC182, JC450, and JC451. The three models in this article are in there, alongside the two we've already tested.

That's a source-code fact, not an assumption or a marketing promise. And it has a very concrete practical consequence: the behavior of these three models with Traccar is already determined, because they follow the exact same path as the JC181 that we did get running on a real server. This isn't a "generic" or "probably compatible" integration — the server recognizes them by name and treats them with the same code.

What is not determined is the hardware. We haven't had our hands on any of the three. Zero first-party testing of the JC371, JC182, or JC451.

What they inherit from the JT808 path

Since they share a decoder with the JC181, they inherit its documented behavior point by point:

  • Live video: yes, via Traccar's JT/T1078 pipeline (Jt1078Protocol, Jt1078FrameDecoder, Jt1078ProtocolDecoder), added in April 2026.
  • The videoStart command triggers the JT808 0x9101 message — it carries host, TCP port of the JT1078 service, video channel, data type, and stream type. videoStop triggers 0x9102.
  • Video files saved on the server: no, with unmodified Traccar. The JT808 decoder doesn't invoke Traccar's generic media system. This isn't an architectural limitation, it's a specific gap in the decoder — it's implementable with a scoped modification, and we've solved it on our own server. Out of the box, you don't have it.
  • Stream drops from the usual two causes: 3G/4G cell handover while the vehicle is moving, and resending videoStart every 2–5 seconds out of impatience, which forces the camera to cancel the session and renegotiate the TCP socket. Wait 10–15 seconds before retrying, and use the sub-stream in poor coverage. The full mechanism is covered in live video over JT1078 on Traccar.

To confirm a given camera obeyed the videoStart, the log check is the usual one:

grep -i "jt1078" /opt/traccar/logs/tracker-server.log

If jt1078 < shows up with the camera's IP right after the videoStart, the session was established. And if you see notifications: 0 on an event, that's not a device failure — Traccar processed the event, you just don't have a notification rule configured for that event type.

The contrast worth keeping straight: the JC400

To make the boundary of this family clear: the JC400, from the same manufacturer, is not in JC_MODELS. It takes a completely different path, the Gt06ProtocolDecoder (GT06/Concox protocol), not JT808. Similar name, different protocol, different behavior. If someone offers you the JC400 thinking it behaves the same as these three, it doesn't — it has its own article: JC400 on Traccar via the GT06 protocol.

What we don't know and won't make up

We don't have a verified spec sheet for the JC371, JC182, or JC451. There's no specs table in this post because we don't have one, and we're not going to fill it in with numbers from another model in the same family and assume they apply. Number of channels, resolution, storage capacity, power voltage, LTE bands, presence of ADAS or DMS: all of that varies within the same product line and has to be confirmed model by model.

Checklist for the distributor

Before buying any of these three models, ask for in writing:

  1. Exact LTE bands compatible with your region. It's the most expensive mistake and the dumbest one.
  2. Power voltage — 12V, 24V, or a wide DC range (light vehicle vs. heavy vehicle).
  3. Actual number of video channels and whether it supports additional remote cameras.
  4. Maximum microSD card capacity supported.
  5. Whether it includes ADAS and/or DMS, and whether those features depend on a separate license or subscription.
  6. Confirmation that the model comes in via JT808 — ask for it even though we already know it from the code, because the distributor may be selling a different regional variant under the same commercial name.

With that in hand, you already know the rest of the behavior on Traccar: same protocol, same live-video mechanism, same lack of out-of-the-box centralized recording as the JC181 and JC450.

NOTE

Verified against Traccar's source code (August 2026): that JC371, JC182, and JC451 belong to the JT808 decoder's JC_MODELS set, and that the JC400 is absent from that same set. Live-video behavior and the lack of server-side recording are inferred from sharing a decoder with the JC181, which we did test in production. Not verified: hardware specifications of the JC371, JC182, and JC451, and any first-party testing of how these three specific models actually perform.

Comentarios (0)