Jimi IoT JC450 on Traccar: fleet camera with ADAS and DMS

We already covered the JC181 in production: dual channel, light vehicle, and the real limitations of Traccar with that camera family. The JC450 is from the same manufacturer, the same protocol, but a step up: multi-camera, ADAS, DMS, and built for heavy commercial vehicles. This article covers what changes and what doesn't when you connect it to Traccar.

If you don't know how cameras work in Traccar in general, start with the camera support guide. Here I'll assume you already know the basics and go straight to the model.

What the JC450 is

It's a multi-channel MDVR (mobile video recorder) aimed at commercial fleets and heavy vehicles, with driver-assistance capabilities the JC181 doesn't have.

The leap over the JC181 is twofold: more channels (up to five versus two) and onboard assistance software — ADAS for driving-event detection (forward collision, lane departure, following distance) and DMS for driver monitoring (drowsiness, distraction). And the DC 9–33 V power input confirms the target: truck, bus, heavy machinery — not a sedan.

How Traccar sees it

Like the JC181, the JC450 comes in via JT/T808. Traccar's decoder (Jt808ProtocolDecoder.java) has an explicit set of Jimi models with dedicated logic — JC_MODELS — and the JC450 is in it, alongside JC371, JC181, JC182, and JC451. This isn't a camera that's "compatible by accident": the server recognizes it by name.

That means it inherits exactly the same live-video mechanism as the JC181: videoStart triggers the JT808 0x9101 message, videoStop triggers 0x9102, and Traccar relays between the camera and your browser via the JT/T1078 pipeline (Jt1078Protocol, Jt1078FrameDecoder, Jt1078ProtocolDecoder). If you already run a JC181, there's nothing new to learn on the protocol side.

What does change is how many channels you have to choose from.

The differentiator: requesting a specific channel

The 0x9101 message that videoStart generates carries, among other parameters, the video channel number — 1 by default. On a two-channel camera like the JC181, that barely matters: front or cabin, and that's it. On the JC450, with up to five possible channels (built-in + 4 remote), that field is where you actually decide what you're watching.

In theory, this opens the door to requesting video from channel 3 (a side camera, say) instead of channel 1 (the built-in one), simply by changing the channel parameter in the videoStart command.

And there's a second half to the story, on the playback side: the channel also travels in the stream URL. Traccar serves live video as HLS from VideoStreamResource, at /api/stream/{deviceId}/{channel}/live.m3u8 (with segments at /api/stream/{deviceId}/{channel}/{index}.ts). Which means a five-channel JC450 exposes five separate playlists, and the side camera is consumed on its own path. The full mechanism is in JT1078 live video on Traccar.

Now for the honest part: we haven't verified how Traccar exposes those five channels in the command interface, whether it selects a default channel automatically, or whether there's any practical limit on the decoder side for high channel numbers. This is exactly what you should test on your own installation before promising a customer "video from all five cameras at once" — start by requesting channel 1, confirm it responds, then work your way up the channel number in the command to see what each one returns.

ADAS and DMS: what actually reaches the server

This is where expectations need lowering with precision, because it's where this camera gets oversold the most.

Traccar does receive ADAS and DMS events. In Jt808ProtocolDecoder.java, subtypes 0x64 (ADAS) and 0x65 (DMS) are decoded and stored on the position as attributes:

• adasAlarm — a numeric byte with the ADAS alarm type
• dmsAlarm — a numeric byte with the DMS alarm type
• alarmLabel — 16 hex bytes identifying the alarm, when the message is long enough

What doesn't happen: those codes are not translated into named Traccar alarms. You won't see "drowsiness" or "lane departure" in the interface; you'll see dmsAlarm: 3. The table of what each number means is defined by the manufacturer, so ask your distributor for it — without it, the attribute is a meaningless number.

There is named mapping for other things on the same unit: subtype 0x70 translates harsh acceleration, braking, harsh cornering and collision into ALARM_ACCELERATION, ALARM_BRAKING, ALARM_CORNERING and ALARM_ACCIDENT. And driver fatigue does get its ALARM_FATIGUE_DRIVING through the status-bit path. But the bulk of ADAS/DMS arrives as a raw number.

If your customer wants readable alerts and notification rules on ADAS/DMS events, that's integration work on top of these attributes, not something Traccar hands you finished.

What doesn't change: no server-side recording, no free network drops

Two things carry over unchanged from the JT808 family, and they're worth repeating even if you already read them in the JC181 post:

The JT808 decoder doesn't save media files on the server. The JC450's historical video stays on its two microSD cards, inside the vehicle. This isn't an architecture limitation in Traccar — it's that the JT808 decoder doesn't invoke the generic media system the server already has. It's implementable with a scoped modification; we have it solved on our own server. But out of the box, no.

Streaming drops for the same two reasons as always. 3G/4G cell handoff while the vehicle is moving, and resending videoStart every few seconds out of impatience — each new request forces the camera to cancel the session and renegotiate the TCP socket, so the quick retry is the cause, not the fix. Wait 10–15 seconds after requesting video, and use the sub-stream in poor coverage. The full mechanism is covered in live JT1078 video in Traccar.

To confirm a given camera obeyed the command, the log check is the same:

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

If you see jt1078 < followed by the camera's IP right after videoStart, the session was established on the camera's end. And if you see notifications: 0 in the event log, it's not a device or ADAS/DMS failure: Traccar processed the event, you just don't have a notification rule configured for that event type.

Is this the right camera?

Yes, if you run heavy commercial vehicles (24 V), need more than two camera channels, or your requirement includes ADAS/DMS as a safety layer on top of GPS position. It's the same proven protocol as the JC181, with more hardware behind it.

No, if you only need two cameras and a light vehicle — the JC181 covers that case with less hardware and lower cost. And no, if your non-negotiable requirement is centralized video storage on your server without touching code: with stock JT808, neither the JC181 nor the JC450 does that. For the full picture of what's compatible, see our guide to Traccar-compatible cameras.