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

Parameter ID=248 Immobilizer is supported for Teltonika FMB devices.
The following parameters are registered in flespi depending on Param ID=248 value:

if immobilizer value is 0: ibutton.connected.status=false parameter is registered
if immobilizer value is 1: ibutton.connected.status=true parameter is registered
if immobilizer value is 2: both parameters ibutton.connected.status=true and ibutton.authorized.status=true are registered

baja

Bugfix in Setting for tst100 and tft100 device types:
motion_detection_sas setting was working not correctly: starting from the firmware 55.00.04++ it works the same way as for FMB series, thus setting motion_detection_sas moved to motion_detection with bitmask as sources.

baja

Minor updates:

Dallas temperature sensor parsing suppression added for values 850, 2000, 3000, 4000, 5000 (it was enabled for 3000 only)
Bugfix: the response from the device is added to command result for all commands
TLS setting added

baja

Minor updates:

manual CAN elements parsing added for FMB640 series as manual.can.ID and manual.can.extended
several bugfixes in parsing for telmetry data and command responses

baja

New custom command added. It's schema is super simple: any of:

field text (in this way command may be also sent as SMS)
field hex to send binary data as codec12 connection command

namo

Teltonika protocol updated: SuperSoco I/O elements are supported for Teltonika TFT100.
Mapping of TFT100 AVL IDs into flespi parameters is below:

855 Power - supersoco.power.status, boolean
856 Current Trip Range - supersoco.current.trip.range
857 Total Trip Range - supersoco.total.trip.range
858 Battery Capacity - supersoco.battery.capacity
859 Low Voltage - supersoco.voltage.low.status
860 High Temperature - supersoco.temperature.high.status, boolean
861 Upload Time - supersoco.upload.time
862 Moving Abnormal - supersoco.moving.abnormal.status, boolean
863 Range - supersoco.range
864 Lock Status - supersoco.lock.status, boolean
865 Vehicle FW version - supersoco.fw.version
866 Total Range - supersoco.total.range
867 Battery Energy - supersoco.battery.energy
868 Power System Error - supersoco.power.system.error, string
869 Power Train Error - supersoco.powertrain.error, string
870 Instrument System Error - supersoco.instrument.system.error, string

baja

Bugfix schedule:
We found a bug in parsing device SIM card ICCID based on Data sending parameter IDs 11 and 14. For some values our parser may add extra 0 symbols in the middle of ICCID value.
The fix will be installed in 2 weeks - January 4th 2022. The result of the fix will be the possible change in gsm.sim.iccid parameter if it is reported by Data sending parameter IDs 11 and 14.
There is another way to obtain gsm.sim.iccid parameter - to send getimeiccid action command. The result will be stored correctly, as the response is sent by the device as an ASCII string. By the change in gsm.sim.iccid parameter you may see if you will be affected by the change.
There are ways to make the smooth transition in this situation, you can ask for help in flespi chat for guidance.

The following update will also remove Deprecated codec12 setting. It is not used by the customers anymore according to our logs, because there is a possibility to send custom command in the device interface.

baja

baja fix installed

namo

Teltonika protocol updated, the following changes are introduced:

Bug in parsing of data sending parameter ID 241 Active GSM Operator is fixed.
Previously it was stored as gsm.mnc parameter; now it's splitted into parameters:
- gsm.mnc - mobile network code (last 2 digits in decimal representation)
- gsm.mcc - mobile country code (first 3 digits in decimal representation)
Added new action settings under CAN tab:
- lvcanunblockengine - Toggle CAN-CONTROL to unblock engine
- lvcanblockengine - Toggle CAN-CONTROL to block engine

Bitwise parsing of CAN Control State Flags P2 is supported.
This is a replacement for the parameter can.lvc.module.control.bitmask that will be removed in a week, 21-Feb-2022.
The mapping into flespi parameters is the following:
- Byte 0:
  0x01 STOP - can.stop.indicator.status
  0x02 oil pressure / level - can.oil.pressure.indicator.status
  0x04 coolant liquid temperature / level - can.coolant.level.low.indicator.status
  0x08 handbrake system - can.handbrake.indicator.status
  0x10 battery not charging - can.battery.indicator.status
  0x20 AIRBAG - can.airbag.indicator.status
  0x40 EPS (electric power steering) - can.eps.indicator.status
  0x80 ESP (electronic stability program) - can.esp.status
- Byte 1:
  0x01 CHECK ENGINE (MIL) - can.check.engine.indicator.status
  0x02 lights failure - can.lights.failure.indicator.status
  0x04 low tire pressure - can.tire.pressure.low.status
  0x08 wear of brake pads - can.wear.brake.pads.indicator.status
  0x10 warning - can.warning.indicator.status
  0x20 ABS - can.abs.failure.indicator.status
  0x40 low fuel - can.fuel.level.low.indicator.status
  0x80 maintenance required - can.maintenance.required.status
- Byte 2:
  0x01 ESP indicator - can.esp.indicator.status
  0x02 glow plug indicator - can.glow.plug.indicator.status
  0x04 FAP - can.soot.filter.indicator.status
  0x08 electronics power control - can.electronic.power.control.status
  0x10 parking lights - can.parking.lights.status
  0x20 dipped headlights - can.low.beam.status
  0x40 full beam headlights - can.high.beam.status
  0x80 front foglights - can.front.fog.lights.status
- Byte 3:
  0x01 ready to drive - can.ready.to.drive.indicator.status
  0x02 cruise control - can.cruise.status
  0x04 automatic retarder - can.automatic.retarder.status
  0x08 manual retarder - can.manual.retarder.status
  0x10 air conditioning - can.air.condition.status
  0x20 rear foglights - can.rear.fog.lights.status
  0x40 passenger's seat belt - can.passenger.seatbelt.indicator.status
  0x80 driver's seat belt - can.driver.seatbelt.indicator.status

baja

Action command setdigout1 added for MSP500 device type

baja

We've detected discrepancy in our parameter naming regarding LLS sensors. LLS sensors send just only some measured value, not the volume of counted liquid. So the parameter has to be postfixed with .value instead of .volume. Changes are the following:
liquid.sensor.fuel.volume to lls.value
liquid.sensor.fuel.temperature to lls.temperature
escort.liquid.sensor.temperature to escort.lls.temperature
escort.liquid.sensor.fuel.level to escort.lls.value
escort.liquid.sensor.battery.voltage to escort.lls.battery.voltage

Both versions of the parameters will be registered for 1 month until 5th April 2022. Then old naming will be removed

Small change rolled out together with the update:

bugfix in trip_scenario setting reading
can.lights.hazard.lights.status is parsed inside can adapter state flags

baja

baja together with the changes on 5th April some minor updates will be installed:

tacho.driver.card.code.1 and tacho.driver.card.code.2 parameters will be converted from HEX to ASCII representation escaping non-printing characters
TAT100 parameter gsm.lac.1, gsm.cellid.1 and gsm.signal.dbm.1 will be renamed to not having index 1 in the end
GPS Rollover check will be applied on messages registration for EoL devices

baja

baja update installed

namo

Teltonika protocol is updated: processing of result of custom command is fixed.

baja

Bugfix: Data sending parameter ID 107 stored as can.fuel.consumed is now stored as can.tracker.counted.fuel.consumed because can.fuel.consumed is parsed from parameter id 83. The renamed has been accomplished to avoid parameter name collision if both IDs are reported by the device.
Green Driving setting added to OBD devices

baja

The protocol will be affected by the change in type of parameters gsm.mcc and gsm.mnc to be installed in 2 weeks - May 23rd, 2022: both parameters that now have type "string" will be stored as "number". The possible leading zeroes in MNC will be ignored (e.g. the value "01" will be stored as 1).

baja

codec12 channel level command scheme was updated with optional wait_response boolean field. By default it is true, if you specify the field value as false, then the command will be treated as executed right after being sent. As a side-effect of such behavior, the command response (if any) will be stored as payload.hex or payload.text parameter.

baja

Device types added:

baja

TST100 model update:

