On the other hand by running: https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttnv2,id={gatewayId} the result I get is as expected: {“netID”:“000013”,“tenantID”:“ttnv2”,“id”:{gatewayID},“eui”:{gatewayEUI},“clusterID”:“ttn-v2-eu-3”,“updatedAt”:“2021-11-18T07:09:19.602706Z”,“location”:{“latitude”:40.56475042,“longitude”:22.99399674,“altitude”:0,“accuracy”:0},“antennaCount”:1,“online”:true,“frequencyPlan”:{“region”:“EU_863_870”,“loraMultiSFChannels”:[868100000,868300000,868500000,867100000,867300000,867500000,867700000,867900000]},“rxRate”:30.508188,“txRate”:0}
Indeed it says “online: true” but apparently this happens only in the case of the v2. I can’t see any data in the applications screen of the v3 console if this is what you are meaning.
All my gateways are still in v2 console. According to the relevant guides, I have to make sure that the migration is successful before I remove the gateway from v2 because there is no way to undo this action in the future. Am I wrong about this?
Begs the question what make, model & configuration are your gateways? Are you able to remotely access them for management?
In my case I have set up >75% of my active personal GW estate in V3 already - rest should be finished next 7 to 10 days(#) and most of those are now operating fine in the new environmment (but not yet deleted from V2), however, there is a rump of GW’s that will not start operating on V3 until I either 1) physically travel to site to directly connect to the target GW and change target NS url to move from V2 to V3 (typically changing one line in code or in Management GUI depending on type for my case from e.g. router.eu.thethings.network instead to eu1.cloud.thethings.network), possiby updating any ports used depending on PF protocol or 2) travel to site or close proximity to allow to access the associated network to log in and do same as 1) or 3) remotely tunnel in over the internet (VPN or whatever) or in case of TTIG’s(#) trigger remote claiming process to effect change of config using scheduled CUPS server update (can take up to 24hrs unless GW is power cycled). So…besides doing work to migrate in the V2 & V3 consoles or via CLI how are you physically redirecting your GW’s to correct V3 server/cluster address?
(#) for several TTIGs I, and many others, still have the problem that we dont have the WiFi code saved locally (claiming code) required for claiming & migrating remotely deployed/inaccessible TTIGs as this is part of the ‘proof of ownership’ & claiming processs required by TTI - despite me or others ‘owning’ the device in V2 - ah well - bureaucracy (Fortunately, I did manage to pursuade the host of a GW deployed in Hamburg - to crawl on hands and knees into space where one was deployed and take a picture for me so I could claim/migrate remotely - dodging a near 2000km round trip Ok would never have happened it would have become abandonware…Similar story for one up in the Tyne Valley - a meer 980km round trip! )
Thank you for your response. As far as i understand I have to change manually the server address (just one line of code) from “router.eu.thethings.network” to “eu1.cloud.thethings.network” (gateways are based in Europe). The only way to do this by remotely accessing the gateway right? My gateways are based on the IMST iC880a board and I built them using a Raspberry Pi by following the known guide (see previous posts for the link).
Are they set up using e.g OpenVPN access or similar (Normal RPi OS images - Raspian etc include a VPN option - but you need to configure…) such that you can log in remotely? If not you will have to access directly and edit appropriate local_conf.json or global_conf.json files to edit server address & if needed ports, potentiall add API key etc - will all depend on what config/firmware builds & PF config you have used - sorry no time to go off following links etc. From what I have seen most users of such have followed e.g. the TTN Zurich or Technoblogy derivative builds or one of Charles Hallard’s or his Ch2i builds if not using a Pi image from actual vendor (iMST had image for their Lite GW using same board.). Many are now looking at remote solution like e.g. Balena to allow remote fleet management - but that still requires a new uSD card image loading physically into the device to get you going. TL:DR likely you need to gain physical access…
Hello again,
Unfortunately I am not the same person who setup these nodes. I took over the task of migrating all nodes and gateways from my boss. I do not know if they had enabled this option while the were building these nodes.
So I created the needed .json files with the correct server address using the relevants EUIs and now I am waiting my request to be accepted in GitHub. I believe I have exhausted all possibilities considering the fact that I have no physical access to the gateways.
If there was no file for the gateways in the repository there is little chance the installed gateway use the remote configuration method because there wouldn’t be a current configuration.
Is there no ssh access to the gateways? To migrate you don’t need physical access.
Thank you for your response!
Because gateways are located at different places around a city we are trying to get ssh access and make the needed change to the server address.
Unfortunately, there where no files in the repository for the gateways. I did a pull request 2 days ago but we are not sure that each gateway has been configured for remote configuration during setup.
Searching the forum comes up with lots of “Gateway ID on the Gateway is the Gateway EUI on the Console”
Make the config file on your Gateway have the Gateway EUI of the Gateway so it matches the Gateway EUI on the Console.
The Gateway ID on the Console is an ID for you to identify your Gateway using your own ID scheme.
If you click the “Download global_conf.json” button it will download a global_conf.json so you can see all the settings that you can copy over to your gateway.
This should be the EUI. I know it is confusing that in the LoRaWAN world we use the same name for different things but once you fill out the EUI you’re in business.
(Fortunately, I did manage to pursuade the host of a GW deployed in Hamburg - to crawl on hands and knees into space where one was deployed and take a picture for me so I could claim/migrate remotely - dodging a near 2000km round trip 
Ok would never have happened it would have become abandonware…Similar story for one up in the Tyne Valley - a meer 980km round trip! 
)