Got the same issue here, but deleted the GW on V3 before reading this post.
In 2019 I left 3 TTIG waiting for application, I thought changing backend was implemented since it was in the description of the product and announced on forums when I bought them. That’s a pity in 2021 almost 2 years later it’s still not possible, it would have wiped out the V3 problem if the TTIG firmware was updated before.
Here the description on RS site for TTIG can connect to any network backend of choice it was already present in 2019 and still as today. TTIG was an awesome idea with a awesome price, but to be honest with so much software limitation, it’s useless for my customers and I.
In the V3 Console, the Gateway EUI can be edited (changed later) but Gateway ID cannot. After deleting a gateway in V3 the Gateway ID cannot be (re)used again, but I suspect the Gateway EUI can.
You can probably add a new gateway on V3 using the EUI of your previously deleted gateway (already now). However, TTIG traffic is currently still routed to V2 and not to V3 yet. So you will have to wait until later this year when TTIG data will be routed to V3, before you can use the TTIG on TTN V3.
Say I have an existing application A2 on TTN V2 with end device D (using OTAA) which I want to (manually) migrate to TTN V3.
I therefore create a new application A3 on TTN V3, add a new end device D’ to A3 and enter the exact same AppEUI, DevEUI and AppKey as used for end device D on V2.
There are two gateways, one is connected to V2 and the other is connected to V3. (Traffic from TTN V2 gateways on the backend will also be routed to TTN V3.)
I now switch on the device and it will start sending a join request.
If the device joined on V2 traffic apparently will be send to application A2, and if joined on V3, traffic will be send to application V3.
To which environment will the device join V2 or V3 and why?
Which aspects play a role here?
Will the device always join on V2 because that somehow has priority over V3?
Does the device need to be deleted from V2 first before it will join V3?
How is routing between V2 and V3 implemented?
When is traffic routed from V2 to V3 and when not?
Will traffic only be routed to V3 if it cannot be processed on V2?
After shutting down my V2 gateways, the device joined to V3 and messages were delivered there.
I was hesitant to remove my devices from V2, but now I’m sure it’s working on V3, I can safely delete them from V2.
Do you mean it depends on which gateway receives the join request first?
If I’m not mistaken, normally only one gateway will send the Join Accept.
But maybe both V2 and V3 will each send a join accept here. In that case it would depend on from which gateway the device receives the Join Accept first.
I tried to make sense from the information in the V3 Live Data views (gateway, application and device). When the device joins to V2 instead of to V3, there is still a lot of information appearing on the V3 console, but I don’t understand all listed events yet. Several are new for V3.
I noticed something unusual in the V3 console:
In the gateway log each uplink message is received once, but forwarded twice.
The application and device logs show that both message are then received, but one of them is dropped because they are duplicates and the other is processed successfully.
Strange enough the SNR values (not shown below) of duplicates messages are different.
Did anyone else observe this behavior?
I noticed that messages arriving from other gateways (other than my V3 gateway) in V3 Console Application and Device Live Data views are shown as separate ‘Received data message’ events. This can also be messages coming from V2 gateways via the packet broker.
(I’m not sure if above is true for messages arriving via the Packet Broker only or for all gateways. I am unable to check because I currently only have a single V3 gateway.)
The duplicate messages described below may be caused by one coming from my V3 gateway (my V2 gateways were shut down during the test) and the other possibly from another (V2) gateway ‘nearby’.
I unfortunately have checked the event details for below messages (events).
If so, that does still not explain why each message is forwarded twice as show in my gateway’s Live Data view.
Situation: only V3 gateway active and testing with a single end device that is registered in a V3 application:
For each uplink message the following appears in the gateway, application and device console logs:
Gateway Live Data view for each uplink message shows: (latest on top, all three have same timestamp)
Forward uplink message
Forward uplink message
Receive uplink message
Application and Device Live Data for above show: (latest on top, all have same timestamp as above)
I have also tried connecting my TTIG gateway to The Things Network V3 stack without success. I can understand that I have to wait a bit in now. However, I have another problem. I can not delete my gateway again ??? Can anyone help with that ?? Thanks in advance
@Jeff-UK was not present this year, I’m working on too much projects on the same time for my brain
About the LoraGW setup I can help of course, and even better, open the repo for you so you can publish directly (without fork and all other) just let me know.