Flespi and Wialon Dual-Stack Architecture Guide

Running both Flespi and Wialon is not a default architecture — it is an intentional trade-off that only makes sense when each system provides capabilities the other cannot. Flespi excels at raw telemetry flexibility: custom protocol parsing, low-latency message access, and programmable data routing via channels and streams. Wialon excels at operational workflows: dispatch management, geofence-triggered notifications, driver assignment, and structured report generation. When your requirements span both domains, a dual-stack becomes the pragmatic choice.

The trigger for dual-stack is usually a data science or analytics requirement that Wialon's event model cannot satisfy. Standard Wialon notifications fire on pre-defined conditions — speed threshold exceeded, geofence entered, sensor value crossed a boundary. But if you need raw CAN-bus parameters for predictive maintenance, sub-second GPS sampling for route optimization models, or custom protocol fields from non-standard trackers, Flespi's message-level access is essential. Wialon processes and summarizes; Flespi preserves the raw signal.

The cost of dual-stack is real and should be estimated before committing. You are maintaining two API contracts, two authentication flows, two sets of monitoring dashboards, and two vendor relationships. Every new vehicle type needs configuration in both systems. Every schema change in your downstream database needs to account for two source formats. If you cannot articulate a specific, measurable capability gap that justifies this overhead, stay single-stack with Wialon and build extraction pipelines for analytics use cases.

The first architectural decision in a dual-stack system is creating an event ownership matrix. For every event family your downstream systems consume, you must declare which system is the source of truth. GPS positions might come from Flespi because its channel messages offer richer metadata and lower latency than Wialon's last-message cache. Trip summaries should come from Wialon because its trip detector applies business logic — minimum parking time, distance threshold, ignition correlation — that would be expensive to replicate.

Driver assignments belong in Wialon because that is where dispatchers work and where the assignment lifecycle is managed. Raw CAN-bus telemetry — engine RPM, coolant temperature, diagnostic trouble codes — belongs in Flespi because Wialon normalizes these into sensor values and discards the original protocol-level detail. Geofence events are trickier: Wialon computes geofence entry and exit server-side with its own geometry engine, but if you need sub-second precision, you might compute geofence events from Flespi's raw GPS stream.

Document the ownership matrix in a shared location that both engineering and operations teams reference. When a downstream consumer reports conflicting data — a vehicle that appears to be in two states simultaneously, or a trip duration that does not match between two dashboards — the ownership matrix tells you which source to trust and where the bug lives. Without this document, debugging dual-source conflicts becomes an archaeological expedition through two API response formats.

A shared event schema is the contract between your dual sources and every downstream consumer. Without it, every consumer needs to understand both Flespi message format and Wialon event format, which doubles integration cost and makes consumer development fragile. The normalization layer sits between the two sources and emits a single, documented event format that downstream systems can depend on.

Field mapping requires careful attention to semantic differences. Flespi timestamps are Unix epoch in seconds with optional millisecond precision in the decimal part. Wialon timestamps are also Unix epoch but report-level timestamps may reflect server processing time rather than device time. Coordinate systems are generally WGS84 from both, but precision differs — Flespi preserves whatever the device sends, while Wialon may round coordinates in certain API responses. Unit identifiers are completely different: Flespi uses device IMEI or channel-assigned IDs, while Wialon uses its own internal unit ID system.

Maintain a schema registry for the normalized contract. This can be as simple as a versioned TypeScript interface file in your repository or as formal as an Avro or JSON Schema registry. The key discipline is that changes to the normalized schema require a version bump and backward-compatible migration. If a consumer breaks because a field was renamed or a timestamp format changed, your normalization layer has failed its primary purpose.

Flespi and Wialon use fundamentally different delivery models, and your ingestion architecture must handle both. Flespi streams push data to your endpoint via HTTP callbacks or MQTT subscriptions. This is an at-least-once delivery model — you will receive duplicates during retries, and your processing layer must be idempotent. Wialon's Remote API is a pull model: you poll for updates via core/search_items or messages/load_interval. This is effectively at-most-once per poll interval — if your poller crashes between polls, you miss a window of data.

