New the things stack v3 supports only payload decoders up to 4k (via webinterface)

[Drasek]

If you try to add the v3 payload decoder to a new application in the things stack v3 from the things network, you will get a error:

"Invalid value of field default_formatters.up_formatter_parameter"

This is the corresponding issue on the things v3 stack repo: https://github.com/TheThingsNetwork/lorawan-stack/issues/4053

If you use the API you can get it to accept up to 16k (which would be fine for us, the decoder is around 10k) and if you already got it in use you can keep it, its just about new applications/decoders.

2 possible proposals:

• try the API and have instructions on this readme how to use it to get the decoder added to a new application in the v3 stack
• try to get the pax-counter integrated in the new device-repo from the things network: https://github.com/TheThingsNetwork/lorawan-devices - cool thing about would be that in the future people building pax-counters could just choose the right device in the backend of the v3 stack and the decoder would be automaticly set. But its a bit of work to get it integrated there. And we have to talk about some wordings (its structured after "vendors" - how do we call "us"?) - i would be willing to help with this and get the yaml files ready to provide them to their repo - but would love to have some things clarified before (wether thats in the interest at all, and than stuff about naming, etc.).

[cyberman54]

Thanks for reporting this issue with TTN v3.

Let us go for the option to integrate paxcounter in the TTN device repo! Two thoughts:

• vendor could be "community", "open source", "no vendor" or something similary
• paxcounter has grown to a ESP32 multitasking multisensor device, counting pax is only one use case. Thus, we maybe should "sell" the device not as a paxcounter but as a more generic thing

Please note that i'm going to release v3.0.0 soon, from current code in development branch. There will be some major changes, e.g. remove wifi/ble sniffing logic from paxcounter repo, code has been moved to a new external "libpax" lib, which shall grow independently from paxcounter. And the deprecated jfrog bintray OTA update service has been exchanged by new homebrewn pax.express service.

[Drasek]

I like the idea about the "community", "open source", whatever vendor name, this would open up a path for other projects as well. Will the paxcounter keep its name in v3.0.0? Or will it change to ESP32-LoRa-Node / ESP-Sensor-Device or something? Would be good to use the repo name for the device name in the new device-repo just to make it clear for users which device to choose.

[cyberman54]

Reponame is not planned to change.

[bsiege]

It seems API is now restricted at the same level...???

--default-formatters.up-formatter-parameter-local-file "Downloads/packed_decodeUplink.js" error:pkg/applicationserver:field_value (invalid value of fielddefault_formatters.up_formatter_parameter) field=default_formatters.up_formatter_parameter correlation_id=5670c43bf58243f283ef23755722cf62 --- error:pkg/applicationserver:formatter_script_too_large (formatter script size exceeds maximum allowed size) size=9858 max_size=4096 Paxcounter was my first test to migrate an application to v3. Failed stylish. Again.

[Drasek]

Added a pullrequest to solve this issue, with a first possible release for the lorawan-device repo from tti.

815

[nottheedge]

any solution available?

[Drasek]

This can be closed i think, after the ESP32-Paxcounter is in the lorawan-device repo and now (v3.14.0) in the things stack community edition.