Vehicle health context
Use available faults, mileage and engine-hour readings to support maintenance assessment. A fault code indicates a condition for investigation, not a complete repair diagnosis.
Connect compatible OEM feeds, CAN interfaces and vehicle data sources to support maintenance, fuel analysis and EV fleet decisions.
Plan your integrationVehicle data is not uniform. Make, model, year, powertrain, interface and permissions can all affect the signals available. Fleetly integration planning starts with a vehicle-by-vehicle capability assessment, then maps the agreed readings into consistent units and meanings while preserving where each value came from.
Use available faults, mileage and engine-hour readings to support maintenance assessment. A fault code indicates a condition for investigation, not a complete repair diagnosis.
Separate tank level from fuel used and calculated consumption. Compare similar vehicle classes and show coverage alongside performance.
Assess supported state-of-charge and energy signals. Treat charging status as a distinct field; a parked vehicle is not necessarily connected to a charger.
Where more than one source reports the same measure, agree priority and correction rules. Retain provenance so teams can explain differences.
Select a stage to see what needs to happen and why it matters.
Confirm make, model, year, powertrain and the exact adapter or OEM service before selecting signals.
Confirm make, model, year, powertrain and the exact adapter or OEM service before selecting signals.
Use the approved installation or authorised data feed. Confirm units, update frequency and unavailable fields.
Map measurements into a common model without converting missing data into zero or merging unlike signals.
Use validated readings for maintenance, fuel or EV analysis within the agreed capability scope.
Compare representative readings with trusted evidence and investigate changes after hardware, firmware or vehicle updates.
These are scoping considerations, not field names or a published API schema. Confirm the exact contract for your implementation.
| Data area | Why it matters | What to validate |
|---|---|---|
| Odometer / distance | Supports usage and maintenance context. | Confirm units, source and resets or discontinuities. |
| Fuel level / fuel used | Describes tank quantity or consumption. | Do not substitute one for the other. |
| State of charge | Estimates remaining EV battery charge. | Confirm availability and distinguish charging status. |
| Fault information | Provides diagnostic context. | Retain source and code definitions for qualified assessment. |
Technical background: Teltonika: CAN adapter vehicle compatibility. External guidance does not establish Fleetly compatibility.
Mark what you have prepared and use the remaining items to shape your discussion. This checklist stays in this page session.
Preparation only; this is not a compatibility assessment or production approval.
No. Supported signals depend on the vehicle, interface and configuration. Assess the exact vehicle and hardware combination.
For some use cases it may provide required signals. Compare coverage, reporting frequency, permissions and the need for cameras or additional sensors before deciding.
Stationary status alone is insufficient. Use a validated charging signal where available and label any derived estimate explicitly.
Not on its own. Maintenance teams should interpret the code alongside inspection and appropriate diagnostic procedures.
Features and integration methods depend on the agreed devices, interfaces, permissions and enabled modules. Request the current technical documentation before implementation; never include passwords or access tokens in an initial enquiry.