Is it okay to post (a) a request for contract/consulting work on, for device CODECs, in this forum? And, if so (and you’ve done this), (b) what cost is fair?
My constraints are that my Chirpstack is not on the Internet, but two of my vendors make life difficult (either don’t supply CODECs or only ones for TTN V3 - vendors want us to use their integration & cloud services, which is not an option) and, while I’m sure that ChirpStack will make it easier to repurpose TTN V3 CODECs in the future, currently I am stretched so thin that I can’t keep up.
I need help and am willing to pay for it. I have CODECs that work for some sensors, but not more recent ones (e.g. Laird RTD) and while I have vendor specs and know what to do, I simply don’t have time to brush up on JavaScript, make changes & test. I can supply lender sensors, if need be.
For now I don’t think the forum is a good place to act as a “marketplace”. I have to think about handling these types of requests first
Yes, I’m working on a refactor which will make it a lot easier to re-use codecs. Until then, please know that if the code is executable by the Otto JS engine (used by ChirpStack), it should be fairly easy to create a wrapping function around the TTN / TTI codec to match the function signature.
@brocaar, vendor here - it would be great if we could have a stardardized way to supply ChirpStack codecs to our customers . Curretly we use a docs page with ChirpStack code for cut&paste (like here: LoRaWAN parser - Moire Labs Telemetry Instrumentation Documentation ), but having a better experience in integration would be great as debugging implementation remotely over emails is a real PITA. Even something like Import button which would fill out all necessary information about the device and codec. Something that can be delivered offline.
@sagarpatel that project looks great.
I can say that I’m annoyed by the lack of JavaScript support we currently see with the Otto JS engine. The “stunts” you have to do just to do some simple things has already cost me several hours of work.
This even resulted in the question:
“Should I really use ChirpStack with it’s experimental programming language called “Go” it is build upon as there is not even a usable library for JavaScript or even better TypeScript as the non-strictness of types is also catastrophic in the first place?”
To make the replacement of the JavaScript engine not breaking anything it seems to be an option to extend the DropDown list to choose the JavaScript engine (current “Custom JavaScript codec functions” should be renamed to indicate that his refers to the outdated Otto JS engine).
On updates this can would still default to the Otto JS Engine, so the old scripts still work and if you add a new “Device profile” the Codec would use the new JavaScript engine (=default to goja)
So from the GUI standpoint ChirpStack seems to be already prepared to add another JavaScript frontend as you can already choose from different options.
