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.
[Changelog] teltonika protocol
7 days later
- Edited
As described in previous post we do major refactoring here. The list of updates installed today:
- Edited
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)
19 days later
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.
- Edited
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.
5 days later
- Edited
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
...}A bug fixed with towing.alarm.status parameter. Parsing was inversed. Now the parameter is registered as true when alarm for towing is active, false - when device is steady and there are no towing alarm detected
6 days later
Parameters renaming:
can.relative.fuel.level.pressure is renamed to can.relative.fuel.rail.pressure
can.direct.fuel.level.pressure is renamed to can.direct.fuel.rail.pressure
Old parameters will be removed 17 Dec 2019.
7 days later
a month later
baja We are remastering work with BLE beacons. Now instead of registering in the way presented on December 19, we will register ble beacons data as following:
{...
"ble.E2C56DB5DEADBEEFB060D0F5A71096E012349876": {
"rssi": -79
},
"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
...}
Both new and old formats will be present until February 14.
15 days later
baja We are remastering the remastering of BLE beacons work. After long discussions with our customers we decided that the best format to represent BLE beacons data will be
"ble.beacons":[{"id":"01020304-0506-0708-090A-010203040A0B","rssi":-27}]
instead of old one
"ble.beacons":{"01020304-0506-0708-090A-010203040A0B":{"rssi":-27}
and inconvenient separate parameter variant
"ble.0102030405060708090A010203040A0B": {"rssi": -27}
Old variant will be removed tomorrow (February 19) 10:00 UTC.
Along with it we will remove outdated parameters:
ble.asset.tag.code
ble.asset.rssi
ble.asset.battery.voltage
ble.sensor.temperature
that were registered under the Teltonika AVL ID 385
6 days later
The parsing for GNSS status AVL ID changed. New parameter gnss.state.enum which contains actual tag value added
FMB series - tag 69:
0 - GNSS OFF
1 – GNSS ON with fix
2 - GNSS ON without fix
3 - GNSS sleep
FMB 640 series tag 71:
0 - GNSS OFF
1 - GNSS ON, no GPS antena
2 - GNSS ON, without fix
3 - GNSS ON, with fix
4 - GNSS SLEEP
5 - GNSS Overcurrent/protect state
FM3612 series tag 69:
0 – GPS module is power off.
1 – GPS antenna is disconnected.
2 – Working, no GPS FIX.
3 – Working, GPS FIX acquired.
4 – GPS sleep.
5 – GPS antenna is short circuited.
The parsing change will affect gnss.status, position.valid, gnss.sleep.mode.status, gnss.antenna.short.circuit.status and gnss.antenna.status parameters.
Parameter can.vehicle.vin will be renamed to vehicle.vin
Both parameters will be registered for 2 weeks until 10 March, 2020. Then can.vehicle.vin will be removed
14 days later
A bug fixed with ACK server response for codec12 messages. flespi will not respond with 4-byte ACK for codec12 responses from devices for GPRS commands from server.
Parameter can.vehicle.vin removed
6 days later
Parameter can.fuel.rate will be renamed to can.fuel.consumption
Both parameters will be registered for 2 weeks until 30 March, 2020. Then can.fuel.rate will be removed
