Teltonika is one of the most popular protocols in flespi platform and in the world of Telematics. This topic will be used to post changes in protocol implementation. Here is a guide how to obtain telematics data from Teltonika devices over API . Supported devices list Teltonika FM1100 Teltonika FM1110 Teltonika FM1120 Teltonika FM1122 Teltonika FM1125 Teltonika FM1200 Teltonika FM1202 Teltonika FM2200 Teltonika FM3001 Teltonika FM3300 Teltonika FM3612 Teltonika FM3622 Teltonika FM36M1 Teltonika FM4100 Teltonika FM4200 Teltonika FM5300 Teltonika FM6300 Teltonika FM6320 Teltonika FMA110 Teltonika FMA120 Teltonika FMA202 Teltonika FMA204 Teltonika FMB001 Teltonika FMB002 Teltonika FMB003 Teltonika FMB010 Teltonika FMC001 Teltonika FMM001 Teltonika FMB110 Teltonika FMB120 Teltonika FMB122 Teltonika FMB125 Teltonika FMB130 Teltonika FMB202 Teltonika FMB204 Teltonika FMB630 Teltonika FMB640 Teltonika FMB641 Teltonika FMC650 Teltonika FMB900 Teltonika FMB910 Teltonika FMB920 Teltonika FMB962 Teltonika FMB964 Teltonika FMT100 Teltonika FMU125 Teltonika FMU130 Teltonika GH5200 Teltonika MTB100 Teltonika TMT250 Teltonika TST100 Teltonika FMM125 Teltonika FMC125 Teltonika FMM130 Teltonika FMC130 Teltonika FMB204 Teltonika FMB140 Teltonika TFT100 Teltonika FMM800 Teltonika FMC800 Teltonika FMM920 Teltonika FMM150 Teltonika FMM13A Teltonika FMC13A Teltonika FMM80A Teltonika FMM650 Teltonika FMB930 Teltonika FMM880 Teltonika FMC880 Teltonika FMC234

BLE temperature and humidity sensor values parsing added to device types FMB

Dear flespi users. We have added a new device type Teltonika TST100 to the list of supported Teltonika devices. With this update we also announce major refactoring of the whole Teltonika protocol implementation for all device types. The newly integrated TST100 already works on the new base, and has all possible settings integrated. In the nearest future we will move all other devices messages parsing and settings operations to the new base. We will report here the log of the migration. The main goal is to make parameters parsing more faster and more precise. Update will touch only "secondary" parameters without influencing time and position parameters.

Teltonika FM3001 moved to new parsing scheme. FM3001 settings have been remastered to correspond Teltonika Parameter list With this update we also moved "Generic Teltonika" device type to new parsing scheme. So if you do not register a device in Telematics Hub and use it only in channel level - the parsing will work with correspondence to Teltonika FMB table as it is the most popular device family. Again, this relates only to "secondary" parameters without influencing time and position parameters.

As described in previous post we do major refactoring here. The list of updates installed today: (and the main): All device types moved to new parsing scheme. Device types added: FMC125 , FMM125 , FMC130 , FMM130 , FMB206 Wide range of settings added for devices: MTB100 , TMT250 . Digital inputs settings remastered to fit clearly to all FMB devices family list.

Device types added: FMC001 , FMM001 And for the OBD device family device settings are almost full. (We skip Geofence settings and Bluetooth OBD settings as they require settings Arrays work which is under construction on Telematics Hub back-end side)

tags 253 and 254 remastered as specified in Teltonika wiki . As for now it is parsed as following: if parameter 253 is: 1 – harsh.acceleration.event = true (parameter 254 is parsed to absolute.acceleration in G) 2 – harsh.braking.event = true (parameter 254 is parsed to absolute.acceleration in G) 3 – harsh.cornering.event = true (parameter 254 is parsed to harsh.cornering.angle in degrees) For FMB640, FMB630, FM3612 and FM36m1 254 tag have been parsed to eco.driving.events.number which is not valid parsing. This parameter will be removed from 254 tag parsing in a week - 20 November, 2019

Teltonika protocol updated: Parameter can.liquid.sensor.fuel.volume is renamed to can.fuel.volume For backward compatibility both parameters are registered for now. Old parameter will be removed 25 Nov 2019. Multiplier 0.1 is applied to can.fuel.volume parameter to get resulting value in liters.

namo Teltonika protocol updated: can.liquid.sensor.fuel.volume parameter is removed

Dear flespi users, there are minor changes in Teltonika protocol: overspeeding.event parameter will be renamed to overspeeding.status parameter. movement.event parameter will be renamed to movement.status . For now both parameters are registered. movement.event and overspeeding.event will be removed on December 4th There are also some bugfixes: Several parameters has wrong signed/unsigned parsing. E.g. external.powersource.voltage generated bad values as it was parsed as signed integer, now it switched to unsigned and has correct values. The same with gsm.lac or gsm.cellid (it was parsed as signed, and now as unsigned, so on big values it was possible incorrect). FMB630 device series parameter can.engine.coolant.temperature parsing fixed towing.event parameter parsing was incorrect. We've fixed it and now correct parameter value is stored in towing.alarm.status gsm.jamming.event parameter parsing was incorrect. We've fixed it to gsm.jamming.alarm.status If you will find something suspicious in Teltonika parameter parsing - please, contact us.

