Hello again,
Thank you for your quick response! I really appreciate it. Almost 8 hours have passed and I still haven’t seen any changes. Still all 9 gateways are remaining offline in V3. What is the maximum period of time for it to be considered abnormal?
Have sometimes gone to bed after some late night hacking and transitions or new additions to find all ok in morning so I guess lots of processes sweep overnight…Eu time. Typicalmused be adding a new V2 gw that wouldn’t sometimes wouldn’t show up on community maps until next day…not sure on timing/processes for V3. If showing as disconnected in V3 are you actually seeing data coming into applications? If so take a peek at message meta data…basically if gw info says your V3 name all is good and console waiting to catch up, if it shows as PacketBroker then still coming in through V2…
Have you run https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id={gatwayID} to see what it returns while not showing on the map or the console?
This will be interesting to know.
What do you mean by offline? Is the gateway console showing the regular pings (typically about every 30 seconds)? Is it showing any traffic from devices?
Personally when I setup a gateway or start one up, I see pings (alive messages) immediately. And I pay no attention to the connection status - it’s traffic that counts.
Good morning!
Their status is remaining ‘Disconnected’ and I still don’t see any traffic in the live data screen, not even pings.
Sure!
By running: https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id={gatewayId} the result I get is the following:
{“message”:“store: not found: get gateway”}
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}
Interesting it say “online”:true
Do you see the data in the applications?
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.
The “v2” in the API have nothing to do with V2 or V3 stack.
Have you delete the gateway form v2? If you have not you have the same eui in V2 and V3
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?
Sorry a while a go I did mine.
Double check your cluster address.
https://www.thethingsnetwork.org/docs/the-things-stack/migrate-to-v3/migrate-gateways/
Is there a way to do it remotely? I have no physical access to my gateways. Actually they are located in a different city.
It is strange because I have successfully migrated one of them one month ago without even checking/changing the cluster address. Note that they are all configured years ago using this guide: How to build your own LoRaWAN gateway - Stories - Labs (thethingsnetwork.org).
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…
The software used in that guide is very old and should probably be updated. Did you choose to use the remote configuration option?
@Ioannis_K, you said previously that you had successfully migrated a gateway a month back.
Can you not replicate that same actions?
How did you manage to change the gateway address on that gateway?
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.
Thank you all for your support.