I nudged them again and I heard that my team already did so as well. There’s apparently something in the pipeline. We help platforms to get their webhook templates ready, like we did with Datacake, Ubidots and others. We are not on the critical path.
What I meant in TTN V2 to The Things Stack V3 Transition - #52 by johan above is that we have collaborators (access) and contact information. The latter allows for contacting the person. That may be the owner, it may also be the representative or the person living next to the gateway. It doesn’t have to be the owner, or the funder or the sponsor. That is why we probably need three fields: collaborators (access), contact information (send thanks, ask questions) and owner or sponsor (who paid for it).
Is there anything the (a few!) users need to do to lobby or cajole them that might help your case or is that just noise and hinderance if you think progressing in a timely manner
So far I have the following observations / issues:
A test gateway setup using V3 alongside my old V2 gateway.
A test node that used to live in V2 using ABP moved to V3, when I first moved it I saw packets just fine but now I do not see any packets, the node has ephemeral packet count that does not survive a reboot, is there anyway to disable packet counting? I only see “reset” which I presume resets it to 0 not disable the check entirely. Yes I know really I should care more about packet counting, but thats a different discussion.
A bunch of nodes from V2 using OTAA which I have added to V3, these are out in the field so I don’t really want to remove them from V2 until they are working in V3 due to fear of having to hire a cherry picker. I copied the App EUI, Device EUI and App Session Key from V2, I see no packets for these in the application, the V2 gateway receives the packets fine and the nodes still work fine in V2, the V3 gateway however just says… “Host cluster failed to handle message: No device matches uplink” I presume this is because it doesn’t know the device as it was activated against V2 activation server not V3. How do we transition such devices cleanly?
I have tweaked my decoder code for the new 1 parameter style decoder in V3 for the test node and configured MQTT integration. I setup my MQTT client to use the new hostname, username and API key from V3. The MQTT client says it’s connected and I see the following in the applications data feed “Subscribe application”, however I receive no messages, I guess I have the topic wrong, so I tried a wildcard, again no messages. How do we get MQTT to play nicely? - this one is now fixed, topic changes from APP/devices/+/up to v3/APP@ttn/devices/+/up
Unplugging my V3 gateway I do not always see packets for V3 devices forwarded via the V2 gateway, is the forwarding of packets from V2 to V3 buggy or unreliable?
We deploy a number of TTI Indoor Gateways which we do not have physical access to without requesting so from building owners. When the time comes how do we move these with the BasicStation push config stuff? I heard in the Slack chat it currently only works with TTN V2 despite being network neutral in the product details (feels a bit mis-sold).
When will JP & the community have V3 support in TTN Mapper? Will V3 gateways be flagged as V3 only so V2 users can differentiate coverage based on their needs? For now I am shoving my mapping activities for V3 into InfluxDB, hopefully I can replay these into TTN Mapper later.
Some of this is probably my ignorance, but personally I find this transition messy and with a fair bit of heavy lifting and pitfalls. Hopefully soon we’ll get a for dummies transition guide. Any help before then with the above is greatly appreciated.
Reminder for Windows users of lorawan-stack-migrate CLI should not blindly copy paste from readme.md.
export TTNV2_APP_ID=“abc” should be set TTNV2_APP_ID=abc for example.
I deleted my gateway from V2 (was using the UK Digital Catapult ttn.thingsconnected.net) and recreated the gateway and app in V3 in EU1. The application works, although my gateway shows as disconnected in V3. When I inspect traffic routing for the application it appears the gateway is still connected via V2 with forwarding, although I don’t have any listed. Could this be something to do with the fact I was using Digital Catapult initially? Not sure how to resolve? Please can you help.
That is 50% of the work. On the gateway you need to point it to V3 as well. (For TTIG there will be a use interface to do this later this year)
however the moment you move it to V3 all V2 apps won’t get data. All applications of other TTN community member that rely on your gateway will fail. So for now please do not migrate gateways just yet. Give everyone a chance to move their applications (and devices) first.
The idea that has been discussed between the Forum Mods and core staff it to hopefully amend the TTN Map displays in the future to perhaps colour code to differentiate between V2 & V3 Gateways in same way current vs not seen for a time are also coded (before older items aged off Map if not seen for extended period). With lots of others work to be done this may be awhile. For now a bigger issue is to make user migrating GWs or adding new ones in V3 make sure they still show their gw location and make public otherwise wont be seen at all! Default ( I understand) is currently box unticked…so Please All go share! )
what is best process for migrating TTGW (Kickstarter Gw), once finally ready to lift & shift? I may need to go play with that one to see how best done… area well served by other V2’s so little risk to my or others V2 devices & Apps
Thank you for your reply. This makes more sense now, I thought it would automatically pick up the change when associating. No problem, I guess I can reregister the gateway back in V2 and then build my applications in V3. Thanks again.
Is there a specific order to remove apps/devices after moving to v3? Eg : first : remove API keys, then integrations, then …, then collaborators, or will removing the application delete all that (cascaded delete) ?
Here is a quick howto that I use to connect a Kickstarter gateway (KSG) to V3:
Create a gateway in V3.
a. Give a name to the gateway (Gateway ID) no Gateway EUI!
b. Choose the frequency plan “Europe 863-870 MHz (SF9 for RX2 - recommended)” which applies to my situation.
c. Save it
In V3 gateway select API Settings
a. Select Add API key,
b. Provide a name for the key
c. Select “Grant Individual rights”
d. select “link as Gateway to a Gateway Server for traffic exchange, i.e. write uplink and read downlink”
e. click “Generate API Key”
f. Copy the API key to your clipboard (and save it somewhere safe. You cannot read it anymore afterwards)
g. click “I have copied the key”
Connect to the WiFI accesspoint of the gateway with SSID: “TheThings-Gateway-xxxxx”
In the “gateway Settings” menu:
a. At Gateway ID fill in the gateway ID from step 1.a.
b. click advanced options open
c. At account server fill in the URL from V3: https://eu1.cloud.thethings.network/
d. At gateway Key fill in the key from 2.f.
e. click Save.
The KSG will reset connect to V3. The status will change and date will enter at “live data”
As I understand, switching a gateway from V2 to V3 only means changing the server hostname (apart from registering on the V3 system, of course). This will need to administrate the gateway’s setup interface.
Reconfiguring gateways already deployed at locations that are different to reach will in many cases become a serious problem when the time has come, I’m afraid.
I wonder if it would be possible to automatically switch V2 gateways to V3 (of course still using the old packet forwarder) by simply DNS-resolving the old hostname router.eu.thethings.network to the new eu1.cloud.thethings.network (and similar for other regions)? If the V2 world is shut down anyway, the host entry is no longer used, isn’t it?
what is best process for migrating TTGW (Kickstarter Gw), once finally ready to lift & shift? I may need to go play with that one to see how best done… area well served by other V2’s so little risk to my or others V2 devices & Apps 
