Integrar GPS a Servidor Propio: Guía de Protocolo TAIP y Wialon IPS

🎯 Para quién es este artículo: integradores y desarrolladores que operan su propio backend y quieren que el GPS tracker reporte directamente a su servidor, sin plataforma obligatoria en el medio.

Muchas de las consultas técnicas que recibimos empiezan igual: "ya tenemos nuestra propia plataforma, solo necesitamos hardware que hable con ella". Para eso exactamente están construidos los equipos Rinho: el tracker mide y transmite (sus reglas de eventos a bordo deciden cuándo y qué reportar); las alertas de negocio, las reglas y los reportes viven en tu servidor. Esta guía cubre el camino completo para enviar datos GPS a tu propio servidor: elegir entre Rinho TAIP y Wialon IPS, apuntar el equipo a tu host y puerto, levantar un receptor, parsear tramas reales y endurecerlo para producción.

Paso 1: elige el protocolo — TAIP o Wialon IPS

Todos los trackers Rinho — Zero IoT, Smart IoT y Spider IoT — hablan dos protocolos de salida abiertos:

	Rinho TAIP	Wialon IPS
Ideal para	Recibir datos en tu propio servidor	Conectar a una plataforma que ya habla IPS
Tipo	ASCII, base Trimble TAIP con extensiones de Rinho	Protocolo abierto publicado por Gurtam (v1.1)
Transporte	UDP y TCP, framing idéntico	TCP/UDP
Telemetría	Set extendido completo: temperaturas, batería de respaldo, horómetro, identificación de conductor por iButton, CAN bus (OBD-II / J1939)	Según lo define el estándar IPS
Documentación y herramientas	Guía de integración de 30 páginas (PDF) + servidor de ejemplo open source	Soportado por Wialon, Navixy, Traccar y otros

La regla práctica: si estás construyendo tu propia ingesta de datos, usa Rinho TAIP — es el protocolo nativo completamente documentado, y el resto de esta guía lo recorre paso a paso. Si vas a conectar a una plataforma de terceros existente, usa Wialon IPS (disponible en toda la línea desde el firmware v1.09.19): consulta el anuncio de Wialon IPS para ver las plataformas soportadas y los detalles de conexión.

Paso 2: apunta el equipo a tu host y puerto

El host de destino, el puerto y el transporte (UDP o TCP) son configuraciones por equipo; la forma más rápida de definirlas es el configurador web. Los receptores TAIP suelen escuchar en el puerto 4031 (primario) y 4034 (secundario), pero los puertos son totalmente configurables. Dos cosas que conviene saber antes de desplegar:

• El equipo se identifica con un campo ID= en cada mensaje — típicamente el IMEI.
• Una vez en línea, envía un keep-alive cada 60 segundos (configurable), así tu servidor siempre sabe qué equipos están vivos.

El modelo de hardware no cambia la integración: Zero, Smart y Spider son idénticos a nivel de protocolo, y cualquier modelo puede generar cualquier tipo de reporte — el tipo de reporte se configura por equipo, no lo determina el hardware.

Paso 3: levanta el receptor

La elección de transporte define el trabajo del receptor:

• UDP: sin conexión. Mantén una tabla NAT que mapee cada ID de equipo a la IP:puerto de origen de su último paquete, envía los comandos de vuelta a esa dirección por el mismo socket, y expira las entradas que no se hayan visto durante un período prolongado (p. ej. 24 horas).
• TCP: el equipo abre una conexión persistente hacia tu servidor. Como TCP es un stream, almacena los bytes entrantes en un buffer y extrae las tramas >...< completas — un segmento puede traer varios mensajes, o un mensaje partido entre segmentos.

En ambos casos, un mismo datagrama o segmento puede contener múltiples tramas: escanea siempre todos los >...< en los datos recibidos.

No tienes que empezar de cero. El proyecto open source rinho-udp-server (Node.js, licencia MIT) escucha en un puerto UDP configurable, parsea los reportes de posición estándar, envía los ACK, hace seguimiento de los equipos activos, encola comandos con reintentos y guarda en MySQL. Es un ejemplo para aprender y probar — no está listo para producción tal cual — pero muestra todas las piezas en movimiento. Esta es su rutina de checksum XOR, textual:

exports.calculateChecksum = function (cmd) {
    var checksum = 0;
    for (var i = 0; i < cmd.length; i++) {
        checksum = checksum ^ cmd.charCodeAt(i);
    }
    var hexsum = Number(checksum).toString(16).toUpperCase();
    if (hexsum.length < 2) {
        hexsum = ("00" + hexsum).slice(-2);
    }
    return hexsum;
}

El checksum es el XOR de cada byte desde > hasta * inclusive, formateado como dos dígitos hexadecimales en mayúscula. Las tramas con checksum inválido se descartan en silencio — nunca se les envía ACK.

Paso 4: parsea las tramas

Todo mensaje TAIP sigue la misma estructura:

