JC400 de Jimi IoT en Traccar: la que no habla JT808

Dentro de la familia de cámaras Jimi IoT que hemos ido revisando en esta serie, la JC400 es la rareza. No es solo otro modelo con specs distintas: es la única que no se decodifica como JT808. Si vienes de leer sobre la JC181 y esperas el mismo comportamiento con esta, prepárate para lo contrario en casi todo.

Si no sabes cómo funciona por dentro el soporte de cámaras en Traccar, empieza por ese artículo —o por el índice de la serie, cámaras compatibles con Traccar—; aquí voy directo al modelo.

Qué es la JC400

Es un equipo de video 4G orientado a taxi, alquiler de vehículos, logística y transporte de mercancías peligrosas (ADR), según el propio fabricante. Existen además dos variantes de catálogo, JC400P y JC400D, como SKU independientes.

Hasta aquí, specs de dashcam 4G convencional. Lo interesante empieza cuando miras cómo la trata el servidor.

Por qué importa que hable GT06 y no JT808

Sus hermanas de serie — JC181, JC371, JC182, JC450, JC451 — se decodifican en Traccar dentro del protocolo JT/T808, con lógica específica para cada modelo. La JC400 no está en esa lista. En el código fuente del decodificador GT06 de Traccar, Gt06ProtocolDecoder.java, hay un enum Variant con un valor JC400, y comentarios que identifican varios códigos de mensaje como "Jimi IoT 4G". Es decir: la JC400 entra por el protocolo GT06/Concox, la misma familia de protocolo que usan un porcentaje enorme de rastreadores genéricos chinos, no por JT808.

Esto no es un detalle de trivia. Cambia por completo qué camino sigue la multimedia dentro del servidor, y por tanto qué puedes prometerle a un cliente.

Lo que esto habilita: archivos guardados en tu servidor

A diferencia del decodificador JT808 — que no usa el sistema de almacenamiento de media de Traccar —, el protocolo GT06/Concox sí lo invoca. Cuando el equipo sube una foto (o un video, según el flujo), Traccar:

1. Guarda el archivo en disco bajo media.path, en una subcarpeta nombrada con el identificador único del dispositivo.
2. Añade a la posición un atributo image (o video) con el nombre del archivo guardado.
3. Sirve ese archivo en /api/media/{uniqueId}/{archivo}, detrás de un filtro que exige sesión válida y permiso del usuario sobre ese dispositivo concreto.

El decodificador GT06 además tiene su propia solicitud de foto, que en algunos casos se dispara automáticamente al recibir determinados mensajes del equipo.

Traccar suma a esto un camino adicional: JimiPhotoProtocolDecoder.java, un decodificador HTTP dedicado añadido en junio de 2026, que recibe subidas de fotos y video por POST multipart y distingue entre imagen y video según el tipo MIME de la subida. Escucha en el puerto 5267 por defecto, y es un puerto aparte del gt06 (5023): si no lo abres, las subidas simplemente no llegan. Es el camino de subida de clips/fotos de evento — distinto del streaming en vivo JT1078 que usa la familia JT808.

En resumen: la JC400 es, dentro de la serie Jimi que hemos cubierto, la candidata natural para quien quiere fotos (y potencialmente clips) guardados en su propio servidor, exactamente lo contrario de lo que ofrece la JC181 de serie.

Lo que NO está confirmado: video en vivo

El pipeline de streaming en vivo de Traccar (JT1078) está atado al protocolo JT808. La JC400 va por GT06, así que no asumas que hay video en vivo con esta cámara.

Circula la idea de que estos modelos hacen video en vivo por RTMP hacia un servidor externo. Puede ser cierto del lado del equipo —es cosa del firmware—, pero conviene decirlo claro: en el código fuente de Traccar no hay una sola referencia a RTMP. Traccar no ingiere RTMP ni lo publica. Si un proveedor te vende "video en vivo de la JC400 con Traccar", lo que te está vendiendo es Traccar para la posición y otra plataforma aparte para el video. Son dos sistemas, dos costos y dos puntos de fallo. No lo he encontrado documentado ni en el código ni en material del fabricante, que por cierto nunca menciona GT06 ni JT808 por nombre en su material comercial — el protocolo real solo se ve mirando el propio decodificador. Si necesitas video en directo para esta cámara, es algo que hay que verificar en tu instalación concreta, no algo que puedas dar por sentado antes de comprar.

Cómo verificarlo en tu instalación

No te fíes de una ficha comercial ni de este artículo a ciegas: compruébalo en tu propio servidor.

1. Confirma que media.path está configurado. Es la clave que activa el servlet de media (no existe ninguna media.enable, ese es un error frecuente en el foro).

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

2. Revisa también media.bufferSize. Por defecto son 32 MB; las transferencias mayores a ese tamaño se descartan sin avisarte con claridad. Si esperas video, probablemente necesites subirlo.

3. Registra el dispositivo y espera a que suba algo (una foto de evento, por ejemplo). Luego mira si apareció el archivo:

ls -la /opt/traccar/media/TU_IMEI/

4. Si ves archivos ahí, confirma que el atributo image o video aparece en la posición correspondiente desde la interfaz o la API de Traccar.

5. Si buscas video en vivo, no des nada por hecho: revisa los logs del servidor durante una prueba real y confirma si existe algún mecanismo de streaming activo para este dispositivo, porque no está garantizado por el protocolo que usa.

¿Es la cámara adecuada?

Sí, si tu prioridad es tener fotos (y potencialmente clips de evento) guardadas de forma centralizada en tu propio servidor Traccar, sin depender de la plataforma del fabricante ni de la microSD del vehículo, y tu caso de uso encaja con taxi, alquiler o logística.

No, si tu requisito indispensable es video en vivo verificado desde ya: eso no está confirmado para este modelo y el camino técnico (GT06, no JT1078) no lo garantiza de forma automática. Tendrías que comprobarlo tú mismo antes de comprometerte con una flota entera.

Para quien busca justo lo contrario — video en vivo confirmado pero sin archivo en servidor — la JC181 sigue siendo la referencia dentro de esta serie. Si además necesitas entender a fondo el sistema de media antes de decidir, revisa cómo configurar media.path para guardar y servir fotos y cómo pedir una foto remota con requestPhoto.