Message ordering across sources is not guaranteed and should not be assumed. A Flespi stream callback for a GPS position at timestamp T might arrive after a Wialon poll that includes a trip event referencing that same timestamp. Your normalization layer should buffer incoming events briefly and emit them in timestamp order, or your downstream consumers should tolerate out-of-order delivery. In practice, a five-second reorder buffer handles the vast majority of timing skew between sources.

Correlation is the glue that holds dual-stack ingestion together. You need a reliable mapping between Flespi device identifiers and Wialon unit IDs. This mapping should be maintained as a configuration table that is updated whenever a new device is provisioned. Correlate events by device ID and timestamp window — events from both sources within a configurable window (typically one to three seconds) for the same device likely describe the same physical moment. This correlation enables enrichment: attach Wialon's trip context to Flespi's raw telemetry, or attach Flespi's CAN-bus data to Wialon's geofence events.

Replay capability is a requirement, not a luxury, in dual-stack architectures. When you discover a bug in your normalization logic, you need to reprocess historical data from both sources and regenerate downstream state. Flespi provides message storage with configurable retention — you can replay channel data by querying the messages REST API with time range filters. Wialon provides historical data through report execution and messages/load_interval, but the access patterns and rate limits differ from Flespi's replay capabilities.

Reconciling replayed data with the live stream requires careful state management. During a replay, your normalization layer is processing both historical messages and live incoming data for the same devices. You need either a separate replay pipeline that writes to a staging area before cutover, or a deduplication layer that can distinguish replayed messages from live ones. Idempotent processing keys — typically a composite of device ID, timestamp, and message type — are essential for preventing duplicate records in your downstream database.

Plan your retention windows to match your replay needs. If your analytics team needs to reprocess the last ninety days of data when a metric definition changes, both Flespi and Wialon need to retain at least ninety days of accessible history. Flespi message storage retention is configurable per channel. Wialon message retention depends on your hosting plan and configuration. Mismatched retention windows create partial replay scenarios where you can recover data from one source but not the other, producing incomplete or skewed results.

Flespi's pricing model is based on messages per month per channel. Wialon's API has practical throughput limits based on your session's rate budget and the complexity of your queries. Both contribute to your per-vehicle-per-day processing cost, and understanding this cost is essential for margin planning as your fleet scales. A vehicle sending GPS updates every ten seconds generates roughly 8,640 Flespi messages per day — multiply by your fleet size to estimate monthly message volume and cost.

Build a monitoring dashboard that tracks messages ingested, normalized, and failed, broken down by source system. Alert on throughput anomalies: a sudden drop in Flespi messages from a specific channel might indicate a stream configuration problem. A spike in Wialon API errors might indicate rate limit exhaustion. Failed normalization events — messages that could not be mapped to the shared schema — should trigger immediate investigation because they represent data loss.

As your fleet grows, the cost dynamics shift. Flespi message costs scale linearly with fleet size, but your normalization compute costs may scale super-linearly if your processing logic is not optimized. Wialon API polling costs scale with the number of units you query and the polling frequency. Review your cost-per-vehicle-per-day metric monthly and investigate any upward trend. Small inefficiencies at fifty vehicles become significant expenses at five hundred.

Migrating from Wialon-only to dual-stack should be incremental, not a big-bang cutover. Start with shadow mode: configure Flespi streams for a subset of vehicles, ingest the data into your normalization layer, but do not let it affect any downstream business processes. Compare Flespi's raw telemetry against Wialon's processed events for the same vehicles and time periods. This comparison reveals data quality differences, timing discrepancies, and normalization bugs before they affect production.

Define cutover criteria before starting the migration. Typical thresholds include: Flespi message completeness above 99.5% compared to expected device reporting frequency, normalization success rate above 99.9%, end-to-end latency from device message to normalized event under a target threshold (usually five to fifteen seconds), and cost per vehicle per day within budget. Do not cut over until all criteria are met for at least two consecutive weeks — one good week could be a coincidence.

Plan your rollback path explicitly. If dual-stack introduces problems after cutover, you need to revert downstream consumers to Wialon-only data without data loss. This typically means maintaining the Wialon-only ingestion pipeline in parallel for at least thirty days after cutover. The transition period is operationally expensive — you are running three pipelines (Wialon-only, Flespi-only, and dual-stack normalized) — but the alternative is a risky cutover with no safety net.