Hey y’all; for those migrating devices off the public community network or private network, please wait for the 3.0.0 tagged release that will be available shortly. There will be some breaking changes in the database so you’d need to throw away the local databaseThis is very inconvenient but this was the last opportunity to do this. From 3.0.0 on, the first breaking storage and API change that we can’t migrate will be V4
It is a great contribution of TTN to open source the V3 stack. But you guys have put in a lot of hard work. When you make the source code open source, then many people will establish their own private server in the gateways and will no longer want to use the services of TTI or TTN despite having good internet connection. Will this not cut the revenues of TTI as you are giving all your hard work to community for free?
We need to build a few things for that, most importantly peering (so that all gateways are available in V2 and V3 at the same time) and a V2 compatibility layer around the V3 Identity Server so that V2 services keep working. Then, we start deploying V3 PCN clusters to which you can migrate your applications.
Currently, our first priorities are getting a 3.0.0 tagged release out, fix development tooling and finish the Console.
I think V3 PCN clusters become available in preview in May.
No, you need to set that up yourself for the time being. We’re gonna do that, but we’re only going to do that right, i.e. with peering and the same user accounts, for a smooth experience.
Thanks for raising this.
We believe that there is no commercial value in a proprietary LoRaWAN stack. It is a solved problem. There are other open source LoRaWAN initiatives too. Note that all successful development tools (web servers, databases, frameworks, compilers, IDEs, etc) are open source. Offering a proprietary LoRaWAN server stack is either creating vendor lock-in for no apparent reason, or hiding a mess of a codebase.
When building an open, crowd sourced and decentralized network, we want to do that in a transparent way, i.e. doing it open source. Our stacks have been open source from day 0.
As for the community setting up their own networks; I rather have them use The Things Network Stack V3 for that than another stack. This is because V3 is built for the future, scalable, and it will support peering with the public community network, so that still it becomes part of the global network. Also, should these private networks one day be migrated to the public community network or to a commercial private network, then no APIs are changed and devices can be migrated seamlessly.
As for our commercial initiative setting up own open source networks; for the context, The Things Industries provides services and proprietary functionality for enterprise use. TTI offers SLA, commercial support, some advanced monitoring and alerting features, a scalable Kubernetes self hosted or private cloud hosted deployment, multi-tenancy, advanced integrations with commercial cloud platforms, an on-premises Join Server with HSM support, etc, then that is where value is added. And here again, if businesses start using the open source distribution but want commercial services later, we can do that seamlessly. Finally, our larger customers are happy that our stack is open source, because it is a more sustainable model (anyone can become a maintainer by forking) and it allows for easy quality assurance and auditing.
We have already implemented Class A and Class C on STM32L072RZ Nucleo board and have verified its functionality on TTN.
We have successfully connected on TTN server with both Class A and C but not sure how to verify Class A or C on the server end (TTN).
Is there any way we can confirm whether data is from Class A or Class C.