Rinho on Wialon

This note gathers everything needed to add a Rinho device to Wialon  and make the most of it: which device type to choose, how to point the device, under which name each value shows up in Wialon, and how to add custom data without asking for changes on the platform.

1. Two ways to connect

In most cases TAIP is the better choice: it is the device’s native protocol, Wialon decodes it completely, and with the AP field any additional value can be published without switching protocols. With the templates in this note, both protocols publish the data under the same names: you can move from one to the other without touching Wialon.

2. Device types and ports

Rinho types available on Wialon Hosting:

• Wialon Hosting server: the one Wialon indicates for each device type. The test devices in this note report to nl.gpsgsm.org. On Wialon Local or on an integrator’s server, the host and port are defined by whoever administers that server.
• Unit unique ID: the one the device sends in the ID= field of each frame. On IoT models it is the IMEI. Query it with >QID<.
• Every model uses the same protocol: the device type defines the port and the model name in Wialon, but the data is decoded the same way (Spider and Zero published exactly the same in every test).

3. Recipe: adding a device to Wialon

With the Rinho TAIP protocol (recommended)

1. In Wialon, create the unit:

2. On the device, point it to the port of the device type (example for a Zero IoT):

>SIP0"nl.gpsgsm.org",22912<   // main server
>SIP1"nl.gpsgsm.org",22912<   // redundant main server
>SCXIPPP5<                    // TAIP over UDP on the main and backup channels

3. Report template: the standard user report with the AP field (included in the configurator’s Wialon configuration). On Spider IoT and Smart IoT, for engine data, the periodic rule has to generate an ER (J1939) or EQ (OBD-II) report.

4. Import the WLP template for the model (section 10).

5. Verify: new messages show up in Wialon, and on the device >QBU< answers RBUOK00000 (nothing waiting for acknowledgement).

With Wialon IPS

1. In Wialon, create the unit with device type Rinho IPS, unique ID = IMEI. The password can be left empty or set: the device has to send the same one (step 2).

2. On the device (example for a Zero IoT):

>SCXIPWP5<                    // Wialon IPS on the main channel, TAIP UDP on the backup one
>SIP0"nl.gpsgsm.org",22500<   // port of the "Rinho IPS" type
>SIP1"nl.gpsgsm.org",22500<
>SWLNA<                       // unit with no password in Wialon: NA. If it has one, SWL<the password>
>SUC00 QWD0| $rep_num:1:| #| $,cel_level:1:'CSQ',pwr_int:2:'V/100'<

For Spider IoT and Smart IoT, the template with engine data:

>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)'<

The rules already on the device are left untouched: they keep generating the GU0… user report, which now goes out in Wialon IPS.

3. Import the same WLP template for the model (section 10): there is no separate template for Rinho IPS. The device templates above use the same parameter names as TAIP, so the sensors are the same.

4. Verify: >QBU< at RBUOK00000 and >QDL< with nothing pending (the second number at 00000).

Switching protocols with the device installed

The reports already queued on the device were built for the previous protocol and the new server does not acknowledge them: they hold back every report behind them. Before switching, check >QBU< and >QDL<. If there are pending reports and they can be discarded, after the switch:

>CBU<    // empties the send queue
>SDLC<   // empties the datalog

Notes

• Transport: TAIP uses UDP (the factory default). Wialon IPS uses TCP.
• Acknowledgement (TAIP): Wialon answers >ACK;#<nro>;ID=<id>;*<checksum>< to each frame. The device resends until it receives it and only then drains its queue: nothing is lost without coverage. Since April 2025 Wialon also acknowledges frames with date and time set to zero.
• Keep-alive: if configured (>SKA120,B<, for example), each keep-alive uses a message number. That is why in Wialon mess_num “skips” a number every now and then: it is not a lost frame.

4. What Wialon decodes from each frame

5. Base parameters

Every frame publishes:

In addition, Wialon takes the speed, heading, number of satellites and the inputs and outputs from the frame. TAIP frames carry no altitude: Wialon shows 0.

Inputs and outputs

The inputs byte of the frame (HH) is published as-is in the Wialon inputs, and the outputs byte (II) in the outputs:

Verified with a frame with inputs A5 and outputs 02: Wialon showed inputs 165 (in1, in3, in6, in8) and outputs 2 (out2). For an ignition sensor in Wialon use in8.

6. CAN: names in Wialon

ER — CAN J1939

EQ — OBD-II

For any other ECU value (instantaneous consumption, torque, etc.) use a user report with ECU inside the AP field.

7. Custom data: the AP field

Wialon decodes an optional AP field (additional parameters) in any TAIP frame, with the same scheme as Wialon IPS. Each parameter shows up in Wialon under the name the device gives it: it works for BLE sensors, counters, hour meter, internal battery, temperatures or any EVAL value, without asking for changes to the parser.

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

How Wialon behaves

Building the AP on the device

