What keywords were you entering in the search?
the model of my indoor device, also used google search about ttn gateway and but nothing.
It must be clear to people before putting out these alerts.
Sorry, I literally meant, what actual words did you put in.
We can’t improve / tune the search if we don’t know what keywords to prioritise.
I have a question on the back of this post, which I used to perform a migration on my V2 gateway (RAK2247/Rpi combo) as I had only a handful of devices, and figured it was time before I got further down the road.
I now have the gateway showing in both consoles - though V2 has not shown as active since about the first week of use for the usual reason. There has been much comment (which I may have mis-read) about not deleting gateways from V2 until you’ve proved functionality over in V3 - which I believe I have done, with data showing from nodes despite having no applications set up. Is this sufficient to assume it’s functional in V3 and remove V2?
As a side note, it’s no longer showing in my community map - is this because it’s been “not seen” in V2 since its first day of operation because of the usual problem, or is it because it’s now in V3 and that’s a function not currently working in V3, or is it a 3rd problem where it’s not fully in V3 yet and deleting it from V2 would be a mistake 
?
Why do that? It’s permanent and it is doing no harm where it is.
Your gateway is feeding the v3 stack, so it has no impact on v2 at all.
The community map is still work in progress for v3.
Deleting it from v2 could potentially be the biggest mistake of your life.
Just don’t do it.
Perfect answer, thanks! I’ll leave it as-is.
Hello,
I’d like to migrate my Lorix GW, keeping the ttnmapper coverage.
1rst step is to create a GW under TTNv3
I can copy/paste the gateway ID from v2
In GW name, I’ll put description from V2
But what about GW eui ?
Gateway ID is something you make up to identify it.
Gateway EUI is often referred to as the Gateway ID and is a long string of hexadecimal. It may start eui- in the v2 console but it’s everything after the -
1 Like
However to keep V2 reporting the gateway as up (required for TTNmapper right now) it must be a copy of the V2 gateway ID. So copy the ‘eui-…’ string to the gateway ID in V3 and the … part to the V3 EUI field.
And in the gateway name you should put something easily recognizable. There is a separate description field in V3.
2 Likes
Thanls a lot for your clear answer. I have migrated my Lorix One to V3 using your information. The GW is now seen up in both console (V2 and V3) and traffic is correctly routed 
Hi Jac,
I did the above steps in V3 for a Kerlink gateway which is still active in V2. However I don’t see data appear in V3 and the status is Disconnected.
Did I forget something?
Did you enter the EUI in the appropriate field? And did you restart the packet forwarder after updating the configuration on the Kerlink?
Aha Ok,
Yes, I did the copy, but I didn’t:
- download the new global_conf.json
- replace the existing global_conf.json with the new on the gateway
- restart the gateway
so, a few steps to go 
Thank you
EDIT: It is working now
I also had to change router address in the local_conf.json from router.eu.thethings.network to eu1.cloud.thethings.network
2 Likes
How to Migrate a RAQ831 MQTT Gateway to V3?
Sorry, I have not figured out how to create a new topic.
According to the information, migrating a gateway is absolutely easy. Just create a new gateway in the new V3 cloud and then change the server address.
Unfortunately this does NOT work at all for me.
With the old gateway which connected via MQTT, I used an srv_gateway_key starting with ttn-account-v2.
This is not accepted in any of the fields in the new gateway console.
If I create an API Key in the new console and try to use thisas key, this does not work either.
Somehow I am lost…
-Benoit-
Create the gateway key using the instructions @ Adding Gateways | The Things Stack for LoRaWAN
Then in your gateway configuration point to the V3 server, use eu1.cloud.thethings.network:1881 for server and the gateway ID and gateway key you created. (Adjust eu1 to whatever other cluster you might be using)
Unfortunately that is just not working…
global_conf.json:
"server_address": "eu1.cloud.thethings.network",
"serv_gw_id": "hb9eue",
"serv_type": "ttn",
"serv_gw_key": "NNSXS.***OBFUSCATE***",
"serv_enabled": true
serv_gateway_id is the name I set in the console.
serv_gw_key is the API Key I created.
Result:
Jun 12 19:33:22 loragw loragw[4535]: 19:33:22 ERROR: [TTN] Connection to server “eu1.cloud.thethings.network” failed, retry in 30 seconds
Switching back to the old v2 key and the old v2 server works flawlessly.
Ok, I noticed port 1881 NOT 1883 as it used to be.
I could not find this information anywhere on the website, just checked again.
But changing port to 1881 made my gateway connect.
1 Like
For the record, you should use the ID as set in the console. Not the name. (The two can be the same and then it does not matter which you use of course.)
Excellent. The port number (change) is why I provided the complete connection string. The devil is in the details for these things.
hie i tried to migrate my gateway frome V2 to V3 with no succes. I have followed the subjet claimeing that first delete my V2 gateway from my V2 console (it works ) and trying to create a new gateway to V3 console with the same EUI (EUI is the mac adress of my gateway cannot be changed) but each time i try the V3 console say that an existing gateway with the same EUI is already registred and so cannot be add to my V3 account.
it seems that the fact i removed my V2 gateway from my V2 account is not taken into account to release this gateway EUI
Do you have any idea to proceed to migration with this EUI?
thanks in advance
regards
p laurent
There may be posts from some saying delete on v2 but everywhere it will also say that’s wrong. But it’s done now.
The two databases are not linked, it’s got nothing to do with v2, it’s got to do with someone somewhere using the same EUI.
What make & model of gateway do you have - maybe it is possible to use a different EUI which is the quick fix. The slow fix is contacting the user who has the same EUI and asking them to check what they have setup.