Rinho en Wialon

Esta nota reúne todo lo necesario para dar de alta y aprovechar un equipo Rinho en Wialon : qué tipo de dispositivo elegir, cómo apuntar el equipo, con qué nombre aparece cada dato en Wialon y cómo sumar datos propios sin pedir cambios en la plataforma.

1. Dos formas de conectar

Para la mayoría de los casos conviene TAIP: es el protocolo nativo del equipo, Wialon lo decodifica completo y con el campo AP se puede publicar cualquier dato adicional sin cambiar de protocolo. Con las plantillas de esta nota, los dos protocolos publican los datos con los mismos nombres: se puede pasar de uno al otro sin tocar Wialon.

2. Tipos de dispositivo y puertos

Tipos Rinho disponibles en Wialon Hosting:

• Servidor de Wialon Hosting: el que indica Wialon para cada tipo de dispositivo. Los equipos de prueba de esta nota reportan a nl.gpsgsm.org. En Wialon Local o en un servidor de un integrador, el host y el puerto los define quien administra ese servidor.
• ID único de la unidad: el que el equipo manda en el campo ID= de cada trama. En los modelos IoT es el IMEI. Se consulta con >QID<.
• Todos los modelos usan el mismo protocolo: el tipo de dispositivo define el puerto y el nombre del modelo en Wialon, pero los datos se decodifican igual (Spider y Zero publicaron exactamente lo mismo en todas las pruebas).

3. Receta: dar de alta un equipo en Wialon

Con el protocolo Rinho TAIP (recomendado)

1. En Wialon, crear la unidad:

2. En el equipo, apuntarlo al puerto del tipo de dispositivo (ejemplo para un Zero IoT):

>SIP0"nl.gpsgsm.org",22912<   // servidor principal
>SIP1"nl.gpsgsm.org",22912<   // servidor principal redundante
>SCXIPPP5<                    // TAIP por UDP en el canal principal y en el de respaldo

3. Plantilla de reporte: el reporte de usuario estándar con campo AP (lo trae la configuración Wialon del configurador). En Spider IoT y Smart IoT, para los datos del motor, la regla periódica tiene que generar un reporte ER (J1939) o EQ (OBD-II).

4. Importar la plantilla WLP del modelo (sección 10).

5. Verificar: en Wialon aparecen mensajes nuevos, y en el equipo >QBU< responde RBUOK00000 (nada esperando confirmación).

Con Wialon IPS

1. En Wialon, crear la unidad con tipo de dispositivo Rinho IPS, ID único = IMEI. La contraseña puede quedar vacía o tener una: el equipo tiene que mandar la misma (paso 2).

2. En el equipo (ejemplo para un Zero IoT):

>SCXIPWP5<                    // Wialon IPS en el canal principal, TAIP UDP en el de respaldo
>SIP0"nl.gpsgsm.org",22500<   // puerto del tipo "Rinho IPS"
>SIP1"nl.gpsgsm.org",22500<
>SWLNA<                       // unidad sin contraseña en Wialon: NA. Si tiene, SWL<la contraseña>
>SUC00 QWD0| $rep_num:1:| #| $,cel_level:1:'CSQ',pwr_int:2:'V/100'<

Para Spider IoT y Smart IoT, la plantilla con los datos del motor:

>SUC00 QWD0| $rep_num:1:| #| $,cel_level:1:'CSQ',pwr_int:2:'V/100',rpm:1:'ECU(0;0)',fuel_lvl:2:'ECU(2;0)',odometer:2:'ECU(3;0)',odoliter:2:'ECU(4;0)',refr_temp:1:'ECU(6;0)',oil_press:1:'ECU(7;0)',trip_time:2:'ECU(10;0)'<

Las reglas que ya tiene el equipo no se tocan: siguen generando el reporte de usuario GU0…, que ahora sale en Wialon IPS.

3. Importar la misma plantilla WLP del modelo (sección 10): no hay una plantilla aparte para Rinho IPS. Las plantillas de equipo de arriba usan los mismos nombres de parámetros que TAIP, así que los sensores son los mismos.

4. Verificar: >QBU< en RBUOK00000 y >QDL< sin pendientes (el segundo número en 00000).

Cambiar de protocolo con el equipo instalado

Los reportes que el equipo ya tiene en cola quedaron armados para el protocolo anterior y el servidor nuevo no los confirma: frenan a todos los que vienen detrás. Antes de cambiar, revisar >QBU< y >QDL<. Si quedan pendientes y se pueden descartar, después del cambio:

>CBU<    // vacía la cola de envío
>SDLC<   // vacía el datalog

Notas

