Thanks again, Nick. I appreciate the context you’ve shared about TTN, TTI, and the challenges around maintaining the platform, as well as your insight into the practical realities of its operation.
That said, I feel like my original questions about the mandatory schema validation for normalizeUplink() and the possibility of more flexibility (e.g., allowing user-defined schemas or bypassing validation) remain unanswered. While I understand the infrastructure and policy constraints you’ve outlined, my intention was to explore practical alternatives or clarify the rationale behind the current design for this feature.
I also want to point out that this discussion isn’t entirely philosophical. In my first message, I referred to a real issue I encountered with the SenseCAP S2120 device and its missing schema fields, which has already been discussed in a related thread. These missing schema elements are exactly what prompted me to start this conversation because they directly impacted my ability to use normalizeUplink() as intended. I believe this issue serves as a tangible example of the kind of challenges I was hoping to discuss here.
I don’t want to muddle the conversation further, but I’m genuinely curious if there’s space for these kinds of changes or if this is simply a “fixed point” in the system. I think this discussion could benefit others as well, so I hope we can keep the dialogue open. Thanks again for your time and perspective!
Hello @rish1,
I don’t want to spoil the fun here, but I think there’s been a misinterpretation of my usage of TTN. The confusion seems to stem from my use of the term “consumers,” which in this context refers to what’s consuming my data (e.g., my Elastic cluster), not people or entities in a commercial sense.
I can assure you that I’m not using TTN in any commercial way—I’m essentially prototyping my own environmental monitoring setup. If this ever evolves into a commercially viable project, I promise we’ll have that conversation when the time comes.
Thanks for understanding!
Colin