Flespi and Wialon Integration

Wialon is built around fleet operations: units, drivers, geofences, reports, the workflows a dispatcher uses all day. flespi sits a layer lower — device protocols, raw message streams, per-message logic, retention you configure rather than inherit. Most fleets need only the first. The ones that need both usually hit the same wall.

The wall is a device or a parameter Wialon does not surface the way you need it: a protocol not yet supported, a sensor field that arrives raw and must be normalised before it means anything, a data-science workload that needs message-level history rather than trip summaries. Working around that inside Wialon means storing derived values in fields never meant for them — which works until the next platform update.

The failure mode of dual-stack is not technical complexity. It is the same business event being computed in two places, drifting apart, and nobody knowing which number to trust. The fix is an explicit ownership rule per data class, written down before implementation starts.

Payload shapes differ per protocol and per firmware, and every consumer that parses them itself is a place where the parsing goes stale. So mapping happens once, in a shared schema with rules under version control, and everything downstream — warehouse, dashboards, alerting — reads the normalised form.

Delivery is designed to be replay-safe from the start: queued, retried with backoff, and idempotent at the handler, so an outage is caught up rather than reconciled by hand. That property is what makes a phased migration possible at all, because a stream can be re-run against a new consumer without polluting what already landed.

Message volume is the number that decides the architecture. A fleet sending high-frequency telemetry from thousands of units generates a workload where retention settings and processing paths move the monthly bill more than any code change will. So throughput, lag and processing cost are instrumented from day one rather than discovered on an invoice.

The practical output is a routing rule per use case: what must arrive in seconds, what can arrive in minutes, and what belongs in a nightly batch to the analytics warehouse. Where the business systems are the destination rather than the analytics stack, that path is the same one described under Wialon integration.

Nobody can afford to cut a live fleet over to a new data path on a Friday and hope. So the migration runs both paths in parallel: the existing flow keeps serving operations while the new stream lands alongside it, writing to its own tables, with a comparison job checking that the two agree on the events they both cover.

That parallel period is the acceptance test. When the streams have agreed for a few weeks on a representative slice of the fleet, consumers are moved over one at a time — analytics first, since it tolerates a rollback, and operational alerting last. The old path stays available until the new one has survived a full billing cycle and at least one platform update, because replay-safe handlers make keeping it cheap and cutting it early expensive.