The AP is built with a user report that copies a native frame and adds the field. The pattern works for any family ($RCQ| #| QCQ,5,100, $RER| #| QER,5,200, $RBQ| #| QBQ,5,120, …):

// UC00: CQ frame with signal, voltage, speed, input 0 and send channel
>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'<
 
// Report every time TD00 expires with ignition on
>SRL00E;TRG=TD00+;CND=IGN;ACC={GU000L;@LOG}<

In Wialon rpt, csq, vcc, in0, pwr, vel and canal (WIFI or GPRS) show up.

Ready-made examples in the configurator: the BLE fuel level probes (;AP=fl1:1:2997,ag1:1:3,…) and the rest of the recipes that report to Wialon.

8. Wialon IPS in detail

The IoT models (Zero, Spider and Smart) also speak Wialon IPS: login #L#, data #D# and short data #SD#, over TCP. It is available since firmware 1.09.19; 1.09.24 or later is recommended, which completes the SWL, QWL and QWD commands. The recipe is in section 3.

Port and login

Wialon Hosting responses to the login of a device added as Rinho IPS with no password:

• The port is the one of the device type: 22500 for Rinho IPS. 20332 belongs to the generic Wialon IPS type and rejects a unit added as Rinho IPS.
• With no password in Wialon, the device has to send NA (>SWLNA<). With a password, the same one on both sides.
• A rejected login leaves no trace in Wialon: the unit simply receives no messages. On the device it shows because >QBU< or >QDL< do not go down. After 5 attempts the device waits 60 seconds and tries over the other channel (WiFi or cellular).

What Wialon publishes

From the #D# packet, always:

Plus the template parameters, under whatever name they are given. The templates in this note use the same names Wialon gives to TAIP (rep_num, cel_level, pwr_int, rpm, fuel_lvl, …): the same WLP template works for both protocols, and you can switch protocols without touching the sensors.

The device template

QWD0 builds the full #D# packet and ends in NA;. What follows in the $ segments are the parameters, in the name:type:value format of the AP field:

>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

To see the frame the device would send, without sending it: >QWD0<.

9. Event number

Wialon does not read the event number the same way in every frame:

In TAIP it happens with and without AP, and it has already been reported to Wialon. Meanwhile:

• For events 00 to 09 there is no difference.
• When translating events in Wialon (sensor on rep_num), load the value according to the frame family: in CQ and EQ, the number read as hexadecimal.

10. WLP templates by model

Unit templates to import in Wialon (Unit properties → Import from WLP). Each one works for TAIP and for Wialon IPS (with the device templates in section 3): a Rinho IPS unit uses the same template as a TAIP unit of the same model.

The templates were tested on Wialon Hosting:

• TAIP, on a Spider IoT unit: with an ER frame of known values, Wialon computed RPM 1234, fuel 50 %, temperature 85 °C, pressure 300 kPa, odometer 20000 km, engine hours 1500 and consumption 10000 L.
• Wialon IPS, on a Rinho IPS unit: ignition, voltage, backup battery, inputs, signal, event and the CAN sensors computed with the device templates from section 3.

Notes:

• Outputs: the frame carries XP0 and XP1, which is why the Spider and Smart templates include two.
• The Event sensor has no text table: event numbers depend on how each device is configured. Load them according to the device rules and the note on the event number.
• The other AP field parameters (BLE sensors, counters…) are added as new sensors under the name used by the device’s user report.

11. Commands from Wialon

Wialon can send commands to the device, in TAIP and in Wialon IPS: they are defined on the unit as a custom message (custom_msg) with the full Rinho command, for example >QVR<. Verified on both protocols with a >STAG…< command sent from Wialon, which changed the device label.

The templates include two query commands: Device version (>QVR<) and Current position (>QCQ<).

• In TAIP (UDP) the command goes out when the device communicates again (with the next report or keep-alive): a device reporting every few seconds receives it right away.
• Wialon logs that the command was sent, but does not store the device response (RVR…) as a message. To read it, use the configurator or a rule that sends the information in a report.

12. If something does not show up in Wialon

1. Nothing arrives (TAIP): >QIP0< and >QCXIP<. The port has to be the one of the unit’s device type, and the unique ID the one the device sends in ID= (>QID<).
2. Nothing arrives (Wialon IPS): it is almost always the login. >QWL< has to return the unit’s password, or NA if it has none; the port, 22500 for Rinho IPS.
3. The queue does not go down (>QBU< or >QDL< with pending reports): the server is not acknowledging. If the protocol was just switched, see switching protocols.
4. Frames arrive repeated or delayed: the device does not receive the acknowledgement and resends. Check the unit’s device type and that the port is the one of that type.
5. A parameter is missing: see the table in section 4. What Wialon does not publish is sent in the AP field.
6. An AP parameter does not show up: empty value, wrong type or a name longer than 32 characters.
7. The event does not match: see event number.
8. To see the exact frame: >QWD0< in Wialon IPS; >QCQ<, >QER<, etc. in TAIP.

See Also

• CQ Report - Base frame format
• ER Report - CAN J1939
• EQ Report - OBD-II
• User reports - Building the AP field
• Reception acknowledgement - ACK
• WL Command - Wialon IPS password