Do the LNS always decode the payload or are there instances where is does not do it?
I meant in the sense that I have associated (configured) a decoder in the console with the end device.
Barring decoder resource issues (which are infrastructural), I don’t see a reason why a valid payload decoder will not be run successfully on a valid payload.
Does anyone have concrete examples/logs?
Detail is there is no guarantee/sla around TTN or associated functions. The decoder activity is overall server load dependent. If your decoder is too long it may time out (depending on its own needs and overall server load), and at one point (around V2-V3 transition IIRC) they (TTI) introduced a limit on how long the decoder could be as a block of code - too tight to start with they then relaxed it a little as caused too many problems. If server is heavily loaded even a ‘short’ decoder may not execute or complete in time and may drop - no sla remember ;-).
Best practice, therefore, is think of the decoder as a nice to have and debugging tool and look to exfiltrate your payloads to you own external database, under your own control and servers/cloud and process/decode/manipulate and manage from there - keeping e.g. Storage integration (again not guaranteed) as a short term buffer and occasional assist if needing to recover a recently (few hours only) missed message, with the decoder helping locally and pehaps to pass on to other integrations (e.g. cayenne dashboard) etc. Often these will not need a local decoder 1st as the decoder can be loaded there or may be a standard item for them (e.g. I have original Semtech/iMST LoRaMOTEs that for the love of me I cant find a decoder to plug into TTN console, but which is then decoded happily at Cayenne as they have the decoder in their own repository)
Answer remains the same.
Assuming you’ve tested it.
Ha, sure, fricking thousands of them, most were on v2 towards the end but it happens on v3 as well - all it means for me is that a test uplink doesn’t get in to a test database. All production stuff is put in the database and then decoded at ‘my’ end - which means I can go back & decode packets after a client has changed their payload in firmware but not the decoders in the infrastructure.
I mourn the day that the PF size was so dramatically increased - it let all those hackers off the hook.
IIRC it was big to start with…then they tried to limit - but too many things broke and too many complained so some relaxation - but not back to how big it used to be - perhaps that is why you see fewer problems (but still see them) than was the case under V2…?
Or when you get an uplink via a WebHook, the only sane way to receive, and it detects that the f_cnt is out of sequence, a sub-process is triggered that looks to retrieve the missing uplink(s) from the Storage Integration.
This occurs so rarely that testing that code is a mess - typically I have to setup a test server so I can turn off the web server running on it to miss a few uplinks. But it’s worth it for those odd moments when something glitches or the database ends up with a field missing whilst someone is hacking on the decoder on the live system.
Probably, but I don’t class them as a problem, they are just part of the landscape. I don’t even monitor for them as there is nothing anyone can do without TTI adding more servers “just because”.
My FireHose console can decode using the same PF so I’ve plenty of options. If the streams didn’t disconnect I could add a couple of graphs and take a dashboard feed from the console output. And then add storage integration as a backstop for missing uplinks. But that would put an un-natural load on the whole lot, rather like those mobile apps that query storage without caching any local copies …
I would still like concrete examples to be able to be certain that this is only a JS decoding engine resource issue.
All we get is the uplink without the decoded element - leaving the console window open won’t work as it will be a miracle / make-work to detect one & then ferret it out the log.
The best I can do is to add a flag to records in my dev databases if there’s no decoded payload but I’m not pushing through the volume to capture examples with any statistical reliability. And then you’d have to grab the logs at your end to see what’s what.
All the other discussion aside, what’s up?
So essentially not a issue for years, since V2.
As with the hand full of end devices I have, stuck in strange places, working on high load gateways (borrowed one, more on this in a few days, thank you sir for your kind assistance) I have never seen it.
Gateways have no bearing on the matter - it’s all about the load on the TTN LNS.