I added a new TTIG gateway to The Things Network V3 stack.
It appears to not connect because status keeps showing ‘Disconnected’ in the V3 console.
I’m not sure why. Am I overlooking something?
Steps I have taken:
Setup TTIG
Reset TTIG via reset button.
Set TTIG in setup mode (hold setup button 10s).
Conncect to TTIG WiFi setup menu.
Enter my WiFi SSID and passphrase.
Write down the Gateway EUI displayed at the bottom.
Select Save and Reboot.
Gateway is connected to WiFi. I can successfully ping it.
Add gateway to V3 console
Select ‘Add gateway’
Enter the following details:
Gateway ID (arbitrary string)
Gateway EUI (previously written down)
Gateway Name (arbitrary string)
Gateway Server address: eu1.cloud.thethings.network
Frequency plan: Europe 863-870 MHz (SF9 for RX2 - recommended) [EU_863_870_TTN]
Duty cycle: Enforced (default)
Schedule any time delay: 0.53 seconds (default)
Select ‘Create gateway’.
Gateway was created/added but status stays Disconnected.
I initially made a typo in the Gateway EUI when adding the gateway but corrected this later. I then powered the gateway down and up again just to be sure.
I have several ‘V2 application’ end devices running that frequently generate traffic (no ‘V3 applications’ yet). But status just stays Disconnected.
Assumptions:
This is V3. I assume the V3 Console will not experience the same issues as V2 Console where connection status is unreliable.
Traffic from ‘V2 application’ end devices should be visible as ‘Live data’ for the new gateway (even while not routed to the V2 environment).
Are these assumptions correct?
What could be causing that the gateway status does not show Connected?
That is not possible yet. All TTIGs use a LNS that points them to V2.
Sometime during the next months TTI will provide a web interface where you can point the TTIG to a backend of your choice, however that is not an option just now,
I have the impression that deleting a gateway in V3 will render the Gateway ID useless for future use, but will not render the gateway (Gateway EUI) useless to be used in future.
This is just an assumption though. I have not (yet) verified it in practice.
I wouldnt gamble on assumption at this point - unless willing to sacrifice a device in the interest of furthering human knowledge If you go that route let us all know
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.
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!
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?
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?
[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)
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.
Computer sadly says No! 
).
(I know - you did say you dont do things that way anymore!..)