>BODY[;#MSGNUM];ID=DEVICEID;*CHECKSUM<

Aquí tienes un reporte de posición estándar de ejemplo (tipo RCQ):

>RCQ28060426153025-3462000-05838000045180A2031280000001103051005121115;#002A;ID=860012345678901;*4E<

Después del prefijo de 3 caracteres (R + tipo de reporte), la base es siempre de 66 caracteres de posición fija. Campos clave de esta trama:

Campo	Crudo	Decodificado	Regla
Fecha/hora (UTC)	060426153025	2026-04-06 15:30:25	reloj GPS del equipo
Latitud	-3462000	-34.62000°	÷ 100000
Longitud	-05838000	-58.38000°	÷ 100000
Velocidad	045	45 km/h	km/h, no nudos
Rumbo	180	180°	directo
Entradas	A2	ignición ON (bit 7) + IN05 + IN01	máscara de bits hex
Tensión principal	128	12.8 V	÷ 10
Odómetro	00000011	17 m	hex → metros
Satélites / PDOP	10 / 05	10 satélites, PDOP 5	decimal

RCQ es uno de los 14 tipos de reporte que comparten esta base de 66 caracteres; los sufijos agregan temperaturas (RCR/RCV), tensión de la batería de respaldo (RBQ), batería de respaldo + horómetro del motor (RHQ), identificación de conductor por iButton (RCT), sesiones de conductor (RCU) y datos de CAN bus como PIDs OBD-II (REQ) o SPNs J1939 (RER). Los valores de sensores custom (temperatura BLE, combustible, etc.) viajan en un segmento AP= o PA= (ambos prefijos son equivalentes; la versión de firmware determina cuál se usa) con parámetros tipados name:type:value — ten en cuenta que algunos scripts legacy emiten pares name:value sin tipo. Dos conversiones que muerden en integraciones reales: el campo de antigüedad de la temperatura es hexadecimal (0x00–0xFF segundos) mientras que el PDOP es decimal, y el horómetro convierte hex → segundos de funcionamiento del motor. Los mapas de campos completos están en la guía de integración del protocolo (PDF).

Paso 5: producción — ACK, keep-alive y confiabilidad

La confiabilidad se apoya en la numeración de mensajes más el ACK. Tu servidor debe confirmar cada mensaje que traiga un #MSGNUM menor a 0x8000, devolviendo el msgNum exacto y el ID del equipo:

Equipo → servidor:  >RCQ28060426153025-3462000-05838...;#002A;ID=860012345678901;*4E<
Servidor → equipo:  >ACK;#002A;ID=860012345678901;*38<

• Envía el ACK solo después de persistir. Si la escritura en tu base de datos falla, no envíes el ACK — el equipo retransmite (timeout de 7 segundos, hasta 4 reintentos por mensaje, hasta 9 mensajes en vuelo en paralelo). Esto es lo que garantiza que no se pierdan datos.
• Nunca envíes ACK a los keep-alives. >KA;ID=860012345678901;*10< llega cada 60 segundos; solo refresca tu tabla NAT (UDP) o el estado de la conexión (TCP) y guarda silencio.
• msgNum ≥ 0x8000 es una respuesta, no un reporte nuevo. Un comando que envías como #0042 vuelve confirmado como #8042 (bit 15 activado). Asócialo al comando pendiente — no le envíes ACK.
• Asegura el perímetro. El protocolo es texto plano con identificación basada solo en el ID, así que restringe quién puede alcanzar tu puerto de ingesta (VPN, whitelisting de IP, firewall) y valida los IDs de equipo contra tu propio registro de dispositivos.

Los comandos usan el mismo framing en la dirección opuesta — desde tu backend puedes consultar el firmware (>QVR;#0042;ID=860012345678901;*51<), leer el IMEI y el número de serie, o enviar configuración.

Recursos

Rinho Telematics:

• Guía de integración del protocolo Rinho (PDF) — 30 páginas: framing, checksum, los 14 tipos de reporte, mecanismo de ACK, comandos y mensajes de ejemplo.
• Configurador web — define host/puerto de destino y opciones del equipo desde el navegador.
• Documentación técnica — referencia de firmware y configuración.
• Anuncio de Wialon IPS — si en cambio vas a conectar a una plataforma existente.

Recursos externos:

• rinho-udp-server en GitHub — receptor de referencia open source en Node.js (MIT).

En resumen

• Los trackers Rinho reportan directamente a tu host:puerto por UDP o TCP — Rinho TAIP para tu propio backend, Wialon IPS para plataformas que ya lo hablan. No se requiere plataforma intermedia.
• El protocolo es ASCII y está completamente documentado: una base de posición de 66 caracteres, sufijos de telemetría extendida y ACK con retransmisión (timeout de 7 s, 4 reintentos) para que las fallas transitorias no pierdan datos en silencio.
• Entre la guía en PDF y el servidor UDP de ejemplo, puedes estar parseando tramas en vivo de un equipo real el mismo día.

¿Estás construyendo tu solución sobre tu propio backend? Ese es exactamente el perfil para el que diseñamos: protocolo abierto, hardware documentado, soporte directo de fábrica. Empieza por nuestra página Para integradores, o escríbenos y te ayudamos a que tus primeras tramas lleguen a tu servidor.