Hello,
I’d like to test a specific codec implementation on chirpstack v4 fresh install.
Unfortunately no section of the Web interface gives me the ability to “simulate uplinks” on a provisioned “virtual” sensor, or its profile template.
In advance many thanks for your advices
Hi Pierre. Welcome to the forum!
As an industry standard and also good practice, I strongly suggest you perform your tests outside of chirpstack. Assuming you have the expected codec result of a particular uplink payload, using a test framework like JEST makes testing a breeze.
Then you can automate your tests for each and every codec use-cases and when everything is ok, import the codec into chirpstack.
Hope this helps.
Hello,
Thanks for this advice.
But notice the codec I’d like to use is working on different infrastructures like TTN LiveObjects, Tago.io, or others. But often it needs some sligth “calling” adaptations or JS versions adaptations.
We do not use every existing infrastructures, but some customers relate us problems to install our " TS013-1.0.0 Payload Codec API" compliant codecs on chirpstack maybe due to embeded JS version in Chripstack (wich one exactly ?), and some “import” keywords at the end ??
So my objective, was to try it by myself, and after installing the chirpstack on a VM, I could not access aywhere to a “decoding test” HMI wher you can input manually a frame then test a custom js codec ?
BR
Pierre-emmanuel
Hello all,
Still no suggestion about the way to test codec integration on a fresh install of chirpstack server without any gateway or sensor configured ? I mean just manually sending “fake” uplinks ?
Notice that our codec are operatioal and available for download with an API compatible with " TS013-1.0.0 Payload Codec API". However it seems that some customers encounter difficulty to integrate them on chirpstack server due to problems like “JS version” or “JS Size” …
.
Any advice welcome.
Many thanks
Pierre,
I better understand the issue you’re having now. I remember we had issue too when importing some codecs into CS due to the way JS code execution is integrated (QuickJS supporting ES2020 spec). Unfortunately not much I see to be done here except having a device hands-on and perform some test.
Perhaps @brocaar or others can chime him and give their takes about this.
I think adding a codec test feature (with as input HEX or BASE64 encoded string and as output the JSON) would make a lot of sense 
It might be something I will start working on, but I’m also welcoming a pull-request for this.
Thanks for your answers.
On previous version of CS we discovered that ES5 compliant interreter was used. Then we adviced (blindly) a customer using UG56 gateway, to use these tools to change our codecs back to ES5 :
But with new chirpstack (using ES2020 compliant QuickJS) our current LoraWAN TS013 compliant codecs should work, but still, size of codec or an “exports” at the end can make the integration fail. So 2 questions: