This needs to be clarified in documentation. In the meantime, you can find the highlights here: Document how The Things Stack deals with IDs and EUIs · Issue #211 · TheThingsIndustries/lorawan-stack-docs · GitHub
1 Like
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.
2 Likes
Hi @Charles, long time no see!
I think you have not sacrificed it (yet 
).
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.
2 Likes
Hey Charles great to hear from you again - been a while! Looked out for you during TTConf but must have missed you
Was only joking with some of the other Mods yesterday how I could do with you updating these for the V3 Era!? 
(I know - you did say you dont do things that way anymore!..)
All may not be lost wrt your TTIG per Leonel
Hang in there & Stay safe!
What if
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.
Questions:
-
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?
Just my interpretation of all information so far:
It depends on who is received by the node first.
Only time.
yes, when you want to be sure that it joins on V3.
For as far as I know there is no “intelligence” between V2 and V3.
2 Likes
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.
Duplicate messages
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?
[Update]
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)
- Forward data message to Application Server
- Forward uplink data message
- Receive uplink data message
- Successfully processed data message
- Drop data message - Uplink is a duplicate
- Receive data message
- Receive data message
Yes that was what I meant.
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 
Best,
ohlhues
@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.
1 Like
Hi. I tried registering one GW, which is alive in V2 on V3 user interface, but it seems not working. It is TTIG gateway converted to TTOG (plastic housing and external antenna, mounted on my antenna mast). How do I register TTIG gateway on new user interface?
You cant, yet! Per other posts on this subject (forum search is your friend) The TIG relies on a CUPS (server) as it uses BasicStation, and then has some glue/translator s/w to bring the data into V2, which doesnt support Basictation implementations. V3 will support Basistation on TTIG’s natively without the glue but TTF have yet to establish the required V3 CUPS (server) and support. This is due in a few weeks as I understand it. BTW TTOG (The Things Outdoor Gateway) is a thing so if looking for support be careful what you post as they are very definetly not the same thing…what you have is still a TTIG…just in an external housing and with augmented antenna. Note also depending on where you are in the world you need to be carefull addiing an external ant if higher dbi (gain) than the original internal one, unless it is purely to compensate for external cable/connector losses, as higher gain units may lead to your device exceeding local RF EIRP limits, I dont think the TTIG has the flexibility to allow you to dial down the TX power to compensate for this.
hello all,
A slightly more general question regarding TTIG and TTSv3.
I have a TTIG connected to TTNv2, but my devices/sensors are on TTSv3 and everything works fine until now. I have a monitoring project coming up where the intention was to buy a few TTIGs to install them in different locations, with each one serving a few sensors. This is meant to start in May (or earlier) and last for minimum 6 months, but most likely 1 year.
Is TTIG still a suitable option for this, if all the new TTIGs are put now on TTNv2? or will there be a cut-off point in the next months where they have to be migrated to TTSv3, at which point I won’t have access to the gateways and thus potentially they might also stop working (if there is no online/remote way of doing it) and as a results lose data. I understand that the dates set by TTI might not be fully set yet.
I am asking for some advice, as the budget is limited and TTIGs very well priced compared to other gateways. Looking around, I can see that the DRAGINO LP8 gateway seems like a suitable alternative that appears to work with TTSv3 at a slightly higher cost. Anything else seems too expensive.
Any thoughts would be most welcome.
TTIG reconfigure for V3 will be a remote operation. The gateway reads it config from a remote server periodically. When the config is updated on that server it will connect to the newly configured backend.
2 Likes
Just hope before sir TTN decide to shut down V2 clusters:
"The Things Network is shutting down v2 clusters later this year. "
TTN is not stupid and they know everyone will need a way to point the TTIGs to V3.
4 Likes