Keep the trackers you already run

It means the platform ingests data from trackers it did not sell. A device from another vendor reports into MoboSafe alongside MoboSafe hardware, appearing in the same list with the same alerts and the same reports.

It does not mean every feature works on every device. What you get from a device is bounded by what that device measures, and no software layer invents a reading that no sensor produced.

So the honest framing is that you keep the hardware and the visibility it already produces, and gain a better layer on top. Anything requiring a sensor the device does not have still needs that sensor. See what hardware-agnostic means.

Three things, in order of how often they are the blocker.

The second one is the usual obstacle, and it is commercial rather than technical. A vendor unwilling to release the device configuration is the reason most estates cannot be unified, not the protocol.

• The protocol the device speaks. Most commercial trackers report over well-known telematics protocols, and support is a question of whether that protocol is already handled or needs adding.
• Where it is allowed to send data. Many devices can only report to one destination configured by the original vendor, so the practical question is whether you or your vendor can point it at a second endpoint.
• What the device measures. A unit reporting only position cannot produce fuel or temperature data regardless of platform.

Setting expectations by category is more useful than by brand, because the variation within a brand is larger than between brands.

• Basic GPS trackers: position, speed, ignition where wired. No fuel, no engine data, no driver behaviour beyond what position implies.
• AIS-140 certified VLTDs: the above plus panic-button events, and a mandatory second data stream to the state backend that is separate from any platform you use.
• OBD-plugged devices: position plus engine parameters and fault codes, but only what the specific vehicle exposes, which differs by make and model.
• Devices with fuel sensors: level readings whose usefulness depends entirely on calibration, not on the platform reading them.
• Dashcams: highly variable. Video retrieval, event upload and live streaming are separate capabilities and a device may have one without the others.

Publishing one would be a claim about other companies’ products and firmware versions, which change without notice.

A buyer who finds their model on a list and then discovers their firmware revision behaves differently is worse off than one who was told how to check. The failure mode of an inaccurate compatibility list is a stalled migration, and it is not recoverable by apologising for the list.

So the offer is the check rather than the list: send the make, model and firmware of what you run, and the answer will be specific to your estate. That is a slower answer and a correct one.

A platform that only ever says keep your devices is selling something too, so the cases where replacement is correct are worth stating.

Everything else is usually a software problem wearing a hardware costume, and replacing forty working units to solve it is the expensive way round.

• The device is not AIS-140 certified on a vehicle that requires one. No software layer makes an uncertified unit compliant. See what is a VLTD.
• The vendor has been removed from your state approved list, which is a compliance problem rather than a platform one.
• The capability you need is a sensor that is not installed, such as fuel level on a device that has none.
• The unit has been dark for months and diagnosing it costs more than refitting.

The sequence is short and worth doing before any commitment.

See the AI control tower for how a mixed estate is unified once devices are reporting.

• Send the make, model and firmware version of each device type in the fleet, and roughly how many of each.
• Confirm whether you or your current vendor can change where the device sends data. This is the question that decides most cases.
• Pilot one device of each type before committing the estate, because two units of the same model can behave differently across firmware revisions.
• Compare what actually arrives against what you expected the device to report, since that gap is the real answer.