---
title: "Wialon Sensors From Systems Wialon Cannot See | Asset Track"
url: https://theassettrack.com/blog/wialon-sensors-from-any-system/
description: "Message Merger writes probe, weighbridge or ERP readings onto a Wialon unit that keeps its tracker, so they become sensors, report columns and alerts."
---

# Wialon Sensors From Systems Wialon Cannot See

[Siarhei Havarunou](https://www.linkedin.com/in/sergey-govorunov/) – CEO

September 23, 2026

Message Merger writes probe, weighbridge or ERP readings onto a Wialon unit that keeps its tracker, so they become sensors, report columns and alerts.

Every fleet we work with has a number Wialon never sees. The cold-chain probe knows the trailer ran at −18 °C. The weighbridge knows the truck left with 24 tonnes on it. The ERP knows the job was delivered at 14:02. All of it sits in a system the customer already pays for, and none of it can become a Wialon sensor, a report column or an alert — because a Wialon unit binds to exactly one tracking device, and that device’s protocol is the only way in.

**Message Merger** is our answer to that. It takes a webhook from any system, maps its fields onto Wialon message parameters, and writes them onto a unit that keeps its real tracker. The [Message Merger product page](https://theassettrack.com/products/merger/) has the feature breakdown; this is what it is for.

## What a customer actually connects

| What sends | What lands on the unit | What Wialon can then do |
| --- | --- | --- |
| Cold-chain probe | `cargo_temp`, `door_open` | A temperature sensor, a trip report column, an alert when it rises |
| Weighbridge or load cell | `load_kg` | Axle-load trends per vehicle, an alert over the legal limit |
| ERP or dispatch system | `job_id`, `delivered_at` | The job on the same timeline as the movement that served it |
| Driver app or third-party API | whatever it holds | A value the fleet already owns, in the reports it already runs |

The pattern is always the same: a system that knows something about the vehicle, and a Wialon account that cannot ask it. The value is not new data — the customer has it. The value is that it finally lands where the reports are.

## It becomes a real sensor, not a dashboard beside one

This is the part that decides whether the integration is worth anything. A parameter on a unit is not a screen we drew: it is a Wialon message parameter, so a Wialon sensor binds to it by name and everything downstream reads it.

We proved that on a live account on 12 August: a temperature sensor bound to `cargo_temp` rendered the reading as **−18.40 °C**, on a unit that kept its real tracker and its own history. Not a number we displayed — a number Wialon displayed, because by then it was Wialon’s.

From there nothing is special any more, which is the point:

- **Reports** render the values as their own rows, so a delivery report can carry the temperature it ran at.
- **Notifications** fire on a range, so an excursion becomes an alert to the same people who already get the speeding ones.
- **The mobile apps and the customer’s own exports** read it, because it is a sensor like any other.

## Each sender gets its own endpoint

A system that sends is set up once: its own URL, its own secret, and a mapping that says which value in its JSON becomes which parameter on the unit. Adding a second sender changes nothing for the first, and nothing about the sender’s own format has to change for Wialon’s sake — the mapping absorbs grams, millivolts and Kelvin on our side.

Writing that mapping is a conversation with us, not a project for your developers. What it looks like field by field is in the [guide](https://theassettrack.com/blog/webhook-data-into-a-wialon-unit/).

## The tracker stays exactly where it is

The usual route for this problem is a second platform in the path — merge the streams in flespi and feed Wialon one combined virtual device. Merger takes the other route: the unit’s device type does not change, the tracker keeps reporting as it always did, and the extra readings land beside its messages on the same unit. No second vendor, no second bill.

## What it does not do

An honest limit, because it decides whether this fits your case at all. Readings arrive in seconds, not milliseconds. If a value has to trigger an alarm the instant it changes — a panic button, a door opening on a secured load — this is the wrong path and flespi is the right one, and we [build on that stack too](https://theassettrack.com/blog/flespi-and-wialon-dual-stack-architecture-guide/). If it is a number that a report, a claim, a customer SLA or a compliance record has to contain, the delay costs nothing and saves a platform.

## How to get one

Merger is in **preview** rather than on general release. We stand the endpoint up against your account, configure the first sender with you and hand over the admin app that shows what each hook is doing — what has been buffered, imported and retried.

It is priced per application under your own brand, like the rest of the Marketplace set on [our products page](https://theassettrack.com/products/merger/): your logo, your domain, your commercial relationship with the customer.

## Wialon third-party data FAQ

### Does the vehicle need a second device fitted?

No. The data comes from a system that already exists — a probe, a weighbridge, an ERP — over HTTP. Nothing is installed on the vehicle and the tracker is untouched.

### Which systems can send to it?

Any that can make an HTTP request, which in practice is all of them. If the system cannot be made to call out at all, the middle ground is a scheduled job on your side that reads it and posts on its behalf.

### Can it write to any Wialon unit?

Yes, on any device type, including a unit that already has a live tracker on it. That is the whole reason the service exists.

### Does the data pass through your database?

No. A reading is buffered only until its batch is written to Wialon, and what fails is kept so it can be replayed rather than lost silently. The record lives in the customer’s Wialon account, not in ours.

### Can we resell it to our own customers?

Yes — under your brand and domain, with the pricing and the relationship yours.

## Getting started

Tell us the system that holds the data and the unit it belongs on, and we will map its fields onto Wialon parameters with you — it takes a conversation, not a project. The [Message Merger product page](https://theassettrack.com/products/merger/) has the detail, and a note here reaches us directly.

Work with us

Need this running on your own Wialon?

We build Wialon integrations, data pipelines and white-label fleet apps. Twenty minutes on a call is usually enough to say whether your case is a week of work or a quarter.

[Book a free call](https://cal.com/sergey.govorunov/call) or send us a message

## More from Asset Track

- September 29, 2026 · Integration
 ### FleetAI: Chat With Wialon, Plus an MCP Server
 Ask your Wialon fleet in plain words and get a table, map or PDF back. FleetAI is also an MCP server and skill for Claude Code, Codex and Cursor.
 [FleetAI: Chat With Wialon, Plus an MCP Server](https://theassettrack.com/blog/fleetai-for-wialon-released/)
- September 21, 2026 · Integration
 ### Webhook Data into a Wialon Unit
 Wialon has two ways to put a message on a unit and only one works on a unit that already has a tracker. How the import path behaves, and what it costs you.
 [Webhook Data into a Wialon Unit](https://theassettrack.com/blog/webhook-data-into-a-wialon-unit/)
- September 11, 2026 · Integration
 ### Wialon API Python Client That Works
 A modern Python client for the Wialon Remote API: login, search, live events with avl_evts — plus which libraries are alive and which died in 2013.
 [Wialon API Python Client That Works](https://theassettrack.com/blog/wialon-api-python-client/)
