Thanks for the quick answer.
the idea is that it is standardised - you push in a temperature and everyone knows what’s coming out the other side. It totally stops being useful if you can bend its output to your will.
You can replicate the exact same functionality with a standard hand-rolled payload formatter.
I’m not sure I fully understand the logic here. On one hand, you can bend the payload formatter output to your will with the decoder, and “everyone” would need to adjust to its format. On the other hand, the normalizer output schema is mandatory so that “everyone knows what’s coming out.” But who exactly is this “everyone”? Ultimately, the relationship between the producer and the consumer seems either top-down (I get to choose the format of what will be fed to the consumer — in my case, I am on both sides) or bottom-up (I have to conform to a specific schema provided by the consumer). Why does TTN need to police that relationship between the producer and the consumer?
Maybe I’m missing something here?
For me, having a decoupling between the decoder and the normalizer allows me to retain the vendor-provided decoder as-is (which simplifies maintenance) while handling the formatting in the normalizer. But I don’t quite see the value in necessarily adhering to your schema. As I said, I might be missing a bigger vision — please enlighten me if that’s the case!
real programmers decode on their own platform
This really depends on the overall architecture. Your vision of how to build things may not align with that of the people designing it. As long as the limitations (such as PFs not being 100% guaranteed to run) are understood, choosing to do some or all decoding upstream can be entirely reasonable.
Thanks,
Colin