You plan to move a dealer fleet off Wialon over one weekend. The Migrate screen imports every Wialon unit with its sensors, and the log says "Creating device" and "Creating unit" for each. On Monday the units sit on the map, but the fuel graph is flat and ignition never turns on.
The import did what it promises. It copies structure, not working telemetry. This post explains why, what you lose, and the order of work that gets a migrated device reading real values.
The migration reads each Wialon unit through your Wialon session. For each one it creates a device and a unit in your account, then writes the device's sensors. Every sensor field it writes is an expression, the same kind you type on the Sensors tab.
Three design choices drive everything below:
The type-by-type tables are in What a Wialon migration brings across. Here is what happens to one object, end to end.
Northwind Logistics runs Truck 12 on Wialon with three sensors. The Wialon sensor list for the unit looks like this (trimmed):
{
"nm": "Truck 12",
"uid": "860000000000012",
"sens": {
"1": { "n": "Ignition", "t": "engine operation", "m": "On/Off", "p": "in1" },
"2": { "n": "Fuel tank", "t": "fuel level", "m": "l", "p": "adc1",
"c": "{\"lower_bound\":0,\"upper_bound\":300}",
"tbl": [ { "x": 0, "a": 0.045, "b": 0 },
{ "x": 2000, "a": 0.0632, "b": -36.4 },
{ "x": 4000, "a": 0.0816, "b": -110 } ] },
"3": { "n": "Mileage", "t": "mileage", "m": "km", "p": "mileage*0.001" }
}
}
After import, the device carries four sensors. These are the expressions the import writes:
[
{ "type": "GPS", "fields": { "latitude": "{lt}", "longitude": "{lg}", "altitude": "{height}" } },
{ "type": "IGNITION", "fields": { "v": "{params.in1}", "m": "{speed}" } },
{ "type": "FUEL", "fields": { "unit": "l", "capacity": 300,
"level": { "value": "{params.adc1}", "table": "<the three Wialon rows, unchanged>" } } },
{ "type": "ODOMETER", "fields": { "unit": "km", "total_meter": "{params.mileage}*0{params..001}" } }
]
| Wialon setting | After import | Works as is? |
|---|---|---|
in1 on the ignition |
{params.in1} |
No. Write {in1}. |
Fuel parameter adc1 |
{params.adc1} |
No. Write {adc1}. |
| Fuel calibration rows | Same rows, same coefficients | Yes |
Fuel upper_bound 300 |
Tank capacity 300 | Only if 300 is the tank size |
Fuel lower_bound and upper_bound |
Not copied as bounds | No. Set them again. |
mileage*0.001 |
{params.mileage}*0{params..001} |
No. Write {mileage}*0.001. |
Unit km |
Measurement unit km |
Check it. The list offers KM and Miles. |
| (none) | A GPS sensor reading {lt}, {lg} |
No. The app stores position as lat, lng and alt. |
Why the params. prefix: the generic profile writes parameters the way Wialon's own retranslation format nests them. The app's message pipeline reads {in1} as the device parameter in1; {params.in1} looks for a parameter called params and finds nothing. The decimal break is a separate defect: the rewrite treats the .001 of a decimal constant as a parameter name.
The calibration table is the one part that crosses over intact. Wialon and Polygon use the same model: rows of X, A and B, where each row applies Y = aX + b from its X upward. The import copies the rows unchanged. It brings no measured points, so XY Pairs stays empty in the calibration table dialog.
Two more mapping details matter. Wialon's mileage type becomes ODOMETER, a total distance, and Wialon's odometer type becomes RELATIVE_ODOMETER. For the relative type, the import writes the expression into a field key the type does not define, so that sensor shows no value. The ignition sensor also gets {speed} in its moving-status field.
The reference page lists what the import skips. The integrator's view adds the lossy parts:
status:3 as one bit of status. The import turns it into convertToInt({params.status}, 3), a different operation that the server does not evaluate. Rewrite these as conditions; see Sensor types for what each type expects.Order matters, because changing a device's model resets its sensors and commands.
{params. with {, fix GPS keys to lat, lng and alt, and repair decimals and bit references.The trade-off in step 5: keeping the fixed migration model saves the upload step, but parameter hints then check against the wrong protocol.
{params.…}. Fix: rewrite them as in step 6.0{params..5}-style fragments. Cause: the decimal-constant defect. Fix: retype the constant.