A few days ago our Android TTNMapper updated to the new build 28. I notice there is one option now to choose between three LoraWAN network servers, amongst one, namely The Things Stack v3.
We have our private TTSv3 at the DingNet of Leuven : https://dingnet-v3.icts.kuleuven.be.
When I want to link our Adeunis Field Tester with the new stack and I fill out the public address with the above instance, there is no MQTT connection possible, allthough the API Keys and authentication are correct (double checked).
Can only eu1.cloud.thethings.industries:1883 be used as lorawan network server (LNS) and no other LNS besides the TTI?
@jpmeijers Did you foresee it or do you have to redevelop with our private LNS server?
I developed the feature against an *.eu1.cloud.thethings.industries instance. It is quite possible that there is a difference between a private hosted version and the cloud hosted one. Most likely the json that is received from your instance is slightly different from the cloud hosted version. I have seen a crash report regarding a v3 json message that could not be parsed.
If you can send me details for a device on your private instance that is transmitting messages, then I can use that to test, debug and fix the issue. Please send me details like this in private, like on the TTN Slack, or email info@ttnmapper.org
Gents, will you make sure not to include mapping for private instances on the public map? That might confuse people no end.
Exception is of course when the private instance connects to the packet broker to make it useable for the community as well.
If mapping data for private networks gets on to ttnmapper.org users of the community network might expect coverage of the community network where there is a private network. So I hope there won’t be any private networks included on the public map.
Ok @kersing , I understand. A couple of our private gateways have the TTN NWS as packet forwarder. So these will appear on the community network so that everyone can see in Leuven if there is TTN coverage.
@kersing no this is not a problem. Even if someone uploads coverage from a private network, the ttnmapper.org backend will filter the data depending on the mqtt broker the data came from.
This is a new feature that was implemented on the backend in conjunction with the added network server support in the android app. For now non-ttn data is dropped, but the plan is to support multiple networks in the future with a “cloud hosted” coverage map under a more generic domain than “ttnmapper.org”.
hi @jpmeijers I am on the pulic TTN V3 now, but I do not see an integration with TTN Mapper. Will there be one? Or must I make it myself with a webhook?
Marc
Unfortunately it isn’t as simple as adding a webhook. TTN Mapper wouldn’t know where the data comes from. We need to get the ticket linked to in the one above solved first.
For now the Android app should work, but I’ve only tested it on private networks, not the public TTNv3 yet. Best is to hang on for a couple of days and if you need to map use TTNv2.
This is something we’re also interested in - am about to rollout 60+ gateways to our County together with a ttnmapper application to map their coverage but it would be great to get everything moved to V3 before doing this to save on work later on.
Sounds good but the problem is that packetbroker is anonymizing the gateway and stripping metadata (location) from the data and makes the data un-useable for TTNMapper. This solution is only usable for applications that do not rely on gateway metadata.