Jimi IoT JC400 on Traccar: the one that doesn't speak JT808

Within the family of Jimi IoT cameras we've been reviewing in this series, the JC400 is the oddball. It's not just another model with different specs: it's the only one that isn't decoded as JT808. If you're coming from the JC181 post expecting the same behavior here, brace yourself for the opposite on almost every front.

If you don't know how camera support works under the hood in Traccar, start with that article; here I'll go straight to the model.

What the JC400 is

It's a 4G video unit aimed at taxi fleets, vehicle rental, logistics, and hazardous-materials transport (ADR), according to the manufacturer itself. There are also two catalog variants, JC400P and JC400D, listed as separate SKUs.

So far, conventional 4G dashcam specs. Things get interesting once you look at how the server treats it.

Why it matters that it speaks GT06, not JT808

Its siblings in the lineup — JC181, JC371, JC182, JC450, JC451 — are decoded in Traccar under the JT/T808 protocol, with model-specific logic for each. The JC400 isn't on that list. In the source code of Traccar's GT06 decoder, Gt06ProtocolDecoder.java, there's an enum Variant with a JC400 value, and comments identifying several message codes as "Jimi IoT 4G." In other words: the JC400 comes in through the GT06/Concox protocol — the same protocol family used by a huge share of generic Chinese trackers — not through JT808.

This isn't a trivia detail. It completely changes which path media takes inside the server, and therefore what you can promise a customer.

What this enables: files saved on your own server

Unlike the JT808 decoder — which does not use Traccar's media storage system —, the GT06/Concox protocol does invoke it. When the device uploads a photo (or a video, depending on the flow), Traccar:

1. Saves the file to disk under media.path, in a subfolder named after the device's unique identifier.
2. Adds an image (or video) attribute to the position, containing the name of the saved file.
3. Serves that file at /api/media/{uniqueId}/{filename}, behind a filter that requires a valid session and the user's permission on that specific device.

The GT06 decoder also has its own photo-request mechanism, which in some cases fires automatically upon receiving certain messages from the device.

Traccar adds an additional path on top of this: JimiPhotoProtocolDecoder.java, a dedicated HTTP decoder added in June 2026, which receives photo and video uploads via multipart POST and distinguishes between image and video based on the MIME type of the upload. This is the path for event clip/photo uploads — distinct from the JT1078 live-streaming path used by the JT808 family. It listens on port 5267 by default, a separate port from gt06 (5023): if you don't open it, the uploads simply never arrive.

To sum up: within the Jimi series covered so far, the JC400 is the natural candidate for anyone who wants photos (and potentially clips) saved on their own server, exactly the opposite of what the JC181 offers out of the box.

What's NOT confirmed: live video

Traccar's live-streaming pipeline (JT1078) is tied to the JT808 protocol. The JC400 goes through GT06, so don't assume there's live video with this camera.

There's a claim going around that these models do live video over RTMP to an external server. That may well be true on the device side — it's a firmware matter — but it's worth stating plainly: there is not a single RTMP reference in Traccar's source code. Traccar neither ingests nor publishes RTMP. If a vendor sells you "live video from the JC400 with Traccar", what they're selling is Traccar for the position and a separate platform for the video. Two systems, two costs, two points of failure.

I haven't found it documented either in the code or in manufacturer material — which, incidentally, never mentions GT06 or JT808 by name in its marketing material; the actual protocol only shows up when you look at the decoder itself. If you need live video for this camera, that's something you have to verify on your own installation, not something you can take for granted before buying.

How to verify it on your installation

Don't blindly trust a spec sheet or this article: check it on your own server.

1. Confirm that media.path is configured. That's the key that activates the media servlet (there's no such thing as media.enable — that's a common mistake on the forum).

grep media.path /opt/traccar/conf/traccar.xml

2. Also check media.bufferSize. It defaults to 32 MB; transfers larger than that are silently dropped without a clear warning. If you're expecting video, you'll likely need to raise it.

3. Register the device and wait for it to upload something (an event photo, for example). Then check whether the file showed up:

ls -la /opt/traccar/media/YOUR_IMEI/

4. If you see files there, confirm that the image or video attribute appears on the corresponding position from the Traccar UI or API.

5. If you're after live video, don't assume anything: check the server logs during a real test and confirm whether any streaming mechanism is active for this device, because it isn't guaranteed by the protocol it uses.

Is this the right camera?

Yes, if your priority is having photos (and potentially event clips) stored centrally on your own Traccar server, without depending on the manufacturer's platform or the vehicle's microSD card, and your use case fits taxi, rental, or logistics.

No, if your hard requirement is verified live video right now: that's not confirmed for this model, and the underlying tech path (GT06, not JT1078) doesn't guarantee it automatically. You'd need to verify it yourself before committing to an entire fleet.

If you're after the exact opposite — confirmed live video but no server-side file storage — the JC181 is still the reference within this series. And if you need to fully understand the media system before deciding, check out how to configure media.path to save and serve photos and how to request a remote photo with requestPhoto. For the full picture of what's compatible, see our guide to Traccar-compatible cameras.