Hi,
since 2019 our community has used the things network (TTN)'s LoRaWAN backend. See this forum post: Any documentation? - #3 von stefan Additionally we are experimenting with the Helium Backend.
But there are certain limitations of using the TTN Community backend (Network-, Application-Servers and Console) for our community:
1. TTN has Fair Use Limits that are stricter than what is legally required limiting the packages that can be sent per day. Duty Cycle | The Things Network
Fair Use Policy explained - End Devices (Nodes) - The Things Network
To our knowledge those Fair Use Limits are not strictly enforced by TTN right now. But TTN could always enforce them, or change them. We are dependent on TTN.
2. TTN does not give us fine-grained access to the logs of the servers, like operating our own infrastructure would provide.
3. Certain advanced use cases like ADR, Class B devices, Multicast and and others can have more fine grained settings if he had our own backend, or are not possible at all on TTN. (I’m not an expert here).
On the other hand operating and maintining our own LoRaWAN backend based on Chirpstack would take a lot of time - more than we currently have. Additionally it is very likely that we can only process the packets from our communities’ gateways on our own backend, limiting how useful those servers would be.
So we’re making this forum thread to get your feedback if you think it would be worth it, to setup our own backend and experiment with that.
Would you use this? Would you be willing to help us maintain our own backend if we show you how?
Looking forward to your replies! (Gerne auch auf Deutsch, ich weiß gar nicht warum ich das Englisch geschrieben habe)
Markus
- Yes, I want openIOT to maintain its own LoRaWAN servers
- No, I would not use this. E.g. it’s not interesting, useful or not worth the time.
- Something else (please comment below)
0 Teilnehmer