sciap setting added (tab Actions -> E-Scooter's firmware force update )
parsing updated: ID 340 is parsed to parameters pcb.firmware.enum (first 4 bits) and software.version (3 digits by 4 bits)
parsing updated for IDs:
370: External battery FW version [1] to paramter external.battery.firmware.version
371: Internal battery FW version [1] to paramter internal.battery.firmware.version
372: Instrument panel FW version [1] to paramter instrument.panel.firmware.version

namo

Teltonika protocol is updated: parsing of PARAM ID 517 Security State Flags P4 is fixed. Actual for devices FMB series with CAN Adapter support.
The following flespi parameters are registered for Security State Flags F4:

Byte0, Bits 0,1 - can.connection.state.1
Byte0, Bits 2,3 - can.connection.state.2
Byte0, Bits 4,5 - can.connection.state.3
Byte1, Bit 8: 0x01 – ignition on - can.engine.ignition.status
Byte1, Bit 9: 0x02 – key in ignition lock - can.ignition.key.status
Byte1, Bit 10: 0x04 – webasto - can.webasto.status
Byte1, Bit 11: 0x08 – engine is working - can.engine.working.status
Byte1, Bit 12: 0x10 – standalone engine - can.standalone.engine
Byte1, Bit 13: 0x20 – ready to drive - can.ready.to.drive.indicator.status
Byte1, Bit 14: 0x40 – engine is working on CNG - can.cng.status
Byte1, Bit 15: 0x80 – work mode (0 – private, 1 – company) - private.status
Byte1, Bit 16: 0x01 – operator is present - can.operator.present.status
Byte2, Bit 17: 0x02 – interlock active - can.interlock.active
Byte2, Bit 18: 0x04 – handbrake is active - can.handbrake.status
Byte2, Bit 19: 0x08 – footbrake is active - can.pedal.brake.status
Byte2, Bit 20: 0x10 – clutch is pushed - can.pedal.clutch.status
Byte2, Bit 21: 0x20 – status of the hazard warning lights switch active - can.lights.hazard.lights.status
Byte2, Bit 22: 0x40 – front left door opened - can.driver.door.status
Byte2, Bit 23: 0x80 – front right door opened - can.passenger.door.status
Byte3, Bit 24: 0x01 – rear left door opened - can.rear.left.door.status
Byte3, Bit 25: 0x02 – rear right door opened - can.rear.right.door.status
Byte3, Bit 26: 0x04 – trunk door opened - can.trunk.status
Byte3, Bit 27: 0x08 – engine cover opened - can.hood.status
Byte3, Bit 28: 0x10 – charging wire is plugged - cable.connected.status
Byte3, Bit 29: 0x20 – battery charging on - battery.charging.status
Byte3, Bit 30: 0x40 – electric engine is working - can.electric.engine.status
Byte3, Bit 31: 0x80 – car is closed with factory remote control - can.car.closed.remote.status
Byte4, Bit 32: 0x01 – car is closed - can.car.closed.status
Byte4, Bit 33: 0x02 – factory installed alarm is active - factory.alarm.actuated.status
Byte4, Bit 34: 0x04 – emulated alarm is active - factory.alarm.emulated.status
Byte4, Bit 35: 0x08 – signal of closing with factory remote control was sent - can.car.closing.remote.event
Byte4, Bit 36: 0x10 – signal of opening with factory remote control was sent - can.car.opening.remote.event
Byte4, Bit 37: 0x20 – rearm signal was sent - can.rearm.signal.event
Byte4, Bit 38: 0x40 – trunk was opened with remote control - can.trunk.opening.remote.event
Byte4, Bit 39: 0x80 – CAN module is in SLEEP mode - can.module.sleep.mode
Byte5, Bit 40: 0x01 – signal of closing with factory remote control was sent 3 times - can.car.triple.closing.remote.event
Byte5, Bit 41: 0x02 – parking is active - can.parking.status
Byte5, Bit 42: 0x04 – reverse is active - can.reverse.gear.status
Byte5, Bit 43: 0x08 – neutral is active - can.neutral.gear.status
Byte5, Bit 44: 0x10 – drive is active - can.drive.gear.status
Byte5, Bit 45: 0x20 – engine lock active - can.engine.lock.status
Byte5, Bit 46: 0x40 – request to lock the engine (activation after attempt to restart the engine) - can.request.engine.lock.event
Byte5, Bit 47: 0x80 – factory armed - can.factory.armed.status
Byte6, Bit 48: 0x01 – roof opened - can.roof.opened.status