we've implemented special logic for parsing BLE connected devices. Teltonika protocol send it under tag 385 and now it is parsed to parameter ble.beacons which is JSON object, where keys are BLE beacons UUID, and values - JSON objects with beacon parameters, e.g. {... "ble.beacons": { "E2C56DB5-DEAD-BEEF-B060-D0F5A71096E0:1234:9876": { "rssi": -79 }, "E2C56DB5-DEAD-BEEF-B060-D0F5A71096E0:4321:6789": { "rssi": -86 } }, "channel.id": 12345, "event.enum": 385, "event.priority.enum": 0, "ident": "123451234512345", "position.altitude": 126, "position.direction": 60, "position.latitude": 12.3456, "position.longitude": 65.4321 ...} if("undefined"!==typeof hljs)hljs._ha();else if("undefined"===typeof hljsLoading){hljsLoading=1;var a=document.getElementsByTagName("head")[0],e=document.createElement("link");e.type="text/css";e.rel="stylesheet";e.href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.7.0/styles/default.min.css";a.appendChild(e);e=document.createElement("script");e.type="text/javascript";e.onload=function(){var d={},f=0;hljs._hb=function(b){b.removeAttribute("data-hljs");var c=b.innerHTML;c in d?b.innerHTML=d[c]:(7

[Changelog] teltonika protocol

namo

Teltonika protocol is updated: parameter can.engine.mil.indicator.indicator.state renamed to can.engine.mil.indicator.state.
For backward compatibility both old and new parameters will be registered until 04-Aug-2025.

namo

Teltonika protocol is updated: old parameter is removed after renaming (see namo )

EvgenyShatilo

Tacho functionality update: added registration of tachograph file metadata in the saved file that will be finalized. NOTE: parameters will be added only if the corresponding data was provided by the tracker or correctly parsed from the uploaded file.
List of the parameters:

plate_number - vehicle registration number
region - vehicle registration region.
vin - vehicle VIN number
driver_first_name - driver's first name
driver_last_name - driver's last name
driver_id - driver card identifier

EvgenyShatilo

Tacho functionality update.
The issue in auto upload management has been fixed. This primarily concerns older versions of devices such as fmb640, which may work more unstably compared to new models.
The problem was that if the tachograph data download process was not completed correctly, the interval for the next download could be extended for a long time, which could lead to a massive delay in downloading.
At the moment, the issue has been fixed and precautions have been taken.

EvgenyShatilo

Tacho functionality update:

Redesigned the mechanism for sending data to the tachograph card.
Improved logging: if loading tacho conditions are not met, a clear log message (Conditions mismatch — Code 11) is now shown. The system will automatically stop the current session and retry the loading command.
Now, if the conditions for correct operation do not match, for example, the company's card is temporarily disabled for some reason, physically or due to a poor Internet connection, there will be no parsing error, only a message in the log that the conditions are not met.
Fixed errors that could be caused by the absence of a card of configuration.
Improved stability of tachograph data loading.

EvgenyShatilo

Tacho functionality update:
Fixed #tacho.driver.card.status which could register an incorrect value.
Also added a new parameter #tacho.driver.card.presence which registers the original value passed by the tracker:
0 - card is not present, 1 - card is present, 2 - error, 3 - not available (Privacy mode)

baja

FTC series parsing update:
ID 113 parsed as battery.level will also be registered as custom.param.113 till August 13
ID 13266 parsed as log.file.current will also be registered as custom.param.13266 till August 13
ID 13267 parsed as log.file.max.count will also be registered as custom.param.13267 till August 13

EvgenyShatilo

Tacho functionality update: improved control and improved tachograph data loading stability. Now disconnecting the main tracker connection while loading data will not affect the current tacho uploading process.

EvgenyShatilo

Tacho functionality update: the default size of tachograph activity data has been increased (from 30 days to 90 days) when requesting data from the tachograph (VU file).

EvgenyShatilo

Tacho functionality update: added a mechanism for parsing the tachograph file and dynamic generation of the full file name. The file name is formatted automatically based on the file content. Also, depending on the region, the name format will be changed. Here are some examples of files:

VDO format which applies to all countries except France and Spain:

VU file: M_20250801_1406_LT01STR_VINNUMBER00001001.DDD
Driver file: C_20240808_1228_E_Smith1407_1200000000110200.DDD

C1B, V1B format for France:

VU file: FXX-NNN-ZZ2508011746.V1B
Driver file: FXX-NNN-ZZ2508011746.C1B

TGD format for Spain

VU file: V_1234ABC_E_20250801_1745.TGD
Driver file: C_1200000000110200_E_20250801_1745.TGD

EvgenyShatilo

Tacho functionality update: Fixed file name formatting.

fixed a problem where an incomplete file name was registered, for example: DRIVERNAME_DRIVERID00000000001.ddd instead of the full name: "C_20250820_1023_S_LASTNAME_DRIVERID00000000001.ddd". The problem was that if the driver has a double last name or if the last name is written in a file as a double last name, for example "SURENAME/SURENAME", the server cut the file name to the "/" character because such a character is not allowed in a file name and is prohibited in most versions of operating systems, such as MacOS and Linux, and is not always correctly detected in Windiws. Now such a symbol is cut at the parser level, so if the driver has a double surname, the full file name will look like this: "C_20250820_1023_S_SURENAMESURENAME_DRIVERID00000000001.ddd".
The problem of registering an incorrect extension for the regions of France and Spain has been fixed. Despite the correct definition of the driver's region in the file, the extension was always ddd. Previously it was: V_0001_E_20250812_1235.ddd, now it is: V_0001_E_20250812_1235.tgd.
Fixed the problem of an empty name in a correctly formatted file name, for example: C_20250819_1001___XXX0000003X00001.ddd, will now be C_20250819_1001_S_SURENAME_XXX0000003X00001.ddd. The problem was related to the fact that the fields with the driver's first/last name unloaded from different tachograph standards have an internal flag that specifies the presence and validity of the name, which is now processed correctly.
Added additional check for file extension (ddd, tgd, v1b, c1b), it will always be in lower case so that it is equally well processed by different operating systems and applications.