I am trying to move some of mye Dragino LHT65 sensors from v2 to v3 and want to try the repository payload formatter. It looks like the LHT65 is in the repository lorawan-devices/vendor at master · TheThingsNetwork/lorawan-devices · GitHub so I am thinking The Stack would identify my sensor as a Dragino LHT65, use the vendor decoder and forward the decoded payload to my endpoint. But I get a “No version identifiers for device” in the live data and when trying to test the decoder on the device view in the console.
Do I need to set a version identifier? Or am I just not understanding the repository formatter?
Update: there was no DL formatter in the device repository. I set the default JS on the app device payload and the error message disappeared, and DL succeeded.
Hi, i’m facing similar problem. I created a decoder for the device, and on the Application console trying it out looks like it works. But i get the Error on the live log “Decode uplink message failure” and the “No version identifiers for device”, next to it i get the uplink message with the payload in hex visible and after that i can see the uplink messages but without any payload. Any suggestion on what i’m missing in configuration?
This isn’t really a similar problem which was originally about a missing PF in the repository - whereas you are saying the one you created is not working.
We are going to need a whole pile more info - like what your device is, how you registered it (as it sounds like it’s trying to pick up a repository PF) and what your created decoder is, plus some sample data.
Sure, the device is engineered by my collegue, we are using Rpi Pi Pico + LoRa HAT Raspberry Pi shield based on SX1262. The registration is by ABP, with all info generated by TTN apart of DevEUID, which we get from device itself. Created decoder is:
function decodeUplink(input) {
var hexStr = byte2HexString(input.bytes);
var data = payloadParser(hexStr);
return {
data: data,
warnings: [],
errors: []
};
}
/**
* This is the function to create a payload object by decoding hex string
* @param {String} hexStr
* @return {Data}
*/
function payloadParser(hexStr)
{
var data = {};
data.payload = hexStr;
data.node_id = id2Int(hexStr.substr(0, 4));
data.temp = temp2float(hexStr.substr(4, 4))/100;
data.hum = id2Int(hexStr.substr(8, 4))/100;
data.press = id2Int(hexStr.substr(12, 4))/10;
data.AQI = id2Int(hexStr.substr(16, 4))/10;
data.CO2 = id2Int(hexStr.substr(20, 4));
data.VOC = id2Int(hexStr.substr(24, 4))/100;
return data;
}
function byte2HexString(bytes) {
var retHexString = "";
for (var i_b = 0; i_b < bytes.length; i_b++)
{
retHexString = retHexString.concat(("0" + (Number(bytes[i_b]).toString(16))).slice(-2).toUpperCase());
}
return retHexString;
}
function hex2string(hexx) {
var hex = hexx.toString();
var str = "";
for (var j = 0;
(j < hex.length && hex.substr(j, 2) !== "00"); j += 2)
str += String.fromCharCode(parseInt(hex.substr(j, 2), 16));
return str;
}
function id2Int(hexstring){
var bytes = [];
bytes[0] = parseInt(hexstring.substr(0, 2),16);
bytes[1] = parseInt(hexstring.substr(2, 2),16);
var num = bytes[0] | bytes[1] << 8;
return uintToInt(num, 16);
}
function uintToInt(uint, nbit) {
nbit = +nbit || 32;
if (nbit > 32) throw new RangeError('uintToInt only supports ints up to 32 bits');
uint <<= 32 - nbit;
uint >>= 32 - nbit;
return uint;
}
function temp2float(hexstring) {
var bytes = [];
bytes[0] = parseInt(hexstring.substr(0, 2),16);
bytes[1] = parseInt(hexstring.substr(2, 2),16);
var sign = bytes[1] & (1 << 7);
var x = ((bytes[0] & 0xFF) | ((bytes[1] & 0xFF) << 8));
if(sign) return 0xFFFF0000 | x;
else return x;
}
Can you add the uplink as a text block like you did for the JavaScript please.
And perhaps check that you aren’t repeating the process already provided by the server - input.bytes is a hex array, so converting it to a string representing the bytes and then slicing it and then processing it as a number is a bit convoluted and as strings aren’t normally sent, there may be some functions you are using that aren’t available.
i’ll take a look on all your suggestion. I get the inspiration from one of the commercial sensors decoder (pepperl and fuchs) we get and it seems to works fine for that type of messages. But for sure the format is a bit different from what we are sending.
They are recommendations from the people that write TTS, combined with the person that does the integration / payload formatter training videos. And it’s not currently working for you so I don’t think it’s unreasonable to consider the forum expertise over Pepperl & Fuchs.
Search the forum for the fun people have with floating point. The rest of the code changing the byte array in to a string and then cutting it up is just to weird to think about.
And you may exceed the timeout with all that unnecessary processing and not get the payload decoded at all.
the playground looks like accepting the code and return me the values i’m expecting… the problem is what the real-time decoding gave me an error and after that it stops me to show the raw payload, this seems to be very strange to me.
i do not now what was the problem but with the last version i can see the data decoded… i didn’t change anything in the configuration, just some adjustments in a code:
function decodeUplink(input) {
var hexStr = input.bytes;
var data = payloadParser(hexStr);
return {
data: data,
warnings: [],
errors: []
};
}
/**
* This is the function to create a payload object by decoding hex string
* @param {String} hexStr
* @return {Data}
*/
function payloadParser(hexStr)
{
var data = {};
data.payload = hexStr;
data.node_id = returnInt(hexStr, 0);
data.temp = intToInt(hexStr, 2)/100;
data.hum = returnInt(hexStr, 4)/100;
data.press = returnInt(hexStr, 6)/10;
data.AQI = returnInt(hexStr, 8)/10;
data.CO2 = returnInt(hexStr, 10);
data.VOC = returnInt(hexStr, 12)/100;
return data;
}
function returnInt(bytes, idx){
var num = bytes[idx] | bytes[idx+1] << 8;
return uintToInt(num, 16);
}
function uintToInt(uint, nbit) {
nbit = +nbit || 32;
if (nbit > 32) throw new RangeError('uintToInt only supports ints up to 32 bits');
uint <<= 32 - nbit;
uint >>= 32 - nbit;
return uint;
}
function intToInt(bytes, idx){
var sign = bytes[idx+1] & (1 << 7);
var x = ((bytes[idx] & 0xFF) | ((bytes[idx+1] & 0xFF) << 8));
if(sign) return 0xFFFF0000 | x;
else return x;
}
LoRaWAN library for Pico from Github; lorawan-library-for-pico/src/lorawan.c at main · ArmDeveloperEcosystem/lorawan-library-for-pico (github.com)
after reflashing the device and without any decoding on TTN side i saw 4 messages only on Application layer and then it stops recieving anything. The counter is incrementing from 4 to 7.
it is also very confusing the information i’m seeing on the Gateway tab and Application. i can see some frames coming over there, but nothing on application side. is there some configuration i’m missing?
Yes, but more essentially missing is the knowledge of difference between ABP and OTAA and why it’s preferable to use OTAA due to this exact issue.
If you look at the Learn section (top of this page) and search for ‘ABP frame counters’ on the docs and this forum you’ll get lots of info. The docs will point you to the relevant settings to change.
it’s true what the best way is to use OTAA, but still if exist ABP registration and it is allowed on TTN, i do not understand the behavior. Reading the posts and the theory it is clear what for ABP if u reset the node, the frame counter will restart and the frames suppose to be ignored by the Network server, But in my case the behavior is not like this. I still get the first frames and after that they are coming in randomly, but i can’t see these frames in specific part of the TTN dashboard view. I see some frames on GW console and some of them on generic part of application console. But when i get into the specific device console, there is no live frames. i can share the json from all 3 console if u can help me to understand?