• Transporte: TAIP usa UDP (el de fábrica). Wialon IPS usa TCP.
• Confirmación (TAIP): Wialon responde >ACK;#<nro>;ID=<id>;*<checksum>< a cada trama. El equipo reenvía hasta recibirla y recién ahí descarga su cola: sin cobertura no se pierde nada. Desde abril de 2025 Wialon confirma también las tramas con fecha y hora en cero.
• Keep-alive: si está configurado (>SKA120,B<, por ejemplo), cada keep-alive usa un número de mensaje. Por eso en Wialon mess_num “salta” un número cada tanto: no es una trama perdida.

4. Qué decodifica Wialon de cada trama

5. Parámetros base

Todas las tramas publican:

Además, Wialon toma de la trama la velocidad, el rumbo, la cantidad de satélites y las entradas y salidas. Las tramas TAIP no traen altitud: en Wialon figura 0.

Entradas y salidas

El byte de entradas de la trama (HH) se publica tal cual en las entradas de Wialon, y el de salidas (II) en las salidas:

Verificado con una trama con entradas A5 y salidas 02: Wialon mostró entradas 165 (in1, in3, in6, in8) y salidas 2 (out2). Para un sensor de ignición en Wialon se usa in8.

6. CAN: nombres en Wialon

ER — CAN J1939

EQ — OBD-II

Para cualquier otro dato de la ECU (consumo instantáneo, torque, etc.) se usa un reporte de usuario con ECU dentro del campo AP.

7. Datos propios: el campo AP

Wialon decodifica un campo opcional AP (parámetros adicionales) en cualquier trama TAIP, con el mismo esquema que Wialon IPS. Cada parámetro aparece en Wialon con el nombre que le pone el equipo: sirve para sensores BLE, contadores, horómetro, batería interna, temperaturas o cualquier valor de EVAL, sin pedir cambios en el parser.

>RCQ00…<datos del reporte>;AP=temp1:2:25.50,door:1:1,driver:3:JUAN;#0017;ID=865413053386354;*26<

Cómo se comporta Wialon

Armar el AP en el equipo

