"Compatible" is doing a lot of work in most product descriptions. In practice, compatibility between a tracking device and a platform breaks down into four separate questions, and a device can pass three of them and still be unusable.
The four questions
| Question | What to establish | What "no" looks like later |
|---|---|---|
| 1. Protocol | Which protocol the device transmits in, and whether your platform can decode it. | Data arrives and is discarded because nothing can read it. |
| 2. Endpoint | Whether the reporting server address can be changed to one you choose. | The device only ever talks to the vendor's cloud. Changing platform means changing hardware. |
| 3. Field mapping | How each reported field corresponds to the field your platform expects, including units. | Columns that are empty, or worse, populated with the wrong thing. |
| 4. Firmware behaviour | Whether an update can change reporting behaviour, and who controls when updates happen. | A working integration that quietly changes shape one morning. |
A documented protocol and configurable endpoint are useful starting conditions, not proof of compatibility. The platform receiver, permissions, field mapping, firmware behaviour and a real sample still need to be checked.
Endpoint control is the one that matters most
Of the four, endpoint control has long-term consequences. If the device can be pointed at a server you choose, a platform change may avoid replacing hardware — but platform-to-platform exchange, history migration and receiver work can still be separate routes. If it cannot, the platform decision and the hardware decision are tied together for the life of the fleet.
This is worth checking model by model rather than brand by brand. Vendors frequently offer both kinds of product in the same catalogue.
- Device to receiver. The device sends its documented protocol to a receiver/parser. The platform team confirms decoding, authentication, fields and clock; the customer confirms permitted access; the model/manufacturer confirms documentation where available.
- API/file exchange. An existing system exchanges selected fields through an API or file. The source and destination owners agree access, field coverage, limits, licence/API fees, export format and support.
- Historical migration. An authorised export is mapped into the destination using agreed identifiers, units, timestamps and retention. It may not require new hardware, but the source owner, destination team and customer must agree the trial mapping and gaps.
A received-field pilot compares the exact fields, units, timestamps and gaps that the customer and platform team agree to accept. Device-server reporting, API/file exchange and historical migration are different project paths; none proves universal compatibility, guaranteed migration or a successful test in advance.
Field mapping: where integrations quietly fail
Integration problems can be connection failures, mapping failures or firmware and permission issues. A problem may surface only when someone reads a report closely, so the receiving platform and a real sample matter.
- Units. Litres against gallons, kilometres against miles, Celsius against Fahrenheit. A number that arrives in the wrong unit still arrives.
- Semantics. "Engine hours" from a bus and "engine hours" derived from power-on time are different measurements sharing one label.
- Events versus states. Some devices report a door as an event, some as a state. A platform expecting one and receiving the other shows nothing.
- Nulls. What the device sends when a sensor is absent, and what the platform does with it.
The only reliable check is to send real data from a real installation into the actual platform and read the resulting rows. That is part of sample validation.
Keeping your platform or agreeing a third-party route
An existing or third-party receiving platform can remain in place where the model, receiver, permissions and project responsibilities support it. We confirm that route per model before you commit. There is no mandatory LEXUNYU platform subscription. Any connectivity, platform access, integration work, storage, support or third-party fees should be agreed by the parties for the project; this page does not assume a universal platform route or a guaranteed cost of changing later.
For how this layer sits alongside the device and connectivity layers, see vehicle tracking systems; for the hardware layer itself, fleet hardware.
The one-line version
Before ordering, document the protocol, receiver support and permissions, endpoint control, field mapping, firmware behaviour and the sample checks needed on the actual platform. Endpoint control can preserve options, but it does not by itself prove a no-replacement migration.
Platform compatibility does not prove a remote DDD file path; see the DDD project guide.
Frequently asked questions
Can any tracker report to any platform?
No. It depends on whether the platform can decode the device's protocol and whether the device's reporting endpoint can be changed. Both are per-model questions.
What does "open protocol" actually mean?
That the message format is documented well enough for a third party to decode it. Ask for the protocol description before the order — if it cannot be supplied, treat the device as closed.
Why do integrations fail weeks after installation?
Field mapping, connectivity, firmware behaviour, receiver support or permissions can all be involved. Check the actual platform records from a representative installation rather than relying on an online status.
Can we change platform later without changing hardware?
Possibly, if the model supports a new endpoint and the receiving platform can accept the data, but history migration, receiver work and permissions are separate checks. Endpoint control alone is not a no-replacement guarantee.
Who controls firmware updates?
Worth asking explicitly. An update that changes reporting behaviour can break a working integration, so it matters whether updates are pushed automatically or scheduled by you.
How do we prove compatibility before ordering?
Install a sample on a representative asset and send its data to the platform you intend to run. Read the resulting records rather than checking that the device shows online.
Do we have to use your platform?
No mandatory LEXUNYU platform subscription is assumed here. An existing or third-party receiving platform may be used where the model, receiver, permissions, responsibilities and fees are agreed for the project.
What if we have several device types already?
Mixed estates are normal. The question becomes whether each device type can report into one platform, or whether the fleet ends up split across several dashboards.
What is the minimum order quantity?
Custom orders start from 100 units. Samples and small validation batches are handled separately, which is how compatibility gets proved.
What warranty applies?
A 12-month limited warranty from the shipment date shown on the commercial invoice.