Teltonika legacy compatibility

Custom Deployment
1

In reference to the TeltonikaLegacyCodecSupport I have noticed that the data related to the AVL ID #385 (beacon) are passed to the MQTT server as floating or integer instead of HEX as it should be.

Do you think it would work if I modify the code as follows:
function processAvlData(avlData: AVL_Data) {
var params: { [avlid: number | string]: number | string } = avlData.IOelement.Elements;

var parsedParams: { [avlid: number | string]: number | string } = {};

parsedParams[“latlng”] = ${avlData.GPSelement.Latitude},${avlData.GPSelement.Longitude};
parsedParams[“ts”] = moment(avlData.Timestamp).valueOf();
parsedParams[“alt”] = ${avlData.GPSelement.Altitude};
parsedParams[“ang”] = ${avlData.GPSelement.Angle};
parsedParams[“sat”] = ${avlData.GPSelement.Satellites};
parsedParams[“sp”] = ${avlData.GPSelement.Speed};
parsedParams[“evt”] = ${avlData.IOelement.EventID != undefined ? avlData.IOelement.EventID : 0};

for (let key in params) {
if (parseInt(key) === 385) {
// Handle Beacon as HEX
parsedParams[key] = 0x${params[key].toString(16)};
} else {
parsedParams[key] = params[key];
}
}

return { state: { reported: parsedParams } };
}

I have just inserted the condition related to the key 385

2

Good afternoon @glodea !

There are some sporadic issues with AVL data not being cast properly. It’s a difficult thing to debug because of the thousands of AVL IDs that could exist. I’d like to eventually come up with a more stable solution to that.

I don’t see why your code wouldn’t work, but I’m not familiar with how typescript casts variables to hexadecimal, so you’ll have to test it out and see if it works :sweat_smile:

Best of luck!

Panos

3

Hi Panos,

Thanks for the reply. I will try my luck and let you know :wink:

Cheers,
Antonio

1 Like
4

Still one question: I guess the definition of the data type in the Teltonika parameter data and Teltonika parameter map, like:
“385”: {
“propertyIdInAvlPacket”: 385,
“propertyName”: “Beacon”,
“bytes”: “Variable”,
“type”: “HEX”,
“min”: “0”,
“max”: “1024”,
“multiplier”: “-”,
“units”: “-”,
“description”: “List of Beacon IDs”,
“hwSupport”: “FMBXXX Expand”,
“parameterGroup”: “Permanent I/O elements”
},

is not used then?

5

It is used, it’s just that Teltonika is not very strict with the naming conventions in their forums, so I have had to “hardcode” some of the defined data types to be parsed;

In this function, I try to parse any given value as a Double, and if that doesn’t work, I basically return it as a String. It’s very easily adaptable, it’s just that it hasn’t really been needed.

The issue with hexadecimal is that, it’s more beneficial for the string representation of the hex value to be shown instead of the parsed base-10 integer value. An exquisite example of that is AVL ID 143 (in for example the FMC650), that signifies the door status. First of all as you can see they chose to denote it as a decimal here, but still, it’s much easier to understand which door is open and which door is closed using the hexadecimal representation. Due to this situation, and many others, I’ve decided to not parse HEX as a value, as it could remove from the substance of the value itself. If Teltonika was a bit more standardized when it came to their AVL ID lists, it’d be much easier to perform operations like these.

If you feel that it would be simpler for you to simply parse all hexadecimal values as numbers, you can edit that snippet there and depending on the parameter.type, parse the value differently.

I hope that answers some questions!