El AP se arma con un reporte de usuario que copia una trama nativa y le agrega el campo. El patrón sirve para cualquier familia ($RCQ| #| QCQ,5,100, $RER| #| QER,5,200, $RBQ| #| QBQ,5,120, …):

// UC00: trama CQ con señal, tensión, velocidad, entrada 0 y canal de envío
>SUC00 $RCQ| #| QCQ,5,100| $;AP=rpt:1:| $'RNU'| $,csq:1:| $'CSQ'| $,vcc:1:| $'V'| $,in0:1:| $'IN(0)'| $,pwr:2:| $'V/100'| $,vel:2:| $'VEL'| $,canal:3:| $'CHN'<
 
// Reporte cada vez que vence TD00 con la ignición encendida
>SRL00E;TRG=TD00+;CND=IGN;ACC={GU000L;@LOG}<

En Wialon aparecen rpt, csq, vcc, in0, pwr, vel y canal (WIFI o GPRS).

Ejemplos listos en el configurador: el nivel de varillas de combustible BLE (;AP=fl1:1:2997,ag1:1:3,…) y el resto de las recetas que reportan a Wialon.

8. Wialon IPS en detalle

Los modelos IoT (Zero, Spider y Smart) hablan también Wialon IPS: login #L#, datos #D# y datos cortos #SD#, por TCP. Está disponible desde el firmware 1.09.19; se recomienda 1.09.24 o superior, que completa los comandos SWL, QWL y QWD. La receta está en la sección 3.

Puerto y login

Respuestas de Wialon Hosting al login de un equipo dado de alta como Rinho IPS sin contraseña:

• El puerto es el del tipo de dispositivo: 22500 para Rinho IPS. El 20332 es el del tipo genérico Wialon IPS y rechaza a una unidad dada de alta como Rinho IPS.
• Sin contraseña en Wialon, el equipo tiene que mandar NA (>SWLNA<). Con contraseña, la misma en los dos lados.
• Un login rechazado no deja rastro en Wialon: la unidad simplemente no recibe mensajes. En el equipo se ve porque >QBU< o >QDL< no bajan. Después de 5 intentos el equipo espera 60 segundos y prueba por el otro canal (WiFi o celular).

Qué publica Wialon

Del paquete #D#, siempre:

Y los parámetros de la plantilla, con el nombre que se les ponga. Las plantillas de esta nota usan los mismos nombres que Wialon le da a TAIP (rep_num, cel_level, pwr_int, rpm, fuel_lvl, …): la misma plantilla WLP sirve para los dos protocolos, y se puede cambiar de protocolo sin tocar los sensores.

La plantilla del equipo

QWD0 arma el paquete #D# completo y termina en NA;. Lo que sigue en los tramos $ son los parámetros, con el formato nombre:tipo:valor del campo AP:

>SUC00 QWD0| $rep_num:1:| #| $,cel_level:1:'CSQ',pwr_int:2:'V/100'<
#D#101126;140806;2746.8504;S;06415.5070;W;0;358;199;12;0.1;131;0;11.73,3.91;NA;rep_num:1:00,cel_level:1:99,pwr_int:2:11.67

Para ver la trama que el equipo mandaría, sin enviarla: >QWD0<.

9. Número de evento

Wialon no lee el número de evento igual en todas las tramas:

En TAIP ocurre con y sin AP, y ya se informó a Wialon. Mientras tanto:

• Para eventos del 00 al 09 no hay diferencia.
• Al traducir eventos en Wialon (sensor sobre rep_num), cargar el valor según la familia de trama: en CQ y EQ, el número leído en hexadecimal.

10. Plantillas WLP por modelo

Plantillas de unidad para importar en Wialon (Propiedades de la unidad → Importar desde WLP). Cada una sirve para TAIP y para Wialon IPS (con las plantillas de equipo de la sección 3): una unidad Rinho IPS usa la misma plantilla que una TAIP del mismo modelo.

Las plantillas se probaron en Wialon Hosting:

• TAIP, en una unidad Spider IoT: con una trama ER de valores conocidos, Wialon calculó RPM 1234, combustible 50 %, temperatura 85 °C, presión 300 kPa, odómetro 20000 km, horas de motor 1500 y consumo 10000 L.
• Wialon IPS, en una unidad Rinho IPS: ignición, tensión, batería de respaldo, entradas, señal, evento y los sensores CAN calcularon con las plantillas de equipo de la sección 3.

Notas:

• Salidas: la trama trae XP0 y XP1, por eso las plantillas de Spider y Smart incluyen dos.
• El sensor Evento va sin tabla de textos: los números de evento dependen de cómo esté configurado cada equipo. Cargarlos según las reglas del equipo y la nota sobre el número de evento.
• Los demás parámetros del campo AP (sensores BLE, contadores…) se agregan como sensores nuevos con el nombre que use el reporte de usuario del equipo.

11. Comandos desde Wialon

Wialon puede mandar comandos al equipo, en TAIP y en Wialon IPS: se definen en la unidad como mensaje personalizado (custom_msg) con el comando Rinho completo, por ejemplo >QVR<. Verificado en los dos protocolos con un comando >STAG…< enviado desde Wialon, que cambió la etiqueta del equipo.

Las plantillas incluyen dos comandos de consulta: Versión de equipo (>QVR<) y Posición actual (>QCQ<).

• En TAIP (UDP) el comando sale cuando el equipo vuelve a comunicarse (con el próximo reporte o keep-alive): un equipo que reporta cada pocos segundos lo recibe enseguida.
• Wialon registra el envío del comando, pero no guarda la respuesta del equipo (RVR…) como mensaje. Para leerla, usar el configurador o una regla que mande la información en un reporte.

12. Si algo no aparece en Wialon

1. No llega nada (TAIP): >QIP0< y >QCXIP<. El puerto tiene que ser el del tipo de dispositivo de la unidad, y el ID único el que el equipo manda en ID= (>QID<).
2. No llega nada (Wialon IPS): casi siempre es el login. >QWL< tiene que devolver la contraseña de la unidad, o NA si no tiene; el puerto, 22500 para Rinho IPS.
3. La cola no baja (>QBU< o >QDL< con pendientes): el servidor no confirma. Si se acaba de cambiar de protocolo, ver cambiar de protocolo.
4. Llegan tramas repetidas o con atraso: el equipo no recibe la confirmación y reenvía. Revisar el tipo de dispositivo de la unidad y que el puerto sea el de ese tipo.
5. Falta un parámetro: ver la tabla de la sección 4. Lo que Wialon no publica se manda en el campo AP.
6. Un parámetro AP no aparece: valor vacío, tipo equivocado o nombre de más de 32 caracteres.
7. El evento no coincide: ver número de evento.
8. Para ver la trama exacta: >QWD0< en Wialon IPS; >QCQ<, >QER<, etc. en TAIP.

Ver También

• Reporte CQ - Formato de la trama base
• Reporte ER - CAN J1939
• Reporte EQ - OBD-II
• Reportes de usuario - Armar el campo AP
• Confirmación de la recepción - ACK
• Comando WL - Contraseña de Wialon IPS