JC261 and JC120 with Traccar: what to check before you buy
We've already covered Jimi IoT models that Traccar recognizes by name: the JC181, tested in production, and the JC400 via the GT06 protocol. This post is different: it's about two models that don't appear anywhere in Traccar's code, the JC261 and the JC120, and how to make a buying decision without getting swayed by a "compatible" label that nobody is actually guaranteeing. For the full picture of what is and isn't supported, 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 specific case.
What the code confirms: they're not named
Neither the JC261 nor the JC120 appear by name in Traccar's code. They're not in the JC_MODELS set of the JT808 decoder (where JC371, JC181, JC182, JC450, and JC451 are), and they don't have their own variant in the enum Variant of the Gt06ProtocolDecoder either (where JC400 is). This is a direct check against the source code, not an opinion.
What that does NOT mean
Here's the point that gets misunderstood most often on the forum: a model not appearing by name does not mean it's incompatible. It's a distinction worth keeping clear for any camera you're sold, not just these two.
Traccar's GT06/Concox decoder serves a huge range of Chinese trackers without needing a specific entry for every model. And JT808 (JT/T808, also known as Huabao) is a Chinese national standard that dozens of MDVR manufacturers implement, with or without dedicated logic in Traccar.
What the absence of the name does mean is narrower: there's no model-specific logic for that device in the decoder. Nobody has checked whether the JC261's or JC120's firmware quirks — proprietary fields, extended commands, non-standard event formats — are handled. It could work perfectly under the protocol's generic behavior, or some quirk might need special handling that doesn't exist today. We don't know, and saying otherwise would be making it up.
The only external signal we have
A third-party integrator, flespi, documents on its own platform that the JC181, JC400, and JC261 only upload video clips in 1-minute segments. That's the only reference we have that the JC261 integrates with some real system — but it's flespi's data, not Traccar's or the manufacturer's. Don't take it as confirmation of compatibility; take it as a hint that the device speaks some standard protocol recognizable by third parties. For the JC120, we don't even have that much.
Another possible entry point: the HTTP decoder
Traccar also has a dedicated HTTP decoder, JimiPhotoProtocolDecoder.java (added in June 2026), which receives photo and video uploads via multipart POST, distinguishing image from video by MIME type. We don't know whether the JC261 or JC120 use this path — it's simply another entry point that exists for Jimi devices in addition to JT808 and GT06.
How to verify it in practice, without guessing
- Ask your distributor, in writing, what protocol the device speaks — JT808/Huabao, GT06/Concox, or something proprietary — and the corresponding port. This is the question that actually matters, not the brand or the model name.
- Ask for a sample unit before buying the batch. Without this, everything else is theory.
- Register it in Traccar with its identifier and check whether positions come in.
- Check the server log to see which decoder it's coming in through:
grep -i "YOUR_IMEI" /opt/traccar/logs/tracker-server.log - Only then test media:
ls -la /opt/traccar/media/YOUR_IMEI/for files, andgrep -i "jt1078" /opt/traccar/logs/tracker-server.logfor live video.
If no positions come in at step 3, don't keep tweaking the configuration: the device's protocol doesn't match what you configured, and it's time to go back to the distributor with the question from point 1.
A configuration detail that gets confused on the forum
If you make it to the media part, the real key is media.path — the switch that turns on file storage in Traccar, defaulting to ./media. There is no media.enable key; that's a common mistake on the forum. The other related key is media.bufferSize, defaulting to 32 MB.
The general rule, beyond these two models
This isn't a post about whether the JC261 or JC120 are good or bad cameras — we have no basis to say either. It's about a rule that applies to any camera sold to you as "Traccar compatible": the right question is never the brand or the model. It's the protocol. A seller can honestly tell you their camera "works with Traccar" because they tested it once with a specific firmware, without that guaranteeing anything about the unit that's going to arrive at your door.
Do the JC261 and JC120 work with Traccar?
We don't know, and we're not going to dress it up. They're not in the code, we haven't tested them, and the only external signal — flespi's data point about the JC261 — is indirect. If you need an answer before buying the full batch, ask for the sample unit and follow the steps above.
NOTE
Verified against Traccar's source code (August 2026): the absence of JC261 and JC120 from JC_MODELS (JT808 decoder) and from the enum Variant of Gt06ProtocolDecoder, as well as the existence and purpose of JimiPhotoProtocolDecoder.java and the media.path key. Not verified: hardware specifications of either model, and whether they work with Traccar in practice — the data point about the JC261 uploading 1-minute clips comes from a third-party integrator (flespi), not from our own testing or the manufacturer.