This is the original issue that was raised internally to TTI:
You’ll note that the v3 stack is already seeing timeouts (not just TTI sysops, I have seen timeouts on the console as well as in WebHook packages for <1k decoders) so some correction was inevitable. This happens often enough on v2. The bottom line seems to be that payload formatting is a convenience function that should not be relied upon for production deployment, ie, decode the raw payload on your own servers.
I really like the template system you’ve got for defining the byte stream and the corresponding value label but that and the flexibility on the number of decimal places for different sizes sure does add up.
I’m finalising some examples on doing this with Python & PHP. It is entirely feasible to use a JS engine to allow the use of a JavaScript decoder from other languages, I guess it all depends on what the users end-point is - ie WebHook or MQTT and how it’s hosted.
How do ESPEasy users general get their data from TTN? As a WebHook would require access to a full-time internet facing web server, I guess MQTT would be good to run on a machine or Pi or similar. Perhaps a worked solution in Python that can output the data in a number of different ways would help?
PS, there is also some discussion on the payload formatters included in the device registry which you may